Adapting Levels of Assurance for the NSTIC
This is part of an ongoing series on the National Strategy for Trusted Identities in Cyberspace. The introduction to this series can be found here.
One of the goals of the National Strategy for Trusted Identities in Cyberspace (NSTIC) is to support a wide range of use cases. These might include everything from low-value purchases to making adjustments to critical infrastructure, like power systems, where someone might get hurt if an unauthorized action takes place.
The level of confidence in the validity associated with an identity is referred to as Level of Assurance (LOA). In a specification referred to as M-04-04, the US Government has defined four LOA levels, from LOA 1 (little or no confidence) to 4 (very high confidence). They also define the minimum LOA that should be applied in various use cases based on the type and severity of harm that might occur if a user is misauthenticated.
The National Institute of Standards and Technology (NIST) authored a companion specification, Special Publication 800-63, defining the corresponding types of authentication and identity proofing requirements (documentation required at enrollment) that are appropriate for each of the four LOAs. A very brief summary of the requirements is:
- Level 1: Basic challenge-response methods
- Level 2: Single-factor authentication; basic identity proofing
- Level 3: Multi-factor authentication; extended identity proofing
- Level 4: Multi-factor authentication with “hard” token; extended identity proofing
[Note that the very common practice of sending passwords in the clear doesn’t fit anywhere here. A lot of what’s currently being done can be thought of as “Level 0”.]
The underlying principle here is that authentication requirements should correspond to the risk or value of the resultant use. While it’s clearly inappropriate to use a weak form of authentication for a high-risk transaction, it’s also undesirable to require a high level of assurance, which usually involves more overhead, for low-value transactions because of the “friction” it introduces. We don’t want to discourage people from doing things on the Internet by imposing onerous authentication requirements everywhere.
When these specifications were written several years ago, the NSTIC model of separating the role of identity (credential) providers and attribute providers hadn’t fully matured. It has been common practice for credentials to carry a number of attributes, such as the user’s name, as well as cryptographic information required for authentication. As a result, SP 800-63 requires various types of identity proofing (verification of physical credentials at enrollment time) to be associated with the issuance of credentials at LOA 2 and above. However, the wider applicability of NSTIC includes use cases requiring pseudonymity, and that requires the separation of authentication and attributes.
An alternative way to look at this is to consider the association of the user’s name and other identifying characteristics to be attributes rather than elements of the user’s authentication. Identity proofing requirements then would be associated with the user’s enrollment at an attribute provider, which would occur after the user has been issued authentication credentials.
The effective level of assurance for a transaction then becomes a composite of several things. It depends on the LOA of the user’s authentication, and the LOA reflecting the practices of the credential provider. It also depends on the LOA of the attribute (how thorough identity proofing was performed), how securely it is bound to the authentication credential, and the LOA reflecting the attribute provider’s practices. The low-water mark, or minimum of these LOA values, becomes the effective LOA of the identity.
There is currently some discussion with NIST about reflecting this distinction more completely in SP 800-63, which is currently being revised.
The ability of users to choose their identity and attribute providers is important in the NSTIC identity model. The ability to separate these roles completely and assign responsibility for identity proofing to attribute providers enables many additional entities to participate as identity providers. Giving users more ability to choose providers they trust will enhance user acceptance and, ultimately, enhance the value of the NSTIC.