identity 1.0 documentation

Electronic Authentication Guideline

«  NIST SP 800-56A:Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography   ::   Contents   ::   Portable Contacts 1.0 Draft C  »

Electronic Authentication Guideline

8.2. Authentication Mechanism Requirements

Note

Level of Assurance is lowest level reached for 5 metrics

  • Registration and Issuance
  • Tokens
  • Token and Credential Management
  • Authentication Process
  • Assertions

This section covers the mechanical authentication process of a claimant who already has registered a token. Identity proofing and registration are dealt with separately in Section 7. The authentication process shall provide sufficient information to the relying party to uniquely identify the registration information provided by the subscriber and verified by the RA in the issuance of the credential.

Four assurance levels are defined, numbered 1 to 4. Level 4 provides the highest level of authentication assurance, while Level 1 provides the least assurance. The technical requirements for authentication mechanisms (tokens, protocols and security protections) are stated in this section.

8.2.1. Level 1

Although there is no identity proofing requirement at this level, the authentication mechanism provides some assurance that the same claimant is accessing the protected transaction or data. It allows a wide range of available authentication technologies to be employed and permits the use of any token methods of Levels 2, 3 or 4.

Successful authentication requires that the claimant shall prove, through a secure authentication protocol, that he/she controls the token.

Plaintext passwords or secrets shall not be transmitted across a network at Level 1. However this level does not require cryptographic methods that block offline analysis by eavesdroppers.

For example, password challenge-response protocols that combine a password with a challenge to generate an authentication reply satisfy this requirement although an eavesdropper who intercepts the challenge and reply may be able to conduct a successful off-line dictionary or password exhaustion attack and recover the password.

Common protocols that meet Level 1 requirements include APOP [RFC 1939], S/KEY [SKEY], and Kerberos [KERB]. Since an eavesdropper who intercepts such a protocol exchange will often be able to find the password with a straightforward dictionary attack, and this vulnerability is independent of the strength of the operations, there is no requirement at this level to use Approved cryptographic techniques.

At Level 1, long-term shared authentication secrets may be revealed to verifiers.

8.2.1.1.Credential Lifetime, Status or Revocation

There are no stipulations [1] about the revocation or lifetime of credentials at Level 1.

[1]To lay down as a condition of an agreement; require by contract. FreeDictionary .

8.2.1.2.Assertions

Relying parties may accept assertions that are:

  • digitally signed by a trusted entity (e.g., the verifier); or
  • obtained directly from a trusted entity (e.g. a repository or the verifier) using a

protocol where the trusted entity authenticates to the relying party using a secure protocol (e.g. TLS) that cryptographically authenticates the verifier and protects the assertion;

8.2.1.3.Protection of Long-Term Shared Secrets

Files of shared secrets used by verifiers at Level 1 authentication shall be protected by discretionary access controls that limit access to administrators and only those applications that require access. Such shared secret files shall not contain the plaintext passwords; typically they contain a one-way hash or “inversion” of the password. In addition, any method allowed for the protection of long-term shared secrets at Levels 2, 3 or 4 may be used at Level 1.

8.2.1.4.Password Strength

For password (or PIN) based Level 1 authentication systems, the probability of success of a targeted on-line password guessing attack by an attacker who has no a priori knowledge of the password, but knows the user name of the target, shall not exceed 2-10 (1 in 1024), over the life of the password. There are no min-entropy requirements for Level 1. Appendix A contains information about estimating the entropy of passwords.

8.2.1.5.Example Implementations

A wide variety of technologies should be able to meet the requirements of Level 1. For example, a verifier might obtain a subscriber password from a CSP and authenticate the claimant by use of a challenge-response protocol.

Summnary

Registration and Issuance Anonymous credentials permitted, no explicit requirements
Tokens Password, Pre-Registered Knowledge, Look-up Secret, Out of Band
Token and Credential Management Password hashed and protected by ACLs
Authentication Process Shared secrets may not be transmitted in plaintext
Assertions Must be single use, short lifespan, signed or transmitted securely

