tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5996


Pages: 138
Top     in Index     Prev     Next
 

Internet Key Exchange Protocol Version 2 (IKEv2)

Part 1 of 6, p. 1 to 22
None       Next RFC Part

Obsoleted by:    7296
Obsoletes:    4306    4718
Updated by:    5998    6989


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                        C. Kaufman
Request for Comments: 5996                                     Microsoft
Obsoletes: 4306, 4718                                         P. Hoffman
Category: Standards Track                                 VPN Consortium
ISSN: 2070-1721                                                   Y. Nir
                                                             Check Point
                                                               P. Eronen
                                                             Independent
                                                          September 2010


            Internet Key Exchange Protocol Version 2 (IKEv2)

Abstract

   This document describes version 2 of the Internet Key Exchange (IKE)
   protocol.  IKE is a component of IPsec used for performing mutual
   authentication and establishing and maintaining Security Associations
   (SAs).  This document replaces and updates RFC 4306, and includes all
   of the clarifications from RFC 4718.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc5996.

Page 2 
Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

Table of Contents

   1. Introduction ....................................................5
      1.1. Usage Scenarios ............................................6
           1.1.1. Security Gateway to Security Gateway in
                  Tunnel Mode .........................................7
           1.1.2. Endpoint-to-Endpoint Transport Mode .................7
           1.1.3. Endpoint to Security Gateway in Tunnel Mode .........8
           1.1.4. Other Scenarios .....................................9
      1.2. The Initial Exchanges ......................................9
      1.3. The CREATE_CHILD_SA Exchange ..............................13
           1.3.1. Creating New Child SAs with the
                  CREATE_CHILD_SA Exchange ...........................14
           1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA
                  Exchange ...........................................15
           1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA
                  Exchange ...........................................16
      1.4. The INFORMATIONAL Exchange ................................17
           1.4.1. Deleting an SA with INFORMATIONAL Exchanges ........17
      1.5. Informational Messages outside of an IKE SA ...............18
      1.6. Requirements Terminology ..................................19

Top      ToC       Page 3 
      1.7. Significant Differences between RFC 4306 and This
           Document ..................................................20
   2. IKE Protocol Details and Variations ............................22
      2.1. Use of Retransmission Timers ..............................23
      2.2. Use of Sequence Numbers for Message ID ....................24
      2.3. Window Size for Overlapping Requests ......................25
      2.4. State Synchronization and Connection Timeouts .............26
      2.5. Version Numbers and Forward Compatibility .................28
      2.6. IKE SA SPIs and Cookies ...................................30
           2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD .......33
      2.7. Cryptographic Algorithm Negotiation .......................34
      2.8. Rekeying ..................................................34
           2.8.1. Simultaneous Child SA Rekeying .....................36
           2.8.2. Simultaneous IKE SA Rekeying .......................39
           2.8.3. Rekeying the IKE SA versus Reauthentication ........40
      2.9. Traffic Selector Negotiation ..............................40
           2.9.1. Traffic Selectors Violating Own Policy .............43
      2.10. Nonces ...................................................44
      2.11. Address and Port Agility .................................44
      2.12. Reuse of Diffie-Hellman Exponentials .....................44
      2.13. Generating Keying Material ...............................45
      2.14. Generating Keying Material for the IKE SA ................46
      2.15. Authentication of the IKE SA .............................47
      2.16. Extensible Authentication Protocol Methods ...............50
      2.17. Generating Keying Material for Child SAs .................52
      2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange ........53
      2.19. Requesting an Internal Address on a Remote Network .......53
      2.20. Requesting the Peer's Version ............................55
      2.21. Error Handling ...........................................56
           2.21.1. Error Handling in IKE_SA_INIT .....................56
           2.21.2. Error Handling in IKE_AUTH ........................57
           2.21.3. Error Handling after IKE SA is Authenticated ......58
           2.21.4. Error Handling Outside IKE SA .....................58
      2.22. IPComp ...................................................59
      2.23. NAT Traversal ............................................60
           2.23.1. Transport Mode NAT Traversal ......................64
      2.24. Explicit Congestion Notification (ECN) ...................68
      2.25. Exchange Collisions ......................................68
           2.25.1. Collisions while Rekeying or Closing Child SAs ....69
           2.25.2. Collisions while Rekeying or Closing IKE SAs ......69
   3. Header and Payload Formats .....................................69
      3.1. The IKE Header ............................................70
      3.2. Generic Payload Header ....................................73
      3.3. Security Association Payload ..............................75
           3.3.1. Proposal Substructure ..............................78
           3.3.2. Transform Substructure .............................79
           3.3.3. Valid Transform Types by Protocol ..................82
           3.3.4. Mandatory Transform IDs ............................83

