Application of this standard

This standard applies to any Relying Party (RP). The RP is accountable for the controls stated in this standard, even if they have employed or contracted aspects to other parties.

Application of the controls in this standard will contribute to the reduction of identity fraud by reducing the ability for unauthorised entities to gain access to the information and entitlements belonging to an enrolled entity.

The scope of the requirements in this standard is explicitly related to the use of Authenticators and the process of authentication. It does not include considerations for security, messaging methods, or other implementation matters.

Effective date

This standard is effective from 1 October 2024 and replaces the earlier version.

Version 2 (current version) — incorporates the controls from the Binding Assurance Standard relating to binding consistency and control of Authenticators by Entities, regroups and reorders controls and makes some simplifications.

Version 1 (effective 1 March 2021) — first published version of the Standard

Historic versions of the Identification Standards — Department of Internal Affairs

The Authentication Assurance Standard replaces the:

• Authentication Key Strengths Standard, Version 1.0 (published June 2006) and subsequent amendments
• Password Standard, Version 1.0 (published June 2006) and subsequent amendments, for organisations not subject to compliance with the New Zealand Information Security Manual.

Scope

This standard applies whenever a RP needs to ascertain that the current request is being made by the original entity — in other words, that the returning entity is the same entity that was initially enrolled.

Steps to detect unauthorised authentication events using analytics and behaviour measures that are not part of an Authenticator, are outside the scope of this standard.

In relation to the scope of Identification management, this standard relates to the strength of the Authenticator, as indicated in diagram 1.

Detailed description of diagram

This diagram shows a triangle representing the connection between Entity (in this example, represented by a person) at the top of the triangle, Authenticator (represented by a key) at the bottom left, and Entity Information (represented by files of information) at the bottom right.

The connection between Entity and Entity Information is labelled Entity Binding. The connection between Entity Information and Authenticator is labelled Authenticator Registration. The connection between Authenticator and Entity is Authenticator Control.

There is a red circle around Authenticator, Authenticator Control and Authenticator Registration to indicate the scope of the content of this standard in relation to the other elements.

View larger image (PNG 75KB)

Relationship with other identification standards

Assurance components

Table 1 describes each of the assurance components and the processes they relate to. This standard addresses the third of these assurance components — Authentication Assurance.

Before applying this standard

Authenticator types

Interpretation of this standard assumes a strong understanding of the 3 authentication factor types:

• something the Authenticator holder knows — knowledge factor
• something the Authenticator holder has — possession factor
• something the Authenticator holder is or does — biometric factor

along with good knowledge about the characteristics of the entities to whom the service or transaction has been offered. See guidance in Authenticator Types.

Some articles discuss including somewhere the Authenticator holder is — location factor — as a separate factor. Currently there is insufficient reason to support this being recognised as separate from something the authentication holder has. ‘Authenticator holder’ refers to the entity to which the Authenticator was first bound, the rightful holder.

The forthcoming guide to Implementing Authentication Assurance groups single factor Authenticators and two-factor combinations into categories to provide an easy selection guide of known Authenticators against required levels of authentication assurance.

Assumptions

The following assumptions have been applied for the development of this authentication assurance standard.

• For practical purposes, an Authenticator will normally be paired with an identifier that enables look-up of corresponding entity information. This standard assumes an authentication challenge will be a one-to-one comparison (not one-to-many).
• Combining 2 or more authentication factors of the same type can add some additional strength in mitigating a threat but does not reduce the overall risk. The authentication assurance strength is determined by the best instance of the authentication factor type.
• Authentication combining 3 different authentication factors is possible, but the extra effort does not significantly improve on the strength obtained by the 2 strongest factors.

Document structure

This standard divides requirements into 2 sections:

• Requirements for Authentication – These controls apply regardless of the Authenticators used.
• Requirements for Authenticator strength by factor – These controls will be applied depending on the type of authentication factors the Authenticators use.

Requirements for Authentication

Objective 1 — Authentication risk is understood

Rationale

For entities to trust that their information is being adequately protected from unauthorised access and use, the authentication level should be consistent with the risk posed.

