Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 4306

Internet Key Exchange (IKEv2) Protocol

Pages: 99
Obsoletes:  240724082409
Obsoleted by:  5996
Updated by:  5282
Part 5 of 5 – Pages 88 to 99
First   Prev   None

ToP   noToC   RFC4306 - Page 88   prevText

5. Security Considerations

While this protocol is designed to minimize disclosure of configuration information to unauthenticated peers, some such disclosure is unavoidable. One peer or the other must identify itself first and prove its identity first. To avoid probing, the initiator of an exchange is required to identify itself first, and usually is required to authenticate itself first. The initiator can, however, learn that the responder supports IKE and what cryptographic protocols it supports. The responder (or someone impersonating the responder) can probe the initiator not only for its identity, but using CERTREQ payloads may be able to determine what certificates the initiator is willing to use. Use of EAP authentication changes the probing possibilities somewhat. When EAP authentication is used, the responder proves its identity before the initiator does, so an initiator that knew the name of a valid initiator could probe the responder for both its name and certificates. Repeated rekeying using CREATE_CHILD_SA without additional Diffie- Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a single key or overrun of either endpoint. Implementers should take note of this fact and set a limit on CREATE_CHILD_SA exchanges between exponentiations. This memo does not prescribe such a limit. The strength of a key derived from a Diffie-Hellman exchange using any of the groups defined here depends on the inherent strength of the group, the size of the exponent used, and the entropy provided by the random number generator used. Due to these inputs, it is difficult to determine the strength of a key for any of the defined groups. Diffie-Hellman group number two, when used with a strong random number generator and an exponent no less than 200 bits, is common for use with 3DES. Group five provides greater security than group two. Group one is for historic purposes only and does not provide sufficient strength except for use with DES, which is also for historic use only. Implementations should make note of these estimates when establishing policy and negotiating security parameters. Note that these limitations are on the Diffie-Hellman groups themselves. There is nothing in IKE that prohibits using stronger groups nor is there anything that will dilute the strength obtained from stronger groups (limited by the strength of the other algorithms negotiated including the prf function). In fact, the extensible framework of IKE encourages the definition of more groups; use of elliptical curve groups may greatly increase strength using much smaller numbers.
ToP   noToC   RFC4306 - Page 89
   It is assumed that all Diffie-Hellman exponents are erased from
   memory after use.  In particular, these exponents MUST NOT be derived
   from long-lived secrets like the seed to a pseudo-random generator
   that is not erased after use.

   The strength of all keys is limited by the size of the output of the
   negotiated prf function.  For this reason, a prf function whose
   output is less than 128 bits (e.g., 3DES-CBC) MUST NOT be used with
   this protocol.

   The security of this protocol is critically dependent on the
   randomness of the randomly chosen parameters.  These should be
   generated by a strong random or properly seeded pseudo-random source
   (see [RFC4086]).  Implementers should take care to ensure that use of
   random numbers for both keys and nonces is engineered in a fashion
   that does not undermine the security of the keys.

   For information on the rationale of many of the cryptographic design
   choices in this protocol, see [SIGMA] and [SKEME].  Though the
   security of negotiated CHILD_SAs does not depend on the strength of
   the encryption and integrity protection negotiated in the IKE_SA,
   implementations MUST NOT negotiate NONE as the IKE integrity
   protection algorithm or ENCR_NULL as the IKE encryption algorithm.

   When using pre-shared keys, a critical consideration is how to assure
   the randomness of these secrets.  The strongest practice is to ensure
   that any pre-shared key contain as much randomness as the strongest
   key being negotiated.  Deriving a shared secret from a password,
   name, or other low-entropy source is not secure.  These sources are
   subject to dictionary and social engineering attacks, among others.

   The NAT_DETECTION_*_IP notifications contain a hash of the addresses
   and ports in an attempt to hide internal IP addresses behind a NAT.
   Since the IPv4 address space is only 32 bits, and it is usually very
   sparse, it would be possible for an attacker to find out the internal
   address used behind the NAT box by trying all possible IP addresses
   and trying to find the matching hash.  The port numbers are normally
   fixed to 500, and the SPIs can be extracted from the packet.  This
   reduces the number of hash calculations to 2^32.  With an educated
   guess of the use of private address space, the number of hash
   calculations is much smaller.  Designers should therefore not assume
   that use of IKE will not leak internal address information.

   When using an EAP authentication method that does not generate a
   shared key for protecting a subsequent AUTH payload, certain man-in-
   the-middle and server impersonation attacks are possible [EAPMITM].
   These vulnerabilities occur when EAP is also used in protocols that
   are not protected with a secure tunnel.  Since EAP is a general-
