Authentication – Level of Assurance

Authentication is the process of confirming an entity’s identity based on reliable credentials. The process and the technology involved in authentication varies with various level of assurance required from the entity.

Authentication Level of Assurance can be defined as the authentication strength required for a relying party to be assured that an entity is indeed who it claims to be. As part of an effort to create a set of criteria for levels of assurance, I want to find out existing assurance framework that exists today.

United States

Most online documentations refer to M-04-04 document published by Office of Management and Budget at the US Whitehouse. It identifies four levels of assurance –

• Level 1: Little or no confidence in the asserted identity’s validity.
• Level 2: Some confidence in the asserted identity’s validity.
• Level 3: High confidence in the asserted identity’s validity.
• Level 4: Very high confidence in the asserted identity’s validity.

According to the OMB, the risk from an authentication error can be measured in terms of (1) potential harm or impact and (2) likelihood of its occurrence. The maximum potential impact for each assurance level is summarized in table below –

Table 1 – Maximum Potential Impacts for Each Assurance Level

	Assurance Level Impact Profiles
Potential Impact Categories for Authentication	1	2	3	4
Inconvenience, distress or damage to standing or reputation	Low	Mod	Mod	High
Financial loss or agency liability	Low	Mod	Mod	High
Harm to agency programs or public interests	N/A	Low	Mod	High
Unauthorized release of sensitive information	N/A	Low	Mod	High
Personal Safety	N/A	N/A	Low	Mod, High
Civil or criminal violations	N/A	Low	Mod	High

Mod = Moderate

The OMB recommends the following steps in managing authentication to access government services:

1. Conduct a risk assessment for all the transactions performed on an underlying system to assess the severity of potential harm and likelihood of their occurrence in each impact category.

1. Determine the required assurance level using Table 1.
2. Select the necessary technology to achieve the determined LoA based on the NIST ‘Electronic Authentication Guideline’ [NIST-SP800-63].
3. Validate the system to confirm that it has achieved the required LoA.
4. Periodically reassess the system to verify that the technology applied corresponds to the refreshed requirements.

OMB recognizes that each step in the authentication process may influence the overall conformance to the desired LoA, and each should be as strong and robust as the next. Otherwise, the principle of the ‘weakest link’ applies – the step that provides the lowest LoA in the process affects all the others, regardless of how strong they are.

The following LoA affecting processes and procedures have been identified by OMB:

1. Registration and identity proofing: initial enrolment with a Registration Authority (RA) and obtaining a credential and subsequent visits to the RA
2. Credential management: issuance, maintenance, suspension, revocation, re-issuance of credentials
3. Strength (in cryptographic sense) of the credential and the token in which it stored
4. Verification of an identity credential: the use of a credential to proof one’s identity using an authentication protocol
5. Transaction management: from both technical and administrative perspectives
6. Audit and record keeping
7. Periodic system re-assessment

The technical requirement guidance at each level of assurance to access US federal agencies are specified in the complementary NIST 800-63 publication – Electronic Authentication Guideline. They are –

1. Registration and identity proofing
2. Credential management
3. Tokens used for proving identity
4. Remote authentication as a combination of cryptographic protocols, credentials and tokens used to establish the identity of the claimant
5. Assertion mechanisms used to communicate the results of an authentication instance to other interested parties (not mentioned by the OMB Memorandum)

Registration and identity proofing: the process of registering one’s identity with a RA, and obtaining a credential from a Credential Service Provider (CSP) associated with the RA. Requirements that different LoAs should satisfy can be summarised as follows:

• Level 1: Names are not verified (i.e. names are always assumed to be pseudonyms) and anonymous credentials are allowed. There are no LoA-specific requirements at this level.
• Level 2: Credentials and identity/attribute assertions must specify whether the name is real and verified or a pseudonym. In-person or remote registration is permitted.
• Level 3: Real names must be verified. In-person or remote registration is permitted.
• Level 4: Real names must be verified. Only in-person registration is permitted.

