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.

   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-

   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)

          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
   review.

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.

   [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",
              http://eprint.iacr.org/2002/163, November 2002.

   [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
              1997.

   [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,
              http://sec.femto.org/wetice-2001/papers/radia-paper.pdf.

   [Pip98]    Piper, D., "The Internet IP Security Domain Of
              Interpretation for ISAKMP", RFC 2407, November 1998.

   [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
              1998.

   [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
              2000.

   [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
              2005.

   [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.

   [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:
              http://www.informatik.uni-trier.de/~ley/db/conf/
              crypto/crypto2003.html.

   [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.

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;

   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.

Editor's Address

   Charlie Kaufman
   Microsoft Corporation
   1 Microsoft Way
   Redmond, WA 98052

   Phone: 1-425-707-3335
   EMail: charliek@microsoft.com

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
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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
   http://www.ietf.org/ipr.

   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-
   ipr@ietf.org.

Acknowledgement

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