8.2.2. Level 2

Level 2 allows a wide range of available authentication technologies to be employed and permits the use of any of the token methods of Levels 3 or 4, as well as passwords. Successful authentication requires that the claimant shall prove, through a secure authentication protocol, that he/she controls the token. Eavesdropper, replay, and on-line guessing attacks shall be prevented. Approved cryptography is required to prevent eavesdroppers.

8.2.2.1.Credential and Token Lifetime, Status or Revocation

CSPs shall provide a secure mechanism, such as a digitally signed revocation list or a status responder, to allow verifiers or relying parties to ensure that the credentials are still valid. Verifiers or relying parties shall check to ensure that the credentials they use are valid. Shared secret based authentication systems may simply remove revoked subscribers from the verification database.

CSPs shall revoke credentials and tokens within 72 hours after being notified that a credential is no longer valid or a token is compromised to ensure that a claimant using the token cannot successfully be authenticated. If the CSP issues credentials that expire automatically within 72 hours (e.g. issues fresh certificates with a 24 hour validity period each day) then the CSP is not required to provide an explicit mechanism to revoke the credentials. CSPs that register passwords shall ensure that the revocation or de-registration of the password can be accomplished in no more than 72 hours and that the use of that password in authentication shall fail.

CAs cross-certified with the Federal Bridge CA at the Basic, Medium, High, Citizen and Commerce Class, or Common Certificate Policy levels are considered to meet credential status and revocation provisions of this level.

8.2.2.2.Assertions

Relying parties may accept assertions that are:

  • digitally signed by a trusted entity (e.g., the verifier); or
  • obtained directly from a trusted entity (e.g. a repository or the verifier) using a protocol where the trusted entity authenticates to the relying party using a secure protocol (e.g. TLS) that cryptographically authenticates the verifier and protects the assertion;

Assertions generated by a verifier shall expire after 12 hours and should not be accepted thereafter by the relying party.

8.2.2.3.Protection of Long-term Shared Secrets

Long term shared authentication secrets, if used, shall never be revealed to any party except the subscriber and CSP (including verifiers operated as a part of the CSP), however session (temporary) shared secrets may be provided by the CSP to independent verifiers.

Files of shared secrets used by CSPs at Level 2 shall be protected by discretionary access controls that limit access to administrators and only those applications that require access. Such shared secret files shall not contain the plaintext passwords or secret; two alternative methods may be used to protect the shared secret:

  1. Passwords may be concatenated to a salt and/or username and then hashed with a Approved algorithm so that the computations used to conduct a dictionary or exhaustion attack on a stolen password file are not useful to attack other similar password files. The hashed passwords are then stored in the password file.
  2. Store shared secrets in encrypted form using Approved encryption algorithms and modes and decrypt the needed secret only when immediately required for authentication. In addition any method allowed to protect shared secrets at Level 3 or 4 may be used at Level 2.

8.2.2.4.Password Strength

For password based Level 2 authentication systems, the probability of success of an on-line password guessing attack by an attacker who has no a priori knowledge of the password, but knows the user name of the target, shall not exceed 2-14 (1 in 16,384), over the life of the password.

Level 2 passwords shall have at least 10 bits of min-entropy. Appendix A contains information about estimating the entropy of passwords.

8.2.2.5.Example Implementations

A wide variety of technologies can meet the requirements of Level 2. For example, a verifier might authenticate a claimant who provides a password through a secure (encrypted) TLS protocol session (tunneling).

This prevents eavesdropper attacks, but generally does not adequately block not man-in-the middle attacks or verification impersonation attacks because common web browser clients offer many avenues to fool or trick users.

After a successful authentication, the verifier then puts a security assertion for the claimant in a secure server, and sends a “handle” for that assertion to a relying party in an HTTP referral.

Summary

8.2.3. Level 3

Level 3 authentication is based on proof of possession of a cryptographic key using a cryptographic protocol. Level 3 authentication assurance requires cryptographic strength mechanisms that protect the primary authentication token (a secret key or a private key) against compromise by the following protocol threats defined in section 8.1.1: eavesdropper, replay, on-line guessing, verifier impersonation and man-in-the-middle attacks.

