PD-0105: Acceptability of IKE Authentication as "Single Use" In Firewall PPs

["Observation Decisions Review Board" <ccevs-odrb@nist.gov>]

This decision represents a long-term technical decision based on a previously 
issued OD, and may not be the same as the final results of the source OD. It 
provides suggested guidance on evaluation direction, but is not the 
authoritative final answer. Authoritative final answers are provided through 
the published criteria documents and published scheme and international 
interpretations thereof.

Decision Date: 2004-04-08
Last Modified 2004-05-06

Issue

The U.S. Government Firewall protection profiles contain requirements for 
Single-Use Authentication Mechanisms. Would use of certificate-based 
authentication conforming to the IKE protocol satisfy that requirement? This is 
based on the fact that certificate-based authentication is at least as 
effective as single-use mechanisms in meeting the security objectives in the 
protection profiles.

Resolution

IKE is an acceptable instance of a single-use authentication mechanism. As IKE 
is not a FIPS mechanism, the following requirements must be met by the IKE 
implementation.  

   FCS_IKE_EXP.1 Internet Key Exchange

FCS_IKE_EXP.1.1 The TSF shall provide cryptographic key establishment 
techniques in accordance with RFC 2409 as follows(s):  

     * Phase 1, the establishment of a secure authenticated channel
       between the TOE and another remote VPN endpoint, shall be
       performed using one of the following, as configured by the
       security administrator:

     * Main Mode
     * Aggressive Mode]

     * New Group mode shall include the private group 14, 2048-bit MOD P,
       [selection:[assignment: other group modes determined by the ST
       author]"no other group modes"] for the Diffie-Hellman key
       exchange.

     * Phase 2, negotiation of security services for IPsec, shall be done
       using Quick Mode, using SHA-1 as the pseudo-random function. Quick
       Mode shall generate key material that provides perfect forward
       secrecy.

   FCS_IKE_EXP.1.2 The TSF shall require the nonce, and the x of g^xy] be
   randomly generated using FIPS-approved random number generator when
   computation is being performed.

   FCS_IKE_EXP.1.3 When performing authentication using pre-shared keys,
   the key shall be generated using the FIPS approved random number
   generator specified in FCS_COP_EXP.5.1.

   FCS_IKE_EXP.1.4 The TSF shall compute the value of SKEYID (as defined
   in RFC 2409), using SHA-1 as the pseudo-random function. The TSF shall
   be capable of authentication using the methods for

     * Signatures: SKEYID = sha(Ni_b | Nr_b, g^xy)

     * Pre-shared keys: SKEYID = sha(pre-shared-key, Ni_b | Nr_b)

     * [selection: Authentication using Public key encryption, computing
       SKEYID as follows: SKEYID = sha(sha(Ni_b | Nr_b), CKY-I | Nr_b,
       [assignment: other authentication method],"no other
       authentication methods"]

   Application Note: If public key encryption is the method of choice,
   the sha algorithm listed in the requirement will be used. If the
   other option is selected, a different authentication method or a
   different hash algorithm for generating SKEYID may be specified.

   Refer to RFC 2409 for an explanation of the notation and definitions
   of the terms.

   FCS_IKE_EXP.1.5 The TSF shall compute authenticated keying material as
   follows:

     * SKEYID_d = sha(SKEYID, g^xy | CKY-I | CKY-R | 0)

     * SKEYID_a = sha(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)

     * SKEYID_e = sha(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)

     * [selection: [assignment: other methods for computing the
       authenticated keying material], none]]

   Application note: If the assignment is selected, a different method
   for computing the authenticated keying material may be used, or a
   different hash algorithm may be specified.

   FCS_IKE.1.6 To authenticate the Phase 1 exchange, the TSF shall
   generate HASH_I if it is the intiator, or HASH_R if it is the
   responder as follows:

     * HASH_I = sha(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b)

     * HASH_R = sha(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAi_b | IDir_b)

   Application note: Refer to RFC 2409 for an explanation of the notation
   and definitions of the terms.

   FCS_IKE_EXP.1.7 The TSF shall be capable of authenticating IKE Phase 1
   using the following methods as defined in RFC 2409, as configured by
   the security administrator:

     a) Authentication with digital signatures: The TSF shall use
     [selection: RSA, DSA,[selection: [assignment: other digital
     signature algorithms], "no other digital signature algorithms"]]

     b) when an RSA signature is applied to HASH I or HASH R it must be
     first PKCS#1 encoded. The TSF shall check the HASH_I and HASH_R
     values sent against a computed value to detect any changes made to
     the proposed transform negotiated in phase one. If changes are
     detected the session shall be terminated and an alarm shall be
     generated.

     c) [selection:[assignment: X.509 certificates Version 3 [selection:
     other version of X.509 certificates, "no other versions"]] X.509 V3
     implementations, if implemented, shall be capable of checking for
     validity of the certificate path, and at option of SA, check for
     certificate revocation.

     d) Authentication with a pre-shared key: The TSF shall allow
     authentication using a pre-shared key.

   FCS_IKE_EXP.1.7. The TSF shall compute the hash values for Quick Mode
   in the following way

     HASH(1) = sha(SKEYID_a, M-ID | SA | Ni [ | KE ] [ | IDci | IDcr )]

     HASH(2) = sha(SKEYID_a, M-ID | Ni_b |SA| Nr [ | KE ] [ | IDci |
     IDcr)]

     HASH(3) = sha(SKEYID_a, 0 | M-ID | Ni_b | Nr_b)

   Application Note: The following steps will be performed when using the
   HASH computation:

     * initator computes HASH(1) and sends to responder

     * responder validates computation of HASH(1) and computes HASH(2)
       and sends HASH(2) to initiator

     * initiator validates computation of HASH(2) and computes HASH(3)
       and sends HASH(3) to responder

   KE is only optional when SA elects not to use perfect forward secrecy.
   
   Verifying that a TFS implementation actually checks HASH(1) , HASH(2),
   and HASH(3) values sent against a computed value is important in
   detecting changes that could have been made to proposed transform
   negotiated in Quick Mode (not as likely as Phase One because Quick
   Mode is encrypted).

   The ordering of the ISAKMP payloads may differ because Quick Mode only
   specifies the location of the HASH and SA payload.

   FCS_IKE_EXP.1.8 The TSF shall compute new keying material during Quick
   Mode as follows:

   [selection: when using perfect forward secrecy
   KEYMAT = sha(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b),
   When perfect forward secrecy is not used
   KEYMAT = sha(SKEYID_d | protocol | SPI | Ni_b | Nr_b)]

