NIST PIV and digital identity SP 800-63B-4
All1 Introduction2 Authentication Assurance Levels3 Authenticator and Verifier Requirements4 Authenticator Event Management
| Ref | Title | Text | |
|---|---|---|---|
| 1 | Introduction | This section is informative. Authentication is the process of determining the validity of one or more authenticators used to claim a digital identity by establishing that a subject attempting to access a digital service is in control of th | changed here |
| 1.1 in 1 |
Notations | This guideline uses the following typographical conventions in text: • Specific terms in CAPITALS represent normative requirements. When these same terms are not in CAPITALS , the term does not represent a normative requirement. – The ter | changed here |
| 1.2 in 1 |
Document Structure | This document is organized as follows. Each section is labeled as either normative (i.e., mandatory for compliance) or informative (i.e., not mandatory). • Section 1 introduces the document. This section is informative . • Section 2 descr | changed here |
| 2 | Authentication Assurance Levels | This section is normative. To satisfy the requirements of a given AAL and be recognized as a subscriber, a claimant SHALL authenticate to an RP (or IdP, as described in [SP800-63C] ) with a process whose strength is equal to or greater tha | changed here |
| 2.1 in 2 |
Authentication Assurance Level 1 | AAL1 provides basic confidence that the claimant controls an authenticator that is bound to the subscriber account. AAL1 requires either single-factor or multi-factor authentication using a wide range of available authentication technologie | changed here |
| 2.1.1 in 2.1 |
Permitted Authenticator Types | AAL1 authentication SHALL use any of the following authentication types, which are further defined in Sec. 3 : • Password ( Sec. 3.1.1 ): A memorizable secret typically chosen by the subscriber • Look-up secret ( Sec. 3.1.2 ): A secret de | changed here |
| 2.1.2 in 2.1 |
Authenticator and Verifier Requirements | Authenticators used at AAL1 SHALL use approved cryptography . In other words, they must use approved algorithms, but the implementation need not be validated under [FIPS140] . Communication between the claimant and verifier SHALL occur via | changed here |
| 2.1.3 in 2.1 |
Reauthentication | These guidelines provide for two types of timeouts, which are further described in Sec. 5.2 : | changed here |
| 2.2 in 2 |
Authentication Assurance Level 2 | AAL2 provides high confidence that the claimant controls one or more authenticators that are bound to the subscriber account. Proof of possession and control of two distinct authentication factors through the use of secure authentication pr | changed here |
| 2.2.1 in 2.2 |
Permitted Authenticator Types | At AAL2, authentication SHALL use either a multi-factor authenticator or a combination of two separate authentication factors. A multi-factor authenticator requires two factors to execute a single authentication event, such as a cryptograph | changed here |
| 2.2.2 in 2.2 |
Authenticator and Verifier Requirements | Authenticators used at AAL2 SHALL use approved cryptography. Cryptographic authenticators procured by federal agencies SHALL be validated to meet the requirements of [FIPS140] Level 1. At least one authenticator used at AAL2 SHALL be replay | changed here |
| 2.2.3 in 2.2 |
Reauthentication | Periodic reauthentication of subscriber sessions SHALL be performed, as described in Sec. 5.2 . A definite reauthentication overall timeout SHALL be established, which SHOULD be no more than 24 hours at AAL2. The inactivity timeout SHOULD b | changed here |
| 2.3 in 2 |
Authentication Assurance Level 3 | AAL3 provides very high confidence that the claimant controls authenticators that are bound to the subscriber account. Authentication at AAL3 is based on the proof of possession of a key through the use of a cryptographic protocol along wit | changed here |
| 2.3.1 in 2.3 |
Permitted Authenticator Types | AAL3 authentication SHALL require one of the following authenticator combinations: • Multi-factor cryptographic authentication ( Sec. 3.1.7 ) • Single-factor cryptographic authentication ( Sec. 3.1.6 ) used in conjunction with either a pas | changed here |
| 2.3.2 in 2.3 |
Authenticator and Verifier Requirements | Authenticators used at AAL3 SHALL use approved cryptography. Communication between the claimant and verifier SHALL occur via one or more authenticated protected channels. The cryptographic authenticator used at AAL3 SHALL have a non-exporta | changed here |
| 2.3.3 in 2.3 |
Reauthentication | Periodic reauthentication of subscriber sessions SHALL be performed, as described in Sec. 5.2 . At AAL3, the overall timeout for reauthentication SHALL be no more than 12 hours. The inactivity timeout SHOULD be no more than 15 minutes. Unli | changed here |
| 2.4 in 2 |
General Requirements | The following requirements apply to authentication at all AALs. | changed here |
| 2.4.1 in 2.4 |
Security Controls | The verifier SHALL employ appropriately tailored security controls from the moderate baseline security controls defined in [SP800-53] or an equivalent federal (e.g., [FEDRAMP] ) or industry standard that the organization has chosen for the | changed here |
| 2.4.2 in 2.4 |
Records Retention Policy | The verifier SHALL comply with its respective records retention policies in accordance with applicable laws, regulations, and policies, including any National Archives and Records Administration (NARA) records retention schedules that may a | changed here |
| 2.4.3 in 2.4 |
Privacy Requirements | The verifier SHALL employ appropriately tailored privacy controls defined in [SP800-53] or an equivalent industry standard. If CSPs or IdPs process attributes for purposes other than identity services (i.e., identity proofing, authenticati | changed here |
| 2.4.4 in 2.4 |
Redress Requirements | The verifier and associated CSP or IdP SHALL provide mechanisms for the redress of subscriber complaints and problems that arise from subscriber authentication processes, as described in Sec. 5.6 of [SP800-63] . These mechanisms SHALL be ea | changed here |
| 2.5 in 2 |
Summary of Requirements | Table 1 provides a non-normative summary of the requirements for each of the AALs. Table 1. Summary of requirements by AAL Requirement AAL1 AAL2 AAL3 Permitted Authenticator Types * Any AAL2 or AAL3 authenticator type * Password * Look-up | changed here |
| 3 | Authenticator and Verifier Requirements | This section is normative. This section provides detailed requirements that are specific to each type of authenticator. With the exception of the reauthentication requirements specified in Sec. 2 and the requirement for phishing resistance | changed here |
| 3.1 in 3 |
Requirements by Authenticator Type | The following requirements apply to specific authenticator types. | changed here |
| 3.1.1 in 3.1 |
Passwords | A password (sometimes referred to as a passphrase or, if numeric, a personal identification number [PIN] ) is a secret value intended to be chosen and either memorized or recorded by the subscriber. Passwords must be of sufficient effective | changed here |
| 3.1.1.1 in 3.1.1 |
Password Authenticators | Passwords SHALL either be chosen by the subscriber or assigned randomly by the CSP. If the CSP disallows a chosen password because it is on a blocklist of commonly used, expected, or compromised values (see Sec. 3.1.1.2 ), the subscriber S | changed here |
| 3.1.1.2 in 3.1.1 |
Password Verifiers | The following requirements apply to passwords. | changed here |
| 3.1.2 in 3.1 |
Look-Up Secrets | A look-up secret authenticator is a physical or electronic record that stores a set of secrets shared between the claimant and the CSP. The claimant uses the authenticator to look up the appropriate secrets needed to respond to a prompt fro | changed here |
| 3.1.2.1 in 3.1.2 |
Look-Up Secret Authenticators | CSPs that create look-up secret authenticators SHALL use an approved random bit generator, as described in Sec. 3.2.12 , to generate the list of secrets and SHALL deliver the authenticator list securely to the subscriber (e.g., in an in-per | changed here |
| 3.1.2.2 in 3.1.2 |
Look-Up Secret Verifiers | Verifiers of look-up secrets SHALL prompt the claimant for a secret from their authenticator. A secret from a look-up secret authenticator SHALL be used successfully only once. If the look-up secret is derived from a grid card, each grid ce | changed here |
| 3.1.3 in 3.1 |
Out-of-Band Devices | An out-of-band authenticator is a physical device that is uniquely addressable and can communicate securely with the verifier over an independent communications channel, which is referred to as the secondary channel. The device is possessed | changed here |
| 3.1.3.1 in 3.1.3 |
Out-of-Band Authenticators | The out-of-band authenticator SHALL establish a separate channel with the verifier to retrieve the out-of-band secret or authentication request. This channel is considered to be out-of-band with respect to the primary communication channel | changed here |
| 3.1.3.2 in 3.1.3 |
Out-of-Band Verifiers | The verifier waits for an authenticated protected channel to be established with the out-of-band authenticator and verifies its identifying key. The verifier SHALL NOT store the identifying key itself but SHALL use a verification method (e. | changed here |
| 3.1.3.3 in 3.1.3 |
Authentication Using the Public Switched Telephone Network | Use of the PSTN for out-of-band verification is restricted as described in this section and SHALL satisfy the requirements of Sec. 3.2.9 . Setting or changing the pre-registered telephone number is considered to be the binding of a new auth | changed here |
| 3.1.3.4 in 3.1.3 |
Multi-Factor Out-of-Band Authenticators | Multi-factor out-of-band authenticators operate similarly to single-factor out-of-band authenticators (see Sec. 3.1.3.1 ). However, they require the presentation and verification of an activation factor (i.e., a password or a biometric char | changed here |
| 3.1.4 in 3.1 |
Single-Factor OTP | A single-factor OTP generates one-time passwords (OTPs). This category includes hardware devices and software-based OTP generators that are installed on devices such as mobile phones. These authenticators have an embedded secret that is use | changed here |
| 3.1.4.1 in 3.1.4 |
Single-Factor OTP Authenticators | Single-factor OTP authenticators and verifiers contain two persistent values: 1) a symmetric key that persists for the authenticator’s lifetime and 2) a nonce that is either changed each time the authenticator is used or is based on a real- | changed here |
| 3.1.4.2 in 3.1.4 |
Single-Factor OTP Verifiers | Single-factor OTP verifiers effectively duplicate the process of generating the OTP used by the authenticator. As such, the symmetric keys used by authenticators are also present in the verifier and SHALL be strongly protected against unaut | changed here |
| 3.1.5 in 3.1 |
Multi-Factor OTPs | A multi-factor OTP generates one-time passwords for authentication following the input of an activation factor. This includes hardware devices and software-based OTP generators that are installed on mobile phones and similar devices. The se | changed here |
| 3.1.5.1 in 3.1.5 |
Multi-Factor OTP Authenticators | Multi-factor OTP authenticators operate similarly to single-factor OTP authenticators (see Sec. 3.1.4.1 ), except they require the presentation and verification of an activation factor (i.e., a password or a biometric characteristic) to obt | changed here |
| 3.1.5.2 in 3.1.5 |
Multi-Factor OTP Verifiers | Multi-factor OTP verifiers effectively duplicate the process of generating the OTP used by the authenticator without requiring a second authentication factor. As such, the symmetric keys used by authenticators SHALL be strongly protected ag | changed here |
| 3.1.6 in 3.1 |
Single-Factor Cryptographic Authentication | Single-factor cryptographic authentication is accomplished by proving the possession and control of a cryptographic key via an authentication protocol. Depending on the strength of authentication required, the authentication key may be stor | changed here |
| 3.1.6.1 in 3.1.6 |
Single-Factor Cryptographic Authenticators | Single-factor cryptographic authenticators encapsulate one or more authentication keys. Authentication keys are described as either exportable (see Sec. 3.2.13 ) or non- exportable. Exportable authentication keys (usable at AAL2 or below) S | changed here |
| 3.1.6.2 in 3.1.6 |
Single-Factor Cryptographic Verifiers | Single-factor cryptographic verifiers generate a challenge nonce, send it to the corresponding authenticator, and use the authenticator output to verify possession of the authenticator. The authenticator output is highly dependent on the sp | changed here |
| 3.1.7 in 3.1 |
Multi-Factor Cryptographic Authentication | Multi-factor cryptographic authentication uses an authentication protocol to prove possession and control of an authentication key that requires activation through a second authentication factor. Depending on the strength of authentication | changed here |
| 3.1.7.1 in 3.1.7 |
Multi-Factor Cryptographic Authenticators | Multi-factor cryptographic authenticators encapsulate one or more authentication keys that SHALL only be accessible through the presentation and verification of an activation factor (i.e., a password or a biometric characteristic). Non-expo | changed here |
| 3.1.7.2 in 3.1.7 |
Multi-Factor Cryptographic Verifiers | The requirements for a multi-factor cryptographic verifier are identical to those for a single-factor cryptographic verifier, as described in Sec. 3.1.6.2 . Some multi-factor authenticators include flags to indicate whether an activation fa | changed here |
| 3.1.7.3 in 3.1.7 |
Usage With Subscriber-Controlled Wallets | A specific form of multi-factor cryptographic authentication is a subscriber-controlled wallet on the subscriber’s device, as described in Sec. 5 of [SP800-63C] . After the claimant first unlocks the wallet using an activation factor, the a | changed here |
| 3.1.7.4 in 3.1.7 |
Syncable Authenticators | Some cryptographic authenticators allow the subscriber to copy (i.e., clone) the authentication secret to additional devices, usually via a sync fabric. This eases the burden for subscribers who want to use additional devices to authenticat | changed here |
| 3.2 in 3 |
General Authenticator Requirements | The following requirements apply to all types of authentication. | changed here |
| 3.2.1 in 3.2 |
Physical Authenticators | CSPs SHALL provide subscriber instructions for appropriately protecting the authenticator against theft or loss. The CSP SHALL provide a mechanism to invalidate 1 the authenticator immediately upon notification from a subscriber that the au | changed here |
| 3.2.2 in 3.2 |
Rate Limiting (Throttling) | When required by the authenticator type descriptions in Sec. 3.1 , the verifier SHALL implement controls to protect against online guessing attacks . Unless otherwise specified in the description of a given authenticator, the verifier SHALL | changed here |
| 3.2.3 in 3.2 |
Use of Biometrics | Biometrics is the automated recognition of individuals based on their biological and behavioral characteristics, such as fingerprints, voice patterns, facial features, keystroke patterns, angle of holding a smart phone, screen pressure, typ | changed here |
| 3.2.3.1 in 3.2.3 |
Biometric Accuracy | The biometric system SHALL operate with an FMR [ISO/IEC2382-37] of one in 10000 or better for all demographic groups. Demographic categories to be considered SHALL include sex and skin tone when these factors affect biometric performance. T | changed here |
| 3.2.3.2 in 3.2.3 |
Presentation Attack Detection | The biometric system SHOULD implement PAD for iris and fingerprint modalities and SHALL implement PAD for facial recognition. Biometric comparison based on voice SHALL NOT be used. Testing the biometric system for deployment SHOULD demonstr | changed here |
| 3.2.3.3 in 3.2.3 |
Injection Attack Detection | The biometric system SHALL allow no more than five consecutive failed authentication attempts or 10 consecutive failed attempts if PAD is implemented and meets the above requirements. Once that limit has been reached, the biometric authenti | changed here |
| 3.2.3.4 in 3.2.3 |
Use of Biometric Samples | Biometric samples collected in the authentication process MAY be used locally within the authenticator or verifier performing the biometric comparison to update the templates for the purpose of compensating for changes in subscriber charact | changed here |
| 3.2.4 in 3.2 |
Attestation | The CSP needs to have a reliable basis for evaluating the characteristics of the authenticator, such as the inclusion of a signed attestation. An attestation is information conveyed to the CSP, generally when an authenticator is bound, rega | changed here |
| 3.2.5 in 3.2 |
Phishing Resistance | Phishing attacks, previously referred to in SP 800-63B as “verifier impersonation,” are attempts by fraudulent verifiers and RPs to fool an unwary claimant into presenting an authenticator to an impostor. In some prior versions of SP 800-63 | changed here |
| 3.2.5.1 in 3.2.5 |
Channel Binding | An authentication protocol with channel binding SHALL establish an authenticated protected channel with the verifier. The protocol SHALL then strongly and irreversibly bind a channel identifier negotiated in establishing the authenticated p | changed here |
| 3.2.5.2 in 3.2.5 |
Verifier Name Binding | An authentication protocol with verifier name binding SHALL establish an authenticated protected channel with the verifier. The protocol SHALL then generate an authenticator output that is cryptographically bound to a verifier identifier th | changed here |
| 3.2.6 in 3.2 |
Verifier-CSP or IdP Communications | If the verifier and CSP or IdP are separate entities (as shown by the dotted line in Fig. 3 of [SP800-63] ), communications between the verifier and CSP or IdP SHALL occur through a mutually authenticated protected channel (e.g., a client-a | changed here |
| 3.2.7 in 3.2 |
Replay Resistance | An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. Replay resistance is in addition to the replay-resistant nature of au | changed here |
| 3.2.8 in 3.2 |
Authentication Intent | An authentication process demonstrates intent if it requires the claimant to respond explicitly to each authentication or reauthentication request. The goal of authentication intent is to make it more difficult for authenticators (e.g., mul | changed here |
| 3.2.9 in 3.2 |
Restricted Authenticators | As threats evolve, authenticators’ ability to resist attacks typically degrades. Conversely, the performance of some authenticators may improve, such as when changes to their underlying standards increase their ability to resist particular | changed here |
| 3.2.10 in 3.2 |
Activation Secrets | A password used locally as an activation factor for a multi-factor authenticator is referred to as an activation secret . An activation secret is used to obtain access to a stored authentication key. In all cases, the activation secret SHAL | changed here |
| 3.2.11 in 3.2 |
Connected Authenticators | Cryptographic authenticators require a trustworthy connection between the authenticator and the endpoint being authenticated that provides resistance to eavesdropping, injection, and relay attacks. This connection SHALL be made using a wire | changed here |
| 3.2.11.1 in 3.2.11 |
Wired Connections | Wired connections, including those with embedded authenticators, MAY be assumed to be trustworthy because their attack surface is minimal. Claimants SHOULD be advised to use trusted hardware (e.g., cables, adapters) to ensure that they have | changed here |
| 3.2.11.2 in 3.2.11 |
Wireless Connections | Wireless authenticator connections are potentially vulnerable to threats, including eavesdropping, injection, and relay attacks. Wireless connections include technologies that function in the absence of a physical connection, such as radio | changed here |
| 3.2.11.3 in 3.2.11 |
Hybrid Connections | Hybrid connections use a combination of technologies to establish a secure connection between the authenticator and endpoint via a network tunnel service. A visual representation (e.g., QR code) is used to support key establishment between | changed here |
| 3.2.12 in 3.2 |
Random Values | Random values are extensively used in authentication processes in a variety of roles (e.g., nonces, authentication secrets). Unless otherwise specified, random values that reference this section SHALL be generated by an approved random bit | changed here |
| 3.2.13 in 3.2 |
Exportability | Exportability is the ability of an authenticator to replicate, share, or store its authentication keys outside of the protected boundary of the authenticator (e.g., copying it to another authenticator, backing up a key to a separate storage | changed here |
| 4 | Authenticator Event Management | This section is normative. Events can occur over the lifetime of a subscriber’s authenticator and affect its use. These events include binding, maintenance, loss, theft, compromise, unauthorized duplication, expiration, and revocation. Thi | changed here |
73 of 73.