Credential management: the measures used for the management of long term secrets, credential and token lifetime, status and revocation.

• Level 1: There are no stipulations about revocation or lifetime of credentials. Long-term secrets may be revealed to verifiers. Files with shared secrets should not contain plaintext passwords and should be protected by discretionary access control that limits access to administrators and only those applications that require access. For instance, passwords should be hashed before storing them in a password file. Password strength, expressed as the probability of successfully breaking a password without any a priori knowledge of it, shall not exceed 1 in 1024 (i.e. 2-10) over the lifetime of the password.
• Level 2: CSP should provide a mechanism, such as a signed revocation list or a status responder, to allow verifiers to check that credentials are still valid. CSP should have mechanisms to revoke credentials within 72 hours after being notified that the credential is no longer valid. Long-term secrets should never be revealed to verifiers or to any other party except for the CSP and the owner themselves. Files with shared secrets should not contain plaintext passwords and should be protected by discretionary access control that limits access to administrators and only those applications that require access. For instance, passwords should be concatenated with salt and then hashed before storing them in a password file. Password strength, expressed as the probability of successfully breaking a password without any a priori knowledge of it, should not exceed 1 in 16384 (i.e. 2-14) over the lifetime of the password.
• Level 3: CSP should provide a mechanism, such as a signed revocation list or on-line validation servers, to allow verifiers to ensure that credentials are still valid. CSP should have mechanisms to revoke credentials within 24 hours after being notified that the credential is no longer valid. Long-term secrets should never be revealed to verifiers or to any other party except for CSP and the owner themselves. Files of shared long-term should be protected by discretionary access control that limits access to administrators and only those applications that require access. For instance, such files should be encrypted with a key held in FIPS 140-2 Level 2 or higher validated hardware cryptographic module or FIPS 140-2 approved Level 3 or higher cryptographic module.
• Level 4: The same as for Level 3.

Token strengths: NIST recognizes four kinds of authentication tokens:

• Password token: a secret memorized by a claimant and linked to their username.
• Soft token: a cryptographic key that is typically stored on disk or some other media. The key can be stored in encrypted form, in which case it is activated by a user-known password.
• One-time password (OTP) device token: a personal hardware device that generates OTPs for authentication purposes. An OTP generated by the device has a limited life-time and is manually entered by the user to the verifier as a password, typically tunneled via a TLS/SSL session. This kind of a device may or may not have an integrated entry keypad or a biometric reader that can be used to activate the device.
• Hard token: a hardware device that contains a protected cryptographic key and requires an entry of a password or a biometrics to activate the key stored in the device.

Password tokens can satisfy the assurance requirements for Levels 1 and 2, which provide single-factor authentication. Constraints imposed on password tokens are that the probability of guessing a password without any a priori knowledge of it should not exceed 2-10 (for Level 1) and 2-14 (for Level 2). Passwords are not allowed at Levels 3 and 4, which require multi-factor authentication according to the NIST guideline. Soft cryptographic tokens and OTP devices can be used with proof-of-possession protocols at assurance Levels 1 to 3. At Level 3, however, they must be activated (unlocked) with the use of a password, a PIN, or a piece of biometric. Hard cryptographic tokens, which are always activated by a password, a PIN or biometrics, can be used at assurance Levels 1 through 4.

Table 2 – Token Types Allowed at Each Assurance Level

	Assurance Level
Token Types	1	2	3	4
Hard crypto token	x	x	x	x
One-time password device	x	x	x**
Soft crypto token	x	x	x**
Passwords & PINs	x	x

** Must be activated by a password, PIN or biometrics at Level 3