Top      ToC       Page 4 
           3.3.5. Transform Attributes ...............................84
           3.3.6. Attribute Negotiation ..............................86
      3.4. Key Exchange Payload ......................................87
      3.5. Identification Payloads ...................................87
      3.6. Certificate Payload .......................................90
      3.7. Certificate Request Payload ...............................93
      3.8. Authentication Payload ....................................95
      3.9. Nonce Payload .............................................96
      3.10. Notify Payload ...........................................97
           3.10.1. Notify Message Types ..............................98
      3.11. Delete Payload ..........................................101
      3.12. Vendor ID Payload .......................................102
      3.13. Traffic Selector Payload ................................103
           3.13.1. Traffic Selector .................................105
      3.14. Encrypted Payload .......................................107
      3.15. Configuration Payload ...................................109
           3.15.1. Configuration Attributes .........................110
           3.15.2. Meaning of INTERNAL_IP4_SUBNET and
                   INTERNAL_IP6_SUBNET ..............................113
           3.15.3. Configuration Payloads for IPv6 ..................115
           3.15.4. Address Assignment Failures ......................116
      3.16. Extensible Authentication Protocol (EAP) Payload ........117
   4. Conformance Requirements ......................................118
   5. Security Considerations .......................................120
      5.1. Traffic Selector Authorization ...........................123
   6. IANA Considerations ...........................................124
   7. Acknowledgements ..............................................125
   8. References ....................................................126
      8.1. Normative References .....................................126
      8.2. Informative References ...................................127
   Appendix A. Summary of Changes from IKEv1 ........................132
   Appendix B. Diffie-Hellman Groups ................................133
     B.1. Group 1 - 768-bit MODP ....................................133
     B.2. Group 2 - 1024-bit MODP ...................................133
   Appendix C.  Exchanges and Payloads ..............................134
     C.1. IKE_SA_INIT Exchange  .....................................134
     C.2. IKE_AUTH Exchange without EAP .............................135
     C.3. IKE_AUTH Exchange with EAP  ...............................136
     C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying
          Child SAs .................................................137
     C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA ..........137
     C.6. INFORMATIONAL Exchange ....................................137

Top      ToC       Page 5 
1.  Introduction

   IP Security (IPsec) provides confidentiality, data integrity, access
   control, and data source authentication to IP datagrams.  These
   services are provided by maintaining shared state between the source
   and the sink of an IP datagram.  This state defines, among other
   things, the specific services provided to the datagram, which
   cryptographic algorithms will be used to provide the services, and
   the keys used as input to the cryptographic algorithms.

   Establishing this shared state in a manual fashion does not scale
   well.  Therefore, a protocol to establish this state dynamically is
   needed.  This document describes such a protocol -- the Internet Key
   Exchange (IKE).  Version 1 of IKE was defined in RFCs 2407 [DOI],
   2408 [ISAKMP], and 2409 [IKEV1].  IKEv2 replaced all of those RFCs.
   IKEv2 was defined in [IKEV2] (RFC 4306) and was clarified in [Clarif]
   (RFC 4718).  This document replaces and updates RFC 4306 and RFC
   4718.  IKEv2 was a change to the IKE protocol that was not backward
   compatible.  In contrast, the current document not only provides a
   clarification of IKEv2, but makes minimum changes to the IKE
   protocol.  A list of the significant differences between RFC 4306 and
   this document is given in Section 1.7.

   IKE performs mutual authentication between two parties and
   establishes an IKE security association (SA) that includes shared
   secret information that can be used to efficiently establish SAs for
   Encapsulating Security Payload (ESP) [ESP] or Authentication Header
   (AH) [AH] and a set of cryptographic algorithms to be used by the SAs
   to protect the traffic that they carry.  In this document, the term
   "suite" or "cryptographic suite" refers to a complete set of
   algorithms used to protect an SA.  An initiator proposes one or more
   suites by listing supported algorithms that can be combined into
   suites in a mix-and-match fashion.  IKE can also negotiate use of IP
   Compression (IPComp) [IP-COMP] in connection with an ESP or AH SA.
   The SAs for ESP or AH that get set up through that IKE SA we call
   "Child SAs".

   All IKE communications consist of pairs of messages: a request and a
   response.  The pair is called an "exchange", and is sometimes called
   a "request/response pair".  The first exchange of messages
   establishing an IKE SA are called the IKE_SA_INIT and IKE_AUTH
   exchanges; subsequent IKE exchanges are called the CREATE_CHILD_SA or
   INFORMATIONAL exchanges.  In the common case, there is a single
   IKE_SA_INIT exchange and a single IKE_AUTH exchange (a total of four
   messages) to establish the IKE SA and the first Child SA.  In
   exceptional cases, there may be more than one of each of these
   exchanges.  In all cases, all IKE_SA_INIT exchanges MUST complete
   before any other exchange type, then all IKE_AUTH exchanges MUST

Top      ToC       Page 6 
   complete, and following that, any number of CREATE_CHILD_SA and
   INFORMATIONAL exchanges may occur in any order.  In some scenarios,
   only a single Child SA is needed between the IPsec endpoints, and
   therefore there would be no additional exchanges.  Subsequent
   exchanges MAY be used to establish additional Child SAs between the
   same authenticated pair of endpoints and to perform housekeeping
   functions.

   An IKE message flow always consists of a request followed by a
   response.  It is the responsibility of the requester to ensure
   reliability.  If the response is not received within a timeout
   interval, the requester needs to retransmit the request (or abandon
   the connection).

   The first exchange of an IKE session, IKE_SA_INIT, negotiates
   security parameters for the IKE SA, sends nonces, and sends Diffie-
   Hellman values.

   The second exchange, IKE_AUTH, transmits identities, proves knowledge
   of the secrets corresponding to the two identities, and sets up an SA
   for the first (and often only) AH or ESP Child SA (unless there is
   failure setting up the AH or ESP Child SA, in which case the IKE SA
   is still established without the Child SA).

   The types of subsequent exchanges are CREATE_CHILD_SA (which creates
   a Child SA) and INFORMATIONAL (which deletes an SA, reports error
   conditions, or does other housekeeping).  Every request requires a
   response.  An INFORMATIONAL request with no payloads (other than the
   empty Encrypted payload required by the syntax) is commonly used as a
   check for liveness.  These subsequent exchanges cannot be used until
   the initial exchanges have completed.

   In the description that follows, we assume that no errors occur.
   Modifications to the flow when errors occur are described in
   Section 2.21.