ToP   noToC   RFC4306 - Page 90
   purpose authentication protocol, which is often used to provide
   single-signon facilities, a deployed IPsec solution that relies on an
   EAP authentication method that does not generate a shared key (also
   known as a non-key-generating EAP method) can become compromised due
   to the deployment of an entirely unrelated application that also
   happens to use the same non-key-generating EAP method, but in an
   unprotected fashion.  Note that this vulnerability is not limited to
   just EAP, but can occur in other scenarios where an authentication
   infrastructure is reused.  For example, if the EAP mechanism used by
   IKEv2 utilizes a token authenticator, a man-in-the-middle attacker
   could impersonate the web server, intercept the token authentication
   exchange, and use it to initiate an IKEv2 connection.  For this
   reason, use of non-key-generating EAP methods SHOULD be avoided where
   possible.  Where they are used, it is extremely important that all
   usages of these EAP methods SHOULD utilize a protected tunnel, where
   the initiator validates the responder's certificate before initiating
   the EAP exchange.  Implementers SHOULD describe the vulnerabilities
   of using non-key-generating EAP methods in the documentation of their
   implementations so that the administrators deploying IPsec solutions
   are aware of these dangers.

   An implementation using EAP MUST also use a public-key-based
   authentication of the server to the client before the EAP exchange
   begins, even if the EAP method offers mutual authentication.  This
   avoids having additional IKEv2 protocol variations and protects the
   EAP data from active attackers.

   If the messages of IKEv2 are long enough that IP-level fragmentation
   is necessary, it is possible that attackers could prevent the
   exchange from completing by exhausting the reassembly buffers.  The
   chances of this can be minimized by using the Hash and URL encodings
   instead of sending certificates (see section 3.6).  Additional
   mitigations are discussed in [KPS03].

6. IANA Considerations

This document defines a number of new field types and values where future assignments will be managed by the IANA. The following registries have been created by the IANA: IKEv2 Exchange Types (section 3.1) IKEv2 Payload Types (section 3.2) IKEv2 Transform Types (section 3.3.2) IKEv2 Transform Attribute Types (section 3.3.2) IKEv2 Encryption Transform IDs (section 3.3.2) IKEv2 Pseudo-random Function Transform IDs (section 3.3.2) IKEv2 Integrity Algorithm Transform IDs (section 3.3.2)
ToP   noToC   RFC4306 - Page 91
          IKEv2 Diffie-Hellman Transform IDs (section 3.3.2)
      IKEv2 Identification Payload ID Types (section 3.5)
      IKEv2 Certificate Encodings (section 3.6)
      IKEv2 Authentication Method (section 3.8)
      IKEv2 Notify Message Types (section 3.10.1)
          IKEv2 Notification IPCOMP Transform IDs (section 3.10.1)
      IKEv2 Security Protocol Identifiers (section 3.3.1)
      IKEv2 Traffic Selector Types (section 3.13.1)
      IKEv2 Configuration Payload CFG Types (section 3.15)
      IKEv2 Configuration Payload Attribute Types (section 3.15.1)

   Note: When creating a new Transform Type, a new registry for it must
   be created.

   Changes and additions to any of those registries are by expert

7. Acknowledgements

This document is a collaborative effort of the entire IPsec WG. If there were no limit to the number of authors that could appear on an RFC, the following, in alphabetical order, would have been listed: Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer Reingold, and Michael Richardson. Many other people contributed to the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI, each of which has its own list of authors. Hugh Daniel suggested the feature of having the initiator, in message 3, specify a name for the responder, and gave the feature the cute name "You Tarzan, Me Jane". David Faucher and Valery Smyzlov helped refine the design of the traffic selector negotiation.

8. References

8.1. Normative References

