Strength of Authentication Mechanism

advertisement
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
Download