6. Using the Authentication Standards

6.1 General

The full suite of the NZ e-GIF authentication standards is designed to enable agencies to undertake the following processes:

1. Determine service risk categories (Evidence of Identity Standard)

2. Determine evidence of identity confidence levels (Evidence of Identity Standard)

3. Determine authentication keys and protections (Authentication Key Strengths Standard)

4. Manage identity-related data (Data Formats for Identity Records Standard)

5. Implement authentication keys and protections (Password Standard, and other authentication key standards when developed)

6. Communicate security assertions (New Zealand Security Assertion Messaging Standard).

As indicated in 3.5, where agencies adopt one or more of the shared services, they can have confidence that the standards relating to the functions of those services will be implemented.

The way in which the authentication standards support the initial establishment and ongoing confirmation of identity is shown in Figure 2.

Figure 2 - Authentication standards

6.2 Determine service risk categories

Determining the level of identity-related risk associated with any given service is essential for ensuring that appropriate evidence of identity processes and authentication keys are implemented. Refer to section 3.3 of the Evidence of Identity Standard.

Some services have no or negligible identity-related risk associated with them. These services do not require the implementation of evidence of identity processes or authentication keys. Other services require evidence of identity processes and authentication keys. The level of confidence required for evidence of identity processes and authentication keys will vary depending on the level of identity-related risk contained in the service. In general, services with higher levels of identity-related risk require more comprehensive and stringent evidence of identity processes and more secure authentication keys.

The Evidence of Identity Standard defines four levels of identity-related risk for services (Nil or Negligible, Low, Moderate, and High). These levels are adapted from the US Federal Office of Management and Budget's E-Authentication Guidance for Federal Agencies.

The level of identity-related risk is determined by analysing the range of consequences that can occur if a particular agency service is provided to an individual who claims an identity that is not their own. This risk is assessed using the Australian/New Zealand Standard Risk Management (AS/NZS 4360:2004) and associated Risk Management Guidelines (SAA/SNZ HB 436:2004) and Information Security Risk Management Guidelines (SAA/SNZ HB 231:2004).

Table 2 outlines four service risk categories.

Table 2 - Service risk categories

6.3 Determine evidence of identity confidence levels

Determining an appropriate level of confidence for a service's evidence of identity process is essential for minimising the likelihood of incorrectly establishing an individual's identity. Refer to 3.4 of the Evidence of Identity Standard.

The Evidence of Identity Standard (Table 8) defines three levels of confidence for evidence of identity business processes corresponding to the Low, Moderate, and High service risk categories.

As outlined, agencies SHOULD assess the level of identity-related risk for each service delivered by a particular agency. Each risk level corresponds to a level of confidence required by the agency in establishing the individual's identity. This will, in practice, determine the level of documentation and associated business processes required to give the appropriate level of confidence in the person's identity.

Table 3 outlines the evidence of identity confidence levels required for each service risk category.

Table 3 - EOI confidence levels required for service risk categories

NOTE -

(1) The Evidence of Identity Standard applies to all services, regardless of whether they are delivered online or offline.

(2) Section 3.4 of the Evidence of Identity Standard is an alternative to the IVS. Where an agency uses the IVS, it need not implement this section of the Evidence of Identity Standard .

6.4 Determine authentication keys and protections

The type of authentication key and its associated protections directly affect the security of ongoing confirmation of identity across the Internet. Refer to the Authentication Key Strengths Standard.

The Authentication Key Strengths Standard defines four types of authentication key - passwords, one-time password, software tokens, and hardware tokens - and maps these, together with their protections, to the service risk categories from the Evidence of Identity Standard.

These definitions and the mapping are adapted from the US National Institute of Standards and Technology's Electronic Authentication Guideline.

Table 4 outlines the minimum authentication keys required for each service risk category.

Table 4 - Minimum authentication keys required for service risk categories

Table 5 summarises the mapping of service risk categories to evidence of identity processes and authentication keys.

Table 5 - Summary of service risk categories, EOI confidence level and authentication keys

NOTE -

(1) Agencies may support the use of a higher strength key for confirmation of identity than specified in Table 5, providing use of the higher strength key by service users is optional.

(2) This mapping was developed in the context of the following principles:

