[Public Interpretations Database]

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

This decision represents a long-term technical decision based on an OD, and may not be the same as the final results of the source OD. With respect to published criteria documentation and scheme documents, it provides suggested guidance on evaluation direction, but is not authoritative. Authoritative decisions are provided through the published criteria documents and published scheme and international interpretations thereof. With respect to published PPs, PDs are authoritative corrections to the PP, based on input from the PP author (if available), that are in force until the publication of the next revision of that PP.

Effective Date: 2004-04-20
Last Modified 2006-08-02

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)]

Modification History:

2004-08-12
Updated effective date to reflect the date the PD was issued. (August 2004 NIB 6.c.xiv)

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

Related NIs:

  • None

Related CCIMB-INTERPs:

  • None

Source OD: 0229