Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 7296


Internet Key Exchange Protocol Version 2 (IKEv2)

Part 6 of 6, p. 124 to 142
Prev RFC Part


prevText      Top      Up      ToC       Page 124 
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) not only can probe the initiator for its identity but may,
   by using CERTREQ payloads, 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

   Repeated rekeying using CREATE_CHILD_SA without additional Diffie-
   Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a
   single key.  Implementers should take note of this fact and set a
   limit on CREATE_CHILD_SA exchanges between exponentiations.  This
   document 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

   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

Top      Up      ToC       Page 125 
   negotiated including the PRF).  In fact, the extensible framework of
   IKE encourages the definition of more groups; use of elliptic curve
   groups may greatly increase strength using much smaller numbers.

   It is assumed that all Diffie-Hellman exponents are erased from
   memory after use.

   The IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator
   has been authenticated.  As a result, an implementation of this
   protocol needs to be completely robust when deployed on any insecure
   network.  Implementation vulnerabilities, particularly DoS attacks,
   can be exploited by unauthenticated peers.  This issue is
   particularly worrisome because of the unlimited number of messages in
   EAP-based authentication.

   The strength of all keys is limited by the size of the output of the
   negotiated PRF.  For this reason, a PRF 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 pseudorandom source
   (see [RANDOMNESS]).  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

Top      Up      ToC       Page 126 
   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 authentication.  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
   authentication 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 [DOSUDPPROT].

   Admission control is critical to the security of the protocol.  For
   example, trust anchors used for identifying IKE peers should probably
   be different than those used for other forms of trust, such as those
   used to identify public web servers.  Moreover, although IKE provides
   a great deal of leeway in defining the security policy for a trusted

Top      Up      ToC       Page 127 
   peer's identity, credentials, and the correlation between them,
   having such security policy defined explicitly is essential to a
   secure implementation.

5.1.  Traffic Selector Authorization

   IKEv2 relies on information in the Peer Authorization Database (PAD)
   when determining what kind of Child SAs a peer is allowed to create.
   This process is described in Section 4.4.3 of [IPSECARCH].  When a
   peer requests the creation of a Child SA with some Traffic Selectors,
   the PAD must contain "Child SA Authorization Data" linking the
   identity authenticated by IKEv2 and the addresses permitted for
   Traffic Selectors.

   For example, the PAD might be configured so that authenticated
   identity "" is allowed to create Child SAs for, meaning this security gateway is a valid
   "representative" for these addresses.  Host-to-host IPsec requires
   similar entries, linking, for example, "" with, meaning this identity is a valid "owner" or
   "representative" of the address in question.

   As noted in [IPSECARCH], "It is necessary to impose these constraints
   on creation of child SAs to prevent an authenticated peer from
   spoofing IDs associated with other, legitimate peers".  In the
   example given above, a correct configuration of the PAD prevents
   sgw23 from creating Child SAs with address, and
   prevents fooserver4 from creating Child SAs with addresses from

   It is important to note that simply sending IKEv2 packets using some
   particular address does not imply a permission to create Child SAs
   with that address in the Traffic Selectors.  For example, even if
   sgw23 would be able to spoof its IP address as, it
   could not create Child SAs matching fooserver4's traffic.

   The IKEv2 specification does not specify how exactly IP address
   assignment using Configuration payloads interacts with the PAD.  Our
   interpretation is that when a security gateway assigns an address
   using Configuration payloads, it also creates a temporary PAD entry
   linking the authenticated peer identity and the newly allocated inner

   It has been recognized that configuring the PAD correctly may be
   difficult in some environments.  For instance, if IPsec is used
   between a pair of hosts whose addresses are allocated dynamically
   using DHCP, it is extremely difficult to ensure that the PAD

Top      Up      ToC       Page 128 
   specifies the correct "owner" for each IP address.  This would
   require a mechanism to securely convey address assignments from the
   DHCP server, and link them to identities authenticated using IKEv2.

   Due to this limitation, some vendors have been known to configure
   their PADs to allow an authenticated peer to create Child SAs with
   Traffic Selectors containing the same address that was used for the
   IKEv2 packets.  In environments where IP spoofing is possible (i.e.,
   almost everywhere) this essentially allows any peer to create Child
   SAs with any Traffic Selectors.  This is not an appropriate or secure
   configuration in most circumstances.  See [H2HIPSEC] for an extensive
   discussion about this issue, and the limitations of host-to-host
   IPsec in general.

6.  IANA Considerations

   [IKEV2] defined many field types and values.  IANA has already
   registered those types and values in [IKEV2IANA], so they are not
   listed here again.

   One item has been deprecated from the "IKEv2 Certificate Encodings"
   registry: "Raw RSA Key".

   IANA has updated all references to RFC 5996 to point to this