References:

     * Application-Layer Firewall Medium Robustness V1, June 2000,
       Section 5
     * Traffic-Filter Firewall Protection Profile for Medium Robustness
       Environments, V1.4, June 2000, Section 5
     * [02-23-2004] -- FIPS 140-2 Annex D: Approved Key Establishment
       Techniques,
     * FIPS-PUB 140-2, Security Requirements for Cryptographic Modules,
       December 3, 2002
     * RFC 2409 - The Internet Engineering Task Force, The Internet Key
       Exchange (IKE), November 1998
     * W. Diffie, P.C. van Oorschot, and M.J. Wiener, Authentication and
       authenticated key exchanges, Designs, Codes and Cryptography 2
       (1992), 107-125.
     * Common Criteria Security Evaluation Part 2: Security functional
       requirements, August 1999, Version 2.1 annotated with
       interpretations as of 2003-10-31 CCIMB-99-032
     * American National Standards Institute. American National Standard
       X9.31-1992: Public Key Cryptography Using Reversible Algorithms
       for the Financial Services Industry: Part 2: The MDC-2 Hash
       Algorithm, June 1993.
     * U.S. Department of Defense Application-level Firewall Protection
       Profile for Basic Robustness Environments, Version 1.0, June 22,
       2000
     * A One-Time Password System, IETF STD0061, N. Haller et. al.,
       February 1998.
     * U.S. Department of Defense Application-level Firewall Protection
       Profile for Medium Robustness Environments, Version 1.0, June 28,
       2000