NIST 800-63-B: Authentication and Lifecycle Management Guidelines
This is part three of a blog series on NIST-800-63-3 guidelines on Digital identity. Part one provides an introduction and overview of the overall guidelines, while part two goes in-depth into the Enrollment and Identity Proofing. This blog will add more color to NIST 800-63-B which explains in detail guidelines related to authentication and lifecycle management of authenticators, including their revocation in the event of loss of theft.
Digital Authentication and Authentication Assurance Levels (AAL)
NIST defines authentication as a “process of determining the validity of one or more authenticators used to claim a digital identity.” In essence, authentication provides proof or assurance that an individual attempting to login to a service or perform a transaction online does in indeed possess and actively control a token or an authenticator used to authenticate to the service. The confidence or the degree of assurance with which we can definitively say that the individual is indeed in possession of the authenticator is referred to as “Authentication Assurance Level” or AAL. The guidelines document defines three AALs:
Authenticator Assurance Level 1: AAL1 provides some assurance that the claimant controls an authenticator bound to the subscriber’s account. AAL1 requires either single-factor or multifactor authentication using a wide range of available authentication technologies. Successful authentication requires that the claimant prove possession and control of the authenticator through a secure authentication protocol.
Authenticator Assurance Level 2: AAL2 provides high confidence that the claimant controls authenticator(s) bound to the subscriber’s account. Proof of possession and control of two different authentication factors is required through secure authentication protocol(s). Approved cryptographic techniques are required at AAL2 and above.
Authenticator Assurance Level 3: AAL3 provides very high confidence that the claimant controls authenticator(s) bound to the subscriber’s account. Authentication at AAL3 is based on proof of possession of a key through a cryptographic protocol. AAL3 authentication requires a hardware-based authenticator and an authenticator that provides verifier impersonation resistance; the same device may fulfill both these requirements. In order to authenticate at AAL3, claimants are required to prove possession and control of two distinct authentication factors through secure authentication protocol(s). Approved cryptographic techniques are required.
A summary table of the requirements for the 3 AALs is listed below:
Address the three AALs with Idaptive Adaptive Multi-factor Authentication
Idaptive has been consistently ranked as one of the top cloud-based multi-factor authentication solutions, both by customers and leading analysts like Kuppinger Cole and Gartner. Idaptive not only has the broadest choice of authentication factors but is also the most versatile in supporting MFA Everywhere – the ability to deploy multi-factor authentication to all possible use cases, whether it is for the VPNs (like Palo Alto Networks), windows PCs or Amazon Workspaces virtual desktops.
Mapping Authenticators to Idaptive Authentication Mechanisms
Below are some examples of how Idaptive’s supported authentication mechanisms map to the authenticators defined by NIST. Note that this is by no means exhaustive in terms of all the authenticators supported by Idaptive.
SMS OTP as a Second Factor? No!
Although SMS OTP is one of Idaptive’s most commonly used second factor, NIST strongly discourages its use and considers it as a “Restricted Authenticator”. According to NIST authenticators that leverage public switched telephone network (read telecom carriers).
Biometrics as an Authenticator
The guidelines also talk about biometrics based authenticators, commonly referred to as “something you are”, and which can take the form of an electronic representation of an individual’s unique physical features (fingerprint, IRIS scan, heartbeat) or unique behavioral characteristics (e.g. typing cadence). The 800-63-B guidelines only allow for very limited use of biometrics as an authenticator. This is because the False Match Rate (FMR) or False Accept Rate (FAR) and False Non-Match Rate (FNMR) or False Reject Ratio (FRR) associated with biometrics does not provide the right level of confidence during authentication. Biometrics comparison is also probabilistic and not deterministic, which is an important aspect of all the other approved authenticators. Biometrics features are also not secrets, since they can often be obtained by taking a picture, high-res if needed, of someone (facial recognition, IRIS scan) or lifted from objects someone touches (fingerprints). There are ways of mitigating these using proprietary feature to biometric template conversion algorithms and such, but that ensures additional trust in those algorithms. Hence, according to NIST, biometrics should only be used as a part of MFA with a physical authenticator (something you have). Also, the FMR of the biometric system should be 1 in 1000 or better. There are more conditions under which biometrics can be used which are explained in more detail in the guidelines document itself. In line with NIST guidelines, Idaptive supports biometrics authentication such as facial or fingerprint recognition on mobile devices as a second factor or even a third factor for authentication into systems.
Risk-based or Adaptive Authentication Systems and NIST
Risk-based or Adaptive Authentication Systems often leverage contextual information such as device context, user context, location context and network context to compute a risk score, that can then be leveraged to determine if and how (with what factors) a user needs to reauthenticate to a system. Adaptive authentication systems are great at improving the end user experience related to MFA, while also ensuring that an authentication decision is augmented by a more in-depth analysis (often driven by machine learning) of the user’s behavior. While these solutions are not considered as a valid authenticator by NIST on their own (since they can’t be called a “secret”), these solutions are becoming table-stakes as we move towards a Zero Trust world. Idaptive is the only leading IDaaS vendor that has its own User Behavior Analytics solution completely integrated with its MFA portfolio, giving us the ability to augment MFA with risk-based access.
I could go on and explore this guideline even further, given that this topic (authentication and authorization) is particularly close to my heart. But I’ll end this conversation here and if you’re interested in finding out more how Idaptive helps address these guidelines in greater detail, reach out to us, or sign-up for our free trial here.