7.  References

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

Top      Up      ToC       Page 129 
              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,

              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,

              IANA, "Internet Key Exchange Version 2 (IKEv2)

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

              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,

Top      Up      ToC       Page 130 
   [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, <>.

              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,

7.2.  Informative References

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

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

              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.

Top      Up      ToC       Page 131 
              Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, December 1998,

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

              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,

              Kaufman, C., Perlman, R., 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
              (DSS)", FIPS 186-4, July 2013,

   [EAI]      Yang, A., Steele, S., and N. Freed, "Internationalized
              Email Headers", RFC 6532, February 2012,

   [EAP-IANA] IANA, "Extensible Authentication Protocol (EAP) Registry:
              Method Types",

   [EAPMITM]  Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
              in Tunneled Authentication Protocols", November 2002,

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

Top      Up      ToC       Page 132 
              Perlman, R. and C. Kaufman, "Analysis of the IPsec key
              exchange Standard", WET-ICE Security Conference, MIT,
              2001, <

              National Institute of Standards and Technology, U.S.
              Department of Commerce, "Secure Hash Standard (SHS)", FIPS
              180-4, March 2012,

   [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]     Lai, X., "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, <>.

Top      Up      ToC       Page 133 
              Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998,

              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,

              Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008, <>.

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

   [MIPV6]    Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011,

   [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]    Dworkin, M., "Recommendation for Block Cipher Modes of
              Operation", National Institute of Standards and
              Technology, NIST Special Publication 800-38A 2001 Edition,
              December 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,

Top      Up      ToC       Page 134 
   [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,

              Eastlake 3rd, 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,

   [RFC4945]  Korver, B., "The Internet IP Security PKI Profile of
              IKEv1/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007,

   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
              5996, September 2010,

   [RFC6989]  Sheffer, Y. and S. Fluhrer, "Additional Diffie-Hellman
              Tests for the Internet Key Exchange Protocol Version 2
              (IKEv2)", RFC 6989, July 2013,

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

Top      Up      ToC       Page 135 
   [SIGMA]    Krawczyk, H., "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,

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

              Carpenter, B., "Internet Transparency", RFC 2775, February
              2000, <>.

Top      Up      ToC       Page 136 
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

   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

   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;

Top      Up      ToC       Page 137 
   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:

   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:

   29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
   EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
   E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
   EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381

   The generator is 2.

Top      Up      ToC       Page 138 
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,

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

   cookie response     <-- N(COOKIE),

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

C.2.  IKE_AUTH Exchange without EAP

   request             --> IDi, [CERT+,]
                           [[N(HTTP_CERT_LOOKUP_SUPPORTED),] CERTREQ+,]
                           SA, TSi, TSr,

Top      Up      ToC       Page 139 
   response            <-- IDr, [CERT+,]
                           SA, TSi, TSr,

   error in Child SA  <--  IDr, [CERT+,]
   creation                AUTH,

C.3.  IKE_AUTH Exchange with EAP

   first request       --> IDi,
                           [[N(HTTP_CERT_LOOKUP_SUPPORTED),] CERTREQ+,]
                           SA, TSi, TSr,

   first response      <-- IDr, [CERT+,] AUTH,

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

Top      Up      ToC       Page 140 
   last request        --> AUTH

   last response       <-- AUTH,
                           SA, TSi, TSr,

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

   request             --> [N(REKEY_SA),]
                           SA, Ni, [KEi,] TSi, TSr,

   normal              <-- [CP(CFG_REPLY),]
   response                [N(IPCOMP_SUPPORTED),]
                           SA, Nr, [KEr,] TSi, TSr,

   error case          <-- N(error)

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

C.5.  CREATE_CHILD_SA Exchange for Rekeying the IKE SA

   request             --> SA, Ni, KEi,

   response            <-- SA, Nr, KEr,

Top      Up      ToC       Page 141 

   request             --> [N+,]

   response            <-- [N+,]


   Many individuals in the IPsecME Working Group were very helpful in
   contributing ideas and text for this document, as well as in
   reviewing the clarifications suggested by others.

   The acknowledgements from the IKEv2 document were:

   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 Smyslov helped refine the design of the
   Traffic Selector negotiation.

Top      Up      ToC       Page 142 
Authors' Addresses

   Charlie Kaufman
   1 Microsoft Way
   Redmond, WA  98052
   United States


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

   Phone: 1-831-426-9827

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


   Pasi Eronen


   Tero Kivinen
   INSIDE Secure
   Eerikinkatu 28
   HELSINKI  FI-00180