1.1.  Usage Scenarios

   IKE is used to negotiate ESP or AH SAs in a number of different
   scenarios, each with its own special requirements.

Top      ToC       Page 7 
1.1.1.  Security Gateway to Security Gateway in Tunnel Mode

                +-+-+-+-+-+            +-+-+-+-+-+
                |         | IPsec      |         |
   Protected    |Tunnel   | tunnel     |Tunnel   |     Protected
   Subnet   <-->|Endpoint |<---------->|Endpoint |<--> Subnet
                |         |            |         |
                +-+-+-+-+-+            +-+-+-+-+-+

          Figure 1:  Security Gateway to Security Gateway Tunnel

   In this scenario, neither endpoint of the IP connection implements
   IPsec, but network nodes between them protect traffic for part of the
   way.  Protection is transparent to the endpoints, and depends on
   ordinary routing to send packets through the tunnel endpoints for
   processing.  Each endpoint would announce the set of addresses
   "behind" it, and packets would be sent in tunnel mode where the inner
   IP header would contain the IP addresses of the actual endpoints.

1.1.2.  Endpoint-to-Endpoint Transport Mode

   +-+-+-+-+-+                                          +-+-+-+-+-+
   |         |                 IPsec transport          |         |
   |Protected|                or tunnel mode SA         |Protected|
   |Endpoint |<---------------------------------------->|Endpoint |
   |         |                                          |         |
   +-+-+-+-+-+                                          +-+-+-+-+-+

                    Figure 2:  Endpoint to Endpoint

   In this scenario, both endpoints of the IP connection implement
   IPsec, as required of hosts in [IPSECARCH].  Transport mode will
   commonly be used with no inner IP header.  A single pair of addresses
   will be negotiated for packets to be protected by this SA.  These
   endpoints MAY implement application-layer access controls based on
   the IPsec authenticated identities of the participants.  This
   scenario enables the end-to-end security that has been a guiding
   principle for the Internet since [ARCHPRINC], [TRANSPARENCY], and a
   method of limiting the inherent problems with complexity in networks
   noted by [ARCHGUIDEPHIL].  Although this scenario may not be fully
   applicable to the IPv4 Internet, it has been deployed successfully in
   specific scenarios within intranets using IKEv1.  It should be more
   broadly enabled during the transition to IPv6 and with the adoption
   of IKEv2.

Top      ToC       Page 8 
   It is possible in this scenario that one or both of the protected
   endpoints will be behind a network address translation (NAT) node, in
   which case the tunneled packets will have to be UDP encapsulated so
   that port numbers in the UDP headers can be used to identify
   individual endpoints "behind" the NAT (see Section 2.23).

1.1.3.  Endpoint to Security Gateway in Tunnel Mode

   +-+-+-+-+-+                          +-+-+-+-+-+
   |         |         IPsec            |         |     Protected
   |Protected|         tunnel           |Tunnel   |     Subnet
   |Endpoint |<------------------------>|Endpoint |<--- and/or
   |         |                          |         |     Internet
   +-+-+-+-+-+                          +-+-+-+-+-+

              Figure 3:  Endpoint to Security Gateway Tunnel

   In this scenario, a protected endpoint (typically a portable roaming
   computer) connects back to its corporate network through an IPsec-
   protected tunnel.  It might use this tunnel only to access
   information on the corporate network, or it might tunnel all of its
   traffic back through the corporate network in order to take advantage
   of protection provided by a corporate firewall against Internet-based
   attacks.  In either case, the protected endpoint will want an IP
   address associated with the security gateway so that packets returned
   to it will go to the security gateway and be tunneled back.  This IP
   address may be static or may be dynamically allocated by the security
   gateway.  In support of the latter case, IKEv2 includes a mechanism
   (namely, configuration payloads) for the initiator to request an IP
   address owned by the security gateway for use for the duration of its
   SA.

   In this scenario, packets will use tunnel mode.  On each packet from
   the protected endpoint, the outer IP header will contain the source
   IP address associated with its current location (i.e., the address
   that will get traffic routed to the endpoint directly), while the
   inner IP header will contain the source IP address assigned by the
   security gateway (i.e., the address that will get traffic routed to
   the security gateway for forwarding to the endpoint).  The outer
   destination address will always be that of the security gateway,
   while the inner destination address will be the ultimate destination
   for the packet.

   In this scenario, it is possible that the protected endpoint will be
   behind a NAT.  In that case, the IP address as seen by the security
   gateway will not be the same as the IP address sent by the protected

Top      ToC       Page 9 
   endpoint, and packets will have to be UDP encapsulated in order to be
   routed properly.  Interaction with NATs is covered in detail in
   Section 2.23.

1.1.4.  Other Scenarios

   Other scenarios are possible, as are nested combinations of the
   above.  One notable example combines aspects of Sections 1.1.1 and
   1.1.3.  A subnet may make all external accesses through a remote
   security gateway using an IPsec tunnel, where the addresses on the
   subnet are routed to the security gateway by the rest of the
   Internet.  An example would be someone's home network being virtually
   on the Internet with static IP addresses even though connectivity is
   provided by an ISP that assigns a single dynamically assigned IP
   address to the user's security gateway (where the static IP addresses
   and an IPsec relay are provided by a third party located elsewhere).

