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, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [AEAD]     Black, D. and D. McGrew, "Using Authenticated Encryption
              Algorithms with the Encrypted Payload of the Internet Key
              Exchange version 2 (IKEv2) Protocol", RFC 5282,
              August 2008.

   [AESCMACPRF128]
              Song, J., Poovendran, R., Lee, J., and T. Iwata, "The
              Advanced Encryption Standard-Cipher-based Message
              Authentication Code-Pseudo-Random Function-128 (AES-CMAC-
              PRF-128) Algorithm for the Internet Key Exchange Protocol
              (IKE)", RFC 4615, August 2006.

   [AESXCBCPRF128]
              Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
              Internet Key Exchange Protocol (IKE)", RFC 4434,
              February 2006.

   [EAP]      Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

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

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

   [HTTP]     Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [IKEV2IANA]
              "Internet Key Exchange Version 2 (IKEv2) Parameters",
              <http://www.iana.org>.

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

   [MUSTSHOULD]
              Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [PKIX]     Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.

   [RFC4307]  Schiller, J., "Cryptographic Algorithms for Use in the
              Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
              December 2005.

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

   [URLS]     Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

8.2.  Informative References

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

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

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

   [Clarif]   Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
              Implementation Guidelines", RFC 4718, October 2006.

   [DES]      American National Standards Institute, "American National
              Standard for Information Systems-Data Link Encryption",
              ANSI X3.106, 1983.

   [DH]       Diffie, W. and M. Hellman, "New Directions in
              Cryptography", IEEE Transactions on Information Theory,
              V.IT-22 n. 6, June 1977.

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

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

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

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

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

   [DSS]      National Institute of Standards and Technology, U.S.
              Department of Commerce, "Digital Signature Standard",
              Draft FIPS 186-3, June 2008.

   [EAI]      Abel, Y., "Internationalized Email Headers", RFC 5335,
              September 2008.

   [EAP-IANA] "Extensible Authentication Protocol (EAP) Registry: Method
              Types", <http://www.iana.org>.

   [EAPMITM]  N. Asokan, V. Nierni, and K. Nyberg, "Man-in-the-Middle in
              Tunneled Authentication Protocols", November 2002,
              <http://eprint.iacr.org/2002/163>.

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

   [EXCHANGEANALYSIS]
              R. Perlman and C. Kaufman, "Analysis of the IPsec key
              exchange Standard", WET-ICE Security Conference, MIT,
              2001,
              <http://sec.femto.org/wetice-2001/papers/radia-paper.pdf>.

   [H2HIPSEC] Aura, T., Roe, M., and A. Mohammed, "Experiences with
              Host-to-Host IPsec", 13th International Workshop on
              Security Protocols, Cambridge, UK, April 2005.

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

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

   [IDNA]     Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, August 2010.

   [IKEV1]    Harkins, D. and D. Carrel, "The Internet Key Exchange
              (IKE)", RFC 2409, November 1998.

   [IKEV2]    Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

   [IP]       Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

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

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

   [IPV6CONFIG]
              Eronen, P., Laganier, J., and C. Madson, "IPv6
              Configuration in Internet Key Exchange Protocol Version 2
              (IKEv2)", RFC 5739, February 2010.

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

   [MAILFORMAT]
              Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008.

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

   [MIPV6]    Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [MLDV2]    Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

   [MOBIKE]   Eronen, P., "IKEv2 Mobility and Multihoming Protocol
              (MOBIKE)", RFC 4555, June 2006.

   [MODES]    National Institute of Standards and Technology, U.S.
              Department of Commerce, "Recommendation for Block Cipher
              Modes of Operation", SP 800-38A, 2001.

   [NAI]      Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
              Network Access Identifier", RFC 4282, December 2005.

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

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

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

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

   [REAUTH]   Nir, Y., "Repeated Authentication in Internet Key Exchange
              (IKEv2) Protocol", RFC 4478, April 2006.

   [REUSE]    Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In
              Diffie-Hellman  Key Agreement Protocols", December 2008,
              <http://www.cacr.math.uwaterloo.ca/techreports/2008/
              cacr2008-24.pdf>.

   [ROHCV2]   Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C.
              Bormann, "IKEv2 Extensions to Support Robust Header
              Compression over IPsec", RFC 5857, May 2010.

   [RSA]      R. Rivest, A. Shamir, and L. Adleman, "A Method for
              Obtaining Digital Signatures and Public-Key
              Cryptosystems", February 1978.

   [SHA]      National Institute of Standards and Technology, U.S.
              Department of Commerce, "Secure Hash Standard",
              FIPS 180-3, October 2008.

   [SIGMA]    H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to
              Authenticated Diffie-Hellman and its Use in the IKE
              Protocols", Advances in Cryptography - CRYPTO 2003
              Proceedings LNCS 2729, 2003, <http://
              www.informatik.uni-trier.de/~ley/db/conf/crypto/
              crypto2003.html>.

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

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

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
        [EXCHANGEANALYSIS];

   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;

   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 in order to make it
        easier to make future revisions in a way that does not break
        backward compatibility;

   11.  To simplify and clarify how shared state is maintained in the
        presence of network failures and DoS 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 [OAKLEY].

   The strength supplied by group 1 may not be sufficient for typical
   uses 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.