Relying parties may also need to achieve specific levels of assurance to mitigate risks and potentially to comply with legislation.

AA1.01 Control

The RP MUST carry out an assessment of the authentication risk posed by any service before offering it.

Additional information — While any risk assessment process can be used, specific guidance is available on Assessing identification risk, of which authentication is a part.

Objective 2 — Ensure correct Authenticator holder behaviour

Rationale

Under normal conditions most Authenticator holders will act appropriately, and directive controls can be relatively effective. Penalties can also discourage incorrect behaviour.

However, Authenticator holders might not initially be aware of their obligations, so these need to be communicated. Over time, understanding may diminish, and ongoing reminders may be appropriate.

At the higher levels of assurance, two-factor authentication helps enforce correct behaviour, so too does detecting behaviour that is not normal in the authentication process.

The RP needs to support correct behaviour by providing the means for the Authenticator holder to report loss or compromise of an Authenticator and appropriately manage the loss of control.

AA2.01 Control

The RP MUST issue terms and conditions describing the authenticator holder’s obligations, including:

• the Authenticator is for the sole use of the Authenticator holder
• explaining how the holder will keep the Authenticator safe
• that the holder reports loss of the Authenticator including unauthorised use, sharing, theft of the Authenticator, possible compromise, or any other suspected loss of control of the Authenticator.

Additional information — Examples of expected behaviours:

• an access card should not be shared with another employee
• a passport should remain in the traveller’s possession
• or a device provided by the Authenticator holder (such as a mobile phone) can only be used as an Authenticator when it’s individually possessed and used by the holder.

AA2.02 Control

The RP MUST provide communication to Authenticator holders reminding them about their obligations, including:

• the Authenticator is for the sole use of the holder
• the holder will keep the Authenticator safe
• that the holder reports loss of the Authenticator including unauthorised use, sharing, theft of the Authenticator, possible compromise, or any other suspected loss of control of the Authenticator.

AA2.03 Control

The RP limits the ability to share an Authenticator by implementing 2 different factor types.

For level 1 and 2 — This control does not apply.

For level 3 — The RP MUST undertake this control.

For level 4 — The RP MUST undertake this control using a biometric factor as 1 of the factors.

AA2.04 Control

The RP allows no more than 30 consecutive unsuccessful attempts to authenticate by any factor, disables the account and triggers further investigation.

For level 1 and 2 — This control does not apply.

For level 3 — The RP SHOULD apply this control.

For level 4 — The RP MUST apply this control.

Additional information — This control limits the total attempts by an attacker for any single challenge or combination of challenges of more than 1 authentication factor type. This upper limit applies to prevent multiple attempts that are only partially mitigated by subsequent controls such as the 30-minute timeout after a maximum of 5 incorrect attempts.

Where appropriate to the implementation, the RP MAY allow up to 3 re-entries for the same challenge attempt, for example the same received code for the code receiver method.

AA2.05 Control

The RP MUST provide the means for the holder to report loss or compromise of an Authenticator, and can either:

• deregister the Authenticator and support a process for reregistration; or
• if appropriate, close the associated account and require reenrolment.

Additional information — Where a biometric factor is used and compromise was not prevented by presentation attack detection, disabling needs to include deregistering as the biometric characteristic cannot be revoked.

Objective 3 – Entity binding and Authenticator strength are consistent

Rationale

An Authenticator can be established during enrolment or later during a subsequent transaction. In either case it is essential to ensure that the Entity has been bound to the Entity Information at the required level of assurance before attempting to bind an Authenticator.

If there has been a disruption in the binding transaction this will necessitate repeating Entity Binding when the transaction is resumed.

AA3.01 Control

The RP MUST ensure that the Entity Binding is done in the same transaction session as the Authenticator is established.

Additional information – An Authenticator is not always issued when Entity Information and Entity Binding occur. If the implementation has the establishment of an Authenticator occurring in a separate transaction, a temporary Authenticator can be used to represent the Entity Binding process having previously been undertaken, providing they have the same level of assurance and this is the same or higher than the Authenticator. If the Authenticator being established is for a new delivery channel an existing Authenticator may be presented to confirm Entity Binding, provided it has an equal or greater level of assurance.