1.2.  The Initial Exchanges

   Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH
   exchanges (known in IKEv1 as Phase 1).  These initial exchanges
   normally consist of four messages, though in some scenarios that
   number can grow.  All communications using IKE consist of request/
   response pairs.  We'll describe the base exchange first, followed by
   variations.  The first pair of messages (IKE_SA_INIT) negotiate
   cryptographic algorithms, exchange nonces, and do a Diffie-Hellman
   exchange [DH].

   The second pair of messages (IKE_AUTH) authenticate the previous
   messages, exchange identities and certificates, and establish the
   first Child SA.  Parts of these messages are encrypted and integrity
   protected with keys established through the IKE_SA_INIT exchange, so
   the identities are hidden from eavesdroppers and all fields in all
   the messages are authenticated.  See Section 2.14 for information on
   how the encryption keys are generated.  (A man-in-the-middle attacker
   who cannot complete the IKE_AUTH exchange can nonetheless see the
   identity of the initiator.)

   All messages following the initial exchange are cryptographically
   protected using the cryptographic algorithms and keys negotiated in
   the IKE_SA_INIT exchange.  These subsequent messages use the syntax
   of the Encrypted payload described in Section 3.14, encrypted with
   keys that are derived as described in Section 2.14.  All subsequent
   messages include an Encrypted payload, even if they are referred to
   in the text as "empty".  For the CREATE_CHILD_SA, IKE_AUTH, or
   INFORMATIONAL exchanges, the message following the header is
   encrypted and the message including the header is integrity protected
   using the cryptographic algorithms negotiated for the IKE SA.

Top      ToC       Page 10 
   Every IKE message contains a Message ID as part of its fixed header.
   This Message ID is used to match up requests and responses, and to
   identify retransmissions of messages.

   In the following descriptions, the payloads contained in the message
   are indicated by names as listed below.

   Notation    Payload
   -----------------------------------------
   AUTH        Authentication
   CERT        Certificate
   CERTREQ     Certificate Request
   CP          Configuration
   D           Delete
   EAP         Extensible Authentication
   HDR         IKE header (not a payload)
   IDi         Identification - Initiator
   IDr         Identification - Responder
   KE          Key Exchange
   Ni, Nr      Nonce
   N           Notify
   SA          Security Association
   SK          Encrypted and Authenticated
   TSi         Traffic Selector - Initiator
   TSr         Traffic Selector - Responder
   V           Vendor ID

   The details of the contents of each payload are described in section
   3.  Payloads that may optionally appear will be shown in brackets,
   such as [CERTREQ]; this indicates that a Certificate Request payload
   can optionally be included.

   The initial exchanges are as follows:

   Initiator                         Responder
   -------------------------------------------------------------------
   HDR, SAi1, KEi, Ni  -->

   HDR contains the Security Parameter Indexes (SPIs), version numbers,
   and flags of various sorts.  The SAi1 payload states the
   cryptographic algorithms the initiator supports for the IKE SA.  The
   KE payload sends the initiator's Diffie-Hellman value.  Ni is the
   initiator's nonce.

                                <--  HDR, SAr1, KEr, Nr, [CERTREQ]

Top      ToC       Page 11 
   The responder chooses a cryptographic suite from the initiator's
   offered choices and expresses that choice in the SAr1 payload,
   completes the Diffie-Hellman exchange with the KEr payload, and sends
   its nonce in the Nr payload.

   At this point in the negotiation, each party can generate SKEYSEED,
   from which all keys are derived for that IKE SA.  The messages that
   follow are encrypted and integrity protected in their entirety, with
   the exception of the message headers.  The keys used for the
   encryption and integrity protection are derived from SKEYSEED and are
   known as SK_e (encryption) and SK_a (authentication, a.k.a. integrity
   protection); see Sections 2.13 and 2.14 for details on the key
   derivation.  A separate SK_e and SK_a is computed for each direction.
   In addition to the keys SK_e and SK_a derived from the Diffie-Hellman
   value for protection of the IKE SA, another quantity SK_d is derived
   and used for derivation of further keying material for Child SAs.
   The notation SK { ... } indicates that these payloads are encrypted
   and integrity protected using that direction's SK_e and SK_a.

   HDR, SK {IDi, [CERT,] [CERTREQ,]
       [IDr,] AUTH, SAi2,
       TSi, TSr}  -->

   The initiator asserts its identity with the IDi payload, proves
   knowledge of the secret corresponding to IDi and integrity protects
   the contents of the first message using the AUTH payload (see
   Section 2.15).  It might also send its certificate(s) in CERT
   payload(s) and a list of its trust anchors in CERTREQ payload(s).  If
   any CERT payloads are included, the first certificate provided MUST
   contain the public key used to verify the AUTH field.

   The optional payload IDr enables the initiator to specify to which of
   the responder's identities it wants to talk.  This is useful when the
   machine on which the responder is running is hosting multiple
   identities at the same IP address.  If the IDr proposed by the
   initiator is not acceptable to the responder, the responder might use
   some other IDr to finish the exchange.  If the initiator then does
   not accept the fact that responder used an IDr different than the one
   that was requested, the initiator can close the SA after noticing the
   fact.

   The Traffic Selectors (TSi and TSr) are discussed in Section 2.9.

   The initiator begins negotiation of a Child SA using the SAi2
   payload.  The final fields (starting with SAi2) are described in the
   description of the CREATE_CHILD_SA exchange.