E-authentication protocols: A claimant, through the execution of an e-authentication protocol, proves to a verifier that they are indeed in control of a valid token so as to establish the claimant’s identity. According to NIST, e-authentication protocols can be assigned a LoA category according to specific attacks and threats that they are resistant against, as shown in Tables 3 and 4. Different threats and attacks recognised by the NIST guideline include: password guessing, replay attacks, eavesdropping, verifier impersonation, man-in-the-middle attacks and hijacking of authenticated sessions. Other mentioned threats (not directly related to the protocol itself) include: fooling claimants to use an insecure protocol or accepting unverified servers’ certificates, obtaining tokens out-of-band in some other manner such as social engineering or shoulder-sniffing, or by penetrating the verifier’s or the CSP’s system.

Table 3 – Required Protection

	Assurance Level
Protect Against	1	2	3	4
Online-guessing	x	x	x	x
Replay	x	x	x	X
Eavesdropper		x	x	x
Verifier impersonation			x	x
Man-in-the-middle			x	x
Session hijacking				x

Table 4 – Authentication Protocol

	Assurance Level
Protocol Type	1	2	3	4
Private key Proof-of-Possession (PoP)	x	x	x	x
Symmetric key Proof-of-Possession (PoP)	x	x	x	X
Tunneled or zero-knowledge password	x	x
Challenge-response password	x

Table 5 – Additional Requirements

	Assurance Level
Protocol Type	1	2	3	4
Shared secrets not revealed to third parties by verifiers or CSPs		x	x	x
Multi-factor authentication			x	x
Sensitive data transfer authenticated				x

Assertion mechanisms: An assertion mechanism is used by an identity provider (i.e. the entity performing the authentication) to communicate the result of an e-authentication process to a relying party (e.g. a service provider). Assertions are particularly important in federated environments where the tasks of authentication and authorisation are performed by different organisational or administrative entities. In such environments, a user authenticates to one entity (usually the user’s home organisation), while the authorisation decision is made by the other entity managing the resources based on the outcome of the user’s authentication and possibly the user’s additional attributes passed in the form of an assertion. Signed SAML [SAML] assertions and cookies are most commonly used to carry assertions. A relying party may trust an assertion depending on the origin and the time of generation of the assertion. The NIST guideline recommends that relying parties may accept assertions that are either:

• Digitally signed by a trusted entity (e.g. a verifier), or

• Obtained directly from a trusted entity using a protocol where a trusted entity is authenticated to the relying party using a secure protocol (e.g. TLS) that also protects the confidentiality of an assertion.

Authentication assertions are treated differently at the four defined assurance levels:

• Level 1: Assertions with no expiration time are accepted.

• Level 2: Assertions are accepted up to 12 hours from the time of creation.

• Level 3: Assertions are accepted up to 2 hours from the time of creation.
• Level 4: Authentication assertions are not allowed at Level 4; i.e. at this level, a user must authenticate directly to the relying party.

There are more details on the types of controls in the publications. However, I am not going in to so much depth as I am currently interested in the level of assurance (LoA).

Canada, Province of British Columbia (BC)

The Electronic Credential and Authentication Standard published by the Province of BC in Canada have the following levels

• Level 1 – Low: No or minimal credential requirements; single factor with low security requirement
• Level 2 – Medium: Single factor credential (e.g. user ID and password with strong password requirements). There are required processes for issuing and managing credentials with medium level strength, and system and security requirements for credential services. Where a multi-factor credential is issued that does not meet the high level strength requirements (Level 3), for example, a device that does not meet the cryptographic module validation requirements, then it is considered to meet the medium level strength requirements (Level 2).
• Level 3 – High: Multi-factor credential (e.g. digital certificate combined with a password). Software-based and hardware-based cryptographic tokens and one-time password generators are acceptable. There are strong processes for issuing and managing credentials with high level strength, and system and security requirements for credential services.
• Level 4 – Very High: Owner of hard multi-factor credential corroborated by successful log on or biometric match (e.g. authenticating a smart card and PIN through an encrypted communication session using Transport Layer Security (TLS)). This level includes authentication of high-quality biometrics, however there are currently no standards governing the use of biometric authentication. There are very strong processes and protocols for verifying credentials with very high level strength, and more rigorous system and security requirements for authentication services.