AA3.02 Control

The RP MUST ensure the strength of the Authenticator is consistent with the level of binding assurance (BA) required.

Additional information – Any strength perceived to be gained by using an Authenticator of a higher level of assurance is negated when the corresponding Entity Binding assurance is lower.

Objective 4 - Entity can control Authenticator

Rationale

Associating an Authenticator with Entity Information without first ensuring that the Entity has control of it, can result in an inability for it to be used by the Entity in a future Authentication event or increases the risk of coercion and impersonation.

AA4.01 Control

The RP MUST ensure that the Entity can respond to all the Authenticator’s challenges before the Authenticator is recorded as active in Entity Information.

Additional information – Depending on the implementation there may be a need to record the existence of the Authenticator in Entity Information before the challenges can be tested. However, the Authenticator will not be available as a recognition mechanism until successful completion of the challenges.

AA4.02 Control

The RP establishes if the Authenticator has been previously compromised to the extent it makes it unusable.

For level 1 and 2 – The control does not apply

For level 3 – The RP SHOULD check for compromise with Authenticator issuers or equivalent service providers.

For level 4 – The RP MUST check for compromise with Authenticator issuers or equivalent service providers.

Objective 5 - Authenticator registration status is maintained

Rationale

Authenticators have lifecycles distinct from the Entity and Entity Information. Authenticators can be reused in multiple contexts, therefore connected to different instances of Entity Information. The Authenticator Registration status provides information to the Authentication process as to whether an Authenticator should be accepted, even if the responses to challenges are successful. Typical statuses can include: active, suspended, expired and revoked.

AA5.01 Control

The RP MUST record enough information in Entity Information for an Authenticator to be recognised and its Authenticator Registration status to be managed.

AA5.02 Control

The RP MUST be able to update the Authenticator Registration status to prevent authentication occurring, even if the responses to challenges are successful.

AA5.03 Control

The RP MUST NOT accept an Authentication event as successful unless the Authenticator Registration status allows.

AA5.04 Control

The RP MUST be able to set an expiry on an Authenticator Registration where the implementation indicates this to be desirable.

Objective 6 – Authentication events can be investigated

Rationale

An important element of trust in any identification process is the ability for an Entity or Relying Party to question a process or presentation. 

AA6.01 Control

The RP MUST record appropriate detail about the Authenticator establishment process to enable queries or investigation in the future.

AA6.02 Control

The RP MUST store appropriate detail about an authentication event to enable queries or investigation in the future.

Requirements for Authenticator strength by factor

Objective 7 — Protect knowledge factor response from being guessed or discovered

Rationale

An unauthorised entity can obtain control of a knowledge factor by providing the response that the challenger expects. This threat is most significant when the expected response is static, as once obtained it can be used for multiple authentications. If an expected response is dynamic, then the correct initial response cannot be reused for a subsequent authentication.

Widespread attacks across many Authenticators utilise some form of guessing which may follow sequences, patterns, lists such as dictionaries, or similar techniques.

Targeted attacks on a few Authenticators may utilise some form of discovery to obtain the possible correct responses such as manipulating the holder into disclosing the response or using a list of previously compromised list secrets or the underlying key used to generate a response.

Limiting the number of unsuccessful attempts within a time period is an effective way of controlling automated guessing attacks.

These controls apply where a knowledge factor is used. The controls for replicating the codes related to non-physical challenges on possession factors are covered under Objective 5.

AA7.01 Control

The RP implements minimum levels of complexity on any knowledge factor response (secret).

For level 1 and 3 — The RP MUST require a minimum complexity of 4 numeric characters or utilise an equivalent level of complexity for responses such as swiping points, matching pictograms, etc.

For level 2 and 4 — The RP MUST require a minimum complexity of:

• 12 characters; or
• 7 characters from at least 3 of the lower case, upper case, numeric and symbol character sets; or
• an equivalent level of complexity for responses such as swiping points, matching pictograms, security questions, etc.

Additional information — Upper limits on characters should be set high enough to encourage the use of memorable phrases.

AA7.02 Control