Top      ToC       Page 12 
                                <--  HDR, SK {IDr, [CERT,] AUTH,
                                         SAr2, TSi, TSr}

   The responder asserts its identity with the IDr payload, optionally
   sends one or more certificates (again with the certificate containing
   the public key used to verify AUTH listed first), authenticates its
   identity and protects the integrity of the second message with the
   AUTH payload, and completes negotiation of a Child SA with the
   additional fields described below in the CREATE_CHILD_SA exchange.

   Both parties in the IKE_AUTH exchange MUST verify that all signatures
   and Message Authentication Codes (MACs) are computed correctly.  If
   either side uses a shared secret for authentication, the names in the
   ID payload MUST correspond to the key used to generate the AUTH
   payload.

   Because the initiator sends its Diffie-Hellman value in the
   IKE_SA_INIT, it must guess the Diffie-Hellman group that the
   responder will select from its list of supported groups.  If the
   initiator guesses wrong, the responder will respond with a Notify
   payload of type INVALID_KE_PAYLOAD indicating the selected group.  In
   this case, the initiator MUST retry the IKE_SA_INIT with the
   corrected Diffie-Hellman group.  The initiator MUST again propose its
   full set of acceptable cryptographic suites because the rejection
   message was unauthenticated and otherwise an active attacker could
   trick the endpoints into negotiating a weaker suite than a stronger
   one that they both prefer.

   If creating the Child SA during the IKE_AUTH exchange fails for some
   reason, the IKE SA is still created as usual.  The list of Notify
   message types in the IKE_AUTH exchange that do not prevent an IKE SA
   from being set up include at least the following: NO_PROPOSAL_CHOSEN,
   TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and
   FAILED_CP_REQUIRED.

   If the failure is related to creating the IKE SA (for example, an
   AUTHENTICATION_FAILED Notify error message is returned), the IKE SA
   is not created.  Note that although the IKE_AUTH messages are
   encrypted and integrity protected, if the peer receiving this Notify
   error message has not yet authenticated the other end (or if the peer
   fails to authenticate the other end for some reason), the information
   needs to be treated with caution.  More precisely, assuming that the
   MAC verifies correctly, the sender of the error Notify message is
   known to be the responder of the IKE_SA_INIT exchange, but the
   sender's identity cannot be assured.

Top      ToC       Page 13 
   Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads.
   Thus, the SA payloads in the IKE_AUTH exchange cannot contain
   Transform Type 4 (Diffie-Hellman group) with any value other than
   NONE.  Implementations SHOULD omit the whole transform substructure
   instead of sending value NONE.

1.3.  The CREATE_CHILD_SA Exchange

   The CREATE_CHILD_SA exchange is used to create new Child SAs and to
   rekey both IKE SAs and Child SAs.  This exchange consists of a single
   request/response pair, and some of its function was referred to as a
   Phase 2 exchange in IKEv1.  It MAY be initiated by either end of the
   IKE SA after the initial exchanges are completed.

   An SA is rekeyed by creating a new SA and then deleting the old one.
   This section describes the first part of rekeying, the creation of
   new SAs; Section 2.8 covers the mechanics of rekeying, including
   moving traffic from old to new SAs and the deletion of the old SAs.
   The two sections must be read together to understand the entire
   process of rekeying.

   Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this
   section the term initiator refers to the endpoint initiating this
   exchange.  An implementation MAY refuse all CREATE_CHILD_SA requests
   within an IKE SA.

   The CREATE_CHILD_SA request MAY optionally contain a KE payload for
   an additional Diffie-Hellman exchange to enable stronger guarantees
   of forward secrecy for the Child SA.  The keying material for the
   Child SA is a function of SK_d established during the establishment
   of the IKE SA, the nonces exchanged during the CREATE_CHILD_SA
   exchange, and the Diffie-Hellman value (if KE payloads are included
   in the CREATE_CHILD_SA exchange).

   If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of
   the SA offers MUST include the Diffie-Hellman group of the KEi.  The
   Diffie-Hellman group of the KEi MUST be an element of the group the
   initiator expects the responder to accept (additional Diffie-Hellman
   groups can be proposed).  If the responder selects a proposal using a
   different Diffie-Hellman group (other than NONE), the responder MUST
   reject the request and indicate its preferred Diffie-Hellman group in
   the INVALID_KE_PAYLOAD Notify payload.  There are two octets of data
   associated with this notification: the accepted Diffie-Hellman group
   number in big endian order.  In the case of such a rejection, the
   CREATE_CHILD_SA exchange fails, and the initiator will probably retry
   the exchange with a Diffie-Hellman proposal and KEi in the group that
   the responder gave in the INVALID_KE_PAYLOAD Notify payload.

Top      ToC       Page 14 
   The responder sends a NO_ADDITIONAL_SAS notification to indicate that
   a CREATE_CHILD_SA request is unacceptable because the responder is
   unwilling to accept any more Child SAs on this IKE SA.  This
   notification can also be used to reject IKE SA rekey.  Some minimal
   implementations may only accept a single Child SA setup in the
   context of an initial IKE exchange and reject any subsequent attempts
   to add more.

1.3.1.  Creating New Child SAs with the CREATE_CHILD_SA Exchange

   A Child SA may be created by sending a CREATE_CHILD_SA request.  The
   CREATE_CHILD_SA request for creating a new Child SA is:

   Initiator                         Responder
   -------------------------------------------------------------------
   HDR, SK {SA, Ni, [KEi],
              TSi, TSr}  -->

   The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
   payload, optionally a Diffie-Hellman value in the KEi payload, and
   the proposed Traffic Selectors for the proposed Child SA in the TSi
   and TSr payloads.

   The CREATE_CHILD_SA response for creating a new Child SA is:

                                <--  HDR, SK {SA, Nr, [KEr],
                                         TSi, TSr}

   The responder replies (using the same Message ID to respond) with the
   accepted offer in an SA payload, and a Diffie-Hellman value in the
   KEr payload if KEi was included in the request and the selected
   cryptographic suite includes that group.

   The Traffic Selectors for traffic to be sent on that SA are specified
   in the TS payloads in the response, which may be a subset of what the
   initiator of the Child SA proposed.

   The USE_TRANSPORT_MODE notification MAY be included in a request
   message that also includes an SA payload requesting a Child SA.  It
   requests that the Child SA use transport mode rather than tunnel mode
   for the SA created.  If the request is accepted, the response MUST
   also include a notification of type USE_TRANSPORT_MODE.  If the
   responder declines the request, the Child SA will be established in
   tunnel mode.  If this is unacceptable to the initiator, the initiator
   MUST delete the SA.  Note: Except when using this option to negotiate
   transport mode, all Child SAs will use tunnel mode.

