RFC 7296
Internet Key Exchange Protocol Version 2 (IKEv2)
Pages: 142
Internet Standard: 79
→ Errata
Obsoletes: 5996
Updated by: 7427 7670 8247 8983 9370
Internet Standard: 79
→ Errata
Obsoletes: 5996
Updated by: 7427 7670 8247 8983 9370
Part 1 of 6 – Pages 1 to 17
Internet Engineering Task Force (IETF) C. Kaufman Request for Comments: 7296 Microsoft STD: 79 P. Hoffman Obsoletes: 5996 VPN Consortium Category: Standards Track Y. Nir ISSN: 2070-1721 Check Point P. Eronen Independent T. Kivinen INSIDE Secure October 2014 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 obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard. 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/rfc7296.
Copyright Notice Copyright (c) 2014 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 ............................................7 1.1.1. Security Gateway to Security Gateway in Tunnel Mode .........................................7 1.1.2. Endpoint-to-Endpoint Transport Mode .................8 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 ...........................................16 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 ........18 1.5. Informational Messages outside of an IKE SA ...............19 1.6. Requirements Terminology ..................................20 1.7. Significant Differences between RFC 4306 and RFC 5996 .....20 1.8. Differences between RFC 5996 and This Document ............23 2. IKE Protocol Details and Variations ............................23 2.1. Use of Retransmission Timers ..............................24 2.2. Use of Sequence Numbers for Message ID ....................25 2.3. Window Size for Overlapping Requests ......................26 2.4. State Synchronization and Connection Timeouts .............28 2.5. Version Numbers and Forward Compatibility .................30 2.6. IKE SA SPIs and Cookies ...................................32 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD .......35 2.7. Cryptographic Algorithm Negotiation .......................35 2.8. Rekeying ..................................................36 2.8.1. Simultaneous Child SA Rekeying .....................38 2.8.2. Simultaneous IKE SA Rekeying .......................40 2.8.3. Rekeying the IKE SA versus Reauthentication ........42 2.9. Traffic Selector Negotiation ..............................42 2.9.1. Traffic Selectors Violating Own Policy .............45 2.9.2. Traffic Selectors in Rekeying ......................46 2.10. Nonces ...................................................46 2.11. Address and Port Agility .................................47 2.12. Reuse of Diffie-Hellman Exponentials .....................47 2.13. Generating Keying Material ...............................48 2.14. Generating Keying Material for the IKE SA ................49 2.15. Authentication of the IKE SA .............................50 2.16. Extensible Authentication Protocol Methods ...............52 2.17. Generating Keying Material for Child SAs .................54 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange ........55
2.19. Requesting an Internal Address on a Remote Network .......56
2.20. Requesting the Peer's Version ............................58
2.21. Error Handling ...........................................58
2.21.1. Error Handling in IKE_SA_INIT .....................59
2.21.2. Error Handling in IKE_AUTH ........................59
2.21.3. Error Handling after IKE SA is Authenticated ......60
2.21.4. Error Handling Outside IKE SA .....................60
2.22. IPComp ...................................................61
2.23. NAT Traversal ............................................62
2.23.1. Transport Mode NAT Traversal ......................66
2.24. Explicit Congestion Notification (ECN) ...................70
2.25. Exchange Collisions ......................................70
2.25.1. Collisions while Rekeying or Closing Child SAs ....71
2.25.2. Collisions while Rekeying or Closing IKE SAs ......71
3. Header and Payload Formats .....................................72
3.1. The IKE Header ............................................72
3.2. Generic Payload Header ....................................75
3.3. Security Association Payload ..............................77
3.3.1. Proposal Substructure ..............................80
3.3.2. Transform Substructure .............................81
3.3.3. Valid Transform Types by Protocol ..................85
3.3.4. Mandatory Transform IDs ............................85
3.3.5. Transform Attributes ...............................86
3.3.6. Attribute Negotiation ..............................88
3.4. Key Exchange Payload ......................................89
3.5. Identification Payloads ...................................90
3.6. Certificate Payload .......................................92
3.7. Certificate Request Payload ...............................95
3.8. Authentication Payload ....................................97
3.9. Nonce Payload .............................................98
3.10. Notify Payload ...........................................99
3.10.1. Notify Message Types .............................101
3.11. Delete Payload ..........................................104
3.12. Vendor ID Payload .......................................105
3.13. Traffic Selector Payload ................................106
3.13.1. Traffic Selector .................................108
3.14. Encrypted Payload .......................................110
3.15. Configuration Payload ...................................112
3.15.1. Configuration Attributes .........................113
3.15.2. Meaning of INTERNAL_IP4_SUBNET and
INTERNAL_IP6_SUBNET ..............................116
3.15.3. Configuration Payloads for IPv6 ..................118
3.15.4. Address Assignment Failures ......................119
3.16. Extensible Authentication Protocol (EAP) Payload ........120
4. Conformance Requirements ......................................122
5. Security Considerations .......................................124
5.1. Traffic Selector Authorization ...........................127
6. IANA Considerations ...........................................128 7. References ....................................................128 7.1. Normative References .....................................128 7.2. Informative References ...................................130 Appendix A. Summary of Changes from IKEv1 ........................136 Appendix B. Diffie-Hellman Groups ................................137 B.1. Group 1 - 768-bit MODP ....................................137 B.2. Group 2 - 1024-bit MODP ...................................137 Appendix C. Exchanges and Payloads ...............................138 C.1. IKE_SA_INIT Exchange ......................................138 C.2. IKE_AUTH Exchange without EAP .............................138 C.3. IKE_AUTH Exchange with EAP ................................139 C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying Child SAs .................................................140 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA ..........140 C.6. INFORMATIONAL Exchange ....................................141 Acknowledgements .................................................141 Authors' Addresses ...............................................1421. 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). [RFC5996] replaced and updated RFCs 4306 and 4718. This document replaces RFC 5996. IKEv2 as stated in RFC 4306 was a change to the IKE protocol that was not backward compatible. RFC 5996 revised RFC 4306 to provide a clarification of IKEv2, making minimal changes to the IKEv2 protocol. This document replaces RFC 5996, slightly revising it to make it suitable for progression to Internet Standard. A list of the significant differences between RFCs 4306 and 5996 is given in Section 1.7, and differences between RFC 5996 and this document are given in Section 1.8.
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 two exchanges of messages establishing an IKE SA are called the IKE_SA_INIT exchange and the IKE_AUTH exchange; subsequent IKE exchanges are called either CREATE_CHILD_SA exchanges 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 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.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. 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 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. 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, Exchange Type, Message ID, 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] 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 a quantity called SKEYSEED (see Section 2.14), 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. <-- 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. 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. 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, a nonce in the Nr 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.
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, a nonce in the Nr 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. 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, a nonce in the Nr 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.
(page 17 continued on part 2)