Level of Assurance alternatives: A modest proposal
There has recently been a good deal of attention to the concept of Level of Assurance (LOA), and the unsuitability of a one-dimensional, four-level classification of authentication quality for many current requirements including NSTIC and many non-government uses that had adopted the LOA model. On top of that, President Obama issued an Executive Order last October that further motivates change by requiring two-factor authentication for all US Government transactions with consumers that release their personal information.
I have been thinking about ways to improve (or replace) Levels of Assurance for a few years now. Among the comments I made about NIST Special Publication 800-63 during its 2011 revision to SP-800-63-1 was that LOA didn’t support the NSTIC model of separate identity (authentication) and attribute providers very well, since LOA encompasses aspects of both. That would have required major surgery to SP 800-63, and would make its responsiveness to OMB M-04-04, the requirements document from the White House, less clear. So a paragraph was inserted in the introduction:
Current government systems do not separate functions related to identity proofing in registration from credential issuance. In some applications, credentials (used in authentication) and attribute information (established through identity proofing) could be provided by different parties. While a simpler model is used in this document, it does not preclude agencies from separating these functions.
Briefly, the four LOA levels are:
- LOA 1: Some assurance that this is the same Claimant who participated in previous transactions
- LOA 2: Single factor network authentication
- LOA 3: Multi-factor remote network authentication
- LOA 4: Strong multi-factor cryptographic authentication
Here are some of the problems that I see with the current LOA structure:
- By combining authentication and identity proofing, strong pseudonymous authentication is not recognized. Pseudonymous transactions are limited to LOA 1 or 2.
- LOA 2 is sometimes pseudonymous and sometimes not (requiring identity proofing). It should only mean one thing.
- LOA 2 and 3 identity proofing requirements are different, but not substantially so.
To avoid confusion, we should avoid the use of the term “Assurance” in the new structure.
I propose that we have two dimensions to the new structure, which I will call authentication strength and attribute reliability. Authentication strength refers to the technical strength of the authentication process itself, for example, whether it is single or multi-factor. Attribute reliability refers to the quality of the identity proofing process, as well as the strength of the binding of the identifying attributes to the authentication.
I am proposing that we have three levels each for strength and reliability, as follows:
- Level 1: Some confidence in the authentication (typically username/password)
- Level 2: High confidence (Two or more factors used together)
- Level 3: Very high confidence (Two or more factors including a hardware token)
Note that account reset and recovery must be done at a commensurate level of strength with the original authentication.
- Level 1: Self-asserted
- Level 2: Reliable attribute (Remotely identity proofed)
- Level 3: Very reliable (In-person identity proofed or derived from identity-proofed assertions)
Detailed requirements for the strength and reliability levels will of course need to be worked out.
Why not more levels? One has to ask whether additional levels would be actionable on the part of relying parties. As it is, one could consider there to be are theoretically nine strength x reliability levels, although not all of them may be useful. High strength with low reliability might be used in cases where strong pseudonymous authentication is required, but I struggle to find a use for high reliability with low strength.
These strength/reliability levels map into the existing assurance levels as follows:
|Level of Assurance||Strength||Reliability|
What about other dimensions?
Various other dimensions have been proposed in discussions about LOA alternatives. For example, in a message to the IETF Vectors of Trust mailing list, Justin Richer offered a strawman that included assertion presentation and operational management. Assertion presentation (leakiness of the federation protocol) is more related to the choice of network protocols, and is therefore more directly visible to the relying party, as compared with strength and reliability that need to be explicitly asserted. Operational management is a characteristic that would impact the accreditation (through a trust framework or otherwise) of identity and attribute providers, and therefore generally outside the scope of a given transaction. Assertion presentation and operational management might, however, place upper bounds on the levels of strength and reliability that a relying party is able to accept from a given provider.
Additional dimensions have a major impact on the complexity of the framework, probably multiplying the number of possible combinations by a factor of 3 or 4 per dimension.
Much of the inspiration and many ideas for this framework come from discussion on the IETF Vectors of Trust mailing list.