Top      ToC       Page 15 
   The ESP_TFC_PADDING_NOT_SUPPORTED notification asserts that the
   sending endpoint will not accept packets that contain Traffic Flow
   Confidentiality (TFC) padding over the Child SA being negotiated.  If
   neither endpoint accepts TFC padding, this notification is included
   in both the request and the response.  If this notification is
   included in only one of the messages, TFC padding can still be sent
   in the other direction.

   The NON_FIRST_FRAGMENTS_ALSO notification is used for fragmentation
   control.  See [IPSECARCH] for a fuller explanation.  Both parties
   need to agree to sending non-first fragments before either party does
   so.  It is enabled only if NON_FIRST_FRAGMENTS_ALSO notification is
   included in both the request proposing an SA and the response
   accepting it.  If the responder does not want to send or receive non-
   first fragments, it only omits NON_FIRST_FRAGMENTS_ALSO notification
   from its response, but does not reject the whole Child SA creation.

   An IPCOMP_SUPPORTED notification, covered in Section 2.22, can also
   be included in the exchange.

   A failed attempt to create a Child SA SHOULD NOT tear down the IKE
   SA: there is no reason to lose the work done to set up the IKE SA.
   See Section 2.21 for a list of error messages that might occur if
   creating a Child SA fails.

1.3.2.  Rekeying IKE SAs with the CREATE_CHILD_SA Exchange

   The CREATE_CHILD_SA request for rekeying an IKE SA is:

   Initiator                         Responder
   -------------------------------------------------------------------
   HDR, SK {SA, Ni, KEi} -->

   The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
   payload, and a Diffie-Hellman value in the KEi payload.  The KEi
   payload MUST be included.  A new initiator SPI is supplied in the SPI
   field of the SA payload.  Once a peer receives a request to rekey an
   IKE SA or sends a request to rekey an IKE SA, it SHOULD NOT start any
   new CREATE_CHILD_SA exchanges on the IKE SA that is being rekeyed.

   The CREATE_CHILD_SA response for rekeying an IKE SA is:

                                <--  HDR, SK {SA, Nr, KEr}

   The responder replies (using the same Message ID to respond) with the
   accepted offer in an SA payload, and a Diffie-Hellman value in the
   KEr payload if the selected cryptographic suite includes that group.
   A new responder SPI is supplied in the SPI field of the SA payload.

Top      ToC       Page 16 
   The new IKE SA has its message counters set to 0, regardless of what
   they were in the earlier IKE SA.  The first IKE requests from both
   sides on the new IKE SA will have Message ID 0.  The old IKE SA
   retains its numbering, so any further requests (for example, to
   delete the IKE SA) will have consecutive numbering.  The new IKE SA
   also has its window size reset to 1, and the initiator in this rekey
   exchange is the new "original initiator" of the new IKE SA.

   Section 2.18 also covers IKE SA rekeying in detail.

1.3.3.  Rekeying Child SAs with the CREATE_CHILD_SA Exchange

   The CREATE_CHILD_SA request for rekeying a Child SA is:

   Initiator                         Responder
   -------------------------------------------------------------------
   HDR, SK {N(REKEY_SA), SA, Ni, [KEi],
       TSi, TSr}   -->

   The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
   payload, optionally a Diffie-Hellman value in the KEi payload, and
   the proposed Traffic Selectors for the proposed Child SA in the TSi
   and TSr payloads.

   The notifications described in Section 1.3.1 may also be sent in a
   rekeying exchange.  Usually, these will be the same notifications
   that were used in the original exchange; for example, when rekeying a
   transport mode SA, the USE_TRANSPORT_MODE notification will be used.

   The REKEY_SA notification MUST be included in a CREATE_CHILD_SA
   exchange if the purpose of the exchange is to replace an existing ESP
   or AH SA.  The SA being rekeyed is identified by the SPI field in the
   Notify payload; this is the SPI the exchange initiator would expect
   in inbound ESP or AH packets.  There is no data associated with this
   Notify message type.  The Protocol ID field of the REKEY_SA
   notification is set to match the protocol of the SA we are rekeying,
   for example, 3 for ESP and 2 for AH.

   The CREATE_CHILD_SA response for rekeying a Child SA is:

                                <--  HDR, SK {SA, Nr, [KEr],
                                         TSi, TSr}

   The responder replies (using the same Message ID to respond) with the
   accepted offer in an SA payload, and a Diffie-Hellman value in the
   KEr payload if KEi was included in the request and the selected
   cryptographic suite includes that group.

Top      ToC       Page 17 
   The Traffic Selectors for traffic to be sent on that SA are specified
   in the TS payloads in the response, which may be a subset of what the
   initiator of the Child SA proposed.

