Zero-Trust Network Architecture has 3 steps: Authenticate (Who), Authorise(What), Access(How). 3 Levels of strength of the who are defined in NIST sp 800-63B. Does the goldilocks principle apply to you? Read on!
in NIST sp 800-63A: Introduce Yourself I talked about how a system becomes aware of a user the first time (enrollment). In this, we talk about the subsequent authentication (are you still that person) and how strong that is. Quoting from the NIST sp 800-63B specification:
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 multi-factor 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 an 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.
NIST Special Publication 800-63B
OK, so what does that mean? In a nutshell: Level 1, status quo. A password, a door key dongle, your visa card for ‘tap’ with NFC, etc. You have a thing which proves who you are.
Level 2, new status quo, aspirational but in progress for most. Two independent factors of the “I AM. I HAVE. I KNOW.” troika. Covered in NIST sp 800-63B.
Level 3, not only do I know who you are, but I know the blood is flowing in your eye-vessels to avoid some sort of science-fiction-eye-on-the-scanner attack and that its not some sort of 3d-printed fingerprint your are feeding me.
In addition to these levels, the standard talks about resilience to e.g. local malware (keyloggers), man-in-the-middle-attacks (e.g. snarfing your second-factor on the fly).
In level 1 of NIST sp 800-63B, you must re-authenticate at least every 30 days, making it convenient for devices that are single-user and always with you.
In level 2,multiple (unlike) factors are required. You can use two independent single-factors (e.g. password + possession of FIDO key), or, a single device which implements concurrent multi-factors (e.g. a device with biometric required to activate). Re-authentication is required at least every 12 hours (so once per shift in theory), and, if there is 30 or more minutes of inactivity. However, you can keep a session alive if its not yet reached its limit using only a single factor if you choose.
Level 3 requires 12-hour re-authentication and 15-minute timeout. Both factors are always required. Both factors are strong and impersonation resistant. Interestingly, if you use your phone as one of the factors, unlocking the phone cannot serve as one of the authentication methods (so your 1234 PIN is no good!).
The spec also has a good table overview:
| Requirement | AAL1 | AAL2 | AAL3 |
|---|---|---|---|
| Permitted authenticator types | Memorized Secret; Look-up Secret; Out-of-Band; SF OTP Device; MF OTP Device; SF Crypto Software; SF Crypto Device; MF Crypto Software; MF Crypto Device | MF OTP Device; MF Crypto Software; MF Crypto Device; or Memorized Secret plus: • Look-up Secret • Out-of-Band • SF OTP Device • SF Crypto Software • SF Crypto Device | MF Crypto Device; SF Crypto Device plus Memorized Secret; SF OTP Device plus MF Crypto Device or Software; SF OTP Device plus SF Crypto Software plus Memorized Secret |
| FIPS 140 validation | Level 1 (Government agency verifiers) | Level 1 (Government agency authenticators and verifiers) | Level 2 overall (MF authenticators) Level 1 overall (verifiers and SF Crypto Devices) Level 3 physical security (all authenticators) |
| Reauthentication | 30 days | 12 hours or 30 minutes inactivity; MAY use one authentication factor | 12 hours or 15 minutes inactivity; SHALL use both authentication factors |
| Security controls | SP 800-53 Low Baseline (or equivalent) | SP 800-53 Moderate Baseline (or equivalent) | SP 800-53 High Baseline (or equivalent) |
| MitM resistance | Required | Required | Required |
| Verifier-impersonation resistance | Not required | Not required | Required |
| Verifier-compromise resistance | Not required | Not required | Required |
| Replay resistance | Not required | Required | Required |
| Authentication intent | Not required | Recommended | Required |
| Records Retention Policy | Required | Required | Required |
| Privacy Controls | Required | Required | Required |
Now, there are some other requirements in NIST sp 800-63B, ones that many systems don’t implement for no good reason. An example, ‘memorised secret verifiers’ (AKA passwords). “All printing ASCII (RFC 20) characters as well as the space character…”. I know I have used systems that disallow certain characters from this set. It also suggests “Unicode [ISO/ISC 10646] characters…” are allowed.
NIST sp 800-63B also disallows ‘hints’. No personal verification questions, no “what was the name of your first pet” type things. It also allows ‘paste’ and ‘showing characters’ rather than asterisk, since they’ve found this makes for stronger passwords.
A personal (un)favourite method of mine is also disallowed by NIST sp 800-63B. You cannot use email as an out-of-band proof (nor VoIP / SMS). So it cannot text you or email you a second-factor for login. I’m personally not a fan of these systems where you sign-in, and then get an email to retrieve with a code. They are complex, slow, and not that great IMHO.
The NIST sp 800-63B standard calls for “Binding at Enrollment” (AKA Trust On First Use). The driver of this (a US Presidential Executive order) is summed up as “to release personal data, the user must have multiple-factors”. The only feasible method to get this is at time of initial enrollment. In addition is suggests setting up 2 multi-factor physical devices (for recovery purposes), replacing the “what was your first pet’s name” recover methods).
NIST sp 800-63B has consideration for Federation and single-sign-on across multiple sessions (where a session is defined in OWASP terminology).
Interestingly, and new to me, session id’s should not be fingerprintable nor recognisable. This means don’t use PHPSESSID or ASP.NET_SessionId etc. The humble JWT needs a disguise according to NIST sp 800-63B.
Another complex topic discussed briefly in NIST sp 800-63B… Access Tokens must not suggest presence of user. So I sign in, I get a 4 hour access token via OpenID Connect. 15-minutes later i’ve left the keyboard. The token is still valid, but I am not. This is going to take some more thought for me to internalise since the re-authentication times given are quite short for ‘refresh flow’ usage.
Finally, NIST sp 800-63B gives some guidance around usability (after all, what is the sense in a perfect identity system if you cannot identify yourself)?
OK, now we’ve walked through NIST sp 800-63B together. We’ve discussed the various requirements of identity, and strength of identity. For most readers, level-1 is today, level-2 is soon, and level-3 is the horizon. Many will be looking for the silver bullet (e.g. “let’s just do multi-factor with vendor A”). Many will then struggle to gasket this strong identity to existing applications, and then realise that “Authentication” 🠖”Authorisation” 🠖 “Access”, and that the system as a whole needs addressing, rather than a single layer.
And for that, I can help. Feel free to reach out.