Strength of Authentication Mechanism Standard Departments and agencies must meet the requirements specified in this standard in order to achieve a specified strength of authentication mechanism under the National e-Authentication Framework (NeAF.) Keywords: Authentication, IDAM, NeAF. Identifier: IDAM STD 03 Version no.: 1.0 Status: Final Issue date: 30 November 2013 Date of effect: 1 January 2014 Next review date: 1 July 2015 Authority: Victorian Government CIO Council Issuing authority: Victorian Government Chief Technology Advocate Exemptions – Any exemptions to this standard must be reported to departmental / agency governance bodies. Except for any logos, emblems, trademarks and contents attributed to other parties, the policies, standards and guidelines of the Victorian Government CIO Council are licensed under the Creative Commons Attribution 3.0 Australia License. To view a copy of this license, visit http://creativecommons.org/licenses/by/3.0/au/ Overview The National e-Authentication Framework (NeAF) has been developed as a national framework, addressing the needs of Commonwealth, State, Territory and local government agencies and has been ratified by the Ministerial Online and Communications Council. The scope of NeAF covers two aspects of authentication: electronic authentication of the identity of individuals and businesses; and authentication of government websites. Central to the framework is the concept of assurance levels. An assurance level is determined through a comprehensive risk assessment process to determine the severity of the impact of getting eauthentication wrong. The focus is on answering the question: Do we have the correct party at the other end of the line – i.e. are they who they purport to be? To determine an agency’s assurance level and authentication requirements, the NeAF provides: A standardised set of (five) e-authentication assurance levels and a recommended set of criteria for determining the level of assurance required for a particular e-transaction. A standardised approach to determining the e-authentication solution required to satisfy the eauthentication assurance level, including registration approaches, and e-authentication mechanism alternatives. Requirement Unless a risk assessment determines otherwise, departments and agencies (referred to collectively as ‘agencies’ hereafter) are required to select authentication mechanisms (i.e. credentials and processes for the management of credentials) which are consistent with the levels of strength specified in this standard. The minimum strength of authentication mechanism for access to Victorian Government (VG) infrastructure or systems is Authentication Assurance Level (AAL) 2/One Factor Authentication (1FA), typically a UserID plus a memorised password. Higher strength authentication mechanisms are required wherever a NeAF risk assessment requires it and or ensures alignment to current ISMF. Privileged access to any system must always use at least AAL3/Two Factor Authentication (2FA). Overview This standard specifies the strength of authentication mechanisms, as required to support IDAM STD 01 Identity and Access Management, which mandates the use of NeAF for VG identity and access management (IDAM) initiatives. As described in the NeAF documentation, the strength of an authentication mechanism is dependent on the type of credential, and the management and usage of the credential. Standards for credentials and their management are provided in Table 1. Table 1: Strength of Authentication Mechanism Mechanism NeAF AAL 0 NeAF AAL 1 NeAF AAL 2 NeAF AAL 3 NeAF AAL 4 Credential None One Factor user authentication (1FA) One Factor user authentication (1FA) Two Factor user authentication (2FA) Two Factor user authentication (2FA) plus transaction authentication and non-repudiation UserID plus memorised password. UserID plus memorised password. User ID plus one-time password (OTP) provided by out-of-band channel, accessed by a PIN or password e.g. Identity does not need to be real (pseudonymous registration is acceptable) The identity is real and validated PKI-based: User ID plus private asymmetric key and public asymmetric certificate stored on a PIN-protected smartcard. Secure SMS Token (mobile phone) OR Secure Physical Token (aka. Hard Token) Credential Management for VG staff None. None. The minimum strength of authentication mechanism for access to VG networks or systems is AAL2/One Factor Authentication (1FA), namely a UserID plus a memorised password. The UserID must meet the requirements specified in IDAM STD Privileged access to any VG system must always use at least AAL3 two-factor authentication. As per requirements below. None specified. 15 User Authentication – Network Login Naming. Credential Management for ALL users (including VG Staff) None. The password must meet the requirements specified in the ISM for the G (Government systems) level, including: Agreeing to the terms and conditions of use of passwords. Using initial passwords. Using strong passwords. User protection of passwords. System management of passwords. Management of user sessions. Account blocking and password resetting. Management of user accounts. For all credentials, the password must meet the requirements specified in the ISM for the G (Government systems) level, including: Agreeing to the terms and conditions of use of passwords. Using initial passwords. Using strong passwords. User protection of passwords. System management of passwords. Management of user sessions. Account blocking and password resetting. Management of user accounts. Audit logging. The management requirements for Secure SMS Token are: Mobile phones that receive SMS OTPs must not be granted access to the systems that the OTPs are issued for. The mobile phone used for OTP must be pre-registered and linked to the identity of the user. As part of registration of the phone, the PIN must be changed to at least 6 digits. If a phone is lost it must be reported so that it can be invalidated. The OTP must be random, at least 8 digits, and be valid for a finite time (no more than 2 minutes.) Users must physically protect their phone from theft or physical abuse, and protect their PIN using relevant ISM guidelines for protecting passwords. The management of PKI-based smartcard credentials is based on Gatekeeper High Assurance requirements: The keys must be generated using a Hardware Security Module (HSM) on ASD’s Evaluated Products List (EPL) Credential delivery must use a secure channel with evidence of receipt. When delivered credentials must be locked. Locked credentials must require a single use, credential-specific unlock code to reset PIN. Credentials must be renewed at every 2 years Compromise of credentials must be reported immediately so the certificate can be revoked. Revoked credentials must be listed in a Certificate Revocation List (CRL) within 1 hour of an authenticated request by the user. All lifecycle and authentication events must be logged. Logs must be cryptographically protected against Audit logging. Sufficient audit logging to investigate security breaches must be provided. The management requirements for Secure Physical Token are: Tokens must only be distributed in a disabled state, and must be enabled after receipt by the correct user. PINs and token codes must be a minimum of 6 digits in length. Authentication must be based on time-based one time token codes that change at a set interval, which must be no longer than two minutes. Users must physically protect their hard token from theft or physical abuse, and protect their PIN using the relevant guidelines in the ISM for protecting passwords. If a hard token is lost it must be reported so the related token can be invalidated. Sufficient audit logging to support investigation of security breaches must exist. modification, deletion and addition, and retained for 7 years. They are an amalgam of the credentials available to, or in use by, VG agencies: o UserIDs and passwords; o hardware tokens, and o one-time passwords (OTPs) via mobile phone, the processes typically used for the management and usage of the credentials in VG departments and agencies, and the NeAF strength of credential tables in NeAF Schedules B1 (Credential Type) and B2 (Credential Management and Usage), and the Gatekeeper High Assurance requirements. The NeAF Assurance Level for the person/ role is determined by the process described in IDAM GUIDE 01. Once the Assurance Level is known, an appropriate authentication mechanism can be selected. As a general guide, NeAF Assurance Levels require a minimum credential type as follows: NeAF Authentication Assurance Level 0 (AAL 0) does not require any form of authentication. NeAF Authentication Assurance Level 1 (AAL 1) represents single factor authentication (1FA) where the identity does not need to be real (i.e. pseudonymous registration is acceptable.) NeAF Authentication Assurance Level 2 (AAL 2) represents single factor authentication (1FA) where the identity is real and validated. NeAF Authentication Assurance Level 3 (AAL 3) represents two factor authentication (2FA) i.e. a stronger form of user authentication. NeAF Authentication Assurance Level 4 (AAL 4) represents a form of two factor authentication which not only authenticates the user it also authenticates the user’s electronic transaction, and provides non-repudiation for the electronic transaction. It is not yet in use in VG agencies, but a Gatekeeper High Assurance PKI would meet this requirement (see the AGIMO web site). Rationale Agencies need to select an authentication mechanism of sufficient strength to meet the requirements of a specified NeAF Authentication Assurance Level (AAL). To meet this need, this standard specifies the strength of the most likely VG authentication mechanisms. Derivation The derivation of this standard is based on: SEC STD 01 Information Security Management Framework IDAM STD 01 Identity and Access Management National e-Authentication Framework, AGIMO Gatekeeper High Assurance Certificates, AGIMO Scope The use and adaptation of VG ICT policies, standards, guidelines and other supporting material is open to all, under the appropriate Creative Commons license of the document in question. Use of VG ICT policies and standards is mandated to: all VG departments Victoria Police VicRoads State Revenue Office Environment Protection Authority Public Transport Victoria Country Fire Authority State Emergency Services Ambulance Victoria Emergency Services Telecommunications Authority Metropolitan Fire and Emergency Services Board CenITex The policy applies to all VG IDAM activities, including but not limited to, users that are VG staff and external users of VG networks or systems including consumers, citizens, customers, vendor/ service supplier staff, and (where relevant) the organisations they are associated with. Where applicable, legal and or regulatory compliance obligations take precedence over this policy and related standards. Agencies may have additional legal and or regulatory information protection compliance requirements. Examples include (but are not limited to) Victoria Police and the Commissioner for Law Enforcement Data Security (CLEDS), credit card processing contract obligations of the Payment Card Industry Data Security Standard (PCI DSS) and the Information Privacy Act 2000. Compliance Timing: From the date of effect on the front of the document. Reporting: Reporting of compliance with VG IDAM standards will be via the annual VG ISMF reporting as required by VG SEC STD 01. Guidelines, toolkits and references National e-Authentication Framework (NeAF) http://www.finance.gov.au/policy-guides-procurement/authentication-and-identitymanagement/national-e-authentication-framework/ Australian Government Information Security Manual (ISM): http://www.dsd.gov.au/infosec/ism/index.htm VG IDAM Policy and Standards http://www.enterprisesolutions.vic.gov.au/business-systems/identity-and-access-management/ VG Information Security Policy and standards: http://www.enterprisesolutions.vic.gov.au/business-systems/information-security/ AAL 4 PKI based solutions: See Gatekeeper High Assurance Certificates: http://agimo.gov.au/policy-guides-procurement/gatekeeper-public-keyinfrastructure/gatekeeper-documentation/ Further information For further information regarding this standard, please contact enterprisesolutions@dpc.vic.gov.au. Glossary Term AAL Authentication Credential IDAM NeAF Non-repudiation One time password (OTP) Public Key Infrastructure (PKI) Strong password Meaning Authentication Assurance Level – a level of assurance set by the Australian Government National e-Authentication Framework (NeAF.) The process that delivers a Level of Assurance of the identity of an entity (person or organisation.) The technology used to authenticate a user's identity, including a password, cryptographic key or other form of secret. Identity and access management National e-Authentication Framework Evidence, verifiable by a third party, that a transaction has been sent/ authorised by the purported sender. A password that is valid for only one login session or transaction. The combination of hardware, software, people, policies and procedures needed to create, manage, store and distribute Keys and Certificates based on public key cryptography. A password complying with the passphrase requirements specified in the ISM. Version history Version 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 Date 12 February 2013 14 February 2013 18 February 2013 21 February 2013 12 March 2013 22 April 2013 June 2013 Oct 2013 26 November 2013 30 November 2013 Details Initial structure of document/tables only DTF updates to structure/tables First draft with fully populated tables First draft released to ISAG IDAM subgroup for review Final draft released to ISAG IDAM subgroup for review Updated with feedback from ISAG Feedback from ISAG working group Additional feedback from ISAG working group Final review and checking of dates, links, Submission to CIO Council