1.4.  The INFORMATIONAL Exchange

   At various points during the operation of an IKE SA, peers may desire
   to convey control messages to each other regarding errors or
   notifications of certain events.  To accomplish this, IKE defines an
   INFORMATIONAL exchange.  INFORMATIONAL exchanges MUST ONLY occur
   after the initial exchanges and are cryptographically protected with
   the negotiated keys.  Note that some informational messages, not
   exchanges, can be sent outside the context of an IKE SA.  Section
   2.21 also covers error messages in great detail.

   Control messages that pertain to an IKE SA MUST be sent under that
   IKE SA.  Control messages that pertain to Child SAs MUST be sent
   under the protection of the IKE SA that generated them (or its
   successor if the IKE SA was rekeyed).

   Messages in an INFORMATIONAL exchange contain zero or more
   Notification, Delete, and Configuration payloads.  The recipient of
   an INFORMATIONAL exchange request MUST send some response; otherwise,
   the sender will assume the message was lost in the network and will
   retransmit it.  That response MAY be an empty message.  The request
   message in an INFORMATIONAL exchange MAY also contain no payloads.
   This is the expected way an endpoint can ask the other endpoint to
   verify that it is alive.

   The INFORMATIONAL exchange is defined as:

   Initiator                         Responder
   -------------------------------------------------------------------
   HDR, SK {[N,] [D,]
       [CP,] ...}  -->
                                <--  HDR, SK {[N,] [D,]
                                         [CP], ...}

   The processing of an INFORMATIONAL exchange is determined by its
   component payloads.

1.4.1.  Deleting an SA with INFORMATIONAL Exchanges

   ESP and AH SAs always exist in pairs, with one SA in each direction.
   When an SA is closed, both members of the pair MUST be closed (that
   is, deleted).  Each endpoint MUST close its incoming SAs and allow
   the other endpoint to close the other SA in each pair.  To delete an
   SA, an INFORMATIONAL exchange with one or more Delete payloads is

Top      ToC       Page 18 
   sent listing the SPIs (as they would be expected in the headers of
   inbound packets) of the SAs to be deleted.  The recipient MUST close
   the designated SAs.  Note that one never sends Delete payloads for
   the two sides of an SA in a single message.  If there are many SAs to
   delete at the same time, one includes Delete payloads for the inbound
   half of each SA pair in the INFORMATIONAL exchange.

   Normally, the response in the INFORMATIONAL exchange will contain
   Delete payloads for the paired SAs going in the other direction.
   There is one exception.  If, by chance, both ends of a set of SAs
   independently decide to close them, each may send a Delete payload
   and the two requests may cross in the network.  If a node receives a
   delete request for SAs for which it has already issued a delete
   request, it MUST delete the outgoing SAs while processing the request
   and the incoming SAs while processing the response.  In that case,
   the responses MUST NOT include Delete payloads for the deleted SAs,
   since that would result in duplicate deletion and could in theory
   delete the wrong SA.

   Similar to ESP and AH SAs, IKE SAs are also deleted by sending an
   Informational exchange.  Deleting an IKE SA implicitly closes any
   remaining Child SAs negotiated under it.  The response to a request
   that deletes the IKE SA is an empty INFORMATIONAL response.

   Half-closed ESP or AH connections are anomalous, and a node with
   auditing capability should probably audit their existence if they
   persist.  Note that this specification does not specify time periods,
   so it is up to individual endpoints to decide how long to wait.  A
   node MAY refuse to accept incoming data on half-closed connections
   but MUST NOT unilaterally close them and reuse the SPIs.  If
   connection state becomes sufficiently messed up, a node MAY close the
   IKE SA, as described above.  It can then rebuild the SAs it needs on
   a clean base under a new IKE SA.

1.5.  Informational Messages outside of an IKE SA

   There are some cases in which a node receives a packet that it cannot
   process, but it may want to notify the sender about this situation.

   o  If an ESP or AH packet arrives with an unrecognized SPI.  This
      might be due to the receiving node having recently crashed and
      lost state, or because of some other system malfunction or attack.

   o  If an encrypted IKE request packet arrives on port 500 or 4500
      with an unrecognized IKE SPI.  This might be due to the receiving
      node having recently crashed and lost state, or because of some
      other system malfunction or attack.

Top      ToC       Page 19 
   o  If an IKE request packet arrives with a higher major version
      number than the implementation supports.

   In the first case, if the receiving node has an active IKE SA to the
   IP address from whence the packet came, it MAY send an INVALID_SPI
   notification of the wayward packet over that IKE SA in an
   INFORMATIONAL exchange.  The Notification Data contains the SPI of
   the invalid packet.  The recipient of this notification cannot tell
   whether the SPI is for AH or ESP, but this is not important because
   the SPIs are supposed to be different for the two.  If no suitable
   IKE SA exists, the node MAY send an informational message without
   cryptographic protection to the source IP address, using the source
   UDP port as the destination port if the packet was UDP (UDP-
   encapsulated ESP or AH).  In this case, it should only be used by the
   recipient as a hint that something might be wrong (because it could
   easily be forged).  This message is not part of an INFORMATIONAL
   exchange, and the receiving node MUST NOT respond to it because doing
   so could cause a message loop.  The message is constructed as
   follows: there are no IKE SPI values that would be meaningful to the
   recipient of such a notification; using zero values or random values
   are both acceptable, this being the exception to the rule in
   Section 3.1 that prohibits zero IKE Initiator SPIs.  The Initiator
   flag is set to 1, the Response flag is set to 0, and the version
   flags are set in the normal fashion; these flags are described in
   Section 3.1.

   In the second and third cases, the message is always sent without
   cryptographic protection (outside of an IKE SA), and includes either
   an INVALID_IKE_SPI or an INVALID_MAJOR_VERSION notification (with no
   notification data).  The message is a response message, and thus it
   is sent to the IP address and port from whence it came with the same
   IKE SPIs and the Message ID and Exchange Type are copied from the
   request.  The Response flag is set to 1, and the version flags are
   set in the normal fashion.