The Government of Canada also published its authentication strategy on June 30, 2006. It has pointers to strategies of United States, Australia, New Zealand, and Ireland

Australia

The Australian Government’s National e-Authentication Framework has the following –

• Level 0 – No Assurance: No confidence is required in the identity assertion
• Level 1 – Minimal Assurance: Level 1 – Minimal assurance: Minimal confidence is required in the identity assertion
• Level 2 – Low assurance: Low confidence is required in the identity assertion
• Level 3 – Moderate assurance: Moderate confidence is required in the identity assertion
• Level 4 – High assurance: High confidence is required in the identity assertion

New Zealand

The policy framework for online authentication in New Zealand specifies the following Trust Levels. The definition of the Trust Levels is based upon the Trust Levels developed by the UK Office of the e-Envoy:

• Level 0: Anonymous user. Transactions that do not require the user to be identified or require protection of a user’s identity. For example, access to online publications.
• Level 1: Pseudonymous user. Access is provided for transactions that do not require a person to be uniquely identified, but the service agency must be able to respond to the user. For example, to ‘recognise’ the person when he/she accesses the service on return visits.
• Level 2: Identified user. Access is provided for transactions that require that a person be specifically identified. For example, establishing a bank account.
• Level 3: Identified user and verified transaction. Access is provided for transactions that require the person to be specifically identified; verification of the integrity of the data exchanged and the exchange itself; and the creation of sufficient evidence to indicate that the person agreed to be bound by the transaction. For example, obtaining a passport.

Liberty Alliance

The Liberty Alliance is a global identity consortium formed in 2001 by approximately 30 organizations with the goal of developing open technical, business and privacy standards for federated identity management. The Liberty Identity Assurance Framework (LIAF) published by Identity Assurance Expert Group (IAEG) of Liberty Alliance differs with NIST 800-63; as they believe LoA (or AL in IAEG terms for Assurance Level) are the levels of trust associated with a credential as measured by the associated technology, processes, and policy and practice statements. IAEG assurance framework is better aligned for Credential Service Provider (CSP). According to them ALs are based on two factors:

• The extent to which the identity presented by a CSP in an identity assertion can be trusted to actually belong to the entity represented. This factor is generally established through the identity proofing process and identity information management practices.
• The extent to which the electronic credential presented to a CSP by an individual can be trusted to be a proxy for the entity named in it and not someone else (known as identity binding). This factor is directly related to the integrity and reliability of the technology associated with the credential itself, the processes by which the credential and its verification token are issued, managed, and verified, and the system and security measures followed by the credential service provider responsible for this service.

The four IAEG ALs are based on the four levels of assurance posited by the U.S. Federal Government and described in OMB M-04-04 [M-04-04] and NIST Special Publication 800-63 [NIST800-63] for use by Federal agencies. Their description remains as in Table 1 above. Where they differ is in the details of potential impact at each assurance level.

Table 4 – Potential Impacts for Each Assurance Level

	Assurance Level Impact Profiles
Potential Impact Categories for Authentication	1	2	3	4
Inconvenience, distress or damage to standing or reputation	Min	Mod	Sub	High
Financial loss or agency liability	Min	Mod	Sub	High
Harm to agency programs or public interests	N/A	Min	Mod	High
Unauthorized release of sensitive information	N/A	Mod	Sub	High
Personal Safety	N/A	N/A	Min	Sub, High
Civil or criminal violations	N/A	Min	Sub	High

Min = Minimum; Mod = Moderate; Sub = Substantial; High = High

Recommendation

If you are interested in an industry that is not a government agency, then I would recommend using Liberty Alliance assurance framework as it is widely adopted and leverages the best practices from US OMB and NIST. It helps in vendor assessment as well as choosing right tools that is available in the market. While you adopt Liberty Alliance assurance framework, ensure it meets your information / data classification and protection requirements.

Due Credit

I am very fortunate to find a research report that was completed couple years back by Open Grid Forum on the same topic that gave me quick lead to lot of information.