# NIST sp 800-63B: How Well Do I Know You?

- Link: https://www.agilicus.com/nist-sp-800-63b-how-well-do-i-know-you/
- Published: 2021-12-29T21:29:09+00:00
- Author: Don Bowman

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](https://pages.nist.gov/800-63-3/sp800-63b.html).
Does the goldilocks principle apply to you? Read on!

in [NIST sp 800-63A: Introduce Yourself](https://www.agilicus.com/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](https://pages.nist.gov/800-63-3/sp800-63b.html)

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](https://www.agilicus.com/i-am-i-have-i-know-multi-factor-authentication/)
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](https://pages.nist.gov/800-63-3/sp800-63b.html#SP800-53) Low Baseline (or equivalent) | [SP 800-53](https://pages.nist.gov/800-63-3/sp800-63b.html#SP800-53) Moderate Baseline (or equivalent) | [SP 800-53](https://pages.nist.gov/800-63-3/sp800-63b.html#SP800-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 |

[NIST sp 800-63b](https://pages.nist.gov/800-63-3/sp800-63b.html#63bSec4-Table1)

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](https://datatracker.ietf.org/doc/html/rfc20))
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](https://www.iso.org/standard/76835.html)]
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](https://www.agilicus.com/trust-you-i-just-met-you-how-trust-on-first-use-can-increase-your-security/)).
The driver of this (a US Presidential [Executive order](https://www.federalregister.gov/documents/2014/10/23/2014-25439/improving-the-security-of-consumer-financial-transactions))
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 Identity Verification Levels and OWASP Session Management Vulnerabilities:
A comparison of identity assurance levels required by NIST and common web application
security risks related to session handling, highlighting the importance of strong
authentication and secure session management practices.⌉⌊NIST SP 800-63B Identity
Verification Levels and OWASP Session Management Vulnerabilities: A comparison of
identity assurance levels required by NIST and common web application security risks
related to session handling, highlighting the importance of strong authentication
and secure session management practices.⌉[

NIST sp 800-63B has consideration for Federation and single-sign-on across multiple
sessions (where a session is [defined](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)
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.

[⌊NIST sp 800-63B usability⌉⌊NIST sp 800-63B usability⌉[

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.