FIPS-PUB-196

Abstract

To acceptably implement this standard, an implementation must meet the following criteria: <br>1) Each entity in an authentication exchange must use a FIPS approved digital signature algorithm to generate and/or verify digital signatures; <br>2) Each entity must generate (pseudo)random numbers using a FIPS approved (pseudo)random number generator; <br>3) Each entity acting as a claimant must be bound to a public/private key pair, the private key should remain in the sole control of the claimant who uses that key to sip a random challenge. The key binding require a unique authentication identifier for each claimant, so that a verifier can distinguish between multiple claimants; and <br>4) One or both of the authentication protocols in this standard must be implemented. For each protocol, steps and token fields marked as [OPTIONAL] do not need to be implemented, except where indicated otherwise. However, all other steps and token fields must be implemented. <br>Entity authentication protocols in this standard make use of a digital signature algorithm for the generation of authentication tokens. The authentication protocols are independent of the nature of the authenticating entities (e.g., for mutual authentication, the same protocol is used for human-human, human-process, and process-process authentication). In situations where a human is involved as a principal, a two-step sequence usually takes place, due to the complexity of cryptography. A human user first authenticates oneself to a cryptographic module, which then acts as a claimant and performs the actual signature generation and/or verification on behalf of the human user (see Section <a>3.1.1</a>). <br>The authentication of an entity (viz. a claimant to a verifier) depends on two successful actions: (1) the verification of the claimant's binding with its public/private key pair, and (2) the verification of the claimant's digital signature on a random number challenge. A binding of an entity's unique identifier with its key pair is essential to proving the authenticity of that entity's identify. This must be done prior to any authentication exchange. During an authentication exchange, a random number challenge generated by the verifier is associated with the claimant's identifier. The claimant then generates a signature on that challenge, which is freshly generated for that particular exchange. In order to verify a signature, the verifier uses the claimant's identifier to find a public key that is bound to that identifier. If that public key can be used to successfully verify the claimant's signature on the challenge, then the verifier has in fact verified that the claimant is the same entity that is bound to the key pair. This chain of associations, bindings, and signatures is what allows an entry to successfully authenticate itself. The next several paragraphs address some issues of entity-key bindings, random challenges, and identifiers. <br>Public key certificates are not required by this standard, and the utilization of a public key infrastructure lies outside the scope of this standard. Whether or not public key certificates are used in an authentication implementation, each public/private key pair shall be bound to a particular entity. Such a binding may be performed by a verifier or a third party that is trusted by the verifier. Trusted third parties may be used in conjunction with this standard to distribute delegation keys, login tickets, public keys, or public key certificates. Delegation keys are keys issued, by one entity to let another entity act upon the issuer's behalf; login tickets are generated by a third party, and used by one entity to authenticate to another. Neither of these items is used in this standard, but may be included in a particular implementation using the optional text fields provided in the exchanged authentication tokens (see Section <a>3.1.5</a>). Trusted third parties may provide other necessary services, such as a courier service to transport valid public keys. <br>Since the protocols defined in this standard utilize (pseudo)random number values for the authentication tokens' time variant parameters, authenticating entities do not have to use synchronized clocks to verify the freshness and timeliness of authentication tokens. (Note: Throughout the rest of this document, the term "random" number will imply the use of either a random or pseudorandom number.) Authentication exchanges using date-time stamps and sequence numbers were not chosen for this standard due to their requirements of maintaining synchronized clocks and sequence number log tables, respectively. Random number challenges are generally easier to use in widely distributed environments where entities do not necessarily know one another prior to authentication. <br>A naming convention for the entities involved in an authentication exchange is not defined in this standard. However, unique, distinguishing identifiers for participating authentication entities should be established prior to the execution of either of those protocols. Each entity being authenticated must have such an identifier, which can be used to uniquely associate it with a public/private key pair. <br>Biometric authentication techniques are not included in the authentication exchanges in Section 3. Information pertaining to biometrics, or the results of performing a biometric live scan, may be included in an authentication token's optional text field, and that data may be used in determining authentication success or failure. However, the lack of that biometric functionality, in an implementation of either protocol, will not prevent that implementation from meeting the requirements of this standard. <br>Upon completion of either of the entity authentication protocols in this standard, the entity performing the final verification step may send an acknowledgement of verification success or failure to the other entity involved in the exchange. Although the format and use of such an acknowledgment is not within the scope of this standard, In certain implementations it may be necessary to inform the other principal of a(n) (un)successful authentication exchange.