1.6.  Requirements Terminology

   Definitions of the primitive terms in this document (such as Security
   Association or SA) can be found in [IPSECARCH].  It should be noted
   that parts of IKEv2 rely on some of the processing rules in
   [IPSECARCH], as described in various sections of this document.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [MUSTSHOULD].

Top      ToC       Page 20 
1.7.  Significant Differences between RFC 4306 and This Document

   This document contains clarifications and amplifications to IKEv2
   [IKEV2].  Many of the clarifications are based on [Clarif].  The
   changes listed in that document were discussed in the IPsec Working
   Group and, after the Working Group was disbanded, on the IPsec
   mailing list.  That document contains detailed explanations of areas
   that were unclear in IKEv2, and is thus useful to implementers of
   IKEv2.

   The protocol described in this document retains the same major
   version number (2) and minor version number (0) as was used in RFC
   4306.  That is, the version number is *not* changed from RFC 4306.
   The small number of technical changes listed here are not expected to
   affect RFC 4306 implementations that have already been deployed at
   the time of publication of this document.

   This document makes the figures and references a bit more consistent
   than they were in [IKEV2].

   IKEv2 developers have noted that the SHOULD-level requirements in RFC
   4306 are often unclear in that they don't say when it is OK to not
   obey the requirements.  They also have noted that there are MUST-
   level requirements that are not related to interoperability.  This
   document has more explanation of some of these requirements.  All
   non-capitalized uses of the words SHOULD and MUST now mean their
   normal English sense, not the interoperability sense of [MUSTSHOULD].

   IKEv2 (and IKEv1) developers have noted that there is a great deal of
   material in the tables of codes in Section 3.10.1 in RFC 4306.  This
   leads to implementers not having all the needed information in the
   main body of the document.  Much of the material from those tables
   has been moved into the associated parts of the main body of the
   document.

   This document removes discussion of nesting AH and ESP.  This was a
   mistake in RFC 4306 caused by the lag between finishing RFC 4306 and
   RFC 4301.  Basically, IKEv2 is based on RFC 4301, which does not
   include "SA bundles" that were part of RFC 2401.  While a single
   packet can go through IPsec processing multiple times, each of these
   passes uses a separate SA, and the passes are coordinated by the
   forwarding tables.  In IKEv2, each of these SAs has to be created
   using a separate CREATE_CHILD_SA exchange.

   This document removes discussion of the INTERNAL_ADDRESS_EXPIRY
   configuration attribute because its implementation was very
   problematic.  Implementations that conform to this document MUST

Top      ToC       Page 21 
   ignore proposals that have configuration attribute type 5, the old
   value for INTERNAL_ADDRESS_EXPIRY.  This document also removed
   INTERNAL_IP6_NBNS as a configuration attribute.

   This document removes the allowance for rejecting messages in which
   the payloads were not in the "right" order; now implementations MUST
   NOT reject them.  This is due to the lack of clarity where the orders
   for the payloads are described.

   The lists of items from RFC 4306 that ended up in the IANA registry
   were trimmed to only include items that were actually defined in RFC
   4306.  Also, many of those lists are now preceded with the very
   important instruction to developers that they really should look at
   the IANA registry at the time of development because new items have
   been added since RFC 4306.

   This document adds clarification on when notifications are and are
   not sent encrypted, depending on the state of the negotiation at the
   time.

   This document discusses more about how to negotiate combined-mode
   ciphers.

   In Section 1.3.2, "The KEi payload SHOULD be included" was changed to
   be "The KEi payload MUST be included".  This also led to changes in
   Section 2.18.

   In Section 2.1, there is new material covering how the initiator's
   SPI and/or IP is used to differentiate if this is a "half-open" IKE
   SA or a new request.

   This document clarifies the use of the critical flag in Section 2.5.

   In Section 2.8, "Note that, when rekeying, the new Child SA MAY have
   different Traffic Selectors and algorithms than the old one" was
   changed to "Note that, when rekeying, the new Child SA SHOULD NOT
   have different Traffic Selectors and algorithms than the old one".

   The new Section 2.8.2 covers simultaneous IKE SA rekeying.

   The new Section 2.9.2 covers Traffic Selectors in rekeying.

   This document adds the restriction in Section 2.13 that all
   pseudorandom functions (PRFs) used with IKEv2 MUST take variable-
   sized keys.  This should not affect any implementations because there
   were no standardized PRFs that have fixed-size keys.

Top      ToC       Page 22 
   Section 2.18 requires doing a Diffie-Hellman exchange when rekeying
   the IKE_SA.  In theory, RFC 4306 allowed a policy where the Diffie-
   Hellman exchange was optional, but this was not useful (or
   appropriate) when rekeying the IKE_SA.

   Section 2.21 has been greatly expanded to cover the different cases
   where error responses are needed and the appropriate responses to
   them.

   Section 2.23 clarified that, in NAT traversal, now both UDP-
   encapsulated IPsec packets and non-UDP-encapsulated IPsec packets
   need to be understood when receiving.

   Added Section 2.23.1 to describe NAT traversal when transport mode is
   requested.

   Added Section 2.25 to explain how to act when there are timing
   collisions when deleting and/or rekeying SAs, and two new error
   notifications (TEMPORARY_FAILURE and CHILD_SA_NOT_FOUND) were
   defined.

   In Section 3.6, "Implementations MUST support the HTTP method for
   hash-and-URL lookup.  The behavior of other URL methods is not
   currently specified, and such methods SHOULD NOT be used in the
   absence of a document specifying them" was added.

   In Section 3.15.3, a pointer to a new document that is related to
   configuration of IPv6 addresses was added.

   Appendix C was expanded and clarified.



(page 22 continued on part 2)

Next RFC Part