Level 3 also requires two factor authentication ; in addition to the key, the user must employ a password or biometric to activate the key.

Three kinds of tokens described below may be used to meet Level 3 requirements:

Soft cryptographic token: a cryptographic key stored on a general-purpose computer. Hardware tokens validated at FIPS 140-2 Level 1 or higher may also be used to hold the key and perform cryptographic operations. The claimant shall be required to activate the key before using it with a password or biometric, or, alternatively shall use a password as well as the key in an authentication protocol with the verifier. If a password is employed to unlock the soft token key, the key shall be kept encrypted under a key derived from a password meeting the requirements for Level 2 authentication, and decrypted only for actual use in authentication. Alternatively, if a password protocol is employed with the verifier, the use of the password shall meet the requirements for Level 2 authentication assurance.

Hard token: a cryptographic key stored on a special hardware device. Tokens must be validated at FIPS 140-2 Level 1 or higher overall. The claimant shall be required to activate the key before using it with a password or biometric, or, alternatively, shall use a password as well as the key in an authentication protocol with the verifier. The authentication mechanism used to authenticate the claimant to unlock token shall be validated as meeting the operator authentication requirements for FIPS 140-2 Level 2. Alternatively, if a password protocol is employed with a verifier, the use of the password shall meet the requirements for Level 1 authentication assurance.

One-time password device tokens: the authentication depends on a symmetric key stored on a personal hardware device that is a cryptographic module validated at FIPS 140-2 Level 1 or higher overall. The device combines a nonce with a cryptographic key to produce an output that is sent to the verifier as a password. The password shall be used only once and is cryptographically generated; therefore it needs no additional eavesdropper protection. The one-time password output by the device shall have at least 106 possible values. The verifier must be authenticated cryptographically to the claimant, for example using a TLS server. To protect against the use of a stolen token, one of the following measures shall be used:

  • The authentication mechanism used to authenticate the claimant to the token shall be validated as meeting the operator authentication requirements for FIPS 140-2 Level 2.
  • The claimant sends the verifier a personal password meeting the requirements for (E-authentication) Level 1 with the one-time password.

Authentication requires that the claimant shall prove through a secure authentication protocol that he or she controls the token. Long-term shared authentication secrets, if used, shall never be revealed to any party except the claimant and CSP, however session (temporary) shared secrets may be provided to verifiers by the CSP. Approved cryptographic techniques shall be used for all operations.

Each of the three token types has somewhat different utility and security properties. Soft token solutions are easily realized in “thin clients” with TLS and client certificates. Moreover this solution allows not only initial authentication of claimants, but also allows the entire session, or as much of it as is security critical, to be cryptographically authenticated by a key created during the authentication process. Hard token solutions provide the additional assurance of a physical token, and users should know if their token has been stolen. Like soft tokens, hard tokens allow not only initial authentication of claimants, but also allows the entire session, or as much of it as is security critical, to be cryptographically authenticated by a key created during the authentication process. One- time password device token systems are commercially available, portable and work easily with any browser client. Like hard tokens, one-time password device tokens have the security advantage that the token is a tangible, physical object. Subscribers should know if their token is stolen, and the key is not vulnerable to network, shoulder-surfing or keyboard sniffer attacks. Unlike soft tokens or hard tokens, a session key is not created from the authentication process to authenticate subsequent data transfers.

All three token types present the eavesdroppers with similar strong cryptographic protection. Each has its advantages and disadvantages against various types of attacks. All three offer considerably greater strength than Level 2 solutions. Application implementers with specific Level 3 authentication requirements, who need to select a particular technology should chose the one that best suits the functional needs and risks of their application.

8.2.3.1. Credential/Token Lifetime, Status or Revocation