• Risk-based - a risk management-based approach is required to determine the level of identity-related risk associated with a service.
• Equivalency - the level of confidence required for both components of an authentication solution (establishment and ongoing confirmation) should be comparable.
• Proportionality - the level of confidence required for both components of an authentication solution should be comparable to the identity-related risk of the service.
• Proven technology - authentication keys used by agencies should have a credible implementation history.
• E-government maturity - it is appropriate to drive standardisation of authentication solutions.
• Future-facing - some online services will need upgrading to a more appropriate level, yet this need only happen when agencies upgrade existing systems.

6.5 Manage identity-related data

After establishing the identity of service users, agencies need to manage that identity information. The Data Formats for Identity Records Standard specifies data formats for a set of identity-related data elements that agencies may capture in their customer records.

Use of this Standard will enable agencies to exchange data with other agencies more effectively and efficiently under privacy-compliant agreements. The Standard will also assist agencies to develop functional requirements for identity management systems, thus enabling streamlined Request for Proposal (RFP) processes, which will help vendors to develop consistent customer management system solutions for agencies.

The Standard conforms to the Customer Information Quality (CIQ) v3.0 Specifications, an XML-based standard developed by the Organization for the Advancement of Structured Information Standards (OASIS), which defines a vocabulary to represent customer attributes, including name and address.

The following identity-related data elements from the CIQ v3.0 Specifications are specified in the Standard:

• person's name
• gender
• mother's name
• date of birth
• place of birth.

NOTE -

(1) Agencies may choose to use only a subset of the identity-related data elements specified in the Data Formats for Identity Records Standard . Alternatively, agencies may choose to use identity- related data elements not specified in the Standard.

(2) This Standard requires that, where agencies exchange these identity-related data elements, they do so using the specified data formats. However, agencies may choose to use these data formats to store these data elements.

6.6 Implement authentication keys and protections

While the Authentication Key Strengths Standard outlines the acceptable authentication keys for each service risk category, further standards are required to define the security requirements for each of these authentication keys. This is because authentication keys have different security properties in terms of their strength against attacks. This is true even for a single type of authentication key. For example, a password could be a simple four-digit access code or a system-generated random alpha-numeric character string over ten characters long. The security requirements defined for each authentication key are consistent with the Government's security policy (Security in the Government Sector) and the security-related guidance issued by the Government Communications Security Bureau.

The Password Standard defines the requirements for passwords under the following headings:

• association of passwords
• using higher-level authentication keys
• customer advice and responsibilities
• password construction
• password management
• session logout
• access management.

Further information on multi-factor authentication is contained in the document Guidance on Multi-factor Authentication. Standards specifying other authentication keys, such as one-time password generators and software tokens, will be developed as required. Guidance on Multi-factor Authentication may be superseded once further authentication key standards are developed.

NOTE - Authentication key-specific standards are an alternative to the GLS. Where an agency uses the GLS, it need not implement any of the authentication key standards.

6.7 Communicate security assertions

Communication of standardised messages that confirm the identity of parties (assertions) is essential for the delivery of authenticated online services supplied by independent agencies acting in concert. For example, where the provider of an authentication key is separate from the provider of an online service (e.g. the GLS), standardised messages between both providers are essential to initiate and complete the confirmation of identity process. Refer to the New Zealand Security Assertion Messaging Standard (in preparation).

The Standard conforms to the Security Assertion Markup Language (SAML v2.0), an XML-based standard developed by the Organization for the Advancement of Structured Information Standards (OASIS), which defines messages for communicating a range of security-related statements about individual parties, including their authentication.

A range of SAML v2.0 profiles for authentication-related assertions that are required by agencies will be included in this Standard. These profiles have been selected to support the New Zealand Government's generic 'usage pattern' for security assertion messaging and will enable agencies to address the following technical issues:

• non-interoperability of identity management applications
• confidentiality and integrity of machine/application-based messages
• limitations of browser-based cookies.

It is envisaged that the Standard will, over time, also incorporate messages communicating assertions relating to authorisation and identity attributes, as well as authentication.

A general introduction to security assertion messaging, the Security Assertion Messaging Framework, has also been developed.

[ Previous ] [ Next ]