The RP limits the creation of easily guessable knowledge factor responses by disallowing repetition or patterns and where the Authenticator has the form of an online password, apply the following exclusions (as applicable to the character sets being used):

• disallow repetitive or sequential characters
• disallow specific words, for example the identifier (for example, username), name of the service etc.
• disallow singular dictionary words and common character substitutions
• disallow passwords contained in blacklists (usually include overly common combinations and compromised passwords).

For level 1 and 3 — The RP SHOULD undertake this control.

For level 2 and 4 — The RP MUST undertake this control.

Additional information — These controls are best implemented using a strength meter during knowledge factor establishment.

AA7.03 Control

The RP implements maximum limits for unsuccessful attempts and prevents further attempts for a minimum period.

For level 1 — The RP SHOULD limit unsuccessful attempts to 10 and further attempts for 15 minutes minimum.

For level 2 and above — The RP MUST limit unsuccessful attempts to 5 and disallow further attempts for 30 minutes minimum.

Additional information — In some circumstances, it may be reasonable for the RP to rely on the time and effort taken to provide a response — such as entering a PIN code, as a default control against guessing.

AA7.04 Control

The RP prevents use of a guessed or discovered knowledge factor by combining it with an authentication factor of another type.

For level 1 and 2 — This control does not apply.

For level 3 — The RP MUST undertake this control.

For level 4 — The RP MUST undertake this control using a biometric factor as the second factor.

Additional information – While at level 4 this objective could be met by combining a knowledge factor with a possession factor, it has been restricted to a biometric factor to be consistent with the need for that combination in other level 4 controls. 

Objective 8 — Prevent use of a physically acquired possession factor

Rationale

An Authenticator may be compromised by being physically acquired by someone else.

Possession factors can be acquired by another entity as occasional unauthorised usage or permanent theft.

Where a possession factor is a physical item, the Authenticator holder can become aware that it has been stolen. Requirements for non-physical challenges on possessions and biometric characteristics are covered under Objective 5.

This control applies where a possession factor is used.

AA8.01 Control

The RP prevents use of a physically acquired possession factor by combining it with an authentication factor of another type.

For level 1 and 2 — This control does not apply. Controls in Objective 2 serve.

For level 3 — The RP MUST undertake this control.

For level 4 — The RP MUST undertake this control using a biometric factor as the second factor.

Additional information — This objective could be met by combining a possession with a knowledge factor. However, the level 4 requirement has been restricted to a biometric factor to be consistent with the need for this combination in other level 4 controls.

Objective 9 — Protecting against replication, forgery, or spoofing of possession and biometric factors

Rationale

Authenticators need to be protected against replication, forgery or spoofing by an attacker including the ability to provide the expected static response or 1 or more dynamic responses.

Knowledge-based Authenticators have been covered in Objectives 3 and 4.

Threats against possession-based Authenticators can take the following forms:

• replication or forgery of documents or devices that must be physically presented for manual or automated challenge
• replication of the codes (static or dynamic) used to respond to non-physical challenges on possession of a document, device or software
• replication of the value that represents existence in a specific location.

The RP needs to ensure that Authenticators based on biometric factors are protected against presentation by another entity (spoofing), including the construction of the expected static response, cloning of 1 or more live responses, or the means to produce all expected live responses.

Some level of protection is provided due to the effort required to undertake successful replication or forgery of a possession factor or spoofing of a biometric.

The requirement for two-factor authentication that protects against physical acquisition at higher levels of assurance also mitigates replication of the expected responses to possession factor challenges.

These controls apply where possession and biometric factors are used.

AA9.01 Control

The RP MUST protect against replication or forgery of a physically presented Authenticator by incorporating features that ensure the cost of doing so is relative to the level of assurance.

AA9.02 Control

The RP uses dynamic, non-predictable responses to non-physical challenges on possession factors and limits the response validity to a maximum of 10 minutes or 1 minute, where little messaging delay exists.

For level 1 — The RP MAY undertake this control.

For level 2 and above — The RP MUST undertake this control.