Appendix C.  Exchanges and Payloads

   This appendix contains a short summary of the IKEv2 exchanges, and
   what payloads can appear in which message.  This appendix is purely
   informative; if it disagrees with the body of this document, the
   other text is considered correct.

   Vendor ID (V) payloads may be included in any place in any message.
   This sequence here shows what are the most logical places for them.

C.1.  IKE_SA_INIT Exchange

   request             --> [N(COOKIE)],
                           SA, KE, Ni,
                           [N(NAT_DETECTION_SOURCE_IP)+,
                            N(NAT_DETECTION_DESTINATION_IP)],
                           [V+][N+]

   normal response     <-- SA, KE, Nr,
   (no cookie)             [N(NAT_DETECTION_SOURCE_IP),
                            N(NAT_DETECTION_DESTINATION_IP)],
                           [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
                           [V+][N+]

   cookie response     <-- N(COOKIE),
                           [V+][N+]

   different Diffie-   <-- N(INVALID_KE_PAYLOAD),
   Hellman group           [V+][N+]
   wanted

C.2.  IKE_AUTH Exchange without EAP

   request             --> IDi, [CERT+],
                           [N(INITIAL_CONTACT)],
                           [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
                           [IDr],
                           AUTH,
                           [CP(CFG_REQUEST)],
                           [N(IPCOMP_SUPPORTED)+],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, TSi, TSr,
                           [V+][N+]

   response            <-- IDr, [CERT+],
                           AUTH,
                           [CP(CFG_REPLY)],
                           [N(IPCOMP_SUPPORTED)],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, TSi, TSr,
                           [N(ADDITIONAL_TS_POSSIBLE)],
                           [V+][N+]

   error in Child SA  <--  IDr, [CERT+],
   creation                AUTH,
                           N(error),
                           [V+][N+]

C.3.  IKE_AUTH Exchange with EAP

   first request       --> IDi,
                           [N(INITIAL_CONTACT)],
                           [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
                           [IDr],
                           [CP(CFG_REQUEST)],
                           [N(IPCOMP_SUPPORTED)+],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, TSi, TSr,
                           [V+][N+]

   first response      <-- IDr, [CERT+], AUTH,
                           EAP,
                           [V+][N+]

                     / --> EAP
   repeat 1..N times |
                     \ <-- EAP

   last request        --> AUTH

   last response       <-- AUTH,
                           [CP(CFG_REPLY)],
                           [N(IPCOMP_SUPPORTED)],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, TSi, TSr,
                           [N(ADDITIONAL_TS_POSSIBLE)],
                           [V+][N+]

C.4.  CREATE_CHILD_SA Exchange for Creating or Rekeying Child SAs

   request             --> [N(REKEY_SA)],
                           [CP(CFG_REQUEST)],
                           [N(IPCOMP_SUPPORTED)+],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, Ni, [KEi], TSi, TSr
                           [V+][N+]

   normal              <-- [CP(CFG_REPLY)],
   response                [N(IPCOMP_SUPPORTED)],
                           [N(USE_TRANSPORT_MODE)],
                           [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
                           [N(NON_FIRST_FRAGMENTS_ALSO)],
                           SA, Nr, [KEr], TSi, TSr,
                           [N(ADDITIONAL_TS_POSSIBLE)]
                           [V+][N+]

   error case          <-- N(error)

   different Diffie-   <-- N(INVALID_KE_PAYLOAD),
   Hellman group           [V+][N+]
   wanted

C.5.  CREATE_CHILD_SA Exchange for Rekeying the IKE SA

   request             --> SA, Ni, KEi
                           [V+][N+]

   response            <-- SA, Nr, KEr
                           [V+][N+]

C.6.  INFORMATIONAL Exchange

   request             --> [N+],
                           [D+],
                           [CP(CFG_REQUEST)]

   response            <-- [N+],
                           [D+],
                           [CP(CFG_REPLY)]

Authors' Addresses

   Charlie Kaufman
   Microsoft
   1 Microsoft Way
   Redmond, WA  98052
   US

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


   Paul Hoffman
   VPN Consortium
   127 Segre Place
   Santa Cruz, CA  95060
   US

   Phone: 1-831-426-9827
   EMail: paul.hoffman@vpnc.org


   Yoav Nir
   Check Point Software Technologies Ltd.
   5 Hasolelim St.
   Tel Aviv 67897
   Israel

   EMail: ynir@checkpoint.com


   Pasi Eronen
   Independent

   EMail: pe@iki.fi