CSPs shall provide a secure mechanism to allow verifiers or relying parties to ensure that the credentials are valid. Such mechanisms may include: revocation lists, on-line validation servers, and the use of credentials with short life-times or the involvement of CSP servers that have access to status records in authentication transactions. Shared secret based authentication systems may simply remove revoked subscribers from the verification database. Verifiers shall check to ensure that the credentials they use are valid. CSPs shall have a procedure to revoke credentials and tokens within 24 hours. The certificate status provisions of CAs cross-certified with the Federal Bridge CA at the Basic, Medium, High or Common Certificate Policy levels are considered to meet credential status and revocation provisions of this level.

Verifiers shall ensure that the tokens they rely upon are either freshly issued (within 24 hours) or still valid.

8.2.3.2. Assertions

Relying parties may accept assertions that are:

  • digitally signed by a trusted entity (e.g., the verifier); or
  • obtained directly from a trusted entity (e.g. a repository or the verifier) using a protocol where the trusted entity authenticates to the relying party using a secure protocol (e.g. TLS) that cryptographically authenticates the verifier and protects the assertion;

Assertions generated by a verifier shall expire after 2 hours and should not be accepted thereafter by the relying party.

8.2.3.3.Protection of Long-term Shared Secrets

Files of long-term shared secrets used by CSPs or verifiers at Level 3 shall be protected by discretionary access controls that limit access to administrators and only those applications that require access. Such shared secret files shall be encrypted so that:

  1. The encryption key for the shared secret file is encrypted under a key held in a FIPS 140-2 Level 2 or higher validated hardware cryptographic module or any FIPS 140-2 Level 3 or 4 cryptographic module and decrypted only as immediately required for an authentication operation.
  2. Shared secrets are protected as a key within the boundary of a FIPS 140-2 Level 2 or higher validated hardware cryptographic module or any FIPS 140-2 Level 3 or 4 cryptographic module and is not exported in plaintext from the module.
  3. Shared secrets are split by a cryptographic secret sharing method between m separate verifier systems, so that the cooperation of n (where 2 ≤ n ≤ m) systems in a secure protocol is required to perform the authentication and an attacker who learns n-1 of the secret shares, learns nothing about the secret (except, perhaps, its size).

Temporary session authentication keys may be generated from long-term shared secret keys by CSPs and distributed to third party verifiers, in an appropriate protocol, but long- term shared secrets shall not be shared with any third parties, including third party verifiers. Session authentication keys are typically created by cryptographically combining the long term shared secret with a nonce challenge, to generate a session key. The challenge and session key are securely transmitted to the verifier. The verifier in turn sends only the challenge to the claimant, and the claimant applies the challenge to the long-term shared secret to generate the session key. Both claimant and verifier now share a session key, which can be used for authentication. Such protocols are permitted at this level provided that all keys preserve at least 80-bits of entropy and approved cryptographic algorithms (e.g., AES, SHA-1, SHA256, HMAC) are used for all operations.

8.2.3.4.Example Implementations

Level 3 assurance can be satisfied by client authenticated TLS (implemented in all modern browsers), with claimants who have public key certificates. Other protocols with similar properties can also be used. Level 3 authentication assurance can also be met by tunneling the output of a one-time password device and a Level 1 personal password through a TLS session.

8.2.4. Level 4

Level 4 is intended to provide the highest practical remote network authentication assurance. Level 4 authentication is based on proof of possession of a key through a cryptographic protocol. Level 4 is similar to Level 3 except that only “hard” cryptographic tokens are allowed, FIPS 140-2 cryptographic module validation requirements are strengthened, and subsequent critical data transfers must be authenticated via a key bound to the authentication process. The token shall be a hardware cryptographic module validated at FIPS 140-2 Level 2 or higher overall with at least FIPS 140-2 Level 3 physical security. By requiring a physical token, which cannot readily be copied and since FIPS 140-2 requires operator authentication at Level 2 and higher, this level ensures good, two factor remote authentication. Level 4 requires strong cryptographic authentication of all parties and all sensitive data transfers between the parties. Either public key or symmetric key technology may be used. Authentication requires that the claimant shall prove through a secure authentication protocol that he or she controls the token. The protocol threats defined in section 8.1.1 above (eavesdropper, replay, on-line guessing, verifier impersonation and man-in-the-middle attacks) shall be prevented. In addition, the token shall protect the secret from compromise by the malicious code threat as described in section 8.1.3 above. Long-term shared authentication secrets, if used, shall never be revealed to any party except the claimant and CSP; however session (temporary) shared secrets may be provided to verifiers or relying parties by the CSP. Strong, Approved cryptographic techniques shall be used for all operations. All sensitive data transfers shall be cryptographically authenticated using keys derived in the authentication process.