Additional information — The limits need to be sufficiently short to reduce malicious reuse and sufficiently long to be useable by the holder. They can be influenced by the holder group (for example, technologically savvy versus challenged) and the type of Authenticator (for example, code receiver versus code generator).

AA9.03 Control

The RP MUST, for responses to non-physical challenges on possession factors, utilise a minimum complexity of:

• 6 numeric characters; or
• 4 alphanumeric characters; or
• an equivalent level for other codes such as pictograms.

Additional information — For usability or avoidance of inappropriate words, some alphanumeric characters MAY be restricted when generating the received codes.

AA9.04 Control

The RP addresses spoofing of biometric challenges by ensuring the biometric response is obtained from the person using appropriate measures to detect spoofing attempts (for example, recordings, masks, makeup or prosthetics etc.)

For level 1 — The RP SHOULD undertake this control.

For level 2 and above — The RP MUST undertake this control.

Additional information — This control can also help reduce the occurrence of false acceptance of biometric comparisons when spoofing attempts are successfully recognised.

AA9.05 Control

The RP obtains biometric factor samples in person or remotely incorporating liveness checking which demonstrates at least 90% resistance to presentation attacks.

For level 1 to 3 — This control does not apply.

For level 4 — The RP MUST undertake this control.

Additional information — Manual collection of biometric samples in person is comparable if not superior, to automated collection. Current best minimum practice for resistance to presentation attacks using technology is the use of Clause 12 of ISO/IEC 30107-3.

Objective 10 — Managing biometric factor probability

Rationale

Biometric characteristics suitable for authentication are substantively unique to individual entities. Therefore, an Authenticator with a biometric factor challenge is potentially a more reliable means of authenticating a specific entity than a knowledge or possession factor. However, unlike the other 2 factor types, a biometric response is probabilistic rather than binary.

There remains the possibility that a manual or systematic comparison will incorrectly match a biometric response from another entity with that of the enrolled entity, resulting in a false positive response to the challenge.

At lower levels of assurance, false positives for a biometric factor challenge should be less than the unmitigated risks for knowledge or possession factor challenges.

There are no additional controls for the lower levels and the RP will need to accept that a small proportion of false positive results may be received.

For higher levels of assurance, an Authenticator with a biometric factor needs to have a very low false positive rate and be used in combination with another authentication factor to protect against the statistical possibility of incorrect authentication.

AA10.01 Control

The RP reduces the occurrence of false positives in biometric comparisons by using:

• manual comparison of the biometric characteristic by a trained operator
• systematic comparison with a rate of <0.01% false positives, based on a one-to-one comparison.

For level 1 and 2 — This control does not apply

For level 3 — The RP MUST undertake the control using 1 of the ways stated

For level 4 — The RP MUST use systematic comparison.

Additional information — At level 4 manual comparison may be used, however, it needs to be supported by systematic comparison.

AA10.02 Control

The RP protects against the probabilistic nature of biometric comparisons by combining it with an authentication factor of another type.

For level 1 and 2 — This control does not apply.

For level 3 — The RP MUST undertake this control, when using manual comparison.

For level 4 — The RP MUST undertake this control.

What compliance means

These requirements are provided as good practice for any RP wishing to contribute to the prevention of identity theft and fraud.

Compliance with this standard will be given through means such as contractual requirements, cabinet mandate, legislation etc., which will include mechanisms for assessment and certification.

In order to comply with this standard, an RP needs to meet all the applicable controls for the selected level of authentication assurance.

Applicable controls are determined by the authentication factor(s) used in the Authenticator.

In general:

• LoAA1 can be achieved using a single factor Authenticator with few controls
• LoAA2 using a single factor Authenticator with some additional controls
• LoAA3 using a good biometric factor or combining 2 different factor types in the Authenticator
• LoAA4 using 2 different factor types where 1 is a biometric factor implemented with liveness checking.

Related advice

If the RP is providing authentication assurance services to other parties, there will be additional controls to be applied in the Federation Assurance Standard.

For additional guidance on implementing the controls in this standard, refer to Implementing the Authentication Assurance Standard.

Contact

Te Tari Taiwhenua Department of Internal Affairs
Email: identity@dia.govt.nz