[ADDGROUP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003. [ADDRIPV6] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [Bra97] Bradner, S., "Key Words for use in RFCs to indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
ToP   noToC   RFC4306 - Page 92
   [EAP]      Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
              3748, June 2004.

   [ESPCBC]   Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
              Algorithms", RFC 2451, November 1998.

   [Hutt05]   Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
              Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC
              3948, January 2005.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP", RFC
              3168, September 2001.

   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
              X.509 Public Key Infrastructure Certificate and
              Certificate Revocation List (CRL) Profile", RFC 3280,
              April 2002.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

8.2. Informative References

[DES] ANSI X3.106, "American National Standard for Information Systems-Data Link Encryption", American National Standards Institute, 1983. [DH] Diffie, W., and Hellman M., "New Directions in Cryptography", IEEE Transactions on Information Theory, V. IT-22, n. 6, June 1977. [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [DSS] NIST, "Digital Signature Standard", FIPS 186, National Institute of Standards and Technology, U.S. Department of Commerce, May, 1994. [EAPMITM] Asokan, N., Nierni, V., and Nyberg, K., "Man-in-the-Middle in Tunneled Authentication Protocols",, November 2002.
ToP   noToC   RFC4306 - Page 93
   [HC98]     Harkins, D. and D. Carrel, "The Internet Key Exchange
              (IKE)", RFC 2409, November 1998.

   [IDEA]     Lai, X., "On the Design and Security of Block Ciphers,"
              ETH Series in Information Processing, v. 1, Konstanz:
              Hartung-Gorre Verlag, 1992.

   [IPCOMP]   Shacham, A., Monsour, B., Pereira, R., and M.  Thomas, "IP
              Payload Compression Protocol (IPComp)", RFC 3173,
              September 2001.

   [KPS03]    Kaufman, C., Perlman, R., and Sommerfeld, B., "DoS
              protection for UDP-based protocols", ACM Conference on
              Computer and Communications Security, October 2003.

   [KBC96]    Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104, February

   [LDAP]     Wahl, M., Howes, T., and S  Kille, "Lightweight Directory
              Access Protocol (v3)", RFC 2251, December 1997.

   [MD5]      Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              April 1992.

   [MSST98]   Maughan, D., Schertler, M., Schneider, M., and J. Turner,
              "Internet Security Association and Key Management Protocol
              (ISAKMP)", RFC 2408, November 1998.

   [Orm96]    Orman, H., "The OAKLEY Key Determination Protocol", RFC
              2412, November 1998.

   [PFKEY]    McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
              Management API, Version 2", RFC 2367, July 1998.

   [PKCS1]    Jonsson, J. and B. Kaliski, "Public-Key Cryptography
              Standards (PKCS) #1: RSA Cryptography Specifications
              Version 2.1", RFC 3447, February 2003.

   [PK01]     Perlman, R., and Kaufman, C., "Analysis of the IPsec key
              exchange Standard", WET-ICE Security Conference, MIT,2001,

   [Pip98]    Piper, D., "The Internet IP Security Domain Of
              Interpretation for ISAKMP", RFC 2407, November 1998.
ToP   noToC   RFC4306 - Page 94
   [RADIUS]   Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)", RFC
              2865, June 2000.

   [RFC4086]  Eastlake, D., 3rd, Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              June 2005.

   [RFC1958]  Carpenter, B., "Architectural Principles of the Internet",
              RFC 1958, June 1996.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474, December

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Service", RFC 2475, December 1998.

   [RFC2522]  Karn, P. and W. Simpson, "Photuris: Session-Key Management
              Protocol", RFC 2522, March 1999.

   [RFC2775]  Carpenter, B., "Internet Transparency", RFC 2775, February

   [RFC2983]  Black, D., "Differentiated Services and Tunnels", RFC
              2983, October 2000.

   [RFC3439]  Bush, R. and D. Meyer, "Some Internet Architectural
              Guidelines and Philosophy", RFC 3439, December 2002.

   [RFC3715]  Aboba, B. and W. Dixon, "IPsec-Network Address Translation
              (NAT) Compatibility Requirements", RFC 3715, March 2004.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302, December

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
              4303, December 2005.

   [RSA]      Rivest, R., Shamir, A., and Adleman, L., "A Method for
              Obtaining Digital Signatures and Public-Key
              Cryptosystems", Communications of the ACM, v. 21, n. 2,
              February 1978.
ToP   noToC   RFC4306 - Page 95
   [SHA]      NIST, "Secure Hash Standard", FIPS 180-1, National
              Institute of Standards and Technology, U.S. Department of
              Commerce, May 1994.

   [SIGMA]    Krawczyk, H., "SIGMA: the `SIGn-and-MAc' Approach to
              Authenticated Diffie-Hellman and its Use in the IKE
              Protocols", in Advances in Cryptography - CRYPTO 2003
              Proceedings, LNCS 2729, Springer, 2003.  Available at:

   [SKEME]    Krawczyk, H., "SKEME: A Versatile Secure Key Exchange
              Mechanism for Internet", from IEEE Proceedings of the 1996
              Symposium on Network and Distributed Systems Security.

   [X.501]    ITU-T Recommendation X.501: Information Technology - Open
              Systems Interconnection - The Directory: Models, 1993.

   [X.509]    ITU-T Recommendation X.509 (1997 E): Information
              Technology - Open Systems Interconnection - The Directory:
              Authentication Framework, June 1997.
ToP   noToC   RFC4306 - Page 96

Appendix A: Summary of changes from IKEv1

The goals of this revision to IKE are: 1) To define the entire IKE protocol in a single document, replacing RFCs 2407, 2408, and 2409 and incorporating subsequent changes to support NAT Traversal, Extensible Authentication, and Remote Address acquisition; 2) To simplify IKE by replacing the eight different initial exchanges with a single four-message exchange (with changes in authentication mechanisms affecting only a single AUTH payload rather than restructuring the entire exchange) see [PK01]; 3) To remove the Domain of Interpretation (DOI), Situation (SIT), and Labeled Domain Identifier fields, and the Commit and Authentication only bits; 4) To decrease IKE's latency in the common case by making the initial exchange be 2 round trips (4 messages), and allowing the ability to piggyback setup of a CHILD_SA on that exchange; 5) To replace the cryptographic syntax for protecting the IKE messages themselves with one based closely on ESP to simplify implementation and security analysis; 6) To reduce the number of possible error states by making the protocol reliable (all messages are acknowledged) and sequenced. This allows shortening CREATE_CHILD_SA exchanges from 3 messages to 2; 7) To increase robustness by allowing the responder to not do significant processing until it receives a message proving that the initiator can receive messages at its claimed IP address, and not commit any state to an exchange until the initiator can be cryptographically authenticated; 8) To fix cryptographic weaknesses such as the problem with symmetries in hashes used for authentication documented by Tero Kivinen; 9) To specify Traffic Selectors in their own payloads type rather than overloading ID payloads, and making more flexible the Traffic Selectors that may be specified; 10) To specify required behavior under certain error conditions or when data that is not understood is received, to make it easier to make future revisions that do not break backward compatibility;
ToP   noToC   RFC4306 - Page 97
   11) To simplify and clarify how shared state is maintained in the
   presence of network failures and Denial of Service attacks; and

   12) To maintain existing syntax and magic numbers to the extent
   possible to make it likely that implementations of IKEv1 can be
   enhanced to support IKEv2 with minimum effort.

Appendix B: Diffie-Hellman Groups

There are two Diffie-Hellman groups defined here for use in IKE. These groups were generated by Richard Schroeppel at the University of Arizona. Properties of these primes are described in [Orm96]. The strength supplied by group one may not be sufficient for the mandatory-to-implement encryption algorithm and is here for historic reasons. Additional Diffie-Hellman groups have been defined in [ADDGROUP].

B.1. Group 1 - 768 Bit MODP

This group is assigned id 1 (one). The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } Its hexadecimal value is: FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF The generator is 2.

B.2. Group 2 - 1024 Bit MODP

This group is assigned id 2 (two). The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. Its hexadecimal value is: FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 FFFFFFFF FFFFFFFF The generator is 2.
ToP   noToC   RFC4306 - Page 98

Editor's Address

Charlie Kaufman Microsoft Corporation 1 Microsoft Way Redmond, WA 98052 Phone: 1-425-707-3335 EMail:
ToP   noToC   RFC4306 - Page 99
Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-


   Funding for the RFC Editor function is currently provided by the
   Internet Society.