4 Network Working Group C. Kaufman
5 Internet-Draft Microsoft
6 Obsoletes: 4306, 4718 P. Hoffman
7 (if approved) VPN Consortium
8 Intended status: Standards Track Y. Nir
9 Expires: October 26, 2009 Check Point
15 Internet Key Exchange Protocol: IKEv2
16 draft-ietf-ipsecme-ikev2bis-03
20 This Internet-Draft is submitted to IETF in full conformance with the
21 provisions of BCP 78 and BCP 79. This document may contain material
22 from IETF Documents or IETF Contributions published or made publicly
23 available before November 10, 2008. The person(s) controlling the
24 copyright in some of this material may not have granted the IETF
25 Trust the right to allow modifications of such material outside the
26 IETF Standards Process. Without obtaining an adequate license from
27 the person(s) controlling the copyright in such materials, this
28 document may not be modified outside the IETF Standards Process, and
29 derivative works of it may not be created outside the IETF Standards
30 Process, except to format it for publication as an RFC or to
31 translate it into languages other than English.
33 Internet-Drafts are working documents of the Internet Engineering
34 Task Force (IETF), its areas, and its working groups. Note that
35 other groups may also distribute working documents as Internet-
38 Internet-Drafts are draft documents valid for a maximum of six months
39 and may be updated, replaced, or obsoleted by other documents at any
40 time. It is inappropriate to use Internet-Drafts as reference
41 material or to cite them other than as "work in progress."
43 The list of current Internet-Drafts can be accessed at
44 http://www.ietf.org/ietf/1id-abstracts.txt.
46 The list of Internet-Draft Shadow Directories can be accessed at
47 http://www.ietf.org/shadow.html.
49 This Internet-Draft will expire on October 26, 2009.
55 Kaufman, et al. Expires October 26, 2009 [Page 1]
57 Internet-Draft IKEv2bis April 2009
60 Copyright (c) 2009 IETF Trust and the persons identified as the
61 document authors. All rights reserved.
63 This document is subject to BCP 78 and the IETF Trust's Legal
64 Provisions Relating to IETF Documents in effect on the date of
65 publication of this document (http://trustee.ietf.org/license-info).
66 Please review these documents carefully, as they describe your rights
67 and restrictions with respect to this document.
71 This document describes version 2 of the Internet Key Exchange (IKE)
72 protocol. IKE is a component of IPsec used for performing mutual
73 authentication and establishing and maintaining security associations
74 (SAs). It replaces and updates RFC 4306, and includes all of the
75 clarifications from RFC 4718.
111 Kaufman, et al. Expires October 26, 2009 [Page 2]
113 Internet-Draft IKEv2bis April 2009
118 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
119 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 7
120 1.1.1. Security Gateway to Security Gateway Tunnel Mode . . 7
121 1.1.2. Endpoint-to-Endpoint Transport Mode . . . . . . . . . 8
122 1.1.3. Endpoint to Security Gateway Tunnel Mode . . . . . . 9
123 1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . 9
124 1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 10
125 1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 13
126 1.3.1. Creating New Child SAs with the CREATE_CHILD_SA
127 Exchange . . . . . . . . . . . . . . . . . . . . . . 14
128 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange . 16
129 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA
130 Exchange . . . . . . . . . . . . . . . . . . . . . . 16
131 1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 17
132 1.4.1. Deleting an SA with INFORMATIONAL Exchanges . . . . . 18
133 1.5. Informational Messages outside of an IKE SA . . . . . . . 18
134 1.6. Requirements Terminology . . . . . . . . . . . . . . . . 19
135 1.7. Differences Between RFC 4306 and This Document . . . . . 20
136 2. IKE Protocol Details and Variations . . . . . . . . . . . . . 21
137 2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 22
138 2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 23
139 2.3. Window Size for Overlapping Requests . . . . . . . . . . 24
140 2.4. State Synchronization and Connection Timeouts . . . . . . 25
141 2.5. Version Numbers and Forward Compatibility . . . . . . . . 27
142 2.6. IKE SA SPIs and Cookies . . . . . . . . . . . . . . . . . 29
143 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 32
144 2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 32
145 2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 34
146 2.8.1. Simultaneous Child SA rekeying . . . . . . . . . . . 36
147 2.8.2. Simultaneous IKE SA Rekeying . . . . . . . . . . . . 38
148 2.8.3. Rekeying the IKE SA Versus Reauthentication . . . . . 39
149 2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 39
150 2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 42
151 2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 43
152 2.11. Address and Port Agility . . . . . . . . . . . . . . . . 43
153 2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 43
154 2.13. Generating Keying Material . . . . . . . . . . . . . . . 44
155 2.14. Generating Keying Material for the IKE SA . . . . . . . . 45
156 2.15. Authentication of the IKE SA . . . . . . . . . . . . . . 46
157 2.16. Extensible Authentication Protocol Methods . . . . . . . 48
158 2.17. Generating Keying Material for Child SAs . . . . . . . . 50
159 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange . . . . 51
160 2.19. Requesting an Internal Address on a Remote Network . . . 52
161 2.19.1. Configuration Payloads . . . . . . . . . . . . . . . 53
162 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 55
163 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 55
167 Kaufman, et al. Expires October 26, 2009 [Page 3]
169 Internet-Draft IKEv2bis April 2009
172 2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 56
173 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 58
174 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 61
175 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 62
176 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 62
177 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 65
178 3.3. Security Association Payload . . . . . . . . . . . . . . 67
179 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 69
180 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 71
181 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 74
182 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 74
183 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 75
184 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 77
185 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 78
186 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 79
187 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 81
188 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 83
189 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 85
190 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 87
191 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 87
192 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 88
193 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 91
194 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 93
195 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 94
196 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 95
197 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 97
198 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 99
199 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 100
200 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 103
201 3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 105
202 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 106
203 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 106
204 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 108
205 5. Security Considerations . . . . . . . . . . . . . . . . . . . 110
206 5.1. Traffic selector authorization . . . . . . . . . . . . . 113
207 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 114
208 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 114
209 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 115
210 8.1. Normative References . . . . . . . . . . . . . . . . . . 115
211 8.2. Informative References . . . . . . . . . . . . . . . . . 116
212 Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 120
213 Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 121
214 B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 122
215 B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 122
216 Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 122
217 C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 123
218 C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 124
219 C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 125
223 Kaufman, et al. Expires October 26, 2009 [Page 4]
225 Internet-Draft IKEv2bis April 2009
228 C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying
229 Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 126
230 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA . . . . 126
231 C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 126
232 Appendix D. Significant Changes from RFC 4306 . . . . . . . . . 126
233 Appendix E. Changes Between Internet Draft Versions . . . . . . 127
234 E.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 127
235 E.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 127
236 E.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 129
237 E.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 130
238 E.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 131
239 E.6. Changes from draft -03 to
240 draft-ietf-ipsecme-ikev2bis-00 . . . . . . . . . . . . . 132
241 E.7. Changes from draft-ietf-ipsecme-ikev2bis-00 to
242 draft-ietf-ipsecme-ikev2bis-01 . . . . . . . . . . . . . 133
243 E.8. Changes from draft-ietf-ipsecme-ikev2bis-01 to
244 draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 137
245 E.9. Changes from draft-ietf-ipsecme-ikev2bis-01 to
246 draft-ietf-ipsecme-ikev2bis-02 . . . . . . . . . . . . . 139
247 E.10. Changes from draft-ietf-ipsecme-ikev2bis-02 to
248 draft-ietf-ipsecme-ikev2bis-03 . . . . . . . . . . . . . 140
249 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 140
279 Kaufman, et al. Expires October 26, 2009 [Page 5]
281 Internet-Draft IKEv2bis April 2009
286 {{ An introduction to the differences between RFC 4306 [IKEV2] and
287 this document is given at the end of Section 1. It is put there
288 (instead of here) to preserve the section numbering of RFC 4306. }}
290 IP Security (IPsec) provides confidentiality, data integrity, access
291 control, and data source authentication to IP datagrams. These
292 services are provided by maintaining shared state between the source
293 and the sink of an IP datagram. This state defines, among other
294 things, the specific services provided to the datagram, which
295 cryptographic algorithms will be used to provide the services, and
296 the keys used as input to the cryptographic algorithms.
298 Establishing this shared state in a manual fashion does not scale
299 well. Therefore, a protocol to establish this state dynamically is
300 needed. This memo describes such a protocol -- the Internet Key
301 Exchange (IKE). Version 1 of IKE was defined in RFCs 2407 [DOI],
302 2408 [ISAKMP], and 2409 [IKEV1]. IKEv2 replaced all of those RFCs.
303 IKEv2 was defined in [IKEV2] (RFC 4306) and was clarified in [Clarif]
304 (RFC 4718). This document replaces and updates RFC 4306 and RFC
307 IKE performs mutual authentication between two parties and
308 establishes an IKE security association (SA) that includes shared
309 secret information that can be used to efficiently establish SAs for
310 Encapsulating Security Payload (ESP) [ESP] or Authentication Header
311 (AH) [AH] and a set of cryptographic algorithms to be used by the SAs
312 to protect the traffic that they carry. In this document, the term
313 "suite" or "cryptographic suite" refers to a complete set of
314 algorithms used to protect an SA. An initiator proposes one or more
315 suites by listing supported algorithms that can be combined into
316 suites in a mix-and-match fashion. IKE can also negotiate use of IP
317 Compression (IPComp) [IP-COMP] in connection with an ESP or AH SA.
318 The SAs for ESP or AH that get set up through that IKE SA we call
321 All IKE communications consist of pairs of messages: a request and a
322 response. The pair is called an "exchange". We call the first
323 messages establishing an IKE SA IKE_SA_INIT and IKE_AUTH exchanges
324 and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL
325 exchanges. In the common case, there is a single IKE_SA_INIT
326 exchange and a single IKE_AUTH exchange (a total of four messages) to
327 establish the IKE SA and the first Child SA. In exceptional cases,
328 there may be more than one of each of these exchanges. In all cases,
329 all IKE_SA_INIT exchanges MUST complete before any other exchange
330 type, then all IKE_AUTH exchanges MUST complete, and following that
331 any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur
335 Kaufman, et al. Expires October 26, 2009 [Page 6]
337 Internet-Draft IKEv2bis April 2009
340 in any order. In some scenarios, only a single Child SA is needed
341 between the IPsec endpoints, and therefore there would be no
342 additional exchanges. Subsequent exchanges MAY be used to establish
343 additional Child SAs between the same authenticated pair of endpoints
344 and to perform housekeeping functions.
346 IKE message flow always consists of a request followed by a response.
347 It is the responsibility of the requester to ensure reliability. If
348 the response is not received within a timeout interval, the requester
349 needs to retransmit the request (or abandon the connection).
351 The first request/response of an IKE session (IKE_SA_INIT) negotiates
352 security parameters for the IKE SA, sends nonces, and sends Diffie-
355 The second request/response (IKE_AUTH) transmits identities, proves
356 knowledge of the secrets corresponding to the two identities, and
357 sets up an SA for the first (and often only) AH or ESP Child SA
358 (unless there is failure setting up the AH or ESP Child SA, in which
359 case the IKE SA is still established without IPsec SA).
361 The types of subsequent exchanges are CREATE_CHILD_SA (which creates
362 a Child SA) and INFORMATIONAL (which deletes an SA, reports error
363 conditions, or does other housekeeping). Every request requires a
364 response. An INFORMATIONAL request with no payloads (other than the
365 empty Encrypted payload required by the syntax) is commonly used as a
366 check for liveness. These subsequent exchanges cannot be used until
367 the initial exchanges have completed.
369 In the description that follows, we assume that no errors occur.
370 Modifications to the flow should errors occur are described in
375 IKE is expected to be used to negotiate ESP or AH SAs in a number of
376 different scenarios, each with its own special requirements.
378 1.1.1. Security Gateway to Security Gateway Tunnel Mode
380 +-+-+-+-+-+ +-+-+-+-+-+
382 Protected |Tunnel | tunnel |Tunnel | Protected
383 Subnet <-->|Endpoint |<---------->|Endpoint |<--> Subnet
385 +-+-+-+-+-+ +-+-+-+-+-+
387 Figure 1: Security Gateway to Security Gateway Tunnel
391 Kaufman, et al. Expires October 26, 2009 [Page 7]
393 Internet-Draft IKEv2bis April 2009
396 In this scenario, neither endpoint of the IP connection implements
397 IPsec, but network nodes between them protect traffic for part of the
398 way. Protection is transparent to the endpoints, and depends on
399 ordinary routing to send packets through the tunnel endpoints for
400 processing. Each endpoint would announce the set of addresses
401 "behind" it, and packets would be sent in tunnel mode where the inner
402 IP header would contain the IP addresses of the actual endpoints.
404 1.1.2. Endpoint-to-Endpoint Transport Mode
406 +-+-+-+-+-+ +-+-+-+-+-+
407 | | IPsec transport | |
408 |Protected| or tunnel mode SA |Protected|
409 |Endpoint |<---------------------------------------->|Endpoint |
411 +-+-+-+-+-+ +-+-+-+-+-+
413 Figure 2: Endpoint to Endpoint
415 In this scenario, both endpoints of the IP connection implement
416 IPsec, as required of hosts in [IPSECARCH]. Transport mode will
417 commonly be used with no inner IP header. A single pair of addresses
418 will be negotiated for packets to be protected by this SA. These
419 endpoints MAY implement application layer access controls based on
420 the IPsec authenticated identities of the participants. This
421 scenario enables the end-to-end security that has been a guiding
422 principle for the Internet since [ARCHPRINC], [TRANSPARENCY], and a
423 method of limiting the inherent problems with complexity in networks
424 noted by [ARCHGUIDEPHIL]. Although this scenario may not be fully
425 applicable to the IPv4 Internet, it has been deployed successfully in
426 specific scenarios within intranets using IKEv1. It should be more
427 broadly enabled during the transition to IPv6 and with the adoption
430 It is possible in this scenario that one or both of the protected
431 endpoints will be behind a network address translation (NAT) node, in
432 which case the tunneled packets will have to be UDP encapsulated so
433 that port numbers in the UDP headers can be used to identify
434 individual endpoints "behind" the NAT (see Section 2.23).
447 Kaufman, et al. Expires October 26, 2009 [Page 8]
449 Internet-Draft IKEv2bis April 2009
452 1.1.3. Endpoint to Security Gateway Tunnel Mode
454 +-+-+-+-+-+ +-+-+-+-+-+
455 | | IPsec | | Protected
456 |Protected| tunnel |Tunnel | Subnet
457 |Endpoint |<------------------------>|Endpoint |<--- and/or
459 +-+-+-+-+-+ +-+-+-+-+-+
461 Figure 3: Endpoint to Security Gateway Tunnel
463 In this scenario, a protected endpoint (typically a portable roaming
464 computer) connects back to its corporate network through an IPsec-
465 protected tunnel. It might use this tunnel only to access
466 information on the corporate network, or it might tunnel all of its
467 traffic back through the corporate network in order to take advantage
468 of protection provided by a corporate firewall against Internet-based
469 attacks. In either case, the protected endpoint will want an IP
470 address associated with the security gateway so that packets returned
471 to it will go to the security gateway and be tunneled back. This IP
472 address may be static or may be dynamically allocated by the security
473 gateway. {{ Clarif-6.1 }} In support of the latter case, IKEv2
474 includes a mechanism (namely, configuration payloads) for the
475 initiator to request an IP address owned by the security gateway for
476 use for the duration of its SA.
478 In this scenario, packets will use tunnel mode. On each packet from
479 the protected endpoint, the outer IP header will contain the source
480 IP address associated with its current location (i.e., the address
481 that will get traffic routed to the endpoint directly), while the
482 inner IP header will contain the source IP address assigned by the
483 security gateway (i.e., the address that will get traffic routed to
484 the security gateway for forwarding to the endpoint). The outer
485 destination address will always be that of the security gateway,
486 while the inner destination address will be the ultimate destination
489 In this scenario, it is possible that the protected endpoint will be
490 behind a NAT. In that case, the IP address as seen by the security
491 gateway will not be the same as the IP address sent by the protected
492 endpoint, and packets will have to be UDP encapsulated in order to be
495 1.1.4. Other Scenarios
497 Other scenarios are possible, as are nested combinations of the
498 above. One notable example combines aspects of 1.1.1 and 1.1.3. A
499 subnet may make all external accesses through a remote security
503 Kaufman, et al. Expires October 26, 2009 [Page 9]
505 Internet-Draft IKEv2bis April 2009
508 gateway using an IPsec tunnel, where the addresses on the subnet are
509 routed to the security gateway by the rest of the Internet. An
510 example would be someone's home network being virtually on the
511 Internet with static IP addresses even though connectivity is
512 provided by an ISP that assigns a single dynamically assigned IP
513 address to the user's security gateway (where the static IP addresses
514 and an IPsec relay are provided by a third party located elsewhere).
516 1.2. The Initial Exchanges
518 Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH
519 exchanges (known in IKEv1 as Phase 1). These initial exchanges
520 normally consist of four messages, though in some scenarios that
521 number can grow. All communications using IKE consist of request/
522 response pairs. We'll describe the base exchange first, followed by
523 variations. The first pair of messages (IKE_SA_INIT) negotiate
524 cryptographic algorithms, exchange nonces, and do a Diffie-Hellman
527 The second pair of messages (IKE_AUTH) authenticate the previous
528 messages, exchange identities and certificates, and establish the
529 first Child SA. Parts of these messages are encrypted and integrity
530 protected with keys established through the IKE_SA_INIT exchange, so
531 the identities are hidden from eavesdroppers and all fields in all
532 the messages are authenticated. (See Section 2.14 for information on
533 how the encyrption keys are generated.)
535 All messages following the initial exchange are cryptographically
536 protected using the cryptographic algorithms and keys negotiated in
537 the the IKE_SA_INIT exchange. These subsequent messages use the
538 syntax of the Encrypted Payload described in Section 3.14, encrypted
539 with keys that are derived as described in Section 2.14. All
540 subsequent messages include an Encrypted Payload, even if they are
541 referred to in the text as "empty". For the CREATE_CHILD_SA,
542 IKE_AUTH, or IKE_INFORMATIONAL exchanges, the message following the
543 header is encrypted and the message including the header is integrity
544 protected using the cryptographic algorithms negotiated for the IKE
547 In the following descriptions, the payloads contained in the message
548 are indicated by names as listed below.
559 Kaufman, et al. Expires October 26, 2009 [Page 10]
561 Internet-Draft IKEv2bis April 2009
565 -----------------------------------------
568 CERTREQ Certificate Request
572 EAP Extensible Authentication
574 IDi Identification - Initiator
575 IDr Identification - Responder
579 SA Security Association
580 TSi Traffic Selector - Initiator
581 TSr Traffic Selector - Responder
584 The details of the contents of each payload are described in section
585 3. Payloads that may optionally appear will be shown in brackets,
586 such as [CERTREQ], indicate that optionally a certificate request
587 payload can be included.
589 The initial exchanges are as follows:
592 -------------------------------------------------------------------
593 HDR, SAi1, KEi, Ni -->
595 HDR contains the Security Parameter Indexes (SPIs), version numbers,
596 and flags of various sorts. The SAi1 payload states the
597 cryptographic algorithms the initiator supports for the IKE SA. The
598 KE payload sends the initiator's Diffie-Hellman value. Ni is the
601 <-- HDR, SAr1, KEr, Nr, [CERTREQ]
603 The responder chooses a cryptographic suite from the initiator's
604 offered choices and expresses that choice in the SAr1 payload,
605 completes the Diffie-Hellman exchange with the KEr payload, and sends
606 its nonce in the Nr payload.
608 At this point in the negotiation, each party can generate SKEYSEED,
609 from which all keys are derived for that IKE SA. The messages that
610 follow are encrypted and integrity protected in their entirety, with
611 the exception of the message headers. The keys used for the
615 Kaufman, et al. Expires October 26, 2009 [Page 11]
617 Internet-Draft IKEv2bis April 2009
620 encryption and integrity protection are derived from SKEYSEED and are
621 known as SK_e (encryption) and SK_a (authentication, a.k.a. integrity
622 protection). A separate SK_e and SK_a is computed for each
623 direction. In addition to the keys SK_e and SK_a derived from the DH
624 value for protection of the IKE SA, another quantity SK_d is derived
625 and used for derivation of further keying material for Child SAs.
626 The notation SK { ... } indicates that these payloads are encrypted
627 and integrity protected using that direction's SK_e and SK_a.
629 HDR, SK {IDi, [CERT,] [CERTREQ,]
633 The initiator asserts its identity with the IDi payload, proves
634 knowledge of the secret corresponding to IDi and integrity protects
635 the contents of the first message using the AUTH payload (see
636 Section 2.15). It might also send its certificate(s) in CERT
637 payload(s) and a list of its trust anchors in CERTREQ payload(s). If
638 any CERT payloads are included, the first certificate provided MUST
639 contain the public key used to verify the AUTH field.
641 The optional payload IDr enables the initiator to specify which of
642 the responder's identities it wants to talk to. This is useful when
643 the machine on which the responder is running is hosting multiple
644 identities at the same IP address. If the IDr proposed by the
645 initiator is not acceptable to the responder, the responder might use
646 some other IDr to finish the exchange. If the initiator then does
647 not accept that fact that responder used different IDr than the one
648 that was requested, the initiator can close the SA after noticing the
651 The initiator begins negotiation of a Child SA using the SAi2
652 payload. The final fields (starting with SAi2) are described in the
653 description of the CREATE_CHILD_SA exchange.
655 <-- HDR, SK {IDr, [CERT,] AUTH,
658 The responder asserts its identity with the IDr payload, optionally
659 sends one or more certificates (again with the certificate containing
660 the public key used to verify AUTH listed first), authenticates its
661 identity and protects the integrity of the second message with the
662 AUTH payload, and completes negotiation of a Child SA with the
663 additional fields described below in the CREATE_CHILD_SA exchange.
665 The recipients of messages 3 and 4 MUST verify that all signatures
666 and MACs are computed correctly and that the names in the ID payloads
667 correspond to the keys used to generate the AUTH payload.
671 Kaufman, et al. Expires October 26, 2009 [Page 12]
673 Internet-Draft IKEv2bis April 2009
676 {{ Clarif-4.2}} If creating the Child SA during the IKE_AUTH exchange
677 fails for some reason, the IKE SA is still created as usual. The
678 list of responses in the IKE_AUTH exchange that do not prevent an IKE
679 SA from being set up include at least the following:
680 NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,
681 INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED.
683 {{ Clarif-4.3 }} Note that IKE_AUTH messages do not contain KEi/KEr
684 or Ni/Nr payloads. Thus, the SA payloads in the IKE_AUTH exchange
685 cannot contain Transform Type 4 (Diffie-Hellman Group) with any value
686 other than NONE. Implementations SHOULD omit the whole transform
687 substructure instead of sending value NONE.
689 1.3. The CREATE_CHILD_SA Exchange
691 {{ This is a heavy rewrite of most of this section. The major
692 organization changes are described in Clarif-4.1 and Clarif-5.1. }}
694 The CREATE_CHILD_SA exchange is used to create new Child SAs and to
695 rekey both IKE SAs and Child SAs. This exchange consists of a single
696 request/response pair, and some of its function was referred to as a
697 phase 2 exchange in IKEv1. It MAY be initiated by either end of the
698 IKE SA after the initial exchanges are completed.
700 All messages following the initial exchange are cryptographically
701 protected using the cryptographic algorithms and keys negotiated in
702 the first two messages of the IKE exchange. These subsequent
703 messages use the syntax of the Encrypted Payload described in
704 Section 3.14, encrypted with keys that are derived as described in
705 Section 2.14. All subsequent messages include an Encrypted Payload,
706 even if they are referred to in the text as "empty". For both
707 messages in the CREATE_CHILD_SA, the message following the header is
708 encrypted and the message including the header is integrity protected
709 using the cryptographic algorithms negotiated for the IKE SA.
711 The CREATE_CHILD_SA is also used for rekeying IKE SAs and Child SAs.
712 An SA is rekeyed by creating a new SA and then deleting the old one.
713 This section describes the first part of rekeying, the creation of
714 new SAs; Section 2.8 covers the mechanics of rekeying, including
715 moving traffic from old to new SAs and the deletion of the old SAs.
716 The two sections must be read together to understand the entire
719 Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this
720 section the term initiator refers to the endpoint initiating this
721 exchange. An implementation MAY refuse all CREATE_CHILD_SA requests
727 Kaufman, et al. Expires October 26, 2009 [Page 13]
729 Internet-Draft IKEv2bis April 2009
732 The CREATE_CHILD_SA request MAY optionally contain a KE payload for
733 an additional Diffie-Hellman exchange to enable stronger guarantees
734 of forward secrecy for the Child SA. The keying material for the
735 Child SA is a function of SK_d established during the establishment
736 of the IKE SA, the nonces exchanged during the CREATE_CHILD_SA
737 exchange, and the Diffie-Hellman value (if KE payloads are included
738 in the CREATE_CHILD_SA exchange).
740 If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of
741 the SA offers MUST include the Diffie-Hellman group of the KEi. The
742 Diffie-Hellman group of the KEi MUST be an element of the group the
743 initiator expects the responder to accept (additional Diffie-Hellman
744 groups can be proposed). If the responder selects a proposal using a
745 different Diffie-Hellman group (other than NONE), the responder MUST
746 reject the request and indicate its preferred Diffie-Hellman group in
747 the INVALID_KE_PAYLOAD Notification payload. {{ 3.10.1-17 }} There
748 are two octets of data associated with this notification: the
749 accepted D-H Group number in big endian order. In the case of such a
750 rejection, the CREATE_CHILD_SA exchange fails, and the initiator will
751 probably retry the exchange with a Diffie-Hellman proposal and KEi in
752 the group that the responder gave in the INVALID_KE_PAYLOAD.
754 {{ 3.10.1-35 }} The responder sends a NO_ADDITIONAL_SAS notification
755 to indicate that a CREATE_CHILD_SA request is unacceptable because
756 the responder is unwilling to accept any more Child SAs on this IKE
757 SA. Some minimal implementations may only accept a single Child SA
758 setup in the context of an initial IKE exchange and reject any
759 subsequent attempts to add more.
761 1.3.1. Creating New Child SAs with the CREATE_CHILD_SA Exchange
763 A Child SA may be created by sending a CREATE_CHILD_SA request. The
764 CREATE_CHILD_SA request for creating a new Child SA is:
767 -------------------------------------------------------------------
768 HDR, SK {SA, Ni, [KEi],
771 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
772 payload, optionally a Diffie-Hellman value in the KEi payload, and
773 the proposed traffic selectors for the proposed Child SA in the TSi
776 The CREATE_CHILD_SA response for creating a new Child SA is:
778 <-- HDR, SK {SA, Nr, [KEr],
783 Kaufman, et al. Expires October 26, 2009 [Page 14]
785 Internet-Draft IKEv2bis April 2009
788 The responder replies (using the same Message ID to respond) with the
789 accepted offer in an SA payload, and a Diffie-Hellman value in the
790 KEr payload if KEi was included in the request and the selected
791 cryptographic suite includes that group.
793 The traffic selectors for traffic to be sent on that SA are specified
794 in the TS payloads in the response, which may be a subset of what the
795 initiator of the Child SA proposed.
797 {{ 3.10.1-16391 }} The USE_TRANSPORT_MODE notification MAY be
798 included in a request message that also includes an SA payload
799 requesting a Child SA. It requests that the Child SA use transport
800 mode rather than tunnel mode for the SA created. If the request is
801 accepted, the response MUST also include a notification of type
802 USE_TRANSPORT_MODE. If the responder declines the request, the Child
803 SA will be established in tunnel mode. If this is unacceptable to
804 the initiator, the initiator MUST delete the SA. Note: Except when
805 using this option to negotiate transport mode, all Child SAs will use
808 {{ 3.10.1-16394 }} The ESP_TFC_PADDING_NOT_SUPPORTED notification
809 asserts that the sending endpoint will NOT accept packets that
810 contain Traffic Flow Confidentiality (TFC) padding over the Child SA
811 being negotiated. {{ Clarif-4.5 }} If neither endpoint accepts TFC
812 padding, this notification is included in both the request and the
813 response. If this notification is included in only one of the
814 messages, TFC padding can still be sent in the other direction.
816 {{ 3.10.1-16395 }} The NON_FIRST_FRAGMENTS_ALSO notification is used
817 for fragmentation control. See [IPSECARCH] for a fuller explanation.
818 {{ Clarif-4.6 }} Both parties need to agree to sending non-first
819 fragments before either party does so. It is enabled only if
820 NON_FIRST_FRAGMENTS_ALSO notification is included in both the request
821 proposing an SA and the response accepting it. If the responder does
822 not want to send or receive non-first fragments, it only omits
823 NON_FIRST_FRAGMENTS_ALSO notification from its response, but does not
824 reject the whole Child SA creation.
826 Failure of an attempt to create a CHILD SA SHOULD NOT tear down the
827 IKE SA: there is no reason to lose the work done to set up the IKE
828 SA. When an IKE SA is not created, the error message return SHOULD
829 NOT be encrypted because the other party will not be able to
830 authenticate that message. [[ Note: this text may be changed in the
839 Kaufman, et al. Expires October 26, 2009 [Page 15]
841 Internet-Draft IKEv2bis April 2009
844 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange
846 The CREATE_CHILD_SA request for rekeying an IKE SA is:
849 -------------------------------------------------------------------
850 HDR, SK {SA, Ni, KEi} -->
852 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
853 payload, and a Diffie-Hellman value in the KEi payload. The KEi
854 payload MUST be included. New initiator and responder SPIs are
855 supplied in the SPI fields of the SA payload.
857 The CREATE_CHILD_SA response for rekeying an IKE SA is:
859 <-- HDR, SK {SA, Nr,[KEr]}
861 The responder replies (using the same Message ID to respond) with the
862 accepted offer in an SA payload, and a Diffie-Hellman value in the
863 KEr payload if the selected cryptographic suite includes that group.
865 The new IKE SA has its message counters set to 0, regardless of what
866 they were in the earlier IKE SA. The first IKE requests from both
867 sides on the new IKE SA will have message ID 0. The old IKE SA
868 retains its numbering, so any further requests (for example, to
869 delete the IKE SA) will have consecutive numbering. The new IKE SA
870 also has its window size reset to 1, and the initiator in this rekey
871 exchange is the new "original initiator" of the new IKE SA.
873 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange
875 The CREATE_CHILD_SA request for rekeying a Child SA is:
878 -------------------------------------------------------------------
879 HDR, SK {N, SA, Ni, [KEi],
882 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
883 payload, optionally a Diffie-Hellman value in the KEi payload, and
884 the proposed traffic selectors for the proposed Child SA in the TSi
887 {{ 3.10.1-16393 }} The REKEY_SA notification MUST be included in a
888 CREATE_CHILD_SA exchange if the purpose of the exchange is to replace
889 an existing ESP or AH SA. {{ Clarif-5.4 }} The SA being rekeyed is
890 identified by the SPI field in the Notify payload; this is the SPI
891 the exchange initiator would expect in inbound ESP or AH packets.
895 Kaufman, et al. Expires October 26, 2009 [Page 16]
897 Internet-Draft IKEv2bis April 2009
900 There is no data associated with this Notify type. The Protocol ID
901 field of the REKEY_SA notification is set to match the protocol of
902 the SA we are rekeying, for example, 3 for ESP and 2 for AH.
904 The CREATE_CHILD_SA response for rekeying a Child SA is:
906 <-- HDR, SK {SA, Nr, [KEr],
909 The responder replies (using the same Message ID to respond) with the
910 accepted offer in an SA payload, and a Diffie-Hellman value in the
911 KEr payload if KEi was included in the request and the selected
912 cryptographic suite includes that group.
914 The traffic selectors for traffic to be sent on that SA are specified
915 in the TS payloads in the response, which may be a subset of what the
916 initiator of the Child SA proposed.
918 1.4. The INFORMATIONAL Exchange
920 At various points during the operation of an IKE SA, peers may desire
921 to convey control messages to each other regarding errors or
922 notifications of certain events. To accomplish this, IKE defines an
923 INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur
924 after the initial exchanges and are cryptographically protected with
927 Control messages that pertain to an IKE SA MUST be sent under that
928 IKE SA. Control messages that pertain to Child SAs MUST be sent
929 under the protection of the IKE SA which generated them (or its
930 successor if the IKE SA was rekeyed).
932 Messages in an INFORMATIONAL exchange contain zero or more
933 Notification, Delete, and Configuration payloads. The Recipient of
934 an INFORMATIONAL exchange request MUST send some response (else the
935 Sender will assume the message was lost in the network and will
936 retransmit it). That response MAY be a message with no payloads.
937 The request message in an INFORMATIONAL exchange MAY also contain no
938 payloads. This is the expected way an endpoint can ask the other
939 endpoint to verify that it is alive.
941 The INFORMATIONAL exchange is defined as:
944 -------------------------------------------------------------------
947 <-- HDR, SK {[N,] [D,]
951 Kaufman, et al. Expires October 26, 2009 [Page 17]
953 Internet-Draft IKEv2bis April 2009
958 The processing of an INFORMATIONAL exchange is determined by its
961 1.4.1. Deleting an SA with INFORMATIONAL Exchanges
963 {{ Clarif-5.6 }} ESP and AH SAs always exist in pairs, with one SA in
964 each direction. When an SA is closed, both members of the pair MUST
965 be closed (that is, deleted). Each endpoint MUST close its incoming
966 SAs and allow the other endpoint to close the other SA in each pair.
967 To delete an SA, an INFORMATIONAL exchange with one or more delete
968 payloads is sent listing the SPIs (as they would be expected in the
969 headers of inbound packets) of the SAs to be deleted. The recipient
970 MUST close the designated SAs. {{ Clarif-5.7 }} Note that one never
971 sends delete payloads for the two sides of an SA in a single message.
972 If there are many SAs to delete at the same time, one includes delete
973 payloads for the inbound half of each SA pair in your Informational
976 Normally, the reply in the INFORMATIONAL exchange will contain delete
977 payloads for the paired SAs going in the other direction. There is
978 one exception. If by chance both ends of a set of SAs independently
979 decide to close them, each may send a delete payload and the two
980 requests may cross in the network. If a node receives a delete
981 request for SAs for which it has already issued a delete request, it
982 MUST delete the outgoing SAs while processing the request and the
983 incoming SAs while processing the response. In that case, the
984 responses MUST NOT include delete payloads for the deleted SAs, since
985 that would result in duplicate deletion and could in theory delete
988 {{ Demoted the SHOULD }} Half-closed ESP or AH connections are
989 anomalous, and a node with auditing capability should probably audit
990 their existence if they persist. Note that this specification
991 nowhere specifies time periods, so it is up to individual endpoints
992 to decide how long to wait. A node MAY refuse to accept incoming
993 data on half-closed connections but MUST NOT unilaterally close them
994 and reuse the SPIs. If connection state becomes sufficiently messed
995 up, a node MAY close the IKE SA; doing so will implicitly close all
996 SAs negotiated under it. It can then rebuild the SAs it needs on a
997 clean base under a new IKE SA. {{ Clarif-5.8 }} The response to a
998 request that deletes the IKE SA is an empty Informational response.
1000 1.5. Informational Messages outside of an IKE SA
1002 If an encrypted IKE request packet arrives on port 500 or 4500 with
1003 an unrecognized SPI, it could be because the receiving node has
1007 Kaufman, et al. Expires October 26, 2009 [Page 18]
1009 Internet-Draft IKEv2bis April 2009
1012 recently crashed and lost state or because of some other system
1013 malfunction or attack. If the receiving node has an active IKE SA to
1014 the IP address from whence the packet came, it MAY send a
1015 notification of the wayward packet over that IKE SA in an
1016 INFORMATIONAL exchange. If it does not have such an IKE SA, it MAY
1017 send an Informational message without cryptographic protection to the
1018 source IP address. Such a message is not part of an informational
1019 exchange, and the receiving node MUST NOT respond to it. Doing so
1020 could cause a message loop.
1022 {{ 3.10.1-11 }} The INVALID_SPI notification MAY be sent in an IKE
1023 INFORMATIONAL exchange when a node receives an ESP or AH packet with
1024 an invalid SPI. The Notification Data contains the SPI of the
1025 invalid packet. This usually indicates a node has rebooted and
1026 forgotten an SA. If this Informational Message is sent outside the
1027 context of an IKE SA, it should only be used by the recipient as a
1028 "hint" that something might be wrong (because it could easily be
1031 {{ Clarif-7.7 }} There are two cases when such a one-way notification
1032 is sent: INVALID_IKE_SPI and INVALID_SPI. These notifications are
1033 sent outside of an IKE SA. Note that such notifications are
1034 explicitly not Informational exchanges; these are one-way messages
1035 that must not be responded to.
1037 In case of INVALID_IKE_SPI, the message sent is a response message,
1038 and thus it is sent to the IP address and port from whence it came
1039 with the same IKE SPIs and the Message ID is copied. The Response
1040 bit is set to 1, and the version flags are set in the normal fashion.
1041 For a one-way INVALID_IKE_SPI notification for an unrecognized SPI,
1042 the responder SHOULD copy the Exchange Type from the request.
1044 In case of INVALID_SPI, however, there are no IKE SPI values that
1045 would be meaningful to the recipient of such a notification. Using
1046 zero values or random values are both acceptable. The Initiator flag
1047 is set, the Response bit is set to 0, and the version flags are set
1048 in the normal fashion.
1050 1.6. Requirements Terminology
1052 Definitions of the primitive terms in this document (such as Security
1053 Association or SA) can be found in [IPSECARCH]. {{ Clarif-7.2 }} It
1054 should be noted that parts of IKEv2 rely on some of the processing
1055 rules in [IPSECARCH], as described in various sections of this
1058 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
1059 "MAY" that appear in this document are to be interpreted as described
1063 Kaufman, et al. Expires October 26, 2009 [Page 19]
1065 Internet-Draft IKEv2bis April 2009
1070 1.7. Differences Between RFC 4306 and This Document
1072 {{ Added this entire section, including this recursive remark. }}
1074 This document contains clarifications and amplifications to IKEv2
1075 [IKEV2]. The clarifications are mostly based on [Clarif]. The
1076 changes listed in that document were discussed in the IPsec Working
1077 Group and, after the Working Group was disbanded, on the IPsec
1078 mailing list. That document contains detailed explanations of areas
1079 that were unclear in IKEv2, and is thus useful to implementers of
1082 The protocol described in this document retains the same major
1083 version number (2) and minor version number (0) as was used in RFC
1084 4306. That is, the version number is *not* changed from RFC 4306.
1086 This document makes the figures and references a bit more regular
1089 IKEv2 developers have noted that the SHOULD-level requirements are
1090 often unclear in that they don't say when it is OK to not obey the
1091 requirements. They also have noted that there are MUST-level
1092 requirements that are not related to interoperability. This document
1093 has more explanation of some of these requirements. All non-
1094 capitalized uses of the words SHOULD and MUST now mean their normal
1095 English sense, not the interoperability sense of [MUSTSHOULD].
1097 IKEv2 (and IKEv1) developers have noted that there is a great deal of
1098 material in the tables of codes in Section 3.10.1. This leads to
1099 implementers not having all the needed information in the main body
1100 of the document. Much of the material from those tables has been
1101 moved into the associated parts of the main body of the document.
1103 In the body of this document, notes that are enclosed in double curly
1104 braces {{ such as this }} point out changes from IKEv2. Changes that
1105 come from [Clarif] are marked with the section from that document,
1106 such as "{{ Clarif-2.10 }}". Changes that come from moving
1107 descriptive text out of the tables in Section 3.10.1 are marked with
1108 that number and the message type that contained the text, such as "{{
1111 This document removes discussion of nesting AH and ESP. This was a
1112 mistake in RFC 4306 caused by the lag between finishing RFC 4306 and
1113 RFC 4301. Basically, IKEv2 is based on RFC 4301, which does not
1114 include "SA bundles" that were part of RFC 2401. While a single
1115 packet can go through IPsec processing multiple times, each of these
1119 Kaufman, et al. Expires October 26, 2009 [Page 20]
1121 Internet-Draft IKEv2bis April 2009
1124 passes uses a separate SA, and the passes are coordinated by the
1125 forwarding tables. In IKEv2, each of these SAs has to be created
1126 using a separate CREATE_CHILD_SA exchange.
1128 This document removes discussion of the INTERNAL_ADDRESS_EXPIRY
1129 configuration attribute because its implementation was very
1130 problematic. Implementations that conform to this document MUST
1131 ignore proposals that have configuration attribute type 5, the old
1132 value for INTERNAL_ADDRESS_EXPIRY.
1134 This document adds the restriction in Section 2.13 that all PRFs used
1135 with IKEv2 MUST take variable-sized keys. This should not affect any
1136 implementations because there were no standardized PRFs that have
1139 A later version of this document may have all the {{ }} comments
1140 removed from the body of the document and instead appear in an
1144 2. IKE Protocol Details and Variations
1146 IKE normally listens and sends on UDP port 500, though IKE messages
1147 may also be received on UDP port 4500 with a slightly different
1148 format (see Section 2.23). Since UDP is a datagram (unreliable)
1149 protocol, IKE includes in its definition recovery from transmission
1150 errors, including packet loss, packet replay, and packet forgery.
1151 IKE is designed to function so long as (1) at least one of a series
1152 of retransmitted packets reaches its destination before timing out;
1153 and (2) the channel is not so full of forged and replayed packets so
1154 as to exhaust the network or CPU capacities of either endpoint. Even
1155 in the absence of those minimum performance requirements, IKE is
1156 designed to fail cleanly (as though the network were broken).
1158 Although IKEv2 messages are intended to be short, they contain
1159 structures with no hard upper bound on size (in particular, X.509
1160 certificates), and IKEv2 itself does not have a mechanism for
1161 fragmenting large messages. IP defines a mechanism for fragmentation
1162 of oversize UDP messages, but implementations vary in the maximum
1163 message size supported. Furthermore, use of IP fragmentation opens
1164 an implementation to denial of service attacks [DOSUDPPROT].
1165 Finally, some NAT and/or firewall implementations may block IP
1168 All IKEv2 implementations MUST be able to send, receive, and process
1169 IKE messages that are up to 1280 octets long, and they SHOULD be able
1170 to send, receive, and process messages that are up to 3000 octets
1171 long. {{ Demoted the SHOULD }} IKEv2 implementations need to be aware
1175 Kaufman, et al. Expires October 26, 2009 [Page 21]
1177 Internet-Draft IKEv2bis April 2009
1180 of the maximum UDP message size supported and MAY shorten messages by
1181 leaving out some certificates or cryptographic suite proposals if
1182 that will keep messages below the maximum. Use of the "Hash and URL"
1183 formats rather than including certificates in exchanges where
1184 possible can avoid most problems. {{ Demoted the SHOULD }}
1185 Implementations and configuration need to keep in mind, however, that
1186 if the URL lookups are possible only after the IPsec SA is
1187 established, recursion issues could prevent this technique from
1190 {{ Clarif-7.5 }} The UDP payload of all packets containing IKE
1191 messages sent on port 4500 MUST begin with the prefix of four zeros;
1192 otherwise, the receiver won't know how to handle them.
1194 2.1. Use of Retransmission Timers
1196 All messages in IKE exist in pairs: a request and a response. The
1197 setup of an IKE SA normally consists of two request/response pairs.
1198 Once the IKE SA is set up, either end of the security association may
1199 initiate requests at any time, and there can be many requests and
1200 responses "in flight" at any given moment. But each message is
1201 labeled as either a request or a response, and for each request/
1202 response pair one end of the security association is the initiator
1203 and the other is the responder.
1205 For every pair of IKE messages, the initiator is responsible for
1206 retransmission in the event of a timeout. The responder MUST never
1207 retransmit a response unless it receives a retransmission of the
1208 request. In that event, the responder MUST ignore the retransmitted
1209 request except insofar as it triggers a retransmission of the
1210 response. The initiator MUST remember each request until it receives
1211 the corresponding response. The responder MUST remember each
1212 response until it receives a request whose sequence number is larger
1213 than or equal to the sequence number in the response plus its window
1214 size (see Section 2.3). In order to allow saving memory, responders
1215 are allowed to forget response after a timeout of several minutes.
1216 If the responder receives a retransmitted request for which it has
1217 already forgotten the response, it MUST ignore the request (and not,
1218 for example, attempt constructing a new response).
1220 IKE is a reliable protocol, in the sense that the initiator MUST
1221 retransmit a request until either it receives a corresponding reply
1222 OR it deems the IKE security association to have failed and it
1223 discards all state associated with the IKE SA and any Child SAs
1224 negotiated using that IKE SA. A retransmission from the initiator
1225 MUST be bitwise identical to the original request. That is,
1226 everything starting from the IKE Header (the IKE SA Initiator's SPI
1227 onwards) must be bitwise identical; items before it (such as the IP
1231 Kaufman, et al. Expires October 26, 2009 [Page 22]
1233 Internet-Draft IKEv2bis April 2009
1236 and UDP headers, and the zero non-ESP marker) do not have to be
1239 {{ Clarif-2.3 }} Retransmissions of the IKE_SA_INIT request require
1240 some special handling. When a responder receives an IKE_SA_INIT
1241 request, it has to determine whether the packet is a retransmission
1242 belonging to an existing "half-open" IKE SA (in which case the
1243 responder retransmits the same response), or a new request (in which
1244 case the responder creates a new IKE SA and sends a fresh response),
1245 or it belongs to an existing IKE SA where the IKE_AUTH request has
1246 been already received (in which case the responder ignores it).
1248 It is not sufficient to use the initiator's SPI and/or IP address to
1249 differentiate between these three cases because two different peers
1250 behind a single NAT could choose the same initiator SPI. Instead, a
1251 robust responder will do the IKE SA lookup using the whole packet,
1252 its hash, or the Ni payload.
1254 2.2. Use of Sequence Numbers for Message ID
1256 Every IKE message contains a Message ID as part of its fixed header.
1257 This Message ID is used to match up requests and responses, and to
1258 identify retransmissions of messages.
1260 The Message ID is a 32-bit quantity, which is zero for the
1261 IKE_SA_INIT messages (including retries of the message due to
1262 responses such as COOKIE and INVALID_KE_PAYLOAD {{ Clarif-2.2 }}),
1263 and incremented for each subsequent exchange. Rekeying an IKE SA
1264 resets the sequence numbers. Thus, the first pair of IKE_AUTH
1265 messages will have ID of 1, the second (when EAP is used) will be 2,
1266 and so on. {{ Clarif-3.10 }}
1268 Each endpoint in the IKE Security Association maintains two "current"
1269 Message IDs: the next one to be used for a request it initiates and
1270 the next one it expects to see in a request from the other end.
1271 These counters increment as requests are generated and received.
1272 Responses always contain the same message ID as the corresponding
1273 request. That means that after the initial exchange, each integer n
1274 may appear as the message ID in four distinct messages: the nth
1275 request from the original IKE initiator, the corresponding response,
1276 the nth request from the original IKE responder, and the
1277 corresponding response. If the two ends make very different numbers
1278 of requests, the Message IDs in the two directions can be very
1279 different. There is no ambiguity in the messages, however, because
1280 the (I)nitiator and (R)esponse bits in the message header specify
1281 which of the four messages a particular one is.
1283 {{ Clarif-5.9 }} Throughout this document, "initiator" refers to the
1287 Kaufman, et al. Expires October 26, 2009 [Page 23]
1289 Internet-Draft IKEv2bis April 2009
1292 party who initiated the exchange being described, and "original
1293 initiator" refers to the party who initiated the whole IKE SA. The
1294 "original initiator" always refers to the party who initiated the
1295 exchange which resulted in the current IKE SA. In other words, if
1296 the "original responder" starts rekeying the IKE SA, that party
1297 becomes the "original initiator" of the new IKE SA.
1299 Note that Message IDs are cryptographically protected and provide
1300 protection against message replays. In the unlikely event that
1301 Message IDs grow too large to fit in 32 bits, the IKE SA MUST be
1304 2.3. Window Size for Overlapping Requests
1306 {{ 3.10.1-16385 }} The SET_WINDOW_SIZE notification asserts that the
1307 sending endpoint is capable of keeping state for multiple outstanding
1308 exchanges, permitting the recipient to send multiple requests before
1309 getting a response to the first. The data associated with a
1310 SET_WINDOW_SIZE notification MUST be 4 octets long and contain the
1311 big endian representation of the number of messages the sender
1312 promises to keep. The window size is always one until the initial
1315 An IKE endpoint MUST wait for a response to each of its messages
1316 before sending a subsequent message unless it has received a
1317 SET_WINDOW_SIZE Notify message from its peer informing it that the
1318 peer is prepared to maintain state for multiple outstanding messages
1319 in order to allow greater throughput.
1321 After an IKE SA is set up, in order to maximize IKE throughput, an
1322 IKE endpoint MAY issue multiple requests before getting a response to
1323 any of them, up to the limit set by its peer's SET_WINDOW_SIZE.
1324 These requests may pass one another over the network. An IKE
1325 endpoint MUST be prepared to accept and process a request while it
1326 has a request outstanding in order to avoid a deadlock in this
1327 situation. {{ Downgraded the SHOULD }} An IKE endpoint may also
1328 accept and process multiple requests while it has a request
1331 An IKE endpoint MUST NOT exceed the peer's stated window size for
1332 transmitted IKE requests. In other words, if the responder stated
1333 its window size is N, then when the initiator needs to make a request
1334 X, it MUST wait until it has received responses to all requests up
1335 through request X-N. An IKE endpoint MUST keep a copy of (or be able
1336 to regenerate exactly) each request it has sent until it receives the
1337 corresponding response. An IKE endpoint MUST keep a copy of (or be
1338 able to regenerate exactly) the number of previous responses equal to
1339 its declared window size in case its response was lost and the
1343 Kaufman, et al. Expires October 26, 2009 [Page 24]
1345 Internet-Draft IKEv2bis April 2009
1348 initiator requests its retransmission by retransmitting the request.
1350 An IKE endpoint supporting a window size greater than one ought to be
1351 capable of processing incoming requests out of order to maximize
1352 performance in the event of network failures or packet reordering.
1354 {{ Clarif-7.3 }} The window size is normally a (possibly
1355 configurable) property of a particular implementation, and is not
1356 related to congestion control (unlike the window size in TCP, for
1357 example). In particular, it is not defined what the responder should
1358 do when it receives a SET_WINDOW_SIZE notification containing a
1359 smaller value than is currently in effect. Thus, there is currently
1360 no way to reduce the window size of an existing IKE SA; you can only
1361 increase it. When rekeying an IKE SA, the new IKE SA starts with
1362 window size 1 until it is explicitly increased by sending a new
1363 SET_WINDOW_SIZE notification.
1365 {{ 3.10.1-9 }}The INVALID_MESSAGE_ID notification is sent when an IKE
1366 message ID outside the supported window is received. This Notify
1367 MUST NOT be sent in a response; the invalid request MUST NOT be
1368 acknowledged. Instead, inform the other side by initiating an
1369 INFORMATIONAL exchange with Notification data containing the four
1370 octet invalid message ID. Sending this notification is optional, and
1371 notifications of this type MUST be rate limited.
1373 2.4. State Synchronization and Connection Timeouts
1375 An IKE endpoint is allowed to forget all of its state associated with
1376 an IKE SA and the collection of corresponding Child SAs at any time.
1377 This is the anticipated behavior in the event of an endpoint crash
1378 and restart. It is important when an endpoint either fails or
1379 reinitializes its state that the other endpoint detect those
1380 conditions and not continue to waste network bandwidth by sending
1381 packets over discarded SAs and having them fall into a black hole.
1383 {{ 3.10.1-16384 }} The INITIAL_CONTACT notification asserts that this
1384 IKE SA is the only IKE SA currently active between the authenticated
1385 identities. It MAY be sent when an IKE SA is established after a
1386 crash, and the recipient MAY use this information to delete any other
1387 IKE SAs it has to the same authenticated identity without waiting for
1388 a timeout. This notification MUST NOT be sent by an entity that may
1389 be replicated (e.g., a roaming user's credentials where the user is
1390 allowed to connect to the corporate firewall from two remote systems
1391 at the same time). {{ Clarif-7.9 }} The INITIAL_CONTACT notification,
1392 if sent, MUST be in the first IKE_AUTH request or response, not as a
1393 separate exchange afterwards; however, receiving parties MAY ignore
1394 it in other messages.
1399 Kaufman, et al. Expires October 26, 2009 [Page 25]
1401 Internet-Draft IKEv2bis April 2009
1404 Since IKE is designed to operate in spite of Denial of Service (DoS)
1405 attacks from the network, an endpoint MUST NOT conclude that the
1406 other endpoint has failed based on any routing information (e.g.,
1407 ICMP messages) or IKE messages that arrive without cryptographic
1408 protection (e.g., Notify messages complaining about unknown SPIs).
1409 An endpoint MUST conclude that the other endpoint has failed only
1410 when repeated attempts to contact it have gone unanswered for a
1411 timeout period or when a cryptographically protected INITIAL_CONTACT
1412 notification is received on a different IKE SA to the same
1413 authenticated identity. {{ Demoted the SHOULD }} An endpoint should
1414 suspect that the other endpoint has failed based on routing
1415 information and initiate a request to see whether the other endpoint
1416 is alive. To check whether the other side is alive, IKE specifies an
1417 empty INFORMATIONAL message that (like all IKE requests) requires an
1418 acknowledgement (note that within the context of an IKE SA, an
1419 "empty" message consists of an IKE header followed by an Encrypted
1420 payload that contains no payloads). If a cryptographically protected
1421 (fresh, i.e. not retransmitted) message has been received from the
1422 other side recently, unprotected notifications MAY be ignored.
1423 Implementations MUST limit the rate at which they take actions based
1424 on unprotected messages.
1426 Numbers of retries and lengths of timeouts are not covered in this
1427 specification because they do not affect interoperability. It is
1428 suggested that messages be retransmitted at least a dozen times over
1429 a period of at least several minutes before giving up on an SA, but
1430 different environments may require different rules. To be a good
1431 network citizen, retranmission times MUST increase exponentially to
1432 avoid flooding the network and making an existing congestion
1433 situation worse. If there has only been outgoing traffic on all of
1434 the SAs associated with an IKE SA, it is essential to confirm
1435 liveness of the other endpoint to avoid black holes. If no
1436 cryptographically protected messages have been received on an IKE SA
1437 or any of its Child SAs recently, the system needs to perform a
1438 liveness check in order to prevent sending messages to a dead peer.
1439 (This is sometimes called "dead peer detection" or "DPD", although it
1440 is really detecting live peers, not dead ones.) Receipt of a fresh
1441 cryptographically protected message on an IKE SA or any of its Child
1442 SAs ensures liveness of the IKE SA and all of its Child SAs. Note
1443 that this places requirements on the failure modes of an IKE
1444 endpoint. An implementation MUST NOT continue sending on any SA if
1445 some failure prevents it from receiving on all of the associated SAs.
1446 If Child SAs can fail independently from one another without the
1447 associated IKE SA being able to send a delete message, then they MUST
1448 be negotiated by separate IKE SAs.
1450 There is a Denial of Service attack on the initiator of an IKE SA
1451 that can be avoided if the initiator takes the proper care. Since
1455 Kaufman, et al. Expires October 26, 2009 [Page 26]
1457 Internet-Draft IKEv2bis April 2009
1460 the first two messages of an SA setup are not cryptographically
1461 protected, an attacker could respond to the initiator's message
1462 before the genuine responder and poison the connection setup attempt.
1463 To prevent this, the initiator MAY be willing to accept multiple
1464 responses to its first message, treat each as potentially legitimate,
1465 respond to it, and then discard all the invalid half-open connections
1466 when it receives a valid cryptographically protected response to any
1467 one of its requests. Once a cryptographically valid response is
1468 received, all subsequent responses should be ignored whether or not
1469 they are cryptographically valid.
1471 Note that with these rules, there is no reason to negotiate and agree
1472 upon an SA lifetime. If IKE presumes the partner is dead, based on
1473 repeated lack of acknowledgement to an IKE message, then the IKE SA
1474 and all Child SAs set up through that IKE SA are deleted.
1476 An IKE endpoint may at any time delete inactive Child SAs to recover
1477 resources used to hold their state. If an IKE endpoint chooses to
1478 delete Child SAs, it MUST send Delete payloads to the other end
1479 notifying it of the deletion. It MAY similarly time out the IKE SA.
1480 {{ Clarified the SHOULD }} Closing the IKE SA implicitly closes all
1481 associated Child SAs. In this case, an IKE endpoint SHOULD send a
1482 Delete payload indicating that it has closed the IKE SA unless the
1483 other endpoint is no longer responding.
1485 2.5. Version Numbers and Forward Compatibility
1487 This document describes version 2.0 of IKE, meaning the major version
1488 number is 2 and the minor version number is 0. {{ Restated the
1489 relationship to RFC 4306 }} This document is a replacement for
1490 [IKEV2]. It is likely that some implementations will want to support
1491 version 1.0 and version 2.0, and in the future, other versions.
1493 The major version number should be incremented only if the packet
1494 formats or required actions have changed so dramatically that an
1495 older version node would not be able to interoperate with a newer
1496 version node if it simply ignored the fields it did not understand
1497 and took the actions specified in the older specification. The minor
1498 version number indicates new capabilities, and MUST be ignored by a
1499 node with a smaller minor version number, but used for informational
1500 purposes by the node with the larger minor version number. For
1501 example, it might indicate the ability to process a newly defined
1502 notification message. The node with the larger minor version number
1503 would simply note that its correspondent would not be able to
1504 understand that message and therefore would not send it.
1506 {{ 3.10.1-5 }} If an endpoint receives a message with a higher major
1507 version number, it MUST drop the message and SHOULD send an
1511 Kaufman, et al. Expires October 26, 2009 [Page 27]
1513 Internet-Draft IKEv2bis April 2009
1516 unauthenticated notification message of type INVALID_MAJOR_VERSION
1517 containing the highest (closest) version number it supports. If an
1518 endpoint supports major version n, and major version m, it MUST
1519 support all versions between n and m. If it receives a message with
1520 a major version that it supports, it MUST respond with that version
1521 number. In order to prevent two nodes from being tricked into
1522 corresponding with a lower major version number than the maximum that
1523 they both support, IKE has a flag that indicates that the node is
1524 capable of speaking a higher major version number.
1526 Thus, the major version number in the IKE header indicates the
1527 version number of the message, not the highest version number that
1528 the transmitter supports. If the initiator is capable of speaking
1529 versions n, n+1, and n+2, and the responder is capable of speaking
1530 versions n and n+1, then they will negotiate speaking n+1, where the
1531 initiator will set a flag indicating its ability to speak a higher
1532 version. If they mistakenly (perhaps through an active attacker
1533 sending error messages) negotiate to version n, then both will notice
1534 that the other side can support a higher version number, and they
1535 MUST break the connection and reconnect using version n+1.
1537 Note that IKEv1 does not follow these rules, because there is no way
1538 in v1 of noting that you are capable of speaking a higher version
1539 number. So an active attacker can trick two v2-capable nodes into
1540 speaking v1. {{ Demoted the SHOULD }} When a v2-capable node
1541 negotiates down to v1, it should note that fact in its logs.
1543 Also for forward compatibility, all fields marked RESERVED MUST be
1544 set to zero by an implementation running version 2.0, and their
1545 content MUST be ignored by an implementation running version 2.0 ("Be
1546 conservative in what you send and liberal in what you receive"). In
1547 this way, future versions of the protocol can use those fields in a
1548 way that is guaranteed to be ignored by implementations that do not
1549 understand them. Similarly, payload types that are not defined are
1550 reserved for future use; implementations of a version where they are
1551 undefined MUST skip over those payloads and ignore their contents.
1553 IKEv2 adds a "critical" flag to each payload header for further
1554 flexibility for forward compatibility. If the critical flag is set
1555 and the payload type is unrecognized, the message MUST be rejected
1556 and the response to the IKE request containing that payload MUST
1557 include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an
1558 unsupported critical payload was included. {{ 3.10.1-1 }} In that
1559 Notify payload, the notification data contains the one-octet payload
1560 type. If the critical flag is not set and the payload type is
1561 unsupported, that payload MUST be ignored. Payloads sent in IKE
1562 response messages MUST NOT have the critical flag set. Note that the
1563 critical flag applies only to the payload type, not the contents. If
1567 Kaufman, et al. Expires October 26, 2009 [Page 28]
1569 Internet-Draft IKEv2bis April 2009
1572 the payload type is recognized, but the payload contains something
1573 which is not (such as an unknown transform inside an SA payload, or
1574 an unknown Notify Message Type inside a Notify payload), the critical
1577 {{ Demoted the SHOULD in the second clause }}Although new payload
1578 types may be added in the future and may appear interleaved with the
1579 fields defined in this specification, implementations MUST send the
1580 payloads defined in this specification in the order shown in the
1581 figures in Section 2; implementations are explicitly allowed to
1582 reject as invalid a message with those payloads in any other order.
1584 2.6. IKE SA SPIs and Cookies
1586 The term "cookies" originates with Karn and Simpson [PHOTURIS] in
1587 Photuris, an early proposal for key management with IPsec, and it has
1588 persisted. The Internet Security Association and Key Management
1589 Protocol (ISAKMP) [ISAKMP] fixed message header includes two eight-
1590 octet fields titled "cookies", and that syntax is used by both IKEv1
1591 and IKEv2, although in IKEv2 they are referred to as the "IKE SPI"
1592 and there is a new separate field in a Notify payload holding the
1593 cookie. The initial two eight-octet fields in the header are used as
1594 a connection identifier at the beginning of IKE packets. Each
1595 endpoint chooses one of the two SPIs and MUST choose them so as to be
1596 unique identifiers of an IKE SA. An SPI value of zero is special and
1597 indicates that the remote SPI value is not yet known by the sender.
1599 Incoming IKE packets are mapped to an IKE SA only using the packet's
1600 SPI, not using (for example) the source IP address of the packet.
1602 Unlike ESP and AH where only the recipient's SPI appears in the
1603 header of a message, in IKE the sender's SPI is also sent in every
1604 message. Since the SPI chosen by the original initiator of the IKE
1605 SA is always sent first, an endpoint with multiple IKE SAs open that
1606 wants to find the appropriate IKE SA using the SPI it assigned must
1607 look at the I(nitiator) Flag bit in the header to determine whether
1608 it assigned the first or the second eight octets.
1610 In the first message of an initial IKE exchange, the initiator will
1611 not know the responder's SPI value and will therefore set that field
1614 An expected attack against IKE is state and CPU exhaustion, where the
1615 target is flooded with session initiation requests from forged IP
1616 addresses. This attack can be made less effective if an
1617 implementation of a responder uses minimal CPU and commits no state
1618 to an SA until it knows the initiator can receive packets at the
1619 address from which it claims to be sending them.
1623 Kaufman, et al. Expires October 26, 2009 [Page 29]
1625 Internet-Draft IKEv2bis April 2009
1628 When a responder detects a large number of half-open IKE SAs, it
1629 SHOULD reply to IKE_SA_INIT requests with a response containing the
1630 COOKIE notification. {{ 3.10.1-16390 }} The data associated with this
1631 notification MUST be between 1 and 64 octets in length (inclusive),
1632 and its generation is described later in this section. If the
1633 IKE_SA_INIT response includes the COOKIE notification, the initiator
1634 MUST then retry the IKE_SA_INIT request, and include the COOKIE
1635 notification containing the received data as the first payload, and
1636 all other payloads unchanged. The initial exchange will then be as
1640 -------------------------------------------------------------------
1641 HDR(A,0), SAi1, KEi, Ni -->
1642 <-- HDR(A,0), N(COOKIE)
1643 HDR(A,0), N(COOKIE), SAi1,
1645 <-- HDR(A,B), SAr1, KEr,
1647 HDR(A,B), SK {IDi, [CERT,]
1648 [CERTREQ,] [IDr,] AUTH,
1650 <-- HDR(A,B), SK {IDr, [CERT,]
1651 AUTH, SAr2, TSi, TSr}
1653 The first two messages do not affect any initiator or responder state
1654 except for communicating the cookie. In particular, the message
1655 sequence numbers in the first four messages will all be zero and the
1656 message sequence numbers in the last two messages will be one. 'A'
1657 is the SPI assigned by the initiator, while 'B' is the SPI assigned
1660 {{ Demoted the SHOULD }} An IKE implementation can implement its
1661 responder cookie generation in such a way as to not require any saved
1662 state to recognize its valid cookie when the second IKE_SA_INIT
1663 message arrives. The exact algorithms and syntax they use to
1664 generate cookies do not affect interoperability and hence are not
1665 specified here. The following is an example of how an endpoint could
1666 use cookies to implement limited DOS protection.
1668 A good way to do this is to set the responder cookie to be:
1670 Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)
1672 where <secret> is a randomly generated secret known only to the
1673 responder and periodically changed and | indicates concatenation.
1674 <VersionIDofSecret> should be changed whenever <secret> is
1675 regenerated. The cookie can be recomputed when the IKE_SA_INIT
1679 Kaufman, et al. Expires October 26, 2009 [Page 30]
1681 Internet-Draft IKEv2bis April 2009
1684 arrives the second time and compared to the cookie in the received
1685 message. If it matches, the responder knows that the cookie was
1686 generated since the last change to <secret> and that IPi must be the
1687 same as the source address it saw the first time. Incorporating SPIi
1688 into the calculation ensures that if multiple IKE SAs are being set
1689 up in parallel they will all get different cookies (assuming the
1690 initiator chooses unique SPIi's). Incorporating Ni in the hash
1691 ensures that an attacker who sees only message 2 can't successfully
1692 forge a message 3. Also, incorporating Ni in the hash prevents an
1693 attacker from fetching one one cookie from the other end, and then
1694 initiating many IKE_SA_INIT exchanges all with different initiator
1695 SPIs (and perhaps port numbers) so that the responder thinks that
1696 there are lots of machines behind one NAT box who are all trying to
1699 If a new value for <secret> is chosen while there are connections in
1700 the process of being initialized, an IKE_SA_INIT might be returned
1701 with other than the current <VersionIDofSecret>. The responder in
1702 that case MAY reject the message by sending another response with a
1703 new cookie or it MAY keep the old value of <secret> around for a
1704 short time and accept cookies computed from either one. {{ Demoted
1705 the SHOULD NOT }} The responder should not accept cookies
1706 indefinitely after <secret> is changed, since that would defeat part
1707 of the denial of service protection. {{ Demoted the SHOULD }} The
1708 responder should change the value of <secret> frequently, especially
1711 {{ Clarif-2.1 }} In addition to cookies, there are several cases
1712 where the IKE_SA_INIT exchange does not result in the creation of an
1713 IKE SA (such as INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). In such a
1714 case, sending a zero value for the Responder's SPI is correct. If
1715 the responder sends a non-zero responder SPI, the initiator should
1716 not reject the response for only that reason.
1718 {{ Clarif-2.5 }} When one party receives an IKE_SA_INIT request
1719 containing a cookie whose contents do not match the value expected,
1720 that party MUST ignore the cookie and process the message as if no
1721 cookie had been included; usually this means sending a response
1722 containing a new cookie. The initiator should limit the number of
1723 cookie exchanges it tries before giving up. An attacker can forge
1724 multiple cookie responses to the initiator's IKE_SA_INIT message, and
1725 each of those forged cookie reply will trigger two packets: one
1726 packet from the initiator to the responder (which will reject those
1727 cookies), and one reply from responder to initiator that includes the
1735 Kaufman, et al. Expires October 26, 2009 [Page 31]
1737 Internet-Draft IKEv2bis April 2009
1740 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD
1742 {{ This section added by Clarif-2.4 }}
1744 There are two common reasons why the initiator may have to retry the
1745 IKE_SA_INIT exchange: the responder requests a cookie or wants a
1746 different Diffie-Hellman group than was included in the KEi payload.
1747 If the initiator receives a cookie from the responder, the initiator
1748 needs to decide whether or not to include the cookie in only the next
1749 retry of the IKE_SA_INIT request, or in all subsequent retries as
1752 If the initiator includes the cookie only in the next retry, one
1753 additional roundtrip may be needed in some cases. An additional
1754 roundtrip is needed also if the initiator includes the cookie in all
1755 retries, but the responder does not support this. For instance, if
1756 the responder includes the SAi1 and KEi payloads in cookie
1757 calculation, it will reject the request by sending a new cookie.
1759 If both peers support including the cookie in all retries, a slightly
1760 shorter exchange can happen.
1763 -----------------------------------------------------------
1764 HDR(A,0), SAi1, KEi, Ni -->
1765 <-- HDR(A,0), N(COOKIE)
1766 HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
1767 <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
1768 HDR(A,0), N(COOKIE), SAi1, KEi', Ni -->
1769 <-- HDR(A,B), SAr1, KEr, Nr
1771 Implementations SHOULD support this shorter exchange, but MUST NOT
1772 fail if other implementations do not support this shorter exchange.
1774 2.7. Cryptographic Algorithm Negotiation
1776 The payload type known as "SA" indicates a proposal for a set of
1777 choices of IPsec protocols (IKE, ESP, or AH) for the SA as well as
1778 cryptographic algorithms associated with each protocol.
1780 An SA payload consists of one or more proposals. {{ Clarif-7.13 }}
1781 Each proposal includes one protocol. Each protocol contains one or
1782 more transforms -- each specifying a cryptographic algorithm. Each
1783 transform contains zero or more attributes (attributes are needed
1784 only if the transform identifier does not completely specify the
1785 cryptographic algorithm).
1787 This hierarchical structure was designed to efficiently encode
1791 Kaufman, et al. Expires October 26, 2009 [Page 32]
1793 Internet-Draft IKEv2bis April 2009
1796 proposals for cryptographic suites when the number of supported
1797 suites is large because multiple values are acceptable for multiple
1798 transforms. The responder MUST choose a single suite, which may be
1799 any subset of the SA proposal following the rules below:
1801 {{ Clarif-7.13 }} Each proposal contains one protocol. If a proposal
1802 is accepted, the SA response MUST contain the same protocol. The
1803 responder MUST accept a single proposal or reject them all and return
1804 an error. {{ 3.10.1-14 }} The error is given in a notification of
1805 type NO_PROPOSAL_CHOSEN.
1807 Each IPsec protocol proposal contains one or more transforms. Each
1808 transform contains a transform type. The accepted cryptographic
1809 suite MUST contain exactly one transform of each type included in the
1810 proposal. For example: if an ESP proposal includes transforms
1811 ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256,
1812 AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one
1813 of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six
1814 combinations are acceptable.
1816 If an initiator proposes both normal ciphers with integrity
1817 protection as well as combined-mode ciphers, then two proposals are
1818 needed. One of the proposals includes the normal ciphers with the
1819 integrity algoritms for them, and the other proposal includes all the
1820 combined mode ciphers without the integrity algorithms (because
1821 combined mode ciphers are not allowed to have any integrity algorithm
1824 Since the initiator sends its Diffie-Hellman value in the
1825 IKE_SA_INIT, it must guess the Diffie-Hellman group that the
1826 responder will select from its list of supported groups. If the
1827 initiator guesses wrong, the responder will respond with a Notify
1828 payload of type INVALID_KE_PAYLOAD indicating the selected group. In
1829 this case, the initiator MUST retry the IKE_SA_INIT with the
1830 corrected Diffie-Hellman group. The initiator MUST again propose its
1831 full set of acceptable cryptographic suites because the rejection
1832 message was unauthenticated and otherwise an active attacker could
1833 trick the endpoints into negotiating a weaker suite than a stronger
1834 one that they both prefer.
1836 {{ Clarif-2.1 }} When the IKE_SA_INIT exchange does not result in the
1837 creation of an IKE SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN,
1838 or COOKIE (see Section 2.6), the responder's SPI will be zero.
1839 However, if the responder sends a non-zero responder SPI, the
1840 initiator should not reject the response for only that reason.
1847 Kaufman, et al. Expires October 26, 2009 [Page 33]
1849 Internet-Draft IKEv2bis April 2009
1854 {{ Demoted the SHOULD }} IKE, ESP, and AH security associations use
1855 secret keys that should be used only for a limited amount of time and
1856 to protect a limited amount of data. This limits the lifetime of the
1857 entire security association. When the lifetime of a security
1858 association expires, the security association MUST NOT be used. If
1859 there is demand, new security associations MAY be established.
1860 Reestablishment of security associations to take the place of ones
1861 that expire is referred to as "rekeying".
1863 To allow for minimal IPsec implementations, the ability to rekey SAs
1864 without restarting the entire IKE SA is optional. An implementation
1865 MAY refuse all CREATE_CHILD_SA requests within an IKE SA. If an SA
1866 has expired or is about to expire and rekeying attempts using the
1867 mechanisms described here fail, an implementation MUST close the IKE
1868 SA and any associated Child SAs and then MAY start new ones. {{
1869 Demoted the SHOULD }} Implementations may wish to support in-place
1870 rekeying of SAs, since doing so offers better performance and is
1871 likely to reduce the number of packets lost during the transition.
1873 To rekey a Child SA within an existing IKE SA, create a new,
1874 equivalent SA (see Section 2.17 below), and when the new one is
1875 established, delete the old one. To rekey an IKE SA, establish a new
1876 equivalent IKE SA (see Section 2.18 below) with the peer to whom the
1877 old IKE SA is shared using a CREATE_CHILD_SA within the existing IKE
1878 SA. An IKE SA so created inherits all of the original IKE SA's Child
1879 SAs, and the new IKE SA is used for all control messages needed to
1880 maintain those Child SAs. The old IKE SA is then deleted, and the
1881 Delete payload to delete itself MUST be the last request sent over
1882 the old IKE SA. Note that, when rekeying, the new Child SA MAY have
1883 different traffic selectors and algorithms than the old one.
1885 {{ Demoted the SHOULD }} SAs should be rekeyed proactively, i.e., the
1886 new SA should be established before the old one expires and becomes
1887 unusable. Enough time should elapse between the time the new SA is
1888 established and the old one becomes unusable so that traffic can be
1889 switched over to the new SA.
1891 A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes
1892 were negotiated. In IKEv2, each end of the SA is responsible for
1893 enforcing its own lifetime policy on the SA and rekeying the SA when
1894 necessary. If the two ends have different lifetime policies, the end
1895 with the shorter lifetime will end up always being the one to request
1896 the rekeying. If an SA has been inactive for a long time and if an
1897 endpoint would not initiate the SA in the absence of traffic, the
1898 endpoint MAY choose to close the SA instead of rekeying it when its
1899 lifetime expires. {{ Demoted the SHOULD }} It should do so if there
1903 Kaufman, et al. Expires October 26, 2009 [Page 34]
1905 Internet-Draft IKEv2bis April 2009
1908 has been no traffic since the last time the SA was rekeyed.
1910 Note that IKEv2 deliberately allows parallel SAs with the same
1911 traffic selectors between common endpoints. One of the purposes of
1912 this is to support traffic quality of service (QoS) differences among
1913 the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and section 4.1 of
1914 [DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints
1915 and the traffic selectors may not uniquely identify an SA between
1916 those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on
1917 the basis of duplicate traffic selectors SHOULD NOT be used.
1919 {{ Demoted the SHOULD }} The node that initiated the surviving
1920 rekeyed SA should delete the replaced SA after the new one is
1923 There are timing windows -- particularly in the presence of lost
1924 packets -- where endpoints may not agree on the state of an SA. The
1925 responder to a CREATE_CHILD_SA MUST be prepared to accept messages on
1926 an SA before sending its response to the creation request, so there
1927 is no ambiguity for the initiator. The initiator MAY begin sending
1928 on an SA as soon as it processes the response. The initiator,
1929 however, cannot receive on a newly created SA until it receives and
1930 processes the response to its CREATE_CHILD_SA request. How, then, is
1931 the responder to know when it is OK to send on the newly created SA?
1933 From a technical correctness and interoperability perspective, the
1934 responder MAY begin sending on an SA as soon as it sends its response
1935 to the CREATE_CHILD_SA request. In some situations, however, this
1936 could result in packets unnecessarily being dropped, so an
1937 implementation MAY defer such sending.
1939 The responder can be assured that the initiator is prepared to
1940 receive messages on an SA if either (1) it has received a
1941 cryptographically valid message on the new SA, or (2) the new SA
1942 rekeys an existing SA and it receives an IKE request to close the
1943 replaced SA. When rekeying an SA, the responder continues to send
1944 traffic on the old SA until one of those events occurs. When
1945 establishing a new SA, the responder MAY defer sending messages on a
1946 new SA until either it receives one or a timeout has occurred. {{
1947 Demoted the SHOULD }} If an initiator receives a message on an SA for
1948 which it has not received a response to its CREATE_CHILD_SA request,
1949 it interprets that as a likely packet loss and retransmits the
1950 CREATE_CHILD_SA request. An initiator MAY send a dummy message on a
1951 newly created SA if it has no messages queued in order to assure the
1952 responder that the initiator is ready to receive messages.
1959 Kaufman, et al. Expires October 26, 2009 [Page 35]
1961 Internet-Draft IKEv2bis April 2009
1964 2.8.1. Simultaneous Child SA rekeying
1966 {{ The first two paragraphs were moved, and the rest was added, based
1969 If the two ends have the same lifetime policies, it is possible that
1970 both will initiate a rekeying at the same time (which will result in
1971 redundant SAs). To reduce the probability of this happening, the
1972 timing of rekeying requests SHOULD be jittered (delayed by a random
1973 amount of time after the need for rekeying is noticed).
1975 This form of rekeying may temporarily result in multiple similar SAs
1976 between the same pairs of nodes. When there are two SAs eligible to
1977 receive packets, a node MUST accept incoming packets through either
1978 SA. If redundant SAs are created though such a collision, the SA
1979 created with the lowest of the four nonces used in the two exchanges
1980 SHOULD be closed by the endpoint that created it. {{ Clarif-5.10 }}
1981 "Lowest" means an octet-by-octet, lexicographical comparison (instead
1982 of, for instance, comparing the nonces as large integers). In other
1983 words, start by comparing the first octet; if they're equal, move to
1984 the next octet, and so on. If you reach the end of one nonce, that
1985 nonce is the lower one.
1987 The following is an explanation on the impact this has on
1988 implementations. Assume that hosts A and B have an existing IPsec SA
1989 pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same
1993 -------------------------------------------------------------------
1994 send req1: N(REKEY_SA,SPIa1),
1995 SA(..,SPIa2,..),Ni1,.. -->
1996 <-- send req2: N(REKEY_SA,SPIb1),
2000 At this point, A knows there is a simultaneous rekeying going on.
2001 However, it cannot yet know which of the exchanges will have the
2002 lowest nonce, so it will just note the situation and respond as
2005 send resp2: SA(..,SPIa3,..),
2009 Now B also knows that simultaneous rekeying is going on. It responds
2015 Kaufman, et al. Expires October 26, 2009 [Page 36]
2017 Internet-Draft IKEv2bis April 2009
2020 <-- send resp1: SA(..,SPIb3,..),
2025 At this point, there are three Child SA pairs between A and B (the
2026 old one and two new ones). A and B can now compare the nonces.
2027 Suppose that the lowest nonce was Nr1 in message resp2; in this case,
2028 B (the sender of req2) deletes the redundant new SA, and A (the node
2029 that initiated the surviving rekeyed SA), deletes the old one.
2031 send req3: D(SPIa1) -->
2032 <-- send req4: D(SPIb2)
2034 <-- send resp3: D(SPIb1)
2036 send resp4: D(SPIa3) -->
2038 The rekeying is now finished.
2040 However, there is a second possible sequence of events that can
2041 happen if some packets are lost in the network, resulting in
2042 retransmissions. The rekeying begins as usual, but A's first packet
2046 -------------------------------------------------------------------
2047 send req1: N(REKEY_SA,SPIa1),
2050 <-- send req2: N(REKEY_SA,SPIb1),
2053 send resp2: SA(..,SPIa3,..),
2056 <-- send req3: D(SPIb1)
2058 send resp3: D(SPIa1) -->
2061 From B's point of view, the rekeying is now completed, and since it
2062 has not yet received A's req1, it does not even know that there was
2063 simultaneous rekeying. However, A will continue retransmitting the
2064 message, and eventually it will reach B.
2071 Kaufman, et al. Expires October 26, 2009 [Page 37]
2073 Internet-Draft IKEv2bis April 2009
2076 To B, it looks like A is trying to rekey an SA that no longer exists;
2077 thus, B responds to the request with something non-fatal such as
2080 <-- send resp1: N(NO_PROPOSAL_CHOSEN)
2083 When A receives this error, it already knows there was simultaneous
2084 rekeying, so it can ignore the error message.
2086 2.8.2. Simultaneous IKE SA Rekeying
2088 Probably the most complex case occurs when both peers try to rekey
2089 the IKE_SA at the same time. Basically, the text in Section 2.8
2090 applies to this case as well; however, it is important to ensure that
2091 the CHILD_SAs are inherited by the right IKE_SA.
2093 The case where both endpoints notice the simultaneous rekeying works
2094 the same way as with CHILD_SAs. After the CREATE_CHILD_SA exchanges,
2095 three IKE_SAs exist between A and B; the one containing the lowest
2096 nonce inherits the CHILD_SAs.
2098 However, there is a twist to the other case where one rekeying
2102 -------------------------------------------------------------------
2104 SA(..,SPIa1,..),Ni1,.. -->
2105 <-- send req2: SA(..,SPIb1,..),Ni2,..
2107 <-- send resp1: SA(..,SPIb2,..),Nr2,..
2112 At this point, host B sees a request to close the IKE_SA. There's
2113 not much more to do than to reply as usual. However, at this point
2114 host B should stop retransmitting req2, since once host A receives
2115 resp3, it will delete all the state associated with the old IKE_SA
2116 and will not be able to reply to it.
2127 Kaufman, et al. Expires October 26, 2009 [Page 38]
2129 Internet-Draft IKEv2bis April 2009
2132 2.8.3. Rekeying the IKE SA Versus Reauthentication
2134 {{ Added this section from Clarif-5.2 }}
2136 Rekeying the IKE SA and reauthentication are different concepts in
2137 IKEv2. Rekeying the IKE SA establishes new keys for the IKE SA and
2138 resets the Message ID counters, but it does not authenticate the
2139 parties again (no AUTH or EAP payloads are involved).
2141 Although rekeying the IKE SA may be important in some environments,
2142 reauthentication (the verification that the parties still have access
2143 to the long-term credentials) is often more important.
2145 IKEv2 does not have any special support for reauthentication.
2146 Reauthentication is done by creating a new IKE SA from scratch (using
2147 IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify
2148 payloads), creating new Child SAs within the new IKE SA (without
2149 REKEY_SA notify payloads), and finally deleting the old IKE SA (which
2150 deletes the old Child SAs as well).
2152 This means that reauthentication also establishes new keys for the
2153 IKE SA and Child SAs. Therefore, while rekeying can be performed
2154 more often than reauthentication, the situation where "authentication
2155 lifetime" is shorter than "key lifetime" does not make sense.
2157 While creation of a new IKE SA can be initiated by either party
2158 (initiator or responder in the original IKE SA), the use of EAP
2159 authentication and/or configuration payloads means in practice that
2160 reauthentication has to be initiated by the same party as the
2161 original IKE SA. IKEv2 does not currently allow the responder to
2162 request reauthentication in this case; however, there are extensions
2163 that add this functionality such as [REAUTH].
2165 2.9. Traffic Selector Negotiation
2167 {{ Clarif-7.2 }} When an RFC4301-compliant IPsec subsystem receives
2168 an IP packet that matches a "protect" selector in its Security Policy
2169 Database (SPD), the subsystem protects that packet with IPsec. When
2170 no SA exists yet, it is the task of IKE to create it. Maintenance of
2171 a system's SPD is outside the scope of IKE (see [PFKEY] for an
2172 example protocol, although it only applies to IKEv1), though some
2173 implementations might update their SPD in connection with the running
2174 of IKE (for an example scenario, see Section 1.1.3).
2176 Traffic Selector (TS) payloads allow endpoints to communicate some of
2177 the information from their SPD to their peers. TS payloads specify
2178 the selection criteria for packets that will be forwarded over the
2179 newly set up SA. This can serve as a consistency check in some
2183 Kaufman, et al. Expires October 26, 2009 [Page 39]
2185 Internet-Draft IKEv2bis April 2009
2188 scenarios to assure that the SPDs are consistent. In others, it
2189 guides the dynamic update of the SPD.
2191 Two TS payloads appear in each of the messages in the exchange that
2192 creates a Child SA pair. Each TS payload contains one or more
2193 Traffic Selectors. Each Traffic Selector consists of an address
2194 range (IPv4 or IPv6), a port range, and an IP protocol ID.
2196 The first of the two TS payloads is known as TSi (Traffic Selector-
2197 initiator). The second is known as TSr (Traffic Selector-responder).
2198 TSi specifies the source address of traffic forwarded from (or the
2199 destination address of traffic forwarded to) the initiator of the
2200 Child SA pair. TSr specifies the destination address of the traffic
2201 forwarded to (or the source address of the traffic forwarded from)
2202 the responder of the Child SA pair. For example, if the original
2203 initiator requests the creation of a Child SA pair, and wishes to
2204 tunnel all traffic from subnet 192.0.1.* on the initiator's side to
2205 subnet 192.0.2.* on the responder's side, the initiator would include
2206 a single traffic selector in each TS payload. TSi would specify the
2207 address range (192.0.1.0 - 192.0.1.255) and TSr would specify the
2208 address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was
2209 acceptable to the responder, it would send identical TS payloads
2210 back. (Note: The IP address range 192.0.2.* has been reserved for
2211 use in examples in RFCs and similar documents. This document needed
2212 two such ranges, and so also used 192.0.1.*. This should not be
2213 confused with any actual address.)
2215 IKEv2 allows the responder to choose a subset of the traffic proposed
2216 by the initiator. This could happen when the configurations of the
2217 two endpoints are being updated but only one end has received the new
2218 information. Since the two endpoints may be configured by different
2219 people, the incompatibility may persist for an extended period even
2220 in the absence of errors. It also allows for intentionally different
2221 configurations, as when one end is configured to tunnel all addresses
2222 and depends on the other end to have the up-to-date list.
2224 When the responder chooses a subset of the traffic proposed by the
2225 initiator, it narrows the traffic selectors to some subset of the
2226 initiator's proposal (provided the set does not become the null set).
2227 If the type of traffic selector proposed is unknown, the responder
2228 ignores that traffic selector, so that the unknown type is not be
2229 returned in the narrowed set.
2231 To enable the responder to choose the appropriate range in this case,
2232 if the initiator has requested the SA due to a data packet, the
2233 initiator SHOULD include as the first traffic selector in each of TSi
2234 and TSr a very specific traffic selector including the addresses in
2235 the packet triggering the request. In the example, the initiator
2239 Kaufman, et al. Expires October 26, 2009 [Page 40]
2241 Internet-Draft IKEv2bis April 2009
2244 would include in TSi two traffic selectors: the first containing the
2245 address range (192.0.1.43 - 192.0.1.43) and the source port and IP
2246 protocol from the packet and the second containing (192.0.1.0 -
2247 192.0.1.255) with all ports and IP protocols. The initiator would
2248 similarly include two traffic selectors in TSr. If the initiator
2249 creates the Child SA pair not in response to an arriving packet, but
2250 rather, say, upon startup, then there may be no specific addresses
2251 the initiator prefers for the initial tunnel over any other. In that
2252 case, the first values in TSi and TSr can be ranges rather than
2255 The responder performs the narrowing as follows: {{ Clarif-4.10 }}
2257 o If the responder's policy does not allow it to accept any part of
2258 the proposed traffic selectors, it responds with TS_UNACCEPTABLE.
2260 o If the responder's policy allows the entire set of traffic covered
2261 by TSi and TSr, no narrowing is necessary, and the responder can
2262 return the same TSi and TSr values.
2264 o If the responder's policy allows it to accept the first selector
2265 of TSi and TSr, then the responder MUST narrow the traffic
2266 selectors to a subset that includes the initiator's first choices.
2267 In this example above, the responder might respond with TSi being
2268 (192.0.1.43 - 192.0.1.43) with all ports and IP protocols.
2270 o If the responder's policy does not allow it to accept the first
2271 selector of TSi and TSr, the responder narrows to an acceptable
2272 subset of TSi and TSr.
2274 When narrowing is done, there may be several subsets that are
2275 acceptable but their union is not. In this case, the responder
2276 arbitrarily chooses one of them, and MAY include an
2277 ADDITIONAL_TS_POSSIBLE notification in the response. {{ 3.10.1-16386
2278 }} The ADDITIONAL_TS_POSSIBLE notification asserts that the responder
2279 narrowed the proposed traffic selectors but that other traffic
2280 selectors would also have been acceptable, though only in a separate
2281 SA. There is no data associated with this Notify type. This case
2282 will occur only when the initiator and responder are configured
2283 differently from one another. If the initiator and responder agree
2284 on the granularity of tunnels, the initiator will never request a
2285 tunnel wider than the responder will accept. {{ Demoted the SHOULD }}
2286 Such misconfigurations should be recorded in error logs.
2288 It is possible for the responder's policy to contain multiple smaller
2289 ranges, all encompassed by the initiator's traffic selector, and with
2290 the responder's policy being that each of those ranges should be sent
2291 over a different SA. Continuing the example above, the responder
2295 Kaufman, et al. Expires October 26, 2009 [Page 41]
2297 Internet-Draft IKEv2bis April 2009
2300 might have a policy of being willing to tunnel those addresses to and
2301 from the initiator, but might require that each address pair be on a
2302 separately negotiated Child SA. If the initiator generated its
2303 request in response to an incoming packet from 192.0.1.43 to
2304 192.0.2.123, there would be no way for the responder to determine
2305 which pair of addresses should be included in this tunnel, and it
2306 would have to make a guess or reject the request with a status of
2307 SINGLE_PAIR_REQUIRED.
2309 {{ 3.10.1-34 }} The SINGLE_PAIR_REQUIRED error indicates that a
2310 CREATE_CHILD_SA request is unacceptable because its sender is only
2311 willing to accept traffic selectors specifying a single pair of
2312 addresses. The requestor is expected to respond by requesting an SA
2313 for only the specific traffic it is trying to forward.
2315 {{ Clarif-4.11 }} Few implementations will have policies that require
2316 separate SAs for each address pair. Because of this, if only some
2317 parts of the TSi and TSr proposed by the initiator are acceptable to
2318 the responder, responders SHOULD narrow the selectors to an
2319 acceptable subset rather than use SINGLE_PAIR_REQUIRED.
2321 2.9.1. Traffic Selectors Violating Own Policy
2325 When creating a new SA, the initiator needs to avoid proposing
2326 traffic selectors that violate its own policy. If this rule is not
2327 followed, valid traffic may be dropped. If you use decorrelated
2328 policies from [IPSECARCH], this kind of policy violations cannot
2331 This is best illustrated by an example. Suppose that host A has a
2332 policy whose effect is that traffic to 192.0.1.66 is sent via host B
2333 encrypted using AES, and traffic to all other hosts in 192.0.1.0/24
2334 is also sent via B, but must use 3DES. Suppose also that host B
2335 accepts any combination of AES and 3DES.
2337 If host A now proposes an SA that uses 3DES, and includes TSr
2338 containing (192.0.1.0-192.0.1.255), this will be accepted by host B.
2339 Now, host B can also use this SA to send traffic from 192.0.1.66, but
2340 those packets will be dropped by A since it requires the use of AES
2341 for those traffic. Even if host A creates a new SA only for
2342 192.0.1.66 that uses AES, host B may freely continue to use the first
2343 SA for the traffic. In this situation, when proposing the SA, host A
2344 should have followed its own policy, and included a TSr containing
2345 ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead.
2347 In general, if (1) the initiator makes a proposal "for traffic X
2351 Kaufman, et al. Expires October 26, 2009 [Page 42]
2353 Internet-Draft IKEv2bis April 2009
2356 (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator
2357 does not actually accept traffic X' with SA, and (3) the initiator
2358 would be willing to accept traffic X' with some SA' (!=SA), valid
2359 traffic can be unnecessarily dropped since the responder can apply
2360 either SA or SA' to traffic X'.
2364 The IKE_SA_INIT messages each contain a nonce. These nonces are used
2365 as inputs to cryptographic functions. The CREATE_CHILD_SA request
2366 and the CREATE_CHILD_SA response also contain nonces. These nonces
2367 are used to add freshness to the key derivation technique used to
2368 obtain keys for Child SA, and to ensure creation of strong pseudo-
2369 random bits from the Diffie-Hellman key. Nonces used in IKEv2 MUST
2370 be randomly chosen, MUST be at least 128 bits in size, and MUST be at
2371 least half the key size of the negotiated prf. ("prf" refers to
2372 "pseudo-random function", one of the cryptographic algorithms
2373 negotiated in the IKE exchange.) {{ Clarif-7.4 }} However, the
2374 initiator chooses the nonce before the outcome of the negotiation is
2375 known. Because of that, the nonce has to be long enough for all the
2376 PRFs being proposed. If the same random number source is used for
2377 both keys and nonces, care must be taken to ensure that the latter
2378 use does not compromise the former.
2380 2.11. Address and Port Agility
2382 IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and
2383 AH associations for the same IP addresses it runs over. The IP
2384 addresses and ports in the outer header are, however, not themselves
2385 cryptographically protected, and IKE is designed to work even through
2386 Network Address Translation (NAT) boxes. An implementation MUST
2387 accept incoming requests even if the source port is not 500 or 4500,
2388 and MUST respond to the address and port from which the request was
2389 received. It MUST specify the address and port at which the request
2390 was received as the source address and port in the response. IKE
2391 functions identically over IPv4 or IPv6.
2393 2.12. Reuse of Diffie-Hellman Exponentials
2395 IKE generates keying material using an ephemeral Diffie-Hellman
2396 exchange in order to gain the property of "perfect forward secrecy".
2397 This means that once a connection is closed and its corresponding
2398 keys are forgotten, even someone who has recorded all of the data
2399 from the connection and gets access to all of the long-term keys of
2400 the two endpoints cannot reconstruct the keys used to protect the
2401 conversation without doing a brute force search of the session key
2407 Kaufman, et al. Expires October 26, 2009 [Page 43]
2409 Internet-Draft IKEv2bis April 2009
2412 Achieving perfect forward secrecy requires that when a connection is
2413 closed, each endpoint MUST forget not only the keys used by the
2414 connection but also any information that could be used to recompute
2417 Since the computing of Diffie-Hellman exponentials is computationally
2418 expensive, an endpoint may find it advantageous to reuse those
2419 exponentials for multiple connection setups. There are several
2420 reasonable strategies for doing this. An endpoint could choose a new
2421 exponential only periodically though this could result in less-than-
2422 perfect forward secrecy if some connection lasts for less than the
2423 lifetime of the exponential. Or it could keep track of which
2424 exponential was used for each connection and delete the information
2425 associated with the exponential only when some corresponding
2426 connection was closed. This would allow the exponential to be reused
2427 without losing perfect forward secrecy at the cost of maintaining
2430 Decisions as to whether and when to reuse Diffie-Hellman exponentials
2431 is a private decision in the sense that it will not affect
2432 interoperability. An implementation that reuses exponentials MAY
2433 choose to remember the exponential used by the other endpoint on past
2434 exchanges and if one is reused to avoid the second half of the
2435 calculation. See [REUSE] for a security analysis of this practice
2436 and for additional security considerations when reusing ephemeral DH
2439 2.13. Generating Keying Material
2441 In the context of the IKE SA, four cryptographic algorithms are
2442 negotiated: an encryption algorithm, an integrity protection
2443 algorithm, a Diffie-Hellman group, and a pseudo-random function
2444 (prf). The pseudo-random function is used for the construction of
2445 keying material for all of the cryptographic algorithms used in both
2446 the IKE SA and the Child SAs.
2448 We assume that each encryption algorithm and integrity protection
2449 algorithm uses a fixed-size key and that any randomly chosen value of
2450 that fixed size can serve as an appropriate key. For algorithms that
2451 accept a variable length key, a fixed key size MUST be specified as
2452 part of the cryptographic transform negotiated (see Section 3.3.5 for
2453 the defintion of the Key Length transform attribute). For algorithms
2454 for which not all values are valid keys (such as DES or 3DES with key
2455 parity), the algorithm by which keys are derived from arbitrary
2456 values MUST be specified by the cryptographic transform. For
2457 integrity protection functions based on Hashed Message Authentication
2458 Code (HMAC), the fixed key size is the size of the output of the
2459 underlying hash function.
2463 Kaufman, et al. Expires October 26, 2009 [Page 44]
2465 Internet-Draft IKEv2bis April 2009
2468 It is assumed that pseudo-random functions (PRFs) accept keys of any
2469 length, but have a preferred key size. The preferred key size is
2470 used as the length of SK_d, SK_pi, and SK_pr (see Section 2.14). For
2471 PRFs based on the HMAC construction, the preferred key size is equal
2472 to the length of the output of the underlying hash function. Other
2473 types of PRFs MUST specify their preferred key size.
2475 Keying material will always be derived as the output of the
2476 negotiated prf algorithm. Since the amount of keying material needed
2477 may be greater than the size of the output of the prf algorithm, we
2478 will use the prf iteratively. We will use the terminology prf+ to
2479 describe the function that outputs a pseudo-random stream based on
2480 the inputs to a prf as follows: (where | indicates concatenation)
2482 prf+ (K,S) = T1 | T2 | T3 | T4 | ...
2485 T1 = prf (K, S | 0x01)
2486 T2 = prf (K, T1 | S | 0x02)
2487 T3 = prf (K, T2 | S | 0x03)
2488 T4 = prf (K, T3 | S | 0x04)
2490 continuing as needed to compute all required keys. The keys are
2491 taken from the output string without regard to boundaries (e.g., if
2492 the required keys are a 256-bit Advanced Encryption Standard (AES)
2493 key and a 160-bit HMAC key, and the prf function generates 160 bits,
2494 the AES key will come from T1 and the beginning of T2, while the HMAC
2495 key will come from the rest of T2 and the beginning of T3).
2497 The constant concatenated to the end of each string feeding the prf
2498 is a single octet. prf+ in this document is not defined beyond 255
2499 times the size of the prf output.
2501 2.14. Generating Keying Material for the IKE SA
2503 The shared keys are computed as follows. A quantity called SKEYSEED
2504 is calculated from the nonces exchanged during the IKE_SA_INIT
2505 exchange and the Diffie-Hellman shared secret established during that
2506 exchange. SKEYSEED is used to calculate seven other secrets: SK_d
2507 used for deriving new keys for the Child SAs established with this
2508 IKE SA; SK_ai and SK_ar used as a key to the integrity protection
2509 algorithm for authenticating the component messages of subsequent
2510 exchanges; SK_ei and SK_er used for encrypting (and of course
2511 decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are
2512 used when generating an AUTH payload. The lengths of SK_d, SK_pi,
2513 and SK_pr are the preferred key length of the agreed-to PRF.
2515 SKEYSEED and its derivatives are computed as follows:
2519 Kaufman, et al. Expires October 26, 2009 [Page 45]
2521 Internet-Draft IKEv2bis April 2009
2524 SKEYSEED = prf(Ni | Nr, g^ir)
2526 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr }
2527 = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )
2529 (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er,
2530 SK_pi, and SK_pr are taken in order from the generated bits of the
2531 prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman
2532 exchange. g^ir is represented as a string of octets in big endian
2533 order padded with zeros if necessary to make it the length of the
2534 modulus. Ni and Nr are the nonces, stripped of any headers. For
2535 historical backwards-compatibility reasons, there are two PRFs that
2536 are treated specially in this calculation. If the negotiated PRF is
2537 AES-XCBC-PRF-128 [RFC4434] or AES-CMAC-PRF-128 [RFC4615], only the
2538 first 64 bits of Ni and the first 64 bits of Nr are used in the
2541 The two directions of traffic flow use different keys. The keys used
2542 to protect messages from the original initiator are SK_ai and SK_ei.
2543 The keys used to protect messages in the other direction are SK_ar
2546 2.15. Authentication of the IKE SA
2548 When not using extensible authentication (see Section 2.16), the
2549 peers are authenticated by having each sign (or MAC using a shared
2550 secret as the key) a block of data. For the responder, the octets to
2551 be signed start with the first octet of the first SPI in the header
2552 of the second message (IKE_SA_INIT response) and end with the last
2553 octet of the last payload in the second message. Appended to this
2554 (for purposes of computing the signature) are the initiator's nonce
2555 Ni (just the value, not the payload containing it), and the value
2556 prf(SK_pr,IDr') where IDr' is the responder's ID payload excluding
2557 the fixed header. Note that neither the nonce Ni nor the value
2558 prf(SK_pr,IDr') are transmitted. Similarly, the initiator signs the
2559 first message (IKE_SA_INIT request), starting with the first octet of
2560 the first SPI in the header and ending with the last octet of the
2561 last payload. Appended to this (for purposes of computing the
2562 signature) are the responder's nonce Nr, and the value
2563 prf(SK_pi,IDi'). In the above calculation, IDi' and IDr' are the
2564 entire ID payloads excluding the fixed header. It is critical to the
2565 security of the exchange that each side sign the other side's nonce.
2569 The initiator's signed octets can be described as:
2575 Kaufman, et al. Expires October 26, 2009 [Page 46]
2577 Internet-Draft IKEv2bis April 2009
2580 InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
2581 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
2582 RealIKEHDR = SPIi | SPIr | . . . | Length
2583 RealMessage1 = RealIKEHDR | RestOfMessage1
2584 NonceRPayload = PayloadHeader | NonceRData
2585 InitiatorIDPayload = PayloadHeader | RestOfIDPayload
2586 RestOfInitIDPayload = IDType | RESERVED | InitIDData
2587 MACedIDForI = prf(SK_pi, RestOfInitIDPayload)
2589 The responder's signed octets can be described as:
2591 ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
2592 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
2593 RealIKEHDR = SPIi | SPIr | . . . | Length
2594 RealMessage2 = RealIKEHDR | RestOfMessage2
2595 NonceIPayload = PayloadHeader | NonceIData
2596 ResponderIDPayload = PayloadHeader | RestOfIDPayload
2597 RestOfRespIDPayload = IDType | RESERVED | RespIDData
2598 MACedIDForR = prf(SK_pr, RestOfRespIDPayload)
2600 Note that all of the payloads are included under the signature,
2601 including any payload types not defined in this document. If the
2602 first message of the exchange is sent multiple times (such as with a
2603 responder cookie and/or a different Diffie-Hellman group), it is the
2604 latest version of the message that is signed.
2606 Optionally, messages 3 and 4 MAY include a certificate, or
2607 certificate chain providing evidence that the key used to compute a
2608 digital signature belongs to the name in the ID payload. The
2609 signature or MAC will be computed using algorithms dictated by the
2610 type of key used by the signer, and specified by the Auth Method
2611 field in the Authentication payload. There is no requirement that
2612 the initiator and responder sign with the same cryptographic
2613 algorithms. The choice of cryptographic algorithms depends on the
2614 type of key each has. In particular, the initiator may be using a
2615 shared key while the responder may have a public signature key and
2616 certificate. It will commonly be the case (but it is not required)
2617 that if a shared secret is used for authentication that the same key
2618 is used in both directions.
2620 Note that it is a common but typically insecure practice to have a
2621 shared key derived solely from a user-chosen password without
2622 incorporating another source of randomness. This is typically
2623 insecure because user-chosen passwords are unlikely to have
2624 sufficient unpredictability to resist dictionary attacks and these
2625 attacks are not prevented in this authentication method.
2626 (Applications using password-based authentication for bootstrapping
2627 and IKE SA should use the authentication method in Section 2.16,
2631 Kaufman, et al. Expires October 26, 2009 [Page 47]
2633 Internet-Draft IKEv2bis April 2009
2636 which is designed to prevent off-line dictionary attacks.) {{ Demoted
2637 the SHOULD }} The pre-shared key needs to contain as much
2638 unpredictability as the strongest key being negotiated. In the case
2639 of a pre-shared key, the AUTH value is computed as:
2642 AUTH = prf( prf( Shared Secret,"Key Pad for IKEv2"),
2643 <InitiatorSignedOctets>)
2645 AUTH = prf( prf( Shared Secret,"Key Pad for IKEv2"),
2646 <ResponderSignedOctets>)
2648 where the string "Key Pad for IKEv2" is 17 ASCII characters without
2649 null termination. The shared secret can be variable length. The pad
2650 string is added so that if the shared secret is derived from a
2651 password, the IKE implementation need not store the password in
2652 cleartext, but rather can store the value prf(Shared Secret,"Key Pad
2653 for IKEv2"), which could not be used as a password equivalent for
2654 protocols other than IKEv2. As noted above, deriving the shared
2655 secret from a password is not secure. This construction is used
2656 because it is anticipated that people will do it anyway. The
2657 management interface by which the Shared Secret is provided MUST
2658 accept ASCII strings of at least 64 octets and MUST NOT add a null
2659 terminator before using them as shared secrets. It MUST also accept
2660 a hex encoding of the Shared Secret. The management interface MAY
2661 accept other encodings if the algorithm for translating the encoding
2662 to a binary string is specified.
2664 2.16. Extensible Authentication Protocol Methods
2666 In addition to authentication using public key signatures and shared
2667 secrets, IKE supports authentication using methods defined in RFC
2668 3748 [EAP]. Typically, these methods are asymmetric (designed for a
2669 user authenticating to a server), and they may not be mutual. For
2670 this reason, these protocols are typically used to authenticate the
2671 initiator to the responder and MUST be used in conjunction with a
2672 public key signature based authentication of the responder to the
2673 initiator. These methods are often associated with mechanisms
2674 referred to as "Legacy Authentication" mechanisms.
2676 While this memo references [EAP] with the intent that new methods can
2677 be added in the future without updating this specification, some
2678 simpler variations are documented here and in Section 3.16. [EAP]
2679 defines an authentication protocol requiring a variable number of
2680 messages. Extensible Authentication is implemented in IKE as
2681 additional IKE_AUTH exchanges that MUST be completed in order to
2682 initialize the IKE SA.
2687 Kaufman, et al. Expires October 26, 2009 [Page 48]
2689 Internet-Draft IKEv2bis April 2009
2692 An initiator indicates a desire to use extensible authentication by
2693 leaving out the AUTH payload from message 3. By including an IDi
2694 payload but not an AUTH payload, the initiator has declared an
2695 identity but has not proven it. If the responder is willing to use
2696 an extensible authentication method, it will place an Extensible
2697 Authentication Protocol (EAP) payload in message 4 and defer sending
2698 SAr2, TSi, and TSr until initiator authentication is complete in a
2699 subsequent IKE_AUTH exchange. In the case of a minimal extensible
2700 authentication, the initial SA establishment will appear as follows:
2703 -------------------------------------------------------------------
2704 HDR, SAi1, KEi, Ni -->
2705 <-- HDR, SAr1, KEr, Nr, [CERTREQ]
2706 HDR, SK {IDi, [CERTREQ,]
2709 <-- HDR, SK {IDr, [CERT,] AUTH,
2712 <-- HDR, SK {EAP (success)}
2714 <-- HDR, SK {AUTH, SAr2, TSi, TSr }
2716 {{ Clarif-3.10 }} As described in Section 2.2, when EAP is used, each
2717 pair of IKE SA initial setup messages will have their message numbers
2718 incremented; the first pair of AUTH messages will have an ID of 1,
2719 the second will be 2, and so on.
2721 For EAP methods that create a shared key as a side effect of
2722 authentication, that shared key MUST be used by both the initiator
2723 and responder to generate AUTH payloads in messages 7 and 8 using the
2724 syntax for shared secrets specified in Section 2.15. The shared key
2725 from EAP is the field from the EAP specification named MSK. This
2726 shared key generated during an IKE exchange MUST NOT be used for any
2729 EAP methods that do not establish a shared key SHOULD NOT be used, as
2730 they are subject to a number of man-in-the-middle attacks [EAPMITM]
2731 if these EAP methods are used in other protocols that do not use a
2732 server-authenticated tunnel. Please see the Security Considerations
2733 section for more details. If EAP methods that do not generate a
2734 shared key are used, the AUTH payloads in messages 7 and 8 MUST be
2735 generated using SK_pi and SK_pr, respectively.
2737 {{ Demoted the SHOULD }} The initiator of an IKE SA using EAP needs
2738 to be capable of extending the initial protocol exchange to at least
2739 ten IKE_AUTH exchanges in the event the responder sends notification
2743 Kaufman, et al. Expires October 26, 2009 [Page 49]
2745 Internet-Draft IKEv2bis April 2009
2748 messages and/or retries the authentication prompt. Once the protocol
2749 exchange defined by the chosen EAP authentication method has
2750 successfully terminated, the responder MUST send an EAP payload
2751 containing the Success message. Similarly, if the authentication
2752 method has failed, the responder MUST send an EAP payload containing
2753 the Failure message. The responder MAY at any time terminate the IKE
2754 exchange by sending an EAP payload containing the Failure message.
2756 Following such an extended exchange, the EAP AUTH payloads MUST be
2757 included in the two messages following the one containing the EAP
2760 {{ Clarif-3.5 }} When the initiator authentication uses EAP, it is
2761 possible that the contents of the IDi payload is used only for AAA
2762 routing purposes and selecting which EAP method to use. This value
2763 may be different from the identity authenticated by the EAP method.
2764 It is important that policy lookups and access control decisions use
2765 the actual authenticated identity. Often the EAP server is
2766 implemented in a separate AAA server that communicates with the IKEv2
2767 responder. In this case, the authenticated identity has to be sent
2768 from the AAA server to the IKEv2 responder.
2770 2.17. Generating Keying Material for Child SAs
2772 A single Child SA is created by the IKE_AUTH exchange, and additional
2773 Child SAs can optionally be created in CREATE_CHILD_SA exchanges.
2774 Keying material for them is generated as follows:
2776 KEYMAT = prf+(SK_d, Ni | Nr)
2778 Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this
2779 request is the first Child SA created or the fresh Ni and Nr from the
2780 CREATE_CHILD_SA exchange if this is a subsequent creation.
2782 For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman
2783 exchange, the keying material is defined as:
2785 KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr )
2787 where g^ir (new) is the shared secret from the ephemeral Diffie-
2788 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an
2789 octet string in big endian order padded with zeros in the high-order
2790 bits if necessary to make it the length of the modulus).
2792 For ESP and AH, a single Child SA negotiation results in two security
2793 associations (one in each direction). Keying material MUST be taken
2794 from the expanded KEYMAT in the following order:
2799 Kaufman, et al. Expires October 26, 2009 [Page 50]
2801 Internet-Draft IKEv2bis April 2009
2804 o The encryption key (if any) for the SA carrying data from the
2805 initiator to the responder.
2807 o The authentication key (if any) for the SA carrying data from the
2808 initiator to the responder.
2810 o The encryption key (if any) for the SA carrying data from the
2811 responder to the initiator.
2813 o The authentication key (if any) for the SA carrying data from the
2814 responder to the initiator.
2816 Each cryptographic algorithm takes a fixed number of bits of keying
2817 material specified as part of the algorithm, or negotiated in SA
2818 payloads (see Section 2.13 for description of key lengths, and
2819 Section 3.3.5 for the definition of the Key Length transform
2822 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange
2824 The CREATE_CHILD_SA exchange can be used to rekey an existing IKE SA
2825 (see Section 2.8). {{ Clarif-5.3 }} New initiator and responder SPIs
2826 are supplied in the SPI fields in the Proposal structures inside the
2827 Security Association (SA) payloads (not the SPI fields in the IKE
2828 header). The TS payloads are omitted when rekeying an IKE SA.
2829 SKEYSEED for the new IKE SA is computed using SK_d from the existing
2832 SKEYSEED = prf(SK_d (old), g^ir (new) | Ni | Nr)
2834 where g^ir (new) is the shared secret from the ephemeral Diffie-
2835 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an
2836 octet string in big endian order padded with zeros if necessary to
2837 make it the length of the modulus) and Ni and Nr are the two nonces
2838 stripped of any headers.
2840 {{ Clarif-5.5 }} The old and new IKE SA may have selected a different
2841 PRF. Because the rekeying exchange belongs to the old IKE SA, it is
2842 the old IKE SA's PRF that is used.
2844 {{ Clarif-5.12}} The main reason for rekeying the IKE SA is to ensure
2845 that the compromise of old keying material does not provide
2846 information about the current keys, or vice versa. Therefore,
2847 implementations MUST perform a new Diffie-Hellman exchange when
2848 rekeying the IKE SA. In other words, an initiator MUST NOT propose
2849 the value "NONE" for the D-H transform, and a responder MUST NOT
2850 accept such a proposal. This means that a succesful exchange
2851 rekeying the IKE SA always includes the KEi/KEr payloads.
2855 Kaufman, et al. Expires October 26, 2009 [Page 51]
2857 Internet-Draft IKEv2bis April 2009
2860 The new IKE SA MUST reset its message counters to 0.
2862 SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as
2863 specified in Section 2.14.
2865 2.19. Requesting an Internal Address on a Remote Network
2867 Most commonly occurring in the endpoint-to-security-gateway scenario,
2868 an endpoint may need an IP address in the network protected by the
2869 security gateway and may need to have that address dynamically
2870 assigned. A request for such a temporary address can be included in
2871 any request to create a Child SA (including the implicit request in
2872 message 3) by including a CP payload. Note, however, it is usual to
2873 only assign one IP address during the IKE_AUTH exchange. That
2874 address persists at least until the deletion of the IKE SA.
2876 This function provides address allocation to an IPsec Remote Access
2877 Client (IRAC) trying to tunnel into a network protected by an IPsec
2878 Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an
2879 IKE SA and a Child SA, the IRAC MUST request the IRAS-controlled
2880 address (and optionally other information concerning the protected
2881 network) in the IKE_AUTH exchange. The IRAS may procure an address
2882 for the IRAC from any number of sources such as a DHCP/BOOTP server
2883 or its own address pool.
2886 -------------------------------------------------------------------
2887 HDR, SK {IDi, [CERT,]
2888 [CERTREQ,] [IDr,] AUTH,
2889 CP(CFG_REQUEST), SAi2,
2891 <-- HDR, SK {IDr, [CERT,] AUTH,
2892 CP(CFG_REPLY), SAr2,
2895 In all cases, the CP payload MUST be inserted before the SA payload.
2896 In variations of the protocol where there are multiple IKE_AUTH
2897 exchanges, the CP payloads MUST be inserted in the messages
2898 containing the SA payloads.
2900 CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute
2901 (either IPv4 or IPv6) but MAY contain any number of additional
2902 attributes the initiator wants returned in the response.
2904 For example, message from initiator to responder:
2911 Kaufman, et al. Expires October 26, 2009 [Page 52]
2913 Internet-Draft IKEv2bis April 2009
2918 TSi = (0, 0-65535,0.0.0.0-255.255.255.255)
2919 TSr = (0, 0-65535,0.0.0.0-255.255.255.255)
2921 NOTE: Traffic Selectors contain (protocol, port range, address
2924 Message from responder to initiator:
2927 INTERNAL_ADDRESS(192.0.2.202)
2928 INTERNAL_NETMASK(255.255.255.0)
2929 INTERNAL_SUBNET(192.0.2.0/255.255.255.0)
2930 TSi = (0, 0-65535,192.0.2.202-192.0.2.202)
2931 TSr = (0, 0-65535,192.0.2.0-192.0.2.255)
2933 All returned values will be implementation dependent. As can be seen
2934 in the above example, the IRAS MAY also send other attributes that
2935 were not included in CP(CFG_REQUEST) and MAY ignore the non-
2936 mandatory attributes that it does not support.
2938 {{ 3.10.1-37 }} The FAILED_CP_REQUIRED notification is sent by
2939 responder in the case where CP(CFG_REQUEST) was expected but not
2940 received, and so is a conflict with locally configured policy. There
2941 is no associated data.
2943 The responder MUST NOT send a CFG_REPLY without having first received
2944 a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS
2945 to perform an unnecessary configuration lookup if the IRAC cannot
2946 process the REPLY. In the case where the IRAS's configuration
2947 requires that CP be used for a given identity IDi, but IRAC has
2948 failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and
2949 terminate the IKE exchange with a FAILED_CP_REQUIRED error. The
2950 FAILED_CP_REQUIRED is not fatal to the IKE SA; it simply causes the
2951 Child SA creation fail. The initiator can fix this by later starting
2952 a new configuration payload request.
2954 2.19.1. Configuration Payloads
2956 Editor's note: some of this sub-section is redundant and will go away
2957 in the next version of the document.
2959 In support of the scenario described in Section 1.1.3, an initiator
2960 may request that the responder assign an IP address and tell the
2961 initiator what it is. {{ Clarif-6.1 }} That request is done using
2962 configuration payloads, not traffic selectors. An address in a TSi
2963 payload in a response does not mean that the responder has assigned
2967 Kaufman, et al. Expires October 26, 2009 [Page 53]
2969 Internet-Draft IKEv2bis April 2009
2972 that address to the initiator: it only means that if packets matching
2973 these traffic selectors are sent by the initiator, IPsec processing
2974 can be performed as agreed for this SA.
2976 Configuration payloads are of type CFG_REQUEST/CFG_REPLY or CFG_SET/
2977 CFG_ACK (see CFG Type in the payload description below). CFG_REQUEST
2978 and CFG_SET payloads may optionally be added to any IKE request. The
2979 IKE response MUST include either a corresponding CFG_REPLY or CFG_ACK
2980 or a Notify payload with an error type indicating why the request
2981 could not be honored. An exception is that a minimal implementation
2982 MAY ignore all CFG_REQUEST and CFG_SET payloads, so a response
2983 message without a corresponding CFG_REPLY or CFG_ACK MUST be accepted
2984 as an indication that the request was not supported.
2986 "CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information
2987 from its peer. If an attribute in the CFG_REQUEST Configuration
2988 Payload is not zero-length, it is taken as a suggestion for that
2989 attribute. The CFG_REPLY Configuration Payload MAY return that
2990 value, or a new one. It MAY also add new attributes and not include
2991 some requested ones. Requestors MUST ignore returned attributes that
2992 they do not recognize.
2994 Some attributes MAY be multi-valued, in which case multiple attribute
2995 values of the same type are sent and/or returned. Generally, all
2996 values of an attribute are returned when the attribute is requested.
2997 For some attributes (in this version of the specification only
2998 internal addresses), multiple requests indicates a request that
2999 multiple values be assigned. For these attributes, the number of
3000 values returned SHOULD NOT exceed the number requested.
3002 If the data type requested in a CFG_REQUEST is not recognized or not
3003 supported, the responder MUST NOT return an error type but rather
3004 MUST either send a CFG_REPLY that MAY be empty or a reply not
3005 containing a CFG_REPLY payload at all. Error returns are reserved
3006 for cases where the request is recognized but cannot be performed as
3007 requested or the request is badly formatted.
3009 "CFG_SET/CFG_ACK" allows an IKE endpoint to push configuration data
3010 to its peer. In this case, the CFG_SET Configuration Payload
3011 contains attributes the initiator wants its peer to alter. The
3012 responder MUST return a Configuration Payload if it accepted any of
3013 the configuration data and it MUST contain the attributes that the
3014 responder accepted with zero-length data. Those attributes that it
3015 did not accept MUST NOT be in the CFG_ACK Configuration Payload. If
3016 no attributes were accepted, the responder MUST return either an
3017 empty CFG_ACK payload or a response message without a CFG_ACK
3018 payload. There are currently no defined uses for the CFG_SET/CFG_ACK
3019 exchange, though they may be used in connection with extensions based
3023 Kaufman, et al. Expires October 26, 2009 [Page 54]
3025 Internet-Draft IKEv2bis April 2009
3028 on Vendor IDs. An minimal implementation of this specification MAY
3029 ignore CFG_SET payloads.
3031 {{ Demoted the SHOULD }} Extensions via the CP payload should not be
3032 used for general purpose management. Its main intent is to provide a
3033 bootstrap mechanism to exchange information within IPsec from IRAS to
3034 IRAC. While it MAY be useful to use such a method to exchange
3035 information between some Security Gateways (SGW) or small networks,
3036 existing management protocols such as DHCP [DHCP], RADIUS [RADIUS],
3037 SNMP, or LDAP [LDAP] should be preferred for enterprise management as
3038 well as subsequent information exchanges.
3040 2.20. Requesting the Peer's Version
3042 An IKE peer wishing to inquire about the other peer's IKE software
3043 version information MAY use the method below. This is an example of
3044 a configuration request within an INFORMATIONAL exchange, after the
3045 IKE SA and first Child SA have been created.
3047 An IKE implementation MAY decline to give out version information
3048 prior to authentication or even after authentication to prevent
3049 trolling in case some implementation is known to have some security
3050 weakness. In that case, it MUST either return an empty string or no
3051 CP payload if CP is not supported.
3054 -------------------------------------------------------------------
3055 HDR, SK{CP(CFG_REQUEST)} -->
3056 <-- HDR, SK{CP(CFG_REPLY)}
3059 APPLICATION_VERSION("")
projects / strongswan.git / blob