8.2.4.1.Credential/Token Lifetime, Status or Revocation

CSPs shall provide a secure mechanism to allow verifiers or relying parties to ensure that the credentials are valid. Such mechanisms may include: revocation lists, on-line validation servers, and the use of credentials with short life-times or the involvement of CSP servers that have access to status records in authentication transactions. Shared secret based authentication systems may simply remove revoked subscribers from the verification database. Verifiers shall check to ensure that the credentials they use are either freshly issued or still valid. CSPs shall have a procedure to revoke credentials within 24 hours. Verifiers or relying parties shall ensure that the credentials they rely upon are either freshly issued (within 24 hours) or still valid. The certificate status provisions of CAs cross-certified with the Federal Bridge CA at the High and Common Certificate Policies shall be considered to meet credential status provisions of Level 4. [FBCA1].

At this level sensitive data transfers shall be cryptographically authenticated using keys bound to the authentication process. All temporary or short-term keys derived during the original authentication operation shall expire and re-authentication shall be required after not more than 24 hours from the initial authentication.

8.2.4.2.Protection of Long-term Shared Secrets

Files of long-term shared secrets used by CSPs or verifiers at Level 4 shall be protected in the same manner as long-term shared secrets for Level 3 (specified in section 8.2.3.3 above.)

8.2.4.3.Example Implementations

Level 4 assurance can be satisfied by client authenticated TLS (implemented in all modern browsers), with claimants who have public key hard tokens. Other protocols with similar properties can also be used.

9. Summary of Technical Requirements by level

This section summarizes the technical requirements for each level in tabular form. Table 2 shows the types of tokens that may be used at each authentication assurance level. Table 3 identifies the protections that are required at each level. Protections are defined in section 8.1.2 above. Table 4 summarizes the requirements for the resistance of passwords to on-line password guessing attacks. Table 5 identifies the types of authentication protocols that are applicable to each assurance level. Table 6 identifies additional required protocol and system properties at each level.

Table 2. Token Types Allowed at Each Assurance Level

Token Type Level 1 Level 2 Level 3 Level 4
Hard crypto token
One-time password device  
Soft crypto token  
Passwords & PINs    

Table 3. Required Protections

Protect against Level 1 Level 2 Level 3 Level 4
On-line guessing
Replay
Eavesdropper  
Verifier impersonation    
Man-in-the-middle    
Session hijacking      

Table 4. Minimum Online Password Guessing Resistance

Attack Type Level 1 Level 2
Targeted Attack: Maximum chance of an attacker guessing the password of a selected user over the life of the password with no a priori knowledge other than the username one in 2^10 (1/1024) one in 2^14 (1/16384)
Untargeted Attack: min-entropy
10-bits

Table 5. Authentication Protocol Types

Protocol Type Level 1 Level 2 Level 3 Level 4
Private key PoP
Symmetric key PoP
Tunneled or Zero knowledge password    
Challenge-response password      

Table 6. Additional Required Properties

Required Property Level 1 Level 2 Level 3 Level 4
Shared secrets not revealed to third parties by verifiers or CSPs  
Multi-factor authentication    
Sensitive data transfer authenticated      
Claimant

A party whose identity is to be verified using an authentication protocol. ( http://lafoglia.posterous.com/termclaimant-fismapedia )

A party that makes a claim. FreeDictionary .

«  NIST SP 800-56A:Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography   ::   Contents   ::   Portable Contacts 1.0 Draft C  »