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 P. Eronen
9 Expires: August 28, 2008 Nokia
13 Internet Key Exchange Protocol: IKEv2
14 draft-hoffman-ikev2bis-03
18 By submitting this Internet-Draft, each author represents that any
19 applicable patent or other IPR claims of which he or she is aware
20 have been or will be disclosed, and any of which he or she becomes
21 aware will be disclosed, in accordance with Section 6 of BCP 79.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF), its areas, and its working groups. Note that
25 other groups may also distribute working documents as Internet-
28 Internet-Drafts are draft documents valid for a maximum of six months
29 and may be updated, replaced, or obsoleted by other documents at any
30 time. It is inappropriate to use Internet-Drafts as reference
31 material or to cite them other than as "work in progress."
33 The list of current Internet-Drafts can be accessed at
34 http://www.ietf.org/ietf/1id-abstracts.txt.
36 The list of Internet-Draft Shadow Directories can be accessed at
37 http://www.ietf.org/shadow.html.
39 This Internet-Draft will expire on August 28, 2008.
43 Copyright (C) The IETF Trust (2008).
47 This document describes version 2 of the Internet Key Exchange (IKE)
48 protocol. It is a restatement of RFC 4306, and includes all of the
49 clarifications from RFC 4718.
55 Kaufman, et al. Expires August 28, 2008 [Page 1]
57 Internet-Draft IKEv2bis February 2008
62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
63 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 6
64 1.1.1. Security Gateway to Security Gateway Tunnel . . . . . 6
65 1.1.2. Endpoint-to-Endpoint Transport . . . . . . . . . . . 7
66 1.1.3. Endpoint to Security Gateway Tunnel . . . . . . . . . 8
67 1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . 8
68 1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 9
69 1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 11
70 1.3.1. Creating New CHILD_SAs with the CREATE_CHILD_SA
71 Exchange . . . . . . . . . . . . . . . . . . . . . . 13
72 1.3.2. Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange . 14
73 1.3.3. Rekeying CHILD_SAs with the CREATE_CHILD_SA
74 Exchange . . . . . . . . . . . . . . . . . . . . . . 14
75 1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 15
76 1.5. Informational Messages outside of an IKE_SA . . . . . . . 17
77 1.6. Requirements Terminology . . . . . . . . . . . . . . . . 17
78 1.7. Differences Between RFC 4306 and This Document . . . . . 18
79 2. IKE Protocol Details and Variations . . . . . . . . . . . . . 19
80 2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 20
81 2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 21
82 2.3. Window Size for Overlapping Requests . . . . . . . . . . 21
83 2.4. State Synchronization and Connection Timeouts . . . . . . 23
84 2.5. Version Numbers and Forward Compatibility . . . . . . . . 25
85 2.6. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 27
86 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 29
87 2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 30
88 2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 31
89 2.8.1. Simultaneous CHILD_SA rekeying . . . . . . . . . . . 33
90 2.8.2. Rekeying the IKE_SA Versus Reauthentication . . . . . 35
91 2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 36
92 2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 38
93 2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 39
94 2.11. Address and Port Agility . . . . . . . . . . . . . . . . 39
95 2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 40
96 2.13. Generating Keying Material . . . . . . . . . . . . . . . 40
97 2.14. Generating Keying Material for the IKE_SA . . . . . . . . 42
98 2.15. Authentication of the IKE_SA . . . . . . . . . . . . . . 42
99 2.16. Extensible Authentication Protocol Methods . . . . . . . 44
100 2.17. Generating Keying Material for CHILD_SAs . . . . . . . . 46
101 2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA Exchange . . . . 47
102 2.19. Requesting an Internal Address on a Remote Network . . . 48
103 2.19.1. Configuration Payloads . . . . . . . . . . . . . . . 49
104 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 51
105 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 51
106 2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 52
107 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 54
111 Kaufman, et al. Expires August 28, 2008 [Page 2]
113 Internet-Draft IKEv2bis February 2008
116 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 57
117 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 57
118 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 58
119 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 61
120 3.3. Security Association Payload . . . . . . . . . . . . . . 63
121 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 65
122 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 66
123 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 69
124 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 70
125 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 71
126 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 73
127 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 73
128 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 74
129 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 77
130 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 79
131 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 81
132 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 82
133 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 83
134 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 84
135 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 87
136 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 89
137 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 90
138 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 91
139 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 93
140 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 95
141 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 96
142 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 99
143 3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 101
144 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 101
145 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 102
146 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 104
147 5. Security Considerations . . . . . . . . . . . . . . . . . . . 106
148 5.1. Traffic selector authorization . . . . . . . . . . . . . 108
149 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 109
150 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 110
151 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 110
152 8.1. Normative References . . . . . . . . . . . . . . . . . . 110
153 8.2. Informative References . . . . . . . . . . . . . . . . . 112
154 Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 115
155 Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 117
156 B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 117
157 B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 117
158 Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 118
159 C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 118
160 C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 119
161 C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 120
162 C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying
163 CHILD_SAs . . . . . . . . . . . . . . . . . . . . . . . . 121
167 Kaufman, et al. Expires August 28, 2008 [Page 3]
169 Internet-Draft IKEv2bis February 2008
172 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA . . . . 121
173 C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 121
174 Appendix D. Changes Between Internet Draft Versions . . . . . . 121
175 D.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 121
176 D.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 122
177 D.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 124
178 D.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 124
179 D.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 125
180 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 127
181 Intellectual Property and Copyright Statements . . . . . . . . . 129
223 Kaufman, et al. Expires August 28, 2008 [Page 4]
225 Internet-Draft IKEv2bis February 2008
230 {{ An introduction to the differences between RFC 4306 [IKEV2] and
231 this document is given at the end of Section 1. It is put there
232 (instead of here) to preserve the section numbering of RFC 4306. }}
234 IP Security (IPsec) provides confidentiality, data integrity, access
235 control, and data source authentication to IP datagrams. These
236 services are provided by maintaining shared state between the source
237 and the sink of an IP datagram. This state defines, among other
238 things, the specific services provided to the datagram, which
239 cryptographic algorithms will be used to provide the services, and
240 the keys used as input to the cryptographic algorithms.
242 Establishing this shared state in a manual fashion does not scale
243 well. Therefore, a protocol to establish this state dynamically is
244 needed. This memo describes such a protocol -- the Internet Key
245 Exchange (IKE). Version 1 of IKE was defined in RFCs 2407 [DOI],
246 2408 [ISAKMP], and 2409 [IKEV1]. IKEv2 was defined in [IKEV2] and
247 clarified in [Clarif]. This single document is intended to replace
250 IKE performs mutual authentication between two parties and
251 establishes an IKE security association (SA) that includes shared
252 secret information that can be used to efficiently establish SAs for
253 Encapsulating Security Payload (ESP) [ESP] and/or Authentication
254 Header (AH) [AH] and a set of cryptographic algorithms to be used by
255 the SAs to protect the traffic that they carry. In this document,
256 the term "suite" or "cryptographic suite" refers to a complete set of
257 algorithms used to protect an SA. An initiator proposes one or more
258 suites by listing supported algorithms that can be combined into
259 suites in a mix-and-match fashion. IKE can also negotiate use of IP
260 Compression (IPComp) [IPCOMP] in connection with an ESP and/or AH SA.
261 We call the IKE SA an "IKE_SA". The SAs for ESP and/or AH that get
262 set up through that IKE_SA we call "CHILD_SAs".
264 All IKE communications consist of pairs of messages: a request and a
265 response. The pair is called an "exchange". We call the first
266 messages establishing an IKE_SA IKE_SA_INIT and IKE_AUTH exchanges
267 and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL
268 exchanges. In the common case, there is a single IKE_SA_INIT
269 exchange and a single IKE_AUTH exchange (a total of four messages) to
270 establish the IKE_SA and the first CHILD_SA. In exceptional cases,
271 there may be more than one of each of these exchanges. In all cases,
272 all IKE_SA_INIT exchanges MUST complete before any other exchange
273 type, then all IKE_AUTH exchanges MUST complete, and following that
274 any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur
275 in any order. In some scenarios, only a single CHILD_SA is needed
279 Kaufman, et al. Expires August 28, 2008 [Page 5]
281 Internet-Draft IKEv2bis February 2008
284 between the IPsec endpoints, and therefore there would be no
285 additional exchanges. Subsequent exchanges MAY be used to establish
286 additional CHILD_SAs between the same authenticated pair of endpoints
287 and to perform housekeeping functions.
289 IKE message flow always consists of a request followed by a response.
290 It is the responsibility of the requester to ensure reliability. If
291 the response is not received within a timeout interval, the requester
292 needs to retransmit the request (or abandon the connection).
294 The first request/response of an IKE session (IKE_SA_INIT) negotiates
295 security parameters for the IKE_SA, sends nonces, and sends Diffie-
298 The second request/response (IKE_AUTH) transmits identities, proves
299 knowledge of the secrets corresponding to the two identities, and
300 sets up an SA for the first (and often only) AH and/or ESP CHILD_SA.
302 The types of subsequent exchanges are CREATE_CHILD_SA (which creates
303 a CHILD_SA) and INFORMATIONAL (which deletes an SA, reports error
304 conditions, or does other housekeeping). Every request requires a
305 response. An INFORMATIONAL request with no payloads (other than the
306 empty Encrypted payload required by the syntax) is commonly used as a
307 check for liveness. These subsequent exchanges cannot be used until
308 the initial exchanges have completed.
310 In the description that follows, we assume that no errors occur.
311 Modifications to the flow should errors occur are described in
316 IKE is expected to be used to negotiate ESP and/or AH SAs in a number
317 of different scenarios, each with its own special requirements.
319 1.1.1. Security Gateway to Security Gateway Tunnel
321 +-+-+-+-+-+ +-+-+-+-+-+
323 Protected |Tunnel | tunnel |Tunnel | Protected
324 Subnet <-->|Endpoint |<---------->|Endpoint |<--> Subnet
326 +-+-+-+-+-+ +-+-+-+-+-+
328 Figure 1: Security Gateway to Security Gateway Tunnel
330 In this scenario, neither endpoint of the IP connection implements
331 IPsec, but network nodes between them protect traffic for part of the
335 Kaufman, et al. Expires August 28, 2008 [Page 6]
337 Internet-Draft IKEv2bis February 2008
340 way. Protection is transparent to the endpoints, and depends on
341 ordinary routing to send packets through the tunnel endpoints for
342 processing. Each endpoint would announce the set of addresses
343 "behind" it, and packets would be sent in tunnel mode where the inner
344 IP header would contain the IP addresses of the actual endpoints.
346 1.1.2. Endpoint-to-Endpoint Transport
348 +-+-+-+-+-+ +-+-+-+-+-+
349 | | IPsec transport | |
350 |Protected| or tunnel mode SA |Protected|
351 |Endpoint |<---------------------------------------->|Endpoint |
353 +-+-+-+-+-+ +-+-+-+-+-+
355 Figure 2: Endpoint to Endpoint
357 In this scenario, both endpoints of the IP connection implement
358 IPsec, as required of hosts in [IPSECARCH]. Transport mode will
359 commonly be used with no inner IP header. If there is an inner IP
360 header, the inner addresses will be the same as the outer addresses.
361 A single pair of addresses will be negotiated for packets to be
362 protected by this SA. These endpoints MAY implement application
363 layer access controls based on the IPsec authenticated identities of
364 the participants. This scenario enables the end-to-end security that
365 has been a guiding principle for the Internet since [ARCHPRINC],
366 [TRANSPARENCY], and a method of limiting the inherent problems with
367 complexity in networks noted by [ARCHGUIDEPHIL]. Although this
368 scenario may not be fully applicable to the IPv4 Internet, it has
369 been deployed successfully in specific scenarios within intranets
370 using IKEv1. It should be more broadly enabled during the transition
371 to IPv6 and with the adoption of IKEv2.
373 It is possible in this scenario that one or both of the protected
374 endpoints will be behind a network address translation (NAT) node, in
375 which case the tunneled packets will have to be UDP encapsulated so
376 that port numbers in the UDP headers can be used to identify
377 individual endpoints "behind" the NAT (see Section 2.23).
391 Kaufman, et al. Expires August 28, 2008 [Page 7]
393 Internet-Draft IKEv2bis February 2008
396 1.1.3. Endpoint to Security Gateway Tunnel
398 +-+-+-+-+-+ +-+-+-+-+-+
399 | | IPsec | | Protected
400 |Protected| tunnel |Tunnel | Subnet
401 |Endpoint |<------------------------>|Endpoint |<--- and/or
403 +-+-+-+-+-+ +-+-+-+-+-+
405 Figure 3: Endpoint to Security Gateway Tunnel
407 In this scenario, a protected endpoint (typically a portable roaming
408 computer) connects back to its corporate network through an IPsec-
409 protected tunnel. It might use this tunnel only to access
410 information on the corporate network, or it might tunnel all of its
411 traffic back through the corporate network in order to take advantage
412 of protection provided by a corporate firewall against Internet-based
413 attacks. In either case, the protected endpoint will want an IP
414 address associated with the security gateway so that packets returned
415 to it will go to the security gateway and be tunneled back. This IP
416 address may be static or may be dynamically allocated by the security
417 gateway. {{ Clarif-6.1 }} In support of the latter case, IKEv2
418 includes a mechanism (namely, configuration payloads) for the
419 initiator to request an IP address owned by the security gateway for
420 use for the duration of its SA.
422 In this scenario, packets will use tunnel mode. On each packet from
423 the protected endpoint, the outer IP header will contain the source
424 IP address associated with its current location (i.e., the address
425 that will get traffic routed to the endpoint directly), while the
426 inner IP header will contain the source IP address assigned by the
427 security gateway (i.e., the address that will get traffic routed to
428 the security gateway for forwarding to the endpoint). The outer
429 destination address will always be that of the security gateway,
430 while the inner destination address will be the ultimate destination
433 In this scenario, it is possible that the protected endpoint will be
434 behind a NAT. In that case, the IP address as seen by the security
435 gateway will not be the same as the IP address sent by the protected
436 endpoint, and packets will have to be UDP encapsulated in order to be
439 1.1.4. Other Scenarios
441 Other scenarios are possible, as are nested combinations of the
442 above. One notable example combines aspects of 1.1.1 and 1.1.3. A
443 subnet may make all external accesses through a remote security
447 Kaufman, et al. Expires August 28, 2008 [Page 8]
449 Internet-Draft IKEv2bis February 2008
452 gateway using an IPsec tunnel, where the addresses on the subnet are
453 routed to the security gateway by the rest of the Internet. An
454 example would be someone's home network being virtually on the
455 Internet with static IP addresses even though connectivity is
456 provided by an ISP that assigns a single dynamically assigned IP
457 address to the user's security gateway (where the static IP addresses
458 and an IPsec relay are provided by a third party located elsewhere).
460 1.2. The Initial Exchanges
462 Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH
463 exchanges (known in IKEv1 as Phase 1). These initial exchanges
464 normally consist of four messages, though in some scenarios that
465 number can grow. All communications using IKE consist of request/
466 response pairs. We'll describe the base exchange first, followed by
467 variations. The first pair of messages (IKE_SA_INIT) negotiate
468 cryptographic algorithms, exchange nonces, and do a Diffie-Hellman
471 The second pair of messages (IKE_AUTH) authenticate the previous
472 messages, exchange identities and certificates, and establish the
473 first CHILD_SA. Parts of these messages are encrypted and integrity
474 protected with keys established through the IKE_SA_INIT exchange, so
475 the identities are hidden from eavesdroppers and all fields in all
476 the messages are authenticated.
478 In the following descriptions, the payloads contained in the message
479 are indicated by names as listed below.
482 -----------------------------------------
485 CERTREQ Certificate Request
489 EAP Extensible Authentication
491 IDi Identification - Initiator
492 IDr Identification - Responder
496 SA Security Association
497 TSi Traffic Selector - Initiator
498 TSr Traffic Selector - Responder
503 Kaufman, et al. Expires August 28, 2008 [Page 9]
505 Internet-Draft IKEv2bis February 2008
508 The details of the contents of each payload are described in section
509 3. Payloads that may optionally appear will be shown in brackets,
510 such as [CERTREQ], indicate that optionally a certificate request
511 payload can be included.
513 The initial exchanges are as follows:
516 -------------------------------------------------------------------
517 HDR, SAi1, KEi, Ni -->
519 HDR contains the Security Parameter Indexes (SPIs), version numbers,
520 and flags of various sorts. The SAi1 payload states the
521 cryptographic algorithms the initiator supports for the IKE_SA. The
522 KE payload sends the initiator's Diffie-Hellman value. Ni is the
525 <-- HDR, SAr1, KEr, Nr, [CERTREQ]
527 The responder chooses a cryptographic suite from the initiator's
528 offered choices and expresses that choice in the SAr1 payload,
529 completes the Diffie-Hellman exchange with the KEr payload, and sends
530 its nonce in the Nr payload.
532 At this point in the negotiation, each party can generate SKEYSEED,
533 from which all keys are derived for that IKE_SA. All but the headers
534 of all the messages that follow are encrypted and integrity
535 protected. The keys used for the encryption and integrity protection
536 are derived from SKEYSEED and are known as SK_e (encryption) and SK_a
537 (authentication, a.k.a. integrity protection). A separate SK_e and
538 SK_a is computed for each direction. In addition to the keys SK_e
539 and SK_a derived from the DH value for protection of the IKE_SA,
540 another quantity SK_d is derived and used for derivation of further
541 keying material for CHILD_SAs. The notation SK { ... } indicates
542 that these payloads are encrypted and integrity protected using that
543 direction's SK_e and SK_a.
545 HDR, SK {IDi, [CERT,] [CERTREQ,]
549 The initiator asserts its identity with the IDi payload, proves
550 knowledge of the secret corresponding to IDi and integrity protects
551 the contents of the first message using the AUTH payload (see
552 Section 2.15). It might also send its certificate(s) in CERT
553 payload(s) and a list of its trust anchors in CERTREQ payload(s). If
554 any CERT payloads are included, the first certificate provided MUST
555 contain the public key used to verify the AUTH field. The optional
559 Kaufman, et al. Expires August 28, 2008 [Page 10]
561 Internet-Draft IKEv2bis February 2008
564 payload IDr enables the initiator to specify which of the responder's
565 identities it wants to talk to. This is useful when the machine on
566 which the responder is running is hosting multiple identities at the
567 same IP address. The initiator begins negotiation of a CHILD_SA
568 using the SAi2 payload. The final fields (starting with SAi2) are
569 described in the description of the CREATE_CHILD_SA exchange.
571 <-- HDR, SK {IDr, [CERT,] AUTH,
574 The responder asserts its identity with the IDr payload, optionally
575 sends one or more certificates (again with the certificate containing
576 the public key used to verify AUTH listed first), authenticates its
577 identity and protects the integrity of the second message with the
578 AUTH payload, and completes negotiation of a CHILD_SA with the
579 additional fields described below in the CREATE_CHILD_SA exchange.
581 The recipients of messages 3 and 4 MUST verify that all signatures
582 and MACs are computed correctly and that the names in the ID payloads
583 correspond to the keys used to generate the AUTH payload.
585 {{ Clarif-4.2}} If creating the CHILD_SA during the IKE_AUTH exchange
586 fails for some reason, the IKE_SA is still created as usual. The
587 list of responses in the IKE_AUTH exchange that do not prevent an
588 IKE_SA from being set up include at least the following:
589 NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,
590 INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED.
592 {{ Clarif-4.3 }} Note that IKE_AUTH messages do not contain KEi/KEr
593 or Ni/Nr payloads. Thus, the SA payloads in the IKE_AUTH exchange
594 cannot contain Transform Type 4 (Diffie-Hellman Group) with any value
595 other than NONE. Implementations SHOULD omit the whole transform
596 substructure instead of sending value NONE.
598 1.3. The CREATE_CHILD_SA Exchange
600 {{ This is a heavy rewrite of most of this section. The major
601 organization changes are described in Clarif-4.1 and Clarif-5.1. }}
603 The CREATE_CHILD_SA exchange is used to create new CHILD_SAs and to
604 rekey both IKE_SAs and CHILD_SAs. This exchange consists of a single
605 request/response pair, and some of its function was referred to as a
606 phase 2 exchange in IKEv1. It MAY be initiated by either end of the
607 IKE_SA after the initial exchanges are completed.
609 All messages following the initial exchange are cryptographically
610 protected using the cryptographic algorithms and keys negotiated in
611 the first two messages of the IKE exchange. These subsequent
615 Kaufman, et al. Expires August 28, 2008 [Page 11]
617 Internet-Draft IKEv2bis February 2008
620 messages use the syntax of the Encrypted Payload described in
621 Section 3.14. All subsequent messages include an Encrypted Payload,
622 even if they are referred to in the text as "empty". For both
623 messages in the CREATE_CHILD_SA, the message following the header is
624 encrypted and the message including the header is integrity protected
625 using the cryptographic algorithms negotiated for the IKE_SA.
627 The CREATE_CHILD_SA is also used for rekeying IKE_SAs and CHILD_SAs.
628 An SA is rekeyed by creating a new SA and then deleting the old one.
629 This section describes the first part of rekeying, the creation of
630 new SAs; Section 2.8 covers the mechanics of rekeying, including
631 moving traffic from old to new SAs and the deletion of the old SAs.
632 The two sections must be read together to understand the entire
635 Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this
636 section the term initiator refers to the endpoint initiating this
637 exchange. An implementation MAY refuse all CREATE_CHILD_SA requests
640 The CREATE_CHILD_SA request MAY optionally contain a KE payload for
641 an additional Diffie-Hellman exchange to enable stronger guarantees
642 of forward secrecy for the CHILD_SA. The keying material for the
643 CHILD_SA is a function of SK_d established during the establishment
644 of the IKE_SA, the nonces exchanged during the CREATE_CHILD_SA
645 exchange, and the Diffie-Hellman value (if KE payloads are included
646 in the CREATE_CHILD_SA exchange).
648 If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of
649 the SA offers MUST include the Diffie-Hellman group of the KEi. The
650 Diffie-Hellman group of the KEi MUST be an element of the group the
651 initiator expects the responder to accept (additional Diffie-Hellman
652 groups can be proposed). If the responder selects a proposal using a
653 different Diffie-Hellman group (other than NONE), the responder MUST
654 reject the request and indicate its preferred Diffie-Hellman group in
655 the INVALID_KE_PAYLOAD Notification payload. {{ 3.10.1-17 }} There
656 are two octets of data associated with this notification: the
657 accepted D-H Group number in big endian order. In the case of such a
658 rejection, the CREATE_CHILD_SA exchange fails, and the initiator will
659 probably retry the exchange with a Diffie-Hellman proposal and KEi in
660 the group that the responder gave in the INVALID_KE_PAYLOAD.
662 {{ 3.10.1-35 }} The responder sends a NO_ADDITIONAL_SAS notification
663 to indicate that a CREATE_CHILD_SA request is unacceptable because
664 the responder is unwilling to accept any more CHILD_SAs on this
665 IKE_SA. Some minimal implementations may only accept a single
666 CHILD_SA setup in the context of an initial IKE exchange and reject
667 any subsequent attempts to add more.
671 Kaufman, et al. Expires August 28, 2008 [Page 12]
673 Internet-Draft IKEv2bis February 2008
676 1.3.1. Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange
678 A CHILD_SA may be created by sending a CREATE_CHILD_SA request. The
679 CREATE_CHILD_SA request for creating a new CHILD_SA is:
682 -------------------------------------------------------------------
683 HDR, SK {SA, Ni, [KEi],
686 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
687 payload, optionally a Diffie-Hellman value in the KEi payload, and
688 the proposed traffic selectors for the proposed CHILD_SA in the TSi
691 The CREATE_CHILD_SA response for creating a new CHILD_SA is:
693 <-- HDR, SK {SA, Nr, [KEr],
696 The responder replies (using the same Message ID to respond) with the
697 accepted offer in an SA payload, and a Diffie-Hellman value in the
698 KEr payload if KEi was included in the request and the selected
699 cryptographic suite includes that group.
701 The traffic selectors for traffic to be sent on that SA are specified
702 in the TS payloads in the response, which may be a subset of what the
703 initiator of the CHILD_SA proposed.
705 {{ 3.10.1-16391 }} The USE_TRANSPORT_MODE notification MAY be
706 included in a request message that also includes an SA payload
707 requesting a CHILD_SA. It requests that the CHILD_SA use transport
708 mode rather than tunnel mode for the SA created. If the request is
709 accepted, the response MUST also include a notification of type
710 USE_TRANSPORT_MODE. If the responder declines the request, the
711 CHILD_SA will be established in tunnel mode. If this is unacceptable
712 to the initiator, the initiator MUST delete the SA. Note: Except
713 when using this option to negotiate transport mode, all CHILD_SAs
714 will use tunnel mode.
716 {{ 3.10.1-16394 }} The ESP_TFC_PADDING_NOT_SUPPORTED notification
717 asserts that the sending endpoint will NOT accept packets that
718 contain Traffic Flow Confidentiality (TFC) padding over the CHILD_SA
719 being negotiated. {{ Clarif-4.5 }} If neither endpoint accepts TFC
720 padding, this notification is included in both the request and the
721 response. If this notification is included in only one of the
722 messages, TFC padding can still be sent in the other direction.
727 Kaufman, et al. Expires August 28, 2008 [Page 13]
729 Internet-Draft IKEv2bis February 2008
732 {{ 3.10.1-16395 }} The NON_FIRST_FRAGMENTS_ALSO notification is used
733 for fragmentation control. See [IPSECARCH] for a fuller explanation.
734 {{ Clarif-4.6 }} Sending non-first fragments is enabled only if
735 NON_FIRST_FRAGMENTS_ALSO notification is included in both the request
736 proposing an SA and the response accepting it. If the peer rejects
737 the proposal of the SA, the peer only omits NON_FIRST_FRAGMENTS_ALSO
738 notification from the response, but does not reject the whole
741 1.3.2. Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange
743 The CREATE_CHILD_SA request for rekeying an IKE_SA is:
746 -------------------------------------------------------------------
747 HDR, SK {SA, Ni, [KEi]} -->
749 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
750 payload, and a Diffie-Hellman value in the KEi payload. The KEi
751 payload SHOULD be included. New initiator and responder SPIs are
752 supplied in the SPI fields.
754 The CREATE_CHILD_SA response for rekeying an IKE_SA is:
756 <-- HDR, SK {SA, Nr,[KEr]}
758 The responder replies (using the same Message ID to respond) with the
759 accepted offer in an SA payload, and a Diffie-Hellman value in the
760 KEr payload if the selected cryptographic suite includes that group.
762 The new IKE_SA has its message counters set to 0, regardless of what
763 they were in the earlier IKE_SA. The window size starts at 1 for any
766 1.3.3. Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange
768 The CREATE_CHILD_SA request for rekeying a CHILD_SA is:
771 -------------------------------------------------------------------
772 HDR, SK {N, SA, Ni, [KEi],
775 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
776 payload, optionally a Diffie-Hellman value in the KEi payload, and
777 the proposed traffic selectors for the proposed CHILD_SA in the TSi
783 Kaufman, et al. Expires August 28, 2008 [Page 14]
785 Internet-Draft IKEv2bis February 2008
788 {{ 3.10.1-16393 }} The REKEY_SA notification MUST be included in a
789 CREATE_CHILD_SA exchange if the purpose of the exchange is to replace
790 an existing ESP or AH SA. {{ Clarif-5.4 }} The SA being rekeyed is
791 identified by the SPI field in the Notify payload; this is the SPI
792 the exchange initiator would expect in inbound ESP or AH packets.
793 There is no data associated with this Notify type.
795 The CREATE_CHILD_SA response for rekeying a CHILD_SA is:
797 <-- HDR, SK {SA, Nr, [KEr],
800 The responder replies (using the same Message ID to respond) with the
801 accepted offer in an SA payload, and a Diffie-Hellman value in the
802 KEr payload if KEi was included in the request and the selected
803 cryptographic suite includes that group.
805 The traffic selectors for traffic to be sent on that SA are specified
806 in the TS payloads in the response, which may be a subset of what the
807 initiator of the CHILD_SA proposed.
809 1.4. The INFORMATIONAL Exchange
811 At various points during the operation of an IKE_SA, peers may desire
812 to convey control messages to each other regarding errors or
813 notifications of certain events. To accomplish this, IKE defines an
814 INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur
815 after the initial exchanges and are cryptographically protected with
818 Control messages that pertain to an IKE_SA MUST be sent under that
819 IKE_SA. Control messages that pertain to CHILD_SAs MUST be sent
820 under the protection of the IKE_SA which generated them (or its
821 successor if the IKE_SA was replaced for the purpose of rekeying).
823 Messages in an INFORMATIONAL exchange contain zero or more
824 Notification, Delete, and Configuration payloads. The Recipient of
825 an INFORMATIONAL exchange request MUST send some response (else the
826 Sender will assume the message was lost in the network and will
827 retransmit it). That response MAY be a message with no payloads.
828 The request message in an INFORMATIONAL exchange MAY also contain no
829 payloads. This is the expected way an endpoint can ask the other
830 endpoint to verify that it is alive.
832 {{ Clarif-5.6 }} ESP and AH SAs always exist in pairs, with one SA in
833 each direction. When an SA is closed, both members of the pair MUST
834 be closed (that is, deleted). Each endpoint MUST close its incoming
835 SAs and allow the other endpoint to close the other SA in each pair.
839 Kaufman, et al. Expires August 28, 2008 [Page 15]
841 Internet-Draft IKEv2bis February 2008
844 To delete an SA, an INFORMATIONAL exchange with one or more delete
845 payloads is sent listing the SPIs (as they would be expected in the
846 headers of inbound packets) of the SAs to be deleted. The recipient
847 MUST close the designated SAs. {{ Clarif-5.7 }} Note that one never
848 sends delete payloads for the two sides of an SA in a single message.
849 If there are many SAs to delete at the same time, one includes delete
850 payloads for in inbound half of each SA pair in your Informational
853 Normally, the reply in the INFORMATIONAL exchange will contain delete
854 payloads for the paired SAs going in the other direction. There is
855 one exception. If by chance both ends of a set of SAs independently
856 decide to close them, each may send a delete payload and the two
857 requests may cross in the network. If a node receives a delete
858 request for SAs for which it has already issued a delete request, it
859 MUST delete the outgoing SAs while processing the request and the
860 incoming SAs while processing the response. In that case, the
861 responses MUST NOT include delete payloads for the deleted SAs, since
862 that would result in duplicate deletion and could in theory delete
865 {{ Demoted the SHOULD }} Half-closed ESP or AH connections are
866 anomalous, and a node with auditing capability should probably audit
867 their existence if they persist. Note that this specification
868 nowhere specifies time periods, so it is up to individual endpoints
869 to decide how long to wait. A node MAY refuse to accept incoming
870 data on half-closed connections but MUST NOT unilaterally close them
871 and reuse the SPIs. If connection state becomes sufficiently messed
872 up, a node MAY close the IKE_SA; doing so will implicitly close all
873 SAs negotiated under it. It can then rebuild the SAs it needs on a
874 clean base under a new IKE_SA. {{ Clarif-5.8 }} The response to a
875 request that deletes the IKE_SA is an empty Informational response.
877 The INFORMATIONAL exchange is defined as:
880 -------------------------------------------------------------------
883 <-- HDR, SK {[N,] [D,]
886 The processing of an INFORMATIONAL exchange is determined by its
895 Kaufman, et al. Expires August 28, 2008 [Page 16]
897 Internet-Draft IKEv2bis February 2008
900 1.5. Informational Messages outside of an IKE_SA
902 If an encrypted IKE request packet arrives on port 500 or 4500 with
903 an unrecognized SPI, it could be because the receiving node has
904 recently crashed and lost state or because of some other system
905 malfunction or attack. If the receiving node has an active IKE_SA to
906 the IP address from whence the packet came, it MAY send a
907 notification of the wayward packet over that IKE_SA in an
908 INFORMATIONAL exchange. If it does not have such an IKE_SA, it MAY
909 send an Informational message without cryptographic protection to the
910 source IP address. Such a message is not part of an informational
911 exchange, and the receiving node MUST NOT respond to it. Doing so
912 could cause a message loop.
914 {{ 3.10.1-11 }} The INVALID_SPI notification MAY be sent in an IKE
915 INFORMATIONAL exchange when a node receives an ESP or AH packet with
916 an invalid SPI. The Notification Data contains the SPI of the
917 invalid packet. This usually indicates a node has rebooted and
918 forgotten an SA. If this Informational Message is sent outside the
919 context of an IKE_SA, it should only be used by the recipient as a
920 "hint" that something might be wrong (because it could easily be
923 {{ Clarif-7.7 }} There are two cases when such a one-way notification
924 is sent: INVALID_IKE_SPI and INVALID_SPI. These notifications are
925 sent outside of an IKE_SA. Note that such notifications are
926 explicitly not Informational exchanges; these are one-way messages
927 that must not be responded to. In case of INVALID_IKE_SPI, the
928 message sent is a response message, and thus it is sent to the IP
929 address and port from whence it came with the same IKE SPIs and the
930 Message ID copied. In case of INVALID_SPI, however, there are no IKE
931 SPI values that would be meaningful to the recipient of such a
932 notification. Using zero values or random values are both
935 1.6. Requirements Terminology
937 Definitions of the primitive terms in this document (such as Security
938 Association or SA) can be found in [IPSECARCH]. {{ Clarif-7.2 }} It
939 should be noted that parts of IKEv2 rely on some of the processing
940 rules in [IPSECARCH], as described in various sections of this
943 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
944 "MAY" that appear in this document are to be interpreted as described
951 Kaufman, et al. Expires August 28, 2008 [Page 17]
953 Internet-Draft IKEv2bis February 2008
956 1.7. Differences Between RFC 4306 and This Document
958 {{ Added this entire section, including this recursive remark. }}
960 This document contains clarifications and amplifications to IKEv2
961 [IKEV2]. The clarifications are mostly based on [Clarif]. The
962 changes listed in that document were discussed in the IPsec Working
963 Group and, after the Working Group was disbanded, on the IPsec
964 mailing list. That document contains detailed explanations of areas
965 that were unclear in IKEv2, and is thus useful to implementers of
968 The protocol described in this document retains the same major
969 version number (2) and minor version number (0) as was used in RFC
972 This document makes the figures and references a bit more regular
975 IKEv2 developers have noted that the SHOULD-level requirements are
976 often unclear in that they don't say when it is OK to not obey the
977 requirements. They also have noted that there are MUST-level
978 requirements that are not related to interoperability. This document
979 has more explanation of some of these requirements. All non-
980 capitalized uses of the words SHOULD and MUST now mean their normal
981 English sense, not the interoperability sense of [MUSTSHOULD].
983 IKEv2 (and IKEv1) developers have noted that there is a great deal of
984 material in the tables of codes in Section 3.10.1. This leads to
985 implementers not having all the needed information in the main body
986 of the docment. Much of the material from those tables has been
987 moved into the associated parts of the main body of the document.
989 In the body of this document, notes that are enclosed in double curly
990 braces {{ such as this }} point out changes from IKEv2. Changes that
991 come from [Clarif] are marked with the section from that document,
992 such as "{{ Clarif-2.10 }}". Changes that come from moving
993 descriptive text out of the tables in Section 3.10.1 are marked with
994 that number and the message type that contained the text, such as "{{
997 This document removes discussion of nesting AH and ESP. This was a
998 mistake in RFC 4306 caused by the lag between finishing RFC 4306 and
999 RFC 4301. Basically, IKEv2 is based on RFC 4301, which does not
1000 include "SA bundles" that were part of RFC 2401. While a single
1001 packet can go through IPsec processing multiple times, each of these
1002 passes uses a separate SA, and the passes are coordinated by the
1003 forwarding tables. In IKEv2, each of these SAs has to be created
1007 Kaufman, et al. Expires August 28, 2008 [Page 18]
1009 Internet-Draft IKEv2bis February 2008
1012 using a separate CREATE_CHILD_SA exchange.
1014 This document removes discussion of the INTERNAL_ADDRESS_EXPIRY
1015 configuration attribute because its implementation was very
1016 problematic. Implementations that conform to this document MUST
1017 ignore proposals that have configuration attribute type 5, the old
1018 value for INTERNAL_ADDRESS_EXPIRY.
1020 This document adds the restriction in Section 2.13 that all PRFs used
1021 with IKEv2 MUST take variable-sized keys. This should not affect any
1022 implementations because there were no standardized PRFs that have
1025 A later version of this document may have all the {{ }} comments
1026 removed from the body of the document and instead appear in an
1030 2. IKE Protocol Details and Variations
1032 IKE normally listens and sends on UDP port 500, though IKE messages
1033 may also be received on UDP port 4500 with a slightly different
1034 format (see Section 2.23). Since UDP is a datagram (unreliable)
1035 protocol, IKE includes in its definition recovery from transmission
1036 errors, including packet loss, packet replay, and packet forgery.
1037 IKE is designed to function so long as (1) at least one of a series
1038 of retransmitted packets reaches its destination before timing out;
1039 and (2) the channel is not so full of forged and replayed packets so
1040 as to exhaust the network or CPU capacities of either endpoint. Even
1041 in the absence of those minimum performance requirements, IKE is
1042 designed to fail cleanly (as though the network were broken).
1044 Although IKEv2 messages are intended to be short, they contain
1045 structures with no hard upper bound on size (in particular, X.509
1046 certificates), and IKEv2 itself does not have a mechanism for
1047 fragmenting large messages. IP defines a mechanism for fragmentation
1048 of oversize UDP messages, but implementations vary in the maximum
1049 message size supported. Furthermore, use of IP fragmentation opens
1050 an implementation to denial of service attacks [DOSUDPPROT].
1051 Finally, some NAT and/or firewall implementations may block IP
1054 All IKEv2 implementations MUST be able to send, receive, and process
1055 IKE messages that are up to 1280 octets long, and they SHOULD be able
1056 to send, receive, and process messages that are up to 3000 octets
1057 long. {{ Demoted the SHOULD }} IKEv2 implementations need to be aware
1058 of the maximum UDP message size supported and MAY shorten messages by
1059 leaving out some certificates or cryptographic suite proposals if
1063 Kaufman, et al. Expires August 28, 2008 [Page 19]
1065 Internet-Draft IKEv2bis February 2008
1068 that will keep messages below the maximum. Use of the "Hash and URL"
1069 formats rather than including certificates in exchanges where
1070 possible can avoid most problems. {{ Demoted the SHOULD }}
1071 Implementations and configuration need to keep in mind, however, that
1072 if the URL lookups are possible only after the IPsec SA is
1073 established, recursion issues could prevent this technique from
1076 {{ Clarif-7.5 }} The UDP payload of all packets containing IKE
1077 messages sent on port 4500 MUST begin with the prefix of four zeros;
1078 otherwise, the receiver won't know how to handle them.
1080 2.1. Use of Retransmission Timers
1082 All messages in IKE exist in pairs: a request and a response. The
1083 setup of an IKE_SA normally consists of two request/response pairs.
1084 Once the IKE_SA is set up, either end of the security association may
1085 initiate requests at any time, and there can be many requests and
1086 responses "in flight" at any given moment. But each message is
1087 labeled as either a request or a response, and for each request/
1088 response pair one end of the security association is the initiator
1089 and the other is the responder.
1091 For every pair of IKE messages, the initiator is responsible for
1092 retransmission in the event of a timeout. The responder MUST never
1093 retransmit a response unless it receives a retransmission of the
1094 request. In that event, the responder MUST ignore the retransmitted
1095 request except insofar as it triggers a retransmission of the
1096 response. The initiator MUST remember each request until it receives
1097 the corresponding response. The responder MUST remember each
1098 response until it receives a request whose sequence number is larger
1099 than or equal to the sequence number in the response plus its window
1100 size (see Section 2.3).
1102 IKE is a reliable protocol, in the sense that the initiator MUST
1103 retransmit a request until either it receives a corresponding reply
1104 OR it deems the IKE security association to have failed and it
1105 discards all state associated with the IKE_SA and any CHILD_SAs
1106 negotiated using that IKE_SA.
1108 {{ Clarif-2.3 }} Retransmissions of the IKE_SA_INIT request require
1109 some special handling. When a responder receives an IKE_SA_INIT
1110 request, it has to determine whether the packet is retransmission
1111 belonging to an existing "half-open" IKE_SA (in which case the
1112 responder retransmits the same response), or a new request (in which
1113 case the responder creates a new IKE_SA and sends a fresh response),
1114 or it belongs to an existing IKE_SA where the IKE_AUTH request has
1115 been already received (in which case the responder ignores it).
1119 Kaufman, et al. Expires August 28, 2008 [Page 20]
1121 Internet-Draft IKEv2bis February 2008
1124 It is not sufficient to use the initiator's SPI and/or IP address to
1125 differentiate between these three cases because two different peers
1126 behind a single NAT could choose the same initiator SPI. Instead, a
1127 robust responder will do the IKE_SA lookup using the whole packet,
1128 its hash, or the Ni payload.
1130 2.2. Use of Sequence Numbers for Message ID
1132 Every IKE message contains a Message ID as part of its fixed header.
1133 This Message ID is used to match up requests and responses, and to
1134 identify retransmissions of messages.
1136 The Message ID is a 32-bit quantity, which is zero for the
1137 IKE_SA_INIT messages (including retries of the message due to
1138 responses such as COOKIE and INVALID_KE_PAYLOAD {{ Clarif-2.2 }}),
1139 and incremented for each subsequent exchange. Thus, the first pair
1140 of IKE_AUTH messages will have ID of 1, the second (when EAP is used)
1141 will be 2, and so on. {{ Clarif-3.10 }}
1143 Each endpoint in the IKE Security Association maintains two "current"
1144 Message IDs: the next one to be used for a request it initiates and
1145 the next one it expects to see in a request from the other end.
1146 These counters increment as requests are generated and received.
1147 Responses always contain the same message ID as the corresponding
1148 request. That means that after the initial exchange, each integer n
1149 may appear as the message ID in four distinct messages: the nth
1150 request from the original IKE initiator, the corresponding response,
1151 the nth request from the original IKE responder, and the
1152 corresponding response. If the two ends make very different numbers
1153 of requests, the Message IDs in the two directions can be very
1154 different. There is no ambiguity in the messages, however, because
1155 the (I)nitiator and (R)esponse bits in the message header specify
1156 which of the four messages a particular one is.
1158 Note that Message IDs are cryptographically protected and provide
1159 protection against message replays. In the unlikely event that
1160 Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be
1161 closed. Rekeying an IKE_SA resets the sequence numbers.
1163 2.3. Window Size for Overlapping Requests
1165 In order to maximize IKE throughput, an IKE endpoint MAY issue
1166 multiple requests before getting a response to any of them if the
1167 other endpoint has indicated its ability to handle such requests.
1168 For simplicity, an IKE implementation MAY choose to process requests
1169 strictly in order and/or wait for a response to one request before
1170 issuing another. Certain rules must be followed to ensure
1171 interoperability between implementations using different strategies.
1175 Kaufman, et al. Expires August 28, 2008 [Page 21]
1177 Internet-Draft IKEv2bis February 2008
1180 After an IKE_SA is set up, either end can initiate one or more
1181 requests. These requests may pass one another over the network. An
1182 IKE endpoint MUST be prepared to accept and process a request while
1183 it has a request outstanding in order to avoid a deadlock in this
1184 situation. {{ Downgraded the SHOULD }} An IKE endpoint may also
1185 accept and process multiple requests while it has a request
1188 {{ 3.10.1-16385 }} The SET_WINDOW_SIZE notification asserts that the
1189 sending endpoint is capable of keeping state for multiple outstanding
1190 exchanges, permitting the recipient to send multiple requests before
1191 getting a response to the first. The data associated with a
1192 SET_WINDOW_SIZE notification MUST be 4 octets long and contain the
1193 big endian representation of the number of messages the sender
1194 promises to keep. The window size is always one until the initial
1197 An IKE endpoint MUST wait for a response to each of its messages
1198 before sending a subsequent message unless it has received a
1199 SET_WINDOW_SIZE Notify message from its peer informing it that the
1200 peer is prepared to maintain state for multiple outstanding messages
1201 in order to allow greater throughput.
1203 An IKE endpoint MUST NOT exceed the peer's stated window size for
1204 transmitted IKE requests. In other words, if the responder stated
1205 its window size is N, then when the initiator needs to make a request
1206 X, it MUST wait until it has received responses to all requests up
1207 through request X-N. An IKE endpoint MUST keep a copy of (or be able
1208 to regenerate exactly) each request it has sent until it receives the
1209 corresponding response. An IKE endpoint MUST keep a copy of (or be
1210 able to regenerate exactly) the number of previous responses equal to
1211 its declared window size in case its response was lost and the
1212 initiator requests its retransmission by retransmitting the request.
1214 An IKE endpoint supporting a window size greater than one ought to be
1215 capable of processing incoming requests out of order to maximize
1216 performance in the event of network failures or packet reordering.
1218 {{ Clarif-7.3 }} The window size is normally a (possibly
1219 configurable) property of a particular implementation, and is not
1220 related to congestion control (unlike the window size in TCP, for
1221 example). In particular, it is not defined what the responder should
1222 do when it receives a SET_WINDOW_SIZE notification containing a
1223 smaller value than is currently in effect. Thus, there is currently
1224 no way to reduce the window size of an existing IKE_SA; you can only
1225 increase it. When rekeying an IKE_SA, the new IKE_SA starts with
1226 window size 1 until it is explicitly increased by sending a new
1227 SET_WINDOW_SIZE notification.
1231 Kaufman, et al. Expires August 28, 2008 [Page 22]
1233 Internet-Draft IKEv2bis February 2008
1236 {{ 3.10.1-9 }}The INVALID_MESSAGE_ID notification is sent when an IKE
1237 message ID outside the supported window is received. This Notify
1238 MUST NOT be sent in a response; the invalid request MUST NOT be
1239 acknowledged. Instead, inform the other side by initiating an
1240 INFORMATIONAL exchange with Notification data containing the four
1241 octet invalid message ID. Sending this notification is optional, and
1242 notifications of this type MUST be rate limited.
1244 2.4. State Synchronization and Connection Timeouts
1246 An IKE endpoint is allowed to forget all of its state associated with
1247 an IKE_SA and the collection of corresponding CHILD_SAs at any time.
1248 This is the anticipated behavior in the event of an endpoint crash
1249 and restart. It is important when an endpoint either fails or
1250 reinitializes its state that the other endpoint detect those
1251 conditions and not continue to waste network bandwidth by sending
1252 packets over discarded SAs and having them fall into a black hole.
1254 {{ 3.10.1-16384 }} The INITIAL_CONTACT notification asserts that this
1255 IKE_SA is the only IKE_SA currently active between the authenticated
1256 identities. It MAY be sent when an IKE_SA is established after a
1257 crash, and the recipient MAY use this information to delete any other
1258 IKE_SAs it has to the same authenticated identity without waiting for
1259 a timeout. This notification MUST NOT be sent by an entity that may
1260 be replicated (e.g., a roaming user's credentials where the user is
1261 allowed to connect to the corporate firewall from two remote systems
1262 at the same time). {{ Clarif-7.9 }} The INITIAL_CONTACT notification,
1263 if sent, MUST be in the first IKE_AUTH request, not as a separate
1264 exchange afterwards; however, receiving parties need to deal with it
1267 Since IKE is designed to operate in spite of Denial of Service (DoS)
1268 attacks from the network, an endpoint MUST NOT conclude that the
1269 other endpoint has failed based on any routing information (e.g.,
1270 ICMP messages) or IKE messages that arrive without cryptographic
1271 protection (e.g., Notify messages complaining about unknown SPIs).
1272 An endpoint MUST conclude that the other endpoint has failed only
1273 when repeated attempts to contact it have gone unanswered for a
1274 timeout period or when a cryptographically protected INITIAL_CONTACT
1275 notification is received on a different IKE_SA to the same
1276 authenticated identity. {{ Demoted the SHOULD }} An endpoint should
1277 suspect that the other endpoint has failed based on routing
1278 information and initiate a request to see whether the other endpoint
1279 is alive. To check whether the other side is alive, IKE specifies an
1280 empty INFORMATIONAL message that (like all IKE requests) requires an
1281 acknowledgement (note that within the context of an IKE_SA, an
1282 "empty" message consists of an IKE header followed by an Encrypted
1283 payload that contains no payloads). If a cryptographically protected
1287 Kaufman, et al. Expires August 28, 2008 [Page 23]
1289 Internet-Draft IKEv2bis February 2008
1292 message has been received from the other side recently, unprotected
1293 notifications MAY be ignored. Implementations MUST limit the rate at
1294 which they take actions based on unprotected messages.
1296 Numbers of retries and lengths of timeouts are not covered in this
1297 specification because they do not affect interoperability. It is
1298 suggested that messages be retransmitted at least a dozen times over
1299 a period of at least several minutes before giving up on an SA, but
1300 different environments may require different rules. To be a good
1301 network citizen, retranmission times MUST increase exponentially to
1302 avoid flooding the network and making an existing congestion
1303 situation worse. If there has only been outgoing traffic on all of
1304 the SAs associated with an IKE_SA, it is essential to confirm
1305 liveness of the other endpoint to avoid black holes. If no
1306 cryptographically protected messages have been received on an IKE_SA
1307 or any of its CHILD_SAs recently, the system needs to perform a
1308 liveness check in order to prevent sending messages to a dead peer.
1309 Receipt of a fresh cryptographically protected message on an IKE_SA
1310 or any of its CHILD_SAs ensures liveness of the IKE_SA and all of its
1311 CHILD_SAs. Note that this places requirements on the failure modes
1312 of an IKE endpoint. An implementation MUST NOT continue sending on
1313 any SA if some failure prevents it from receiving on all of the
1314 associated SAs. If CHILD_SAs can fail independently from one another
1315 without the associated IKE_SA being able to send a delete message,
1316 then they MUST be negotiated by separate IKE_SAs.
1318 There is a Denial of Service attack on the initiator of an IKE_SA
1319 that can be avoided if the initiator takes the proper care. Since
1320 the first two messages of an SA setup are not cryptographically
1321 protected, an attacker could respond to the initiator's message
1322 before the genuine responder and poison the connection setup attempt.
1323 To prevent this, the initiator MAY be willing to accept multiple
1324 responses to its first message, treat each as potentially legitimate,
1325 respond to it, and then discard all the invalid half-open connections
1326 when it receives a valid cryptographically protected response to any
1327 one of its requests. Once a cryptographically valid response is
1328 received, all subsequent responses should be ignored whether or not
1329 they are cryptographically valid.
1331 Note that with these rules, there is no reason to negotiate and agree
1332 upon an SA lifetime. If IKE presumes the partner is dead, based on
1333 repeated lack of acknowledgement to an IKE message, then the IKE SA
1334 and all CHILD_SAs set up through that IKE_SA are deleted.
1336 An IKE endpoint may at any time delete inactive CHILD_SAs to recover
1337 resources used to hold their state. If an IKE endpoint chooses to
1338 delete CHILD_SAs, it MUST send Delete payloads to the other end
1339 notifying it of the deletion. It MAY similarly time out the IKE_SA.
1343 Kaufman, et al. Expires August 28, 2008 [Page 24]
1345 Internet-Draft IKEv2bis February 2008
1348 {{ Clarified the SHOULD }} Closing the IKE_SA implicitly closes all
1349 associated CHILD_SAs. In this case, an IKE endpoint SHOULD send a
1350 Delete payload indicating that it has closed the IKE_SA unless the
1351 other endpoint is no longer responding.
1353 2.5. Version Numbers and Forward Compatibility
1355 This document describes version 2.0 of IKE, meaning the major version
1356 number is 2 and the minor version number is 0. {{ Restated the
1357 relationship to RFC 4306 }} This document is a clarification of
1358 [IKEV2]. It is likely that some implementations will want to support
1359 version 1.0 and version 2.0, and in the future, other versions.
1361 The major version number should be incremented only if the packet
1362 formats or required actions have changed so dramatically that an
1363 older version node would not be able to interoperate with a newer
1364 version node if it simply ignored the fields it did not understand
1365 and took the actions specified in the older specification. The minor
1366 version number indicates new capabilities, and MUST be ignored by a
1367 node with a smaller minor version number, but used for informational
1368 purposes by the node with the larger minor version number. For
1369 example, it might indicate the ability to process a newly defined
1370 notification message. The node with the larger minor version number
1371 would simply note that its correspondent would not be able to
1372 understand that message and therefore would not send it.
1374 {{ 3.10.1-5 }} If an endpoint receives a message with a higher major
1375 version number, it MUST drop the message and SHOULD send an
1376 unauthenticated notification message of type INVALID_MAJOR_VERSION
1377 containing the highest (closest) version number it supports. If an
1378 endpoint supports major version n, and major version m, it MUST
1379 support all versions between n and m. If it receives a message with
1380 a major version that it supports, it MUST respond with that version
1381 number. In order to prevent two nodes from being tricked into
1382 corresponding with a lower major version number than the maximum that
1383 they both support, IKE has a flag that indicates that the node is
1384 capable of speaking a higher major version number.
1386 Thus, the major version number in the IKE header indicates the
1387 version number of the message, not the highest version number that
1388 the transmitter supports. If the initiator is capable of speaking
1389 versions n, n+1, and n+2, and the responder is capable of speaking
1390 versions n and n+1, then they will negotiate speaking n+1, where the
1391 initiator will set a flag indicating its ability to speak a higher
1392 version. If they mistakenly (perhaps through an active attacker
1393 sending error messages) negotiate to version n, then both will notice
1394 that the other side can support a higher version number, and they
1395 MUST break the connection and reconnect using version n+1.
1399 Kaufman, et al. Expires August 28, 2008 [Page 25]
1401 Internet-Draft IKEv2bis February 2008
1404 Note that IKEv1 does not follow these rules, because there is no way
1405 in v1 of noting that you are capable of speaking a higher version
1406 number. So an active attacker can trick two v2-capable nodes into
1407 speaking v1. {{ Demoted the SHOULD }} When a v2-capable node
1408 negotiates down to v1, it should note that fact in its logs.
1410 Also for forward compatibility, all fields marked RESERVED MUST be
1411 set to zero by an implementation running version 2.0, and their
1412 content MUST be ignored by an implementation running version 2.0 ("Be
1413 conservative in what you send and liberal in what you receive"). In
1414 this way, future versions of the protocol can use those fields in a
1415 way that is guaranteed to be ignored by implementations that do not
1416 understand them. Similarly, payload types that are not defined are
1417 reserved for future use; implementations of a version where they are
1418 undefined MUST skip over those payloads and ignore their contents.
1420 IKEv2 adds a "critical" flag to each payload header for further
1421 flexibility for forward compatibility. If the critical flag is set
1422 and the payload type is unrecognized, the message MUST be rejected
1423 and the response to the IKE request containing that payload MUST
1424 include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an
1425 unsupported critical payload was included. {{ 3.10.1-1 }} In that
1426 Notify payload, the notification data contains the one-octet payload
1427 type. If the critical flag is not set and the payload type is
1428 unsupported, that payload MUST be ignored. Payloads sent in IKE
1429 response messages MUST NOT have the critical flag set. Note that the
1430 critical flag applies only to the payload type, not the contents. If
1431 the payload type is recognized, but the payload contains something
1432 which is not (such as an unknown transform inside an SA payload, or
1433 an unknown Notify Message Type inside a Notify payload), the critical
1436 NOTE TO IMPLEMENTERS: Does anyone require that the payloads be in the
1437 order shown in the figures in Section 2? Can we eliminate the
1438 requirement in the following paragraph? If not, we will probably
1439 have to add a new appendix with the order, but there is no reason to
1440 do that if no one actually cares. {{ Remove this paragraph before the
1441 document is finalized, of course. }}
1443 {{ Demoted the SHOULD in the second clause }}Although new payload
1444 types may be added in the future and may appear interleaved with the
1445 fields defined in this specification, implementations MUST send the
1446 payloads defined in this specification in the order shown in the
1447 figures in Section 2; implementations are explicitly allowed to
1448 reject as invalid a message with those payloads in any other order.
1455 Kaufman, et al. Expires August 28, 2008 [Page 26]
1457 Internet-Draft IKEv2bis February 2008
1462 The term "cookies" originates with Karn and Simpson [PHOTURIS] in
1463 Photuris, an early proposal for key management with IPsec, and it has
1464 persisted. The Internet Security Association and Key Management
1465 Protocol (ISAKMP) [ISAKMP] fixed message header includes two eight-
1466 octet fields titled "cookies", and that syntax is used by both IKEv1
1467 and IKEv2, although in IKEv2 they are referred to as the "IKE SPI"
1468 and there is a new separate field in a Notify payload holding the
1469 cookie. The initial two eight-octet fields in the header are used as
1470 a connection identifier at the beginning of IKE packets. {{ Demoted
1471 the SHOULD }} Each endpoint chooses one of the two SPIs and needs to
1472 choose them so as to be unique identifiers of an IKE_SA. An SPI
1473 value of zero is special and indicates that the remote SPI value is
1474 not yet known by the sender.
1476 Unlike ESP and AH where only the recipient's SPI appears in the
1477 header of a message, in IKE the sender's SPI is also sent in every
1478 message. Since the SPI chosen by the original initiator of the
1479 IKE_SA is always sent first, an endpoint with multiple IKE_SAs open
1480 that wants to find the appropriate IKE_SA using the SPI it assigned
1481 must look at the I(nitiator) Flag bit in the header to determine
1482 whether it assigned the first or the second eight octets.
1484 In the first message of an initial IKE exchange, the initiator will
1485 not know the responder's SPI value and will therefore set that field
1488 An expected attack against IKE is state and CPU exhaustion, where the
1489 target is flooded with session initiation requests from forged IP
1490 addresses. This attack can be made less effective if an
1491 implementation of a responder uses minimal CPU and commits no state
1492 to an SA until it knows the initiator can receive packets at the
1493 address from which it claims to be sending them.
1495 When a responder detects a large number of half-open IKE_SAs, it
1496 SHOULD reply to IKE_SA_INIT requests with a response containing the
1497 COOKIE notification. {{ 3.10.1-16390 }} The data associated with this
1498 notification MUST be between 1 and 64 octets in length (inclusive),
1499 and its generation is described later in this section. If the
1500 IKE_SA_INIT response includes the COOKIE notification, the initiator
1501 MUST then retry the IKE_SA_INIT request, and include the COOKIE
1502 notification containing the received data as the first payload, and
1503 all other payloads unchanged. The initial exchange will then be as
1511 Kaufman, et al. Expires August 28, 2008 [Page 27]
1513 Internet-Draft IKEv2bis February 2008
1517 -------------------------------------------------------------------
1518 HDR(A,0), SAi1, KEi, Ni -->
1519 <-- HDR(A,0), N(COOKIE)
1520 HDR(A,0), N(COOKIE), SAi1,
1522 <-- HDR(A,B), SAr1, KEr,
1524 HDR(A,B), SK {IDi, [CERT,]
1525 [CERTREQ,] [IDr,] AUTH,
1527 <-- HDR(A,B), SK {IDr, [CERT,]
1528 AUTH, SAr2, TSi, TSr}
1530 The first two messages do not affect any initiator or responder state
1531 except for communicating the cookie. In particular, the message
1532 sequence numbers in the first four messages will all be zero and the
1533 message sequence numbers in the last two messages will be one. 'A'
1534 is the SPI assigned by the initiator, while 'B' is the SPI assigned
1537 {{ Demoted the SHOULD }} An IKE implementation should implement its
1538 responder cookie generation in such a way as to not require any saved
1539 state to recognize its valid cookie when the second IKE_SA_INIT
1540 message arrives. The exact algorithms and syntax they use to
1541 generate cookies do not affect interoperability and hence are not
1542 specified here. The following is an example of how an endpoint could
1543 use cookies to implement limited DOS protection.
1545 A good way to do this is to set the responder cookie to be:
1547 Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)
1549 where <secret> is a randomly generated secret known only to the
1550 responder and periodically changed and | indicates concatenation.
1551 <VersionIDofSecret> should be changed whenever <secret> is
1552 regenerated. The cookie can be recomputed when the IKE_SA_INIT
1553 arrives the second time and compared to the cookie in the received
1554 message. If it matches, the responder knows that the cookie was
1555 generated since the last change to <secret> and that IPi must be the
1556 same as the source address it saw the first time. Incorporating SPIi
1557 into the calculation ensures that if multiple IKE_SAs are being set
1558 up in parallel they will all get different cookies (assuming the
1559 initiator chooses unique SPIi's). Incorporating Ni into the hash
1560 ensures that an attacker who sees only message 2 can't successfully
1563 If a new value for <secret> is chosen while there are connections in
1567 Kaufman, et al. Expires August 28, 2008 [Page 28]
1569 Internet-Draft IKEv2bis February 2008
1572 the process of being initialized, an IKE_SA_INIT might be returned
1573 with other than the current <VersionIDofSecret>. The responder in
1574 that case MAY reject the message by sending another response with a
1575 new cookie or it MAY keep the old value of <secret> around for a
1576 short time and accept cookies computed from either one. {{ Demoted
1577 the SHOULD NOT }} The responder should not accept cookies
1578 indefinitely after <secret> is changed, since that would defeat part
1579 of the denial of service protection. {{ Demoted the SHOULD }} The
1580 responder should change the value of <secret> frequently, especially
1583 {{ Clarif-2.1 }} In addition to cookies, there are several cases
1584 where the IKE_SA_INIT exchange does not result in the creation of an
1585 IKE_SA (such as INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). In such a
1586 case, sending a zero value for the Responder's SPI is correct. If
1587 the responder sends a non-zero responder SPI, the initiator should
1588 not reject the response for only that reason.
1590 {{ Clarif-2.5 }} When one party receives an IKE_SA_INIT request
1591 containing a cookie whose contents do not match the value expected,
1592 that party MUST ignore the cookie and process the message as if no
1593 cookie had been included; usually this means sending a response
1594 containing a new cookie.
1596 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD
1598 {{ This section added by Clarif-2.4 }}
1600 There are two common reasons why the initiator may have to retry the
1601 IKE_SA_INIT exchange: the responder requests a cookie or wants a
1602 different Diffie-Hellman group than was included in the KEi payload.
1603 If the initiator receives a cookie from the responder, the initiator
1604 needs to decide whether or not to include the cookie in only the next
1605 retry of the IKE_SA_INIT request, or in all subsequent retries as
1608 If the initiator includes the cookie only in the next retry, one
1609 additional roundtrip may be needed in some cases. An additional
1610 roundtrip is needed also if the initiator includes the cookie in all
1611 retries, but the responder does not support this. For instance, if
1612 the responder includes the SAi1 and KEi payloads in cookie
1613 calculation, it will reject the request by sending a new cookie.
1615 If both peers support including the cookie in all retries, a slightly
1616 shorter exchange can happen. Implementations SHOULD support this
1617 shorter exchange, but MUST NOT fail if other implementations do not
1618 support this shorter exchange.
1623 Kaufman, et al. Expires August 28, 2008 [Page 29]
1625 Internet-Draft IKEv2bis February 2008
1628 2.7. Cryptographic Algorithm Negotiation
1630 The payload type known as "SA" indicates a proposal for a set of
1631 choices of IPsec protocols (IKE, ESP, and/or AH) for the SA as well
1632 as cryptographic algorithms associated with each protocol.
1634 An SA payload consists of one or more proposals. {{ Clarif-7.13 }}
1635 Each proposal includes one protocol. Each protocol contains one or
1636 more transforms -- each specifying a cryptographic algorithm. Each
1637 transform contains zero or more attributes (attributes are needed
1638 only if the transform identifier does not completely specify the
1639 cryptographic algorithm).
1641 This hierarchical structure was designed to efficiently encode
1642 proposals for cryptographic suites when the number of supported
1643 suites is large because multiple values are acceptable for multiple
1644 transforms. The responder MUST choose a single suite, which may be
1645 any subset of the SA proposal following the rules below:
1647 {{ Clarif-7.13 }} Each proposal contains one protocol. If a proposal
1648 is accepted, the SA response MUST contain the same protocol. The
1649 responder MUST accept a single proposal or reject them all and return
1650 an error. {{ 3.10.1-14 }} The error is given in a notification of
1651 type NO_PROPOSAL_CHOSEN.
1653 Each IPsec protocol proposal contains one or more transforms. Each
1654 transform contains a transform type. The accepted cryptographic
1655 suite MUST contain exactly one transform of each type included in the
1656 proposal. For example: if an ESP proposal includes transforms
1657 ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256,
1658 AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one
1659 of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six
1660 combinations are acceptable.
1662 Since the initiator sends its Diffie-Hellman value in the
1663 IKE_SA_INIT, it must guess the Diffie-Hellman group that the
1664 responder will select from its list of supported groups. If the
1665 initiator guesses wrong, the responder will respond with a Notify
1666 payload of type INVALID_KE_PAYLOAD indicating the selected group. In
1667 this case, the initiator MUST retry the IKE_SA_INIT with the
1668 corrected Diffie-Hellman group. The initiator MUST again propose its
1669 full set of acceptable cryptographic suites because the rejection
1670 message was unauthenticated and otherwise an active attacker could
1671 trick the endpoints into negotiating a weaker suite than a stronger
1672 one that they both prefer.
1674 {{ Clarif-2.1 }} When the IKE_SA_INIT exchange does not result in the
1675 creation of an IKE_SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN,
1679 Kaufman, et al. Expires August 28, 2008 [Page 30]
1681 Internet-Draft IKEv2bis February 2008
1684 or COOKIE (see Section 2.6), the responder's SPI will be zero.
1685 However, if the responder sends a non-zero responder SPI, the
1686 initiator should not reject the response for only that reason.
1690 {{ Demoted the SHOULD }} IKE, ESP, and AH security associations use
1691 secret keys that should be used only for a limited amount of time and
1692 to protect a limited amount of data. This limits the lifetime of the
1693 entire security association. When the lifetime of a security
1694 association expires, the security association MUST NOT be used. If
1695 there is demand, new security associations MAY be established.
1696 Reestablishment of security associations to take the place of ones
1697 that expire is referred to as "rekeying".
1699 To allow for minimal IPsec implementations, the ability to rekey SAs
1700 without restarting the entire IKE_SA is optional. An implementation
1701 MAY refuse all CREATE_CHILD_SA requests within an IKE_SA. If an SA
1702 has expired or is about to expire and rekeying attempts using the
1703 mechanisms described here fail, an implementation MUST close the
1704 IKE_SA and any associated CHILD_SAs and then MAY start new ones. {{
1705 Demoted the SHOULD }} Implementations may wish to support in-place
1706 rekeying of SAs, since doing so offers better performance and is
1707 likely to reduce the number of packets lost during the transition.
1709 To rekey a CHILD_SA within an existing IKE_SA, create a new,
1710 equivalent SA (see Section 2.17 below), and when the new one is
1711 established, delete the old one. To rekey an IKE_SA, establish a new
1712 equivalent IKE_SA (see Section 2.18 below) with the peer to whom the
1713 old IKE_SA is shared using a CREATE_CHILD_SA within the existing
1714 IKE_SA. An IKE_SA so created inherits all of the original IKE_SA's
1715 CHILD_SAs, and the new IKE_SA is used for all control messages needed
1716 to maintain those CHILD_SAs. The old IKE_SA is then deleted, and the
1717 Delete payload to delete itself MUST be the last request sent over
1720 {{ Demoted the SHOULD }} SAs should be rekeyed proactively, i.e., the
1721 new SA should be established before the old one expires and becomes
1722 unusable. Enough time should elapse between the time the new SA is
1723 established and the old one becomes unusable so that traffic can be
1724 switched over to the new SA.
1726 A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes
1727 were negotiated. In IKEv2, each end of the SA is responsible for
1728 enforcing its own lifetime policy on the SA and rekeying the SA when
1729 necessary. If the two ends have different lifetime policies, the end
1730 with the shorter lifetime will end up always being the one to request
1731 the rekeying. If an SA has been inactive for a long time and if an
1735 Kaufman, et al. Expires August 28, 2008 [Page 31]
1737 Internet-Draft IKEv2bis February 2008
1740 endpoint would not initiate the SA in the absence of traffic, the
1741 endpoint MAY choose to close the SA instead of rekeying it when its
1742 lifetime expires. {{ Demoted the SHOULD }} It should do so if there
1743 has been no traffic since the last time the SA was rekeyed.
1745 Note that IKEv2 deliberately allows parallel SAs with the same
1746 traffic selectors between common endpoints. One of the purposes of
1747 this is to support traffic quality of service (QoS) differences among
1748 the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and section 4.1 of
1749 [DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints
1750 and the traffic selectors may not uniquely identify an SA between
1751 those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on
1752 the basis of duplicate traffic selectors SHOULD NOT be used.
1754 {{ Demoted the SHOULD }} The node that initiated the surviving
1755 rekeyed SA should delete the replaced SA after the new one is
1758 There are timing windows -- particularly in the presence of lost
1759 packets -- where endpoints may not agree on the state of an SA. The
1760 responder to a CREATE_CHILD_SA MUST be prepared to accept messages on
1761 an SA before sending its response to the creation request, so there
1762 is no ambiguity for the initiator. The initiator MAY begin sending
1763 on an SA as soon as it processes the response. The initiator,
1764 however, cannot receive on a newly created SA until it receives and
1765 processes the response to its CREATE_CHILD_SA request. How, then, is
1766 the responder to know when it is OK to send on the newly created SA?
1768 From a technical correctness and interoperability perspective, the
1769 responder MAY begin sending on an SA as soon as it sends its response
1770 to the CREATE_CHILD_SA request. In some situations, however, this
1771 could result in packets unnecessarily being dropped, so an
1772 implementation MAY defer such sending.
1774 The responder can be assured that the initiator is prepared to
1775 receive messages on an SA if either (1) it has received a
1776 cryptographically valid message on the new SA, or (2) the new SA
1777 rekeys an existing SA and it receives an IKE request to close the
1778 replaced SA. When rekeying an SA, the responder continues to send
1779 traffic on the old SA until one of those events occurs. When
1780 establishing a new SA, the responder MAY defer sending messages on a
1781 new SA until either it receives one or a timeout has occurred. {{
1782 Demoted the SHOULD }} If an initiator receives a message on an SA for
1783 which it has not received a response to its CREATE_CHILD_SA request,
1784 it interprets that as a likely packet loss and retransmits the
1785 CREATE_CHILD_SA request. An initiator MAY send a dummy message on a
1786 newly created SA if it has no messages queued in order to assure the
1787 responder that the initiator is ready to receive messages.
1791 Kaufman, et al. Expires August 28, 2008 [Page 32]
1793 Internet-Draft IKEv2bis February 2008
1796 {{ Clarif-5.9 }} Throughout this document, "initiator" refers to the
1797 party who initiated the exchange being described, and "original
1798 initiator" refers to the party who initiated the whole IKE_SA. The
1799 "original initiator" always refers to the party who initiated the
1800 exchange which resulted in the current IKE_SA. In other words, if
1801 the "original responder" starts rekeying the IKE_SA, that party
1802 becomes the "original initiator" of the new IKE_SA.
1804 2.8.1. Simultaneous CHILD_SA rekeying
1806 {{ The first two paragraphs were moved, and the rest was added, based
1809 If the two ends have the same lifetime policies, it is possible that
1810 both will initiate a rekeying at the same time (which will result in
1811 redundant SAs). To reduce the probability of this happening, the
1812 timing of rekeying requests SHOULD be jittered (delayed by a random
1813 amount of time after the need for rekeying is noticed).
1815 This form of rekeying may temporarily result in multiple similar SAs
1816 between the same pairs of nodes. When there are two SAs eligible to
1817 receive packets, a node MUST accept incoming packets through either
1818 SA. If redundant SAs are created though such a collision, the SA
1819 created with the lowest of the four nonces used in the two exchanges
1820 SHOULD be closed by the endpoint that created it. {{ Clarif-5.10 }}
1821 "Lowest" means an octet-by-octet, lexicographical comparison (instead
1822 of, for instance, comparing the nonces as large integers). In other
1823 words, start by comparing the first octet; if they're equal, move to
1824 the next octet, and so on. If you reach the end of one nonce, that
1825 nonce is the lower one.
1827 The following is an explanation on the impact this has on
1828 implementations. Assume that hosts A and B have an existing IPsec SA
1829 pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same
1833 -------------------------------------------------------------------
1834 send req1: N(REKEY_SA,SPIa1),
1835 SA(..,SPIa2,..),Ni1,.. -->
1836 <-- send req2: N(REKEY_SA,SPIb1),
1840 At this point, A knows there is a simultaneous rekeying going on.
1841 However, it cannot yet know which of the exchanges will have the
1842 lowest nonce, so it will just note the situation and respond as
1847 Kaufman, et al. Expires August 28, 2008 [Page 33]
1849 Internet-Draft IKEv2bis February 2008
1852 send resp2: SA(..,SPIa3,..),
1856 Now B also knows that simultaneous rekeying is going on. It responds
1859 <-- send resp1: SA(..,SPIb3,..),
1864 At this point, there are three CHILD_SA pairs between A and B (the
1865 old one and two new ones). A and B can now compare the nonces.
1866 Suppose that the lowest nonce was Nr1 in message resp2; in this case,
1867 B (the sender of req2) deletes the redundant new SA, and A (the node
1868 that initiated the surviving rekeyed SA), deletes the old one.
1870 send req3: D(SPIa1) -->
1871 <-- send req4: D(SPIb2)
1873 <-- send resp3: D(SPIb1)
1875 send resp4: D(SPIa3) -->
1877 The rekeying is now finished.
1879 However, there is a second possible sequence of events that can
1880 happen if some packets are lost in the network, resulting in
1881 retransmissions. The rekeying begins as usual, but A's first packet
1885 -------------------------------------------------------------------
1886 send req1: N(REKEY_SA,SPIa1),
1889 <-- send req2: N(REKEY_SA,SPIb1),
1892 send resp2: SA(..,SPIa3,..),
1895 <-- send req3: D(SPIb1)
1897 send resp3: D(SPIa1) -->
1903 Kaufman, et al. Expires August 28, 2008 [Page 34]
1905 Internet-Draft IKEv2bis February 2008
1908 From B's point of view, the rekeying is now completed, and since it
1909 has not yet received A's req1, it does not even know that there was
1910 simultaneous rekeying. However, A will continue retransmitting the
1911 message, and eventually it will reach B.
1916 To B, it looks like A is trying to rekey an SA that no longer exists;
1917 thus, B responds to the request with something non-fatal such as
1920 <-- send resp1: N(NO_PROPOSAL_CHOSEN)
1923 When A receives this error, it already knows there was simultaneous
1924 rekeying, so it can ignore the error message.
1926 2.8.2. Rekeying the IKE_SA Versus Reauthentication
1928 {{ Added this section from Clarif-5.2 }}
1930 Rekeying the IKE_SA and reauthentication are different concepts in
1931 IKEv2. Rekeying the IKE_SA establishes new keys for the IKE_SA and
1932 resets the Message ID counters, but it does not authenticate the
1933 parties again (no AUTH or EAP payloads are involved).
1935 Although rekeying the IKE_SA may be important in some environments,
1936 reauthentication (the verification that the parties still have access
1937 to the long-term credentials) is often more important.
1939 IKEv2 does not have any special support for reauthentication.
1940 Reauthentication is done by creating a new IKE_SA from scratch (using
1941 IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify
1942 payloads), creating new CHILD_SAs within the new IKE_SA (without
1943 REKEY_SA notify payloads), and finally deleting the old IKE_SA (which
1944 deletes the old CHILD_SAs as well).
1946 This means that reauthentication also establishes new keys for the
1947 IKE_SA and CHILD_SAs. Therefore, while rekeying can be performed
1948 more often than reauthentication, the situation where "authentication
1949 lifetime" is shorter than "key lifetime" does not make sense.
1951 While creation of a new IKE_SA can be initiated by either party
1952 (initiator or responder in the original IKE_SA), the use of EAP
1953 authentication and/or configuration payloads means in practice that
1954 reauthentication has to be initiated by the same party as the
1955 original IKE_SA. IKEv2 does not currently allow the responder to
1959 Kaufman, et al. Expires August 28, 2008 [Page 35]
1961 Internet-Draft IKEv2bis February 2008
1964 request reauthentication in this case; however, there are extensions
1965 that add this functionality such as [REAUTH].
1967 2.9. Traffic Selector Negotiation
1969 {{ Clarif-7.2 }} When an RFC4301-compliant IPsec subsystem receives
1970 an IP packet and matches a "protect" selector in its Security Policy
1971 Database (SPD), the subsystem protects that packet with IPsec. When
1972 no SA exists yet, it is the task of IKE to create it. Maintenance of
1973 a system's SPD is outside the scope of IKE (see [PFKEY] for an
1974 example protocol), though some implementations might update their SPD
1975 in connection with the running of IKE (for an example scenario, see
1978 Traffic Selector (TS) payloads allow endpoints to communicate some of
1979 the information from their SPD to their peers. TS payloads specify
1980 the selection criteria for packets that will be forwarded over the
1981 newly set up SA. This can serve as a consistency check in some
1982 scenarios to assure that the SPDs are consistent. In others, it
1983 guides the dynamic update of the SPD.
1985 Two TS payloads appear in each of the messages in the exchange that
1986 creates a CHILD_SA pair. Each TS payload contains one or more
1987 Traffic Selectors. Each Traffic Selector consists of an address
1988 range (IPv4 or IPv6), a port range, and an IP protocol ID.
1990 The first of the two TS payloads is known as TSi (Traffic Selector-
1991 initiator). The second is known as TSr (Traffic Selector-responder).
1992 TSi specifies the source address of traffic forwarded from (or the
1993 destination address of traffic forwarded to) the initiator of the
1994 CHILD_SA pair. TSr specifies the destination address of the traffic
1995 forwarded to (or the source address of the traffic forwarded from)
1996 the responder of the CHILD_SA pair. For example, if the original
1997 initiator requests the creation of a CHILD_SA pair, and wishes to
1998 tunnel all traffic from subnet 192.0.1.* on the initiator's side to
1999 subnet 192.0.2.* on the responder's side, the initiator would include
2000 a single traffic selector in each TS payload. TSi would specify the
2001 address range (192.0.1.0 - 192.0.1.255) and TSr would specify the
2002 address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was
2003 acceptable to the responder, it would send identical TS payloads
2004 back. (Note: The IP address range 192.0.2.* has been reserved for
2005 use in examples in RFCs and similar documents. This document needed
2006 two such ranges, and so also used 192.0.1.*. This should not be
2007 confused with any actual address.)
2009 IKEv2 allows the responder to choose a subset of the traffic proposed
2010 by the initiator. This could happen when the configurations of the
2011 two endpoints are being updated but only one end has received the new
2015 Kaufman, et al. Expires August 28, 2008 [Page 36]
2017 Internet-Draft IKEv2bis February 2008
2020 information. Since the two endpoints may be configured by different
2021 people, the incompatibility may persist for an extended period even
2022 in the absence of errors. It also allows for intentionally different
2023 configurations, as when one end is configured to tunnel all addresses
2024 and depends on the other end to have the up-to-date list.
2026 When the responder chooses a subset of the traffic proposed by the
2027 initiator, it narrows the traffic selectors to some subset of the
2028 initiator's proposal (provided the set does not become the null set).
2030 To enable the responder to choose the appropriate range in this case,
2031 if the initiator has requested the SA due to a data packet, the
2032 initiator SHOULD include as the first traffic selector in each of TSi
2033 and TSr a very specific traffic selector including the addresses in
2034 the packet triggering the request. In the example, the initiator
2035 would include in TSi two traffic selectors: the first containing the
2036 address range (192.0.1.43 - 192.0.1.43) and the source port and IP
2037 protocol from the packet and the second containing (192.0.1.0 -
2038 192.0.1.255) with all ports and IP protocols. The initiator would
2039 similarly include two traffic selectors in TSr. If the initiator
2040 creates the CHILD_SA pair not in response to an arriving packet, but
2041 rather, say, upon startup, then there may be no specific addresses
2042 the initiator prefers for the initial tunnel over any other. In that
2043 case, the first values in TSi and TSr can be ranges rather than
2046 The responder performs the narrowing as follows: {{ Clarif-4.10 }}
2048 o If the responder's policy does not allow it to accept any part of
2049 the proposed traffic selectors, it responds with TS_UNACCEPTABLE.
2051 o If the responder's policy allows the entire set of traffic covered
2052 by TSi and TSr, no narrowing is necessary, and the responder can
2053 return the same TSi and TSr values.
2055 o If the responder's policy allows it to accept the first selector
2056 of TSi and TSr, then the responder MUST narrow the traffic
2057 selectors to a subset that includes the initiator's first choices.
2058 In this example above, the responder might respond with TSi being
2059 (192.0.1.43 - 192.0.1.43) with all ports and IP protocols.
2061 o If the responder's policy does not allow it to accept the first
2062 selector of TSi and TSr, the responder narrows to an acceptable
2063 subset of TSi and TSr.
2065 When narrowing is done, there may be several subsets that are
2066 acceptable but their union is not. In this case, the responder
2067 arbitrarily chooses one of them, and MAY include an
2071 Kaufman, et al. Expires August 28, 2008 [Page 37]
2073 Internet-Draft IKEv2bis February 2008
2076 ADDITIONAL_TS_POSSIBLE notification in the response. {{ 3.10.1-16386
2077 }} The ADDITIONAL_TS_POSSIBLE notification asserts that the responder
2078 narrowed the proposed traffic selectors but that other traffic
2079 selectors would also have been acceptable, though only in a separate
2080 SA. There is no data associated with this Notify type. This case
2081 will occur only when the initiator and responder are configured
2082 differently from one another. If the initiator and responder agree
2083 on the granularity of tunnels, the initiator will never request a
2084 tunnel wider than the responder will accept. {{ Demoted the SHOULD }}
2085 Such misconfigurations should be recorded in error logs.
2087 It is possible for the responder's policy to contain multiple smaller
2088 ranges, all encompassed by the initiator's traffic selector, and with
2089 the responder's policy being that each of those ranges should be sent
2090 over a different SA. Continuing the example above, the responder
2091 might have a policy of being willing to tunnel those addresses to and
2092 from the initiator, but might require that each address pair be on a
2093 separately negotiated CHILD_SA. If the initiator generated its
2094 request in response to an incoming packet from 192.0.1.43 to
2095 192.0.2.123, there would be no way for the responder to determine
2096 which pair of addresses should be included in this tunnel, and it
2097 would have to make a guess or reject the request with a status of
2098 SINGLE_PAIR_REQUIRED.
2100 {{ 3.10.1-34 }} The SINGLE_PAIR_REQUIRED error indicates that a
2101 CREATE_CHILD_SA request is unacceptable because its sender is only
2102 willing to accept traffic selectors specifying a single pair of
2103 addresses. The requestor is expected to respond by requesting an SA
2104 for only the specific traffic it is trying to forward.
2106 {{ Clarif-4.11 }} Few implementations will have policies that require
2107 separate SAs for each address pair. Because of this, if only some
2108 parts of the TSi and TSr proposed by the initiator are acceptable to
2109 the responder, responders SHOULD narrow the selectors to an
2110 acceptable subset rather than use SINGLE_PAIR_REQUIRED.
2112 2.9.1. Traffic Selectors Violating Own Policy
2116 When creating a new SA, the initiator needs to avoid proposing
2117 traffic selectors that violate its own policy. If this rule is not
2118 followed, valid traffic may be dropped.
2120 This is best illustrated by an example. Suppose that host A has a
2121 policy whose effect is that traffic to 192.0.1.66 is sent via host B
2122 encrypted using AES, and traffic to all other hosts in 192.0.1.0/24
2123 is also sent via B, but must use 3DES. Suppose also that host B
2127 Kaufman, et al. Expires August 28, 2008 [Page 38]
2129 Internet-Draft IKEv2bis February 2008
2132 accepts any combination of AES and 3DES.
2134 If host A now proposes an SA that uses 3DES, and includes TSr
2135 containing (192.0.1.0-192.0.1.255), this will be accepted by host B.
2136 Now, host B can also use this SA to send traffic from 192.0.1.66, but
2137 those packets will be dropped by A since it requires the use of AES
2138 for those traffic. Even if host A creates a new SA only for
2139 192.0.1.66 that uses AES, host B may freely continue to use the first
2140 SA for the traffic. In this situation, when proposing the SA, host A
2141 should have followed its own policy, and included a TSr containing
2142 ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead.
2144 In general, if (1) the initiator makes a proposal "for traffic X
2145 (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator
2146 does not actually accept traffic X' with SA, and (3) the initiator
2147 would be willing to accept traffic X' with some SA' (!=SA), valid
2148 traffic can be unnecessarily dropped since the responder can apply
2149 either SA or SA' to traffic X'.
2153 The IKE_SA_INIT messages each contain a nonce. These nonces are used
2154 as inputs to cryptographic functions. The CREATE_CHILD_SA request
2155 and the CREATE_CHILD_SA response also contain nonces. These nonces
2156 are used to add freshness to the key derivation technique used to
2157 obtain keys for CHILD_SA, and to ensure creation of strong pseudo-
2158 random bits from the Diffie-Hellman key. Nonces used in IKEv2 MUST
2159 be randomly chosen, MUST be at least 128 bits in size, and MUST be at
2160 least half the key size of the negotiated prf. ("prf" refers to
2161 "pseudo-random function", one of the cryptographic algorithms
2162 negotiated in the IKE exchange.) {{ Clarif-7.4 }} However, the
2163 initiator chooses the nonce before the outcome of the negotiation is
2164 known. Because of that, the nonce has to be long enough for all the
2165 PRFs being proposed. If the same random number source is used for
2166 both keys and nonces, care must be taken to ensure that the latter
2167 use does not compromise the former.
2169 2.11. Address and Port Agility
2171 IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and
2172 AH associations for the same IP addresses it runs over. The IP
2173 addresses and ports in the outer header are, however, not themselves
2174 cryptographically protected, and IKE is designed to work even through
2175 Network Address Translation (NAT) boxes. An implementation MUST
2176 accept incoming requests even if the source port is not 500 or 4500,
2177 and MUST respond to the address and port from which the request was
2178 received. It MUST specify the address and port at which the request
2179 was received as the source address and port in the response. IKE
2183 Kaufman, et al. Expires August 28, 2008 [Page 39]
2185 Internet-Draft IKEv2bis February 2008
2188 functions identically over IPv4 or IPv6.
2190 2.12. Reuse of Diffie-Hellman Exponentials
2192 IKE generates keying material using an ephemeral Diffie-Hellman
2193 exchange in order to gain the property of "perfect forward secrecy".
2194 This means that once a connection is closed and its corresponding
2195 keys are forgotten, even someone who has recorded all of the data
2196 from the connection and gets access to all of the long-term keys of
2197 the two endpoints cannot reconstruct the keys used to protect the
2198 conversation without doing a brute force search of the session key
2201 Achieving perfect forward secrecy requires that when a connection is
2202 closed, each endpoint MUST forget not only the keys used by the
2203 connection but also any information that could be used to recompute
2204 those keys. In particular, it MUST forget the secrets used in the
2205 Diffie-Hellman calculation and any state that may persist in the
2206 state of a pseudo-random number generator that could be used to
2207 recompute the Diffie-Hellman secrets.
2209 Since the computing of Diffie-Hellman exponentials is computationally
2210 expensive, an endpoint may find it advantageous to reuse those
2211 exponentials for multiple connection setups. There are several
2212 reasonable strategies for doing this. An endpoint could choose a new
2213 exponential only periodically though this could result in less-than-
2214 perfect forward secrecy if some connection lasts for less than the
2215 lifetime of the exponential. Or it could keep track of which
2216 exponential was used for each connection and delete the information
2217 associated with the exponential only when some corresponding
2218 connection was closed. This would allow the exponential to be reused
2219 without losing perfect forward secrecy at the cost of maintaining
2222 Decisions as to whether and when to reuse Diffie-Hellman exponentials
2223 is a private decision in the sense that it will not affect
2224 interoperability. An implementation that reuses exponentials MAY
2225 choose to remember the exponential used by the other endpoint on past
2226 exchanges and if one is reused to avoid the second half of the
2229 2.13. Generating Keying Material
2231 In the context of the IKE_SA, four cryptographic algorithms are
2232 negotiated: an encryption algorithm, an integrity protection
2233 algorithm, a Diffie-Hellman group, and a pseudo-random function
2234 (prf). The pseudo-random function is used for the construction of
2235 keying material for all of the cryptographic algorithms used in both
2239 Kaufman, et al. Expires August 28, 2008 [Page 40]
2241 Internet-Draft IKEv2bis February 2008
2244 the IKE_SA and the CHILD_SAs.
2246 We assume that each encryption algorithm and integrity protection
2247 algorithm uses a fixed-size key and that any randomly chosen value of
2248 that fixed size can serve as an appropriate key. For algorithms that
2249 accept a variable length key, a fixed key size MUST be specified as
2250 part of the cryptographic transform negotiated (see Section 3.3.5 for
2251 the defintion of the Key Length transform attribute). For algorithms
2252 for which not all values are valid keys (such as DES or 3DES with key
2253 parity), the algorithm by which keys are derived from arbitrary
2254 values MUST be specified by the cryptographic transform. For
2255 integrity protection functions based on Hashed Message Authentication
2256 Code (HMAC), the fixed key size is the size of the output of the
2257 underlying hash function.
2259 It is assumed that pseudo-random functions (PRFs) accept keys of any
2260 length, but have a preferred key size. The preferred key size is
2261 used as the length of SK_d, SK_pi, and SK_pr (see Section 2.14). For
2262 PRFs based on the HMAC construction, the preferred key size is equal
2263 to the length of the output of the underlying hash function. Other
2264 types of PRFs MUST specify their preferred key size.
2266 Keying material will always be derived as the output of the
2267 negotiated prf algorithm. Since the amount of keying material needed
2268 may be greater than the size of the output of the prf algorithm, we
2269 will use the prf iteratively. We will use the terminology prf+ to
2270 describe the function that outputs a pseudo-random stream based on
2271 the inputs to a prf as follows: (where | indicates concatenation)
2273 prf+ (K,S) = T1 | T2 | T3 | T4 | ...
2276 T1 = prf (K, S | 0x01)
2277 T2 = prf (K, T1 | S | 0x02)
2278 T3 = prf (K, T2 | S | 0x03)
2279 T4 = prf (K, T3 | S | 0x04)
2281 continuing as needed to compute all required keys. The keys are
2282 taken from the output string without regard to boundaries (e.g., if
2283 the required keys are a 256-bit Advanced Encryption Standard (AES)
2284 key and a 160-bit HMAC key, and the prf function generates 160 bits,
2285 the AES key will come from T1 and the beginning of T2, while the HMAC
2286 key will come from the rest of T2 and the beginning of T3).
2288 The constant concatenated to the end of each string feeding the prf
2289 is a single octet. prf+ in this document is not defined beyond 255
2290 times the size of the prf output.
2295 Kaufman, et al. Expires August 28, 2008 [Page 41]
2297 Internet-Draft IKEv2bis February 2008
2300 2.14. Generating Keying Material for the IKE_SA
2302 The shared keys are computed as follows. A quantity called SKEYSEED
2303 is calculated from the nonces exchanged during the IKE_SA_INIT
2304 exchange and the Diffie-Hellman shared secret established during that
2305 exchange. SKEYSEED is used to calculate seven other secrets: SK_d
2306 used for deriving new keys for the CHILD_SAs established with this
2307 IKE_SA; SK_ai and SK_ar used as a key to the integrity protection
2308 algorithm for authenticating the component messages of subsequent
2309 exchanges; SK_ei and SK_er used for encrypting (and of course
2310 decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are
2311 used when generating an AUTH payload. The lengths of SK_d, SK_pi,
2312 and SK_pr are the preferred key length of the agreed-to PRF.
2314 SKEYSEED and its derivatives are computed as follows:
2316 SKEYSEED = prf(Ni | Nr, g^ir)
2318 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr }
2319 = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )
2321 (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er,
2322 SK_pi, and SK_pr are taken in order from the generated bits of the
2323 prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman
2324 exchange. g^ir is represented as a string of octets in big endian
2325 order padded with zeros if necessary to make it the length of the
2326 modulus. Ni and Nr are the nonces, stripped of any headers. For
2327 historical backwards-compatibility reasons, there are two PRFs that
2328 are treated specially in this calculation. If the negotiated PRF is
2329 AES-XCBC-PRF-128 [RFC4434] or AES-CMAC-PRF-128 [RFC4615], only the
2330 first 64 bits of Ni and the first 64 bits of Nr are used in the
2333 The two directions of traffic flow use different keys. The keys used
2334 to protect messages from the original initiator are SK_ai and SK_ei.
2335 The keys used to protect messages in the other direction are SK_ar
2338 2.15. Authentication of the IKE_SA
2340 When not using extensible authentication (see Section 2.16), the
2341 peers are authenticated by having each sign (or MAC using a shared
2342 secret as the key) a block of data. For the responder, the octets to
2343 be signed start with the first octet of the first SPI in the header
2344 of the second message (IKE_SA_INIT response) and end with the last
2345 octet of the last payload in the second message. Appended to this
2346 (for purposes of computing the signature) are the initiator's nonce
2347 Ni (just the value, not the payload containing it), and the value
2351 Kaufman, et al. Expires August 28, 2008 [Page 42]
2353 Internet-Draft IKEv2bis February 2008
2356 prf(SK_pr,IDr') where IDr' is the responder's ID payload excluding
2357 the fixed header. Note that neither the nonce Ni nor the value
2358 prf(SK_pr,IDr') are transmitted. Similarly, the initiator signs the
2359 first message (IKE_SA_INIT request), starting with the first octet of
2360 the first SPI in the header and ending with the last octet of the
2361 last payload. Appended to this (for purposes of computing the
2362 signature) are the responder's nonce Nr, and the value
2363 prf(SK_pi,IDi'). In the above calculation, IDi' and IDr' are the
2364 entire ID payloads excluding the fixed header. It is critical to the
2365 security of the exchange that each side sign the other side's nonce.
2369 The initiator's signed octets can be described as:
2371 InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
2372 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
2373 RealIKEHDR = SPIi | SPIr | . . . | Length
2374 RealMessage1 = RealIKEHDR | RestOfMessage1
2375 NonceRPayload = PayloadHeader | NonceRData
2376 InitiatorIDPayload = PayloadHeader | RestOfIDPayload
2377 RestOfInitIDPayload = IDType | RESERVED | InitIDData
2378 MACedIDForI = prf(SK_pi, RestOfInitIDPayload)
2380 The responder's signed octets can be described as:
2382 ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
2383 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
2384 RealIKEHDR = SPIi | SPIr | . . . | Length
2385 RealMessage2 = RealIKEHDR | RestOfMessage2
2386 NonceIPayload = PayloadHeader | NonceIData
2387 ResponderIDPayload = PayloadHeader | RestOfIDPayload
2388 RestOfRespIDPayload = IDType | RESERVED | InitIDData
2389 MACedIDForR = prf(SK_pr, RestOfRespIDPayload)
2391 Note that all of the payloads are included under the signature,
2392 including any payload types not defined in this document. If the
2393 first message of the exchange is sent twice (the second time with a
2394 responder cookie and/or a different Diffie-Hellman group), it is the
2395 second version of the message that is signed.
2397 Optionally, messages 3 and 4 MAY include a certificate, or
2398 certificate chain providing evidence that the key used to compute a
2399 digital signature belongs to the name in the ID payload. The
2400 signature or MAC will be computed using algorithms dictated by the
2401 type of key used by the signer, and specified by the Auth Method
2402 field in the Authentication payload. There is no requirement that
2403 the initiator and responder sign with the same cryptographic
2407 Kaufman, et al. Expires August 28, 2008 [Page 43]
2409 Internet-Draft IKEv2bis February 2008
2412 algorithms. The choice of cryptographic algorithms depends on the
2413 type of key each has. In particular, the initiator may be using a
2414 shared key while the responder may have a public signature key and
2415 certificate. It will commonly be the case (but it is not required)
2416 that if a shared secret is used for authentication that the same key
2417 is used in both directions.
2419 Note that it is a common but typically insecure practice to have a
2420 shared key derived solely from a user-chosen password without
2421 incorporating another source of randomness. This is typically
2422 insecure because user-chosen passwords are unlikely to have
2423 sufficient unpredictability to resist dictionary attacks and these
2424 attacks are not prevented in this authentication method.
2425 (Applications using password-based authentication for bootstrapping
2426 and IKE_SA should use the authentication method in Section 2.16,
2427 which is designed to prevent off-line dictionary attacks.) {{ Demoted
2428 the SHOULD }} The pre-shared key needs to contain as much
2429 unpredictability as the strongest key being negotiated. In the case
2430 of a pre-shared key, the AUTH value is computed as:
2432 AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), <msg octets>)
2434 where the string "Key Pad for IKEv2" is 17 ASCII characters without
2435 null termination. The shared secret can be variable length. The pad
2436 string is added so that if the shared secret is derived from a
2437 password, the IKE implementation need not store the password in
2438 cleartext, but rather can store the value prf(Shared Secret,"Key Pad
2439 for IKEv2"), which could not be used as a password equivalent for
2440 protocols other than IKEv2. As noted above, deriving the shared
2441 secret from a password is not secure. This construction is used
2442 because it is anticipated that people will do it anyway. The
2443 management interface by which the Shared Secret is provided MUST
2444 accept ASCII strings of at least 64 octets and MUST NOT add a null
2445 terminator before using them as shared secrets. It MUST also accept
2446 a hex encoding of the Shared Secret. The management interface MAY
2447 accept other encodings if the algorithm for translating the encoding
2448 to a binary string is specified.
2450 2.16. Extensible Authentication Protocol Methods
2452 In addition to authentication using public key signatures and shared
2453 secrets, IKE supports authentication using methods defined in RFC
2454 3748 [EAP]. Typically, these methods are asymmetric (designed for a
2455 user authenticating to a server), and they may not be mutual. {{ In
2456 the next sentence, changed "public key signature based" to "strong"
2457 }} For this reason, these protocols are typically used to
2458 authenticate the initiator to the responder and MUST be used in
2459 conjunction with a strong authentication of the responder to the
2463 Kaufman, et al. Expires August 28, 2008 [Page 44]
2465 Internet-Draft IKEv2bis February 2008
2468 initiator. These methods are often associated with mechanisms
2469 referred to as "Legacy Authentication" mechanisms.
2471 While this memo references [EAP] with the intent that new methods can
2472 be added in the future without updating this specification, some
2473 simpler variations are documented here and in Section 3.16. [EAP]
2474 defines an authentication protocol requiring a variable number of
2475 messages. Extensible Authentication is implemented in IKE as
2476 additional IKE_AUTH exchanges that MUST be completed in order to
2477 initialize the IKE_SA.
2479 An initiator indicates a desire to use extensible authentication by
2480 leaving out the AUTH payload from message 3. By including an IDi
2481 payload but not an AUTH payload, the initiator has declared an
2482 identity but has not proven it. If the responder is willing to use
2483 an extensible authentication method, it will place an Extensible
2484 Authentication Protocol (EAP) payload in message 4 and defer sending
2485 SAr2, TSi, and TSr until initiator authentication is complete in a
2486 subsequent IKE_AUTH exchange. In the case of a minimal extensible
2487 authentication, the initial SA establishment will appear as follows:
2490 -------------------------------------------------------------------
2491 HDR, SAi1, KEi, Ni -->
2492 <-- HDR, SAr1, KEr, Nr, [CERTREQ]
2493 HDR, SK {IDi, [CERTREQ,]
2496 <-- HDR, SK {IDr, [CERT,] AUTH,
2499 <-- HDR, SK {EAP (success)}
2501 <-- HDR, SK {AUTH, SAr2, TSi, TSr }
2503 {{ Clarif-3.10 }} As described in Section 2.2, when EAP is used, each
2504 pair of IKE_SA initial setup messages will have their message numbers
2505 incremented; the first pair of AUTH messages will have an ID of 1,
2506 the second will be 2, and so on.
2508 For EAP methods that create a shared key as a side effect of
2509 authentication, that shared key MUST be used by both the initiator
2510 and responder to generate AUTH payloads in messages 7 and 8 using the
2511 syntax for shared secrets specified in Section 2.15. The shared key
2512 from EAP is the field from the EAP specification named MSK. The
2513 shared key generated during an IKE exchange MUST NOT be used for any
2519 Kaufman, et al. Expires August 28, 2008 [Page 45]
2521 Internet-Draft IKEv2bis February 2008
2524 EAP methods that do not establish a shared key SHOULD NOT be used, as
2525 they are subject to a number of man-in-the-middle attacks [EAPMITM]
2526 if these EAP methods are used in other protocols that do not use a
2527 server-authenticated tunnel. Please see the Security Considerations
2528 section for more details. If EAP methods that do not generate a
2529 shared key are used, the AUTH payloads in messages 7 and 8 MUST be
2530 generated using SK_pi and SK_pr, respectively.
2532 {{ Demoted the SHOULD }} The initiator of an IKE_SA using EAP needs
2533 to be capable of extending the initial protocol exchange to at least
2534 ten IKE_AUTH exchanges in the event the responder sends notification
2535 messages and/or retries the authentication prompt. Once the protocol
2536 exchange defined by the chosen EAP authentication method has
2537 successfully terminated, the responder MUST send an EAP payload
2538 containing the Success message. Similarly, if the authentication
2539 method has failed, the responder MUST send an EAP payload containing
2540 the Failure message. The responder MAY at any time terminate the IKE
2541 exchange by sending an EAP payload containing the Failure message.
2543 Following such an extended exchange, the EAP AUTH payloads MUST be
2544 included in the two messages following the one containing the EAP
2547 {{ Clarif-3.5 }} When the initiator authentication uses EAP, it is
2548 possible that the contents of the IDi payload is used only for AAA
2549 routing purposes and selecting which EAP method to use. This value
2550 may be different from the identity authenticated by the EAP method.
2551 It is important that policy lookups and access control decisions use
2552 the actual authenticated identity. Often the EAP server is
2553 implemented in a separate AAA server that communicates with the IKEv2
2554 responder. In this case, the authenticated identity has to be sent
2555 from the AAA server to the IKEv2 responder.
2557 2.17. Generating Keying Material for CHILD_SAs
2559 A single CHILD_SA is created by the IKE_AUTH exchange, and additional
2560 CHILD_SAs can optionally be created in CREATE_CHILD_SA exchanges.
2561 Keying material for them is generated as follows:
2563 KEYMAT = prf+(SK_d, Ni | Nr)
2565 Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this
2566 request is the first CHILD_SA created or the fresh Ni and Nr from the
2567 CREATE_CHILD_SA exchange if this is a subsequent creation.
2569 For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman
2570 exchange, the keying material is defined as:
2575 Kaufman, et al. Expires August 28, 2008 [Page 46]
2577 Internet-Draft IKEv2bis February 2008
2580 KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr )
2582 where g^ir (new) is the shared secret from the ephemeral Diffie-
2583 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an
2584 octet string in big endian order padded with zeros in the high-order
2585 bits if necessary to make it the length of the modulus).
2587 For ESP and AH, a single CHILD_SA negotiation results in two security
2588 associations (one in each direction). Keying material MUST be taken
2589 from the expanded KEYMAT in the following order:
2591 o The encryption key (if any) for the SA carrying data from the
2592 initiator to the responder.
2594 o The authentication key (if any) for the SA carrying data from the
2595 initiator to the responder.
2597 o The encryption key (if any) for the SA carrying data from the
2598 responder to the initiator.
2600 o The authentication key (if any) for the SA carrying data from the
2601 responder to the initiator.
2603 Each cryptographic algorithm takes a fixed number of bits of keying
2604 material specified as part of the algorithm, or negotiated in SA
2605 payloads (see Section 2.13 for description of key lengths, and
2606 Section 3.3.5 for the definition of the Key Length transform
2609 2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA Exchange
2611 The CREATE_CHILD_SA exchange can be used to rekey an existing IKE_SA
2612 (see Section 2.8). {{ Clarif-5.3 }} New initiator and responder SPIs
2613 are supplied in the SPI fields in the Proposal structures inside the
2614 Security Association (SA) payloads (not the SPI fields in the IKE
2615 header). The TS payloads are omitted when rekeying an IKE_SA.
2616 SKEYSEED for the new IKE_SA is computed using SK_d from the existing
2619 SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)
2621 where g^ir (new) is the shared secret from the ephemeral Diffie-
2622 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an
2623 octet string in big endian order padded with zeros if necessary to
2624 make it the length of the modulus) and Ni and Nr are the two nonces
2625 stripped of any headers.
2627 {{ Clarif-5.5 }} The old and new IKE_SA may have selected a different
2631 Kaufman, et al. Expires August 28, 2008 [Page 47]
2633 Internet-Draft IKEv2bis February 2008
2636 PRF. Because the rekeying exchange belongs to the old IKE_SA, it is
2637 the old IKE_SA's PRF that is used.
2639 {{ Clarif-5.12}} The main purpose of rekeying the IKE_SA is to ensure
2640 that the compromise of old keying material does not provide
2641 information about the current keys, or vice versa. Therefore,
2642 implementations SHOULD perform a new Diffie-Hellman exchange when
2643 rekeying the IKE_SA. In other words, an initiator SHOULD NOT propose
2644 the value "NONE" for the D-H transform, and a responder SHOULD NOT
2645 accept such a proposal. This means that a succesful exchange
2646 rekeying the IKE_SA always includes the KEi/KEr payloads.
2648 The new IKE_SA MUST reset its message counters to 0.
2650 SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as
2651 specified in Section 2.14.
2653 2.19. Requesting an Internal Address on a Remote Network
2655 Most commonly occurring in the endpoint-to-security-gateway scenario,
2656 an endpoint may need an IP address in the network protected by the
2657 security gateway and may need to have that address dynamically
2658 assigned. A request for such a temporary address can be included in
2659 any request to create a CHILD_SA (including the implicit request in
2660 message 3) by including a CP payload.
2662 This function provides address allocation to an IPsec Remote Access
2663 Client (IRAC) trying to tunnel into a network protected by an IPsec
2664 Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an
2665 IKE_SA and a CHILD_SA, the IRAC MUST request the IRAS-controlled
2666 address (and optionally other information concerning the protected
2667 network) in the IKE_AUTH exchange. The IRAS may procure an address
2668 for the IRAC from any number of sources such as a DHCP/BOOTP server
2669 or its own address pool.
2672 -------------------------------------------------------------------
2673 HDR, SK {IDi, [CERT,]
2674 [CERTREQ,] [IDr,] AUTH,
2675 CP(CFG_REQUEST), SAi2,
2677 <-- HDR, SK {IDr, [CERT,] AUTH,
2678 CP(CFG_REPLY), SAr2,
2681 In all cases, the CP payload MUST be inserted before the SA payload.
2682 In variations of the protocol where there are multiple IKE_AUTH
2683 exchanges, the CP payloads MUST be inserted in the messages
2687 Kaufman, et al. Expires August 28, 2008 [Page 48]
2689 Internet-Draft IKEv2bis February 2008
2692 containing the SA payloads.
2694 CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute
2695 (either IPv4 or IPv6) but MAY contain any number of additional
2696 attributes the initiator wants returned in the response.
2698 {{ 3.10.1-37 }} The FAILED_CP_REQUIRED notification is sent by
2699 responder in the case where CP(CFG_REQUEST) was expected but not
2700 received, and so is a conflict with locally configured policy. There
2701 is no associated data.
2703 For example, message from initiator to responder:
2707 TSi = (0, 0-65535,0.0.0.0-255.255.255.255)
2708 TSr = (0, 0-65535,0.0.0.0-255.255.255.255)
2710 NOTE: Traffic Selectors contain (protocol, port range, address
2713 Message from responder to initiator:
2716 INTERNAL_ADDRESS(192.0.2.202)
2717 INTERNAL_NETMASK(255.255.255.0)
2718 INTERNAL_SUBNET(192.0.2.0/255.255.255.0)
2719 TSi = (0, 0-65535,192.0.2.202-192.0.2.202)
2720 TSr = (0, 0-65535,192.0.2.0-192.0.2.255)
2722 All returned values will be implementation dependent. As can be seen
2723 in the above example, the IRAS MAY also send other attributes that
2724 were not included in CP(CFG_REQUEST) and MAY ignore the non-
2725 mandatory attributes that it does not support.
2727 The responder MUST NOT send a CFG_REPLY without having first received
2728 a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS
2729 to perform an unnecessary configuration lookup if the IRAC cannot
2730 process the REPLY. In the case where the IRAS's configuration
2731 requires that CP be used for a given identity IDi, but IRAC has
2732 failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and
2733 terminate the IKE exchange with a FAILED_CP_REQUIRED error.
2735 2.19.1. Configuration Payloads
2737 Editor's note: some of this sub-section is redundant and will go away
2738 in the next version of the document.
2743 Kaufman, et al. Expires August 28, 2008 [Page 49]
2745 Internet-Draft IKEv2bis February 2008
2748 In support of the scenario described in Section 1.1.3, an initiator
2749 may request that the responder assign an IP address and tell the
2750 initiator what it is. {{ Clarif-6.1 }} That request is done using
2751 configuration payloads, not traffic selectors. An address in a TSi
2752 payload in a response does not mean that the responder has assigned
2753 that address to the initiator: it only means that if packets matching
2754 these traffic selectors are sent by the initiator, IPsec processing
2755 can be performed as agreed for this SA.
2757 Configuration payloads are of type CFG_REQUEST/CFG_REPLY or CFG_SET/
2758 CFG_ACK (see CFG Type in the payload description below). CFG_REQUEST
2759 and CFG_SET payloads may optionally be added to any IKE request. The
2760 IKE response MUST include either a corresponding CFG_REPLY or CFG_ACK
2761 or a Notify payload with an error type indicating why the request
2762 could not be honored. An exception is that a minimal implementation
2763 MAY ignore all CFG_REQUEST and CFG_SET payloads, so a response
2764 message without a corresponding CFG_REPLY or CFG_ACK MUST be accepted
2765 as an indication that the request was not supported.
2767 "CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information
2768 from its peer. If an attribute in the CFG_REQUEST Configuration
2769 Payload is not zero-length, it is taken as a suggestion for that
2770 attribute. The CFG_REPLY Configuration Payload MAY return that
2771 value, or a new one. It MAY also add new attributes and not include
2772 some requested ones. Requestors MUST ignore returned attributes that
2773 they do not recognize.
2775 Some attributes MAY be multi-valued, in which case multiple attribute
2776 values of the same type are sent and/or returned. Generally, all
2777 values of an attribute are returned when the attribute is requested.
2778 For some attributes (in this version of the specification only
2779 internal addresses), multiple requests indicates a request that
2780 multiple values be assigned. For these attributes, the number of
2781 values returned SHOULD NOT exceed the number requested.
2783 If the data type requested in a CFG_REQUEST is not recognized or not
2784 supported, the responder MUST NOT return an error type but rather
2785 MUST either send a CFG_REPLY that MAY be empty or a reply not
2786 containing a CFG_REPLY payload at all. Error returns are reserved
2787 for cases where the request is recognized but cannot be performed as
2788 requested or the request is badly formatted.
2790 "CFG_SET/CFG_ACK" allows an IKE endpoint to push configuration data
2791 to its peer. In this case, the CFG_SET Configuration Payload
2792 contains attributes the initiator wants its peer to alter. The
2793 responder MUST return a Configuration Payload if it accepted any of
2794 the configuration data and it MUST contain the attributes that the
2795 responder accepted with zero-length data. Those attributes that it
2799 Kaufman, et al. Expires August 28, 2008 [Page 50]
2801 Internet-Draft IKEv2bis February 2008
2804 did not accept MUST NOT be in the CFG_ACK Configuration Payload. If
2805 no attributes were accepted, the responder MUST return either an
2806 empty CFG_ACK payload or a response message without a CFG_ACK
2807 payload. There are currently no defined uses for the CFG_SET/CFG_ACK
2808 exchange, though they may be used in connection with extensions based
2809 on Vendor IDs. An minimal implementation of this specification MAY
2810 ignore CFG_SET payloads.
2812 {{ Demoted the SHOULD }} Extensions via the CP payload should not be
2813 used for general purpose management. Its main intent is to provide a
2814 bootstrap mechanism to exchange information within IPsec from IRAS to
2815 IRAC. While it MAY be useful to use such a method to exchange
2816 information between some Security Gateways (SGW) or small networks,
2817 existing management protocols such as DHCP [DHCP], RADIUS [RADIUS],
2818 SNMP, or LDAP [LDAP] should be preferred for enterprise management as
2819 well as subsequent information exchanges.
2821 2.20. Requesting the Peer's Version
2823 An IKE peer wishing to inquire about the other peer's IKE software
2824 version information MAY use the method below. This is an example of
2825 a configuration request within an INFORMATIONAL exchange, after the
2826 IKE_SA and first CHILD_SA have been created.
2828 An IKE implementation MAY decline to give out version information
2829 prior to authentication or even after authentication to prevent
2830 trolling in case some implementation is known to have some security
2831 weakness. In that case, it MUST either return an empty string or no
2832 CP payload if CP is not supported.
2835 -------------------------------------------------------------------
2836 HDR, SK{CP(CFG_REQUEST)} -->
2837 <-- HDR, SK{CP(CFG_REPLY)}
2840 APPLICATION_VERSION("")
2842 CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar
2845 2.21. Error Handling
2847 There are many kinds of errors that can occur during IKE processing.
2848 If a request is received that is badly formatted or unacceptable for
2849 reasons of policy (e.g., no matching cryptographic algorithms), the
2850 response MUST contain a Notify payload indicating the error. If an
2851 error occurs outside the context of an IKE request (e.g., the node is
2855 Kaufman, et al. Expires August 28, 2008 [Page 51]
2857 Internet-Draft IKEv2bis February 2008
2860 getting ESP messages on a nonexistent SPI), the node SHOULD initiate
2861 an INFORMATIONAL exchange with a Notify payload describing the
2864 Errors that occur before a cryptographically protected IKE_SA is
2865 established must be handled very carefully. There is a trade-off
2866 between wanting to be helpful in diagnosing a problem and responding
2867 to it and wanting to avoid being a dupe in a denial of service attack
2868 based on forged messages.
2870 If a node receives a message on UDP port 500 or 4500 outside the
2871 context of an IKE_SA known to it (and not a request to start one), it
2872 may be the result of a recent crash of the node. If the message is
2873 marked as a response, the node MAY audit the suspicious event but
2874 MUST NOT respond. If the message is marked as a request, the node
2875 MAY audit the suspicious event and MAY send a response. If a
2876 response is sent, the response MUST be sent to the IP address and
2877 port from whence it came with the same IKE SPIs and the Message ID
2878 copied. The response MUST NOT be cryptographically protected and
2879 MUST contain a Notify payload indicating INVALID_IKE_SPI. {{ 3.10.1-4
2880 }} The INVALID_IKE_SPI notification indicates an IKE message was
2881 received with an unrecognized destination SPI; this usually indicates
2882 that the recipient has rebooted and forgotten the existence of an
2885 A node receiving such an unprotected Notify payload MUST NOT respond
2886 and MUST NOT change the state of any existing SAs. The message might
2887 be a forgery or might be a response the genuine correspondent was
2888 tricked into sending. {{ Demoted two SHOULDs }} A node should treat
2889 such a message (and also a network message like ICMP destination
2890 unreachable) as a hint that there might be problems with SAs to that
2891 IP address and should initiate a liveness test for any such IKE_SA.
2892 An implementation SHOULD limit the frequency of such tests to avoid
2893 being tricked into participating in a denial of service attack.
2895 A node receiving a suspicious message from an IP address with which
2896 it has an IKE_SA MAY send an IKE Notify payload in an IKE
2897 INFORMATIONAL exchange over that SA. {{ Demoted the SHOULD }} The
2898 recipient MUST NOT change the state of any SAs as a result, but may
2899 wish to audit the event to aid in diagnosing malfunctions. A node
2900 MUST limit the rate at which it will send messages in response to
2901 unprotected messages.
2905 Use of IP compression [IPCOMP] can be negotiated as part of the setup
2906 of a CHILD_SA. While IP compression involves an extra header in each
2907 packet and a compression parameter index (CPI), the virtual
2911 Kaufman, et al. Expires August 28, 2008 [Page 52]
2913 Internet-Draft IKEv2bis February 2008
2916 "compression association" has no life outside the ESP or AH SA that
2917 contains it. Compression associations disappear when the
2918 corresponding ESP or AH SA goes away. It is not explicitly mentioned
2919 in any DELETE payload.
2921 Negotiation of IP compression is separate from the negotiation of
2922 cryptographic parameters associated with a CHILD_SA. A node
2923 requesting a CHILD_SA MAY advertise its support for one or more
2924 compression algorithms through one or more Notify payloads of type
2925 IPCOMP_SUPPORTED. This notification may be included only in a
2926 message containing an SA payload negotiating a CHILD_SA and indicates
2927 a willingness by its sender to use IPComp on this SA. The response
2928 MAY indicate acceptance of a single compression algorithm with a
2929 Notify payload of type IPCOMP_SUPPORTED. These payloads MUST NOT
2930 occur in messages that do not contain SA payloads.
2932 {{ 3.10.1-16387 }}The data associated with this notification includes
2933 a two-octet IPComp CPI followed by a one-octet transform ID
2934 optionally followed by attributes whose length and format are defined
2935 by that transform ID. A message proposing an SA may contain multiple
2936 IPCOMP_SUPPORTED notifications to indicate multiple supported
2937 algorithms. A message accepting an SA may contain at most one.
2939 The transform IDs currently defined are:
2941 Name Number Defined In
2942 -------------------------------------
2945 IPCOMP_DEFLATE 2 RFC 2394
2946 IPCOMP_LZS 3 RFC 2395
2947 IPCOMP_LZJH 4 RFC 3051
2948 RESERVED TO IANA 5-240
2951 Although there has been discussion of allowing multiple compression
2952 algorithms to be accepted and to have different compression
2953 algorithms available for the two directions of a CHILD_SA,
2954 implementations of this specification MUST NOT accept an IPComp
2955 algorithm that was not proposed, MUST NOT accept more than one, and
2956 MUST NOT compress using an algorithm other than one proposed and
2957 accepted in the setup of the CHILD_SA.
2959 A side effect of separating the negotiation of IPComp from
2960 cryptographic parameters is that it is not possible to propose
2961 multiple cryptographic suites and propose IP compression with some of
2962 them but not others.
2967 Kaufman, et al. Expires August 28, 2008 [Page 53]
2969 Internet-Draft IKEv2bis February 2008
2974 Network Address Translation (NAT) gateways are a controversial
2975 subject. This section briefly describes what they are and how they
2976 are likely to act on IKE traffic. Many people believe that NATs are
2977 evil and that we should not design our protocols so as to make them
2978 work better. IKEv2 does specify some unintuitive processing rules in
2979 order that NATs are more likely to work.
2981 NATs exist primarily because of the shortage of IPv4 addresses,
2982 though there are other rationales. IP nodes that are "behind" a NAT
2983 have IP addresses that are not globally unique, but rather are
2984 assigned from some space that is unique within the network behind the
2985 NAT but that are likely to be reused by nodes behind other NATs.
2986 Generally, nodes behind NATs can communicate with other nodes behind
2987 the same NAT and with nodes with globally unique addresses, but not
2988 with nodes behind other NATs. There are exceptions to that rule.
2989 When those nodes make connections to nodes on the real Internet, the
2990 NAT gateway "translates" the IP source address to an address that
2991 will be routed back to the gateway. Messages to the gateway from the
2992 Internet have their destination addresses "translated" to the
2993 internal address that will route the packet to the correct endnode.
2995 NATs are designed to be "transparent" to endnodes. Neither software
2996 on the node behind the NAT nor the node on the Internet requires
2997 modification to communicate through the NAT. Achieving this
2998 transparency is more difficult with some protocols than with others.
2999 Protocols that include IP addresses of the endpoints within the
3000 payloads of the packet will fail unless the NAT gateway understands
3001 the protocol and modifies the internal references as well as those in
3002 the headers. Such knowledge is inherently unreliable, is a network
3003 layer violation, and often results in subtle problems.
3005 Opening an IPsec connection through a NAT introduces special
3006 problems. If the connection runs in transport mode, changing the IP
3007 addresses on packets will cause the checksums to fail and the NAT
3008 cannot correct the checksums because they are cryptographically
3009 protected. Even in tunnel mode, there are routing problems because
3010 transparently translating the addresses of AH and ESP packets
3011 requires special logic in the NAT and that logic is heuristic and
3012 unreliable in nature. For that reason, IKEv2 can negotiate UDP
3013 encapsulation of IKE and ESP packets. This encoding is slightly less
3014 efficient but is easier for NATs to process. In addition, firewalls
3015 may be configured to pass IPsec traffic over UDP but not ESP/AH or
3018 It is a common practice of NATs to translate TCP and UDP port numbers
3019 as well as addresses and use the port numbers of inbound packets to
3023 Kaufman, et al. Expires August 28, 2008 [Page 54]
3025 Internet-Draft IKEv2bis February 2008
3028 decide which internal node should get a given packet. For this
3029 reason, even though IKE packets MUST be sent from and to UDP port
3030 500, they MUST be accepted coming from any port and responses MUST be
3031 sent to the port from whence they came. This is because the ports
3032 may be modified as the packets pass through NATs. Similarly, IP
3033 addresses of the IKE endpoints are generally not included in the IKE
3034 payloads because the payloads are cryptographically protected and
3035 could not be transparently modified by NATs.
3037 Port 4500 is reserved for UDP-encapsulated ESP and IKE. When working
3038 through a NAT, it is generally better to pass IKE packets over port
3039 4500 because some older NATs handle IKE traffic on port 500 cleverly
3040 in an attempt to transparently establish IPsec connections between
3041 endpoints that don't handle NAT traversal themselves. Such NATs may
3042 interfere with the straightforward NAT traversal envisioned by this
3043 document. {{ Clarif-7.6 }} An IPsec endpoint that discovers a NAT
3044 between it and its correspondent MUST send all subsequent traffic
3045 from port 4500, which NATs should not treat specially (as they might
3048 The specific requirements for supporting NAT traversal [NATREQ] are
3049 listed below. Support for NAT traversal is optional. In this
3050 section only, requirements listed as MUST apply only to
3051 implementations supporting NAT traversal.
3053 o IKE MUST listen on port 4500 as well as port 500. IKE MUST
3054 respond to the IP address and port from which packets arrived.
3056 o Both IKE initiator and responder MUST include in their IKE_SA_INIT
3057 packets Notify payloads of type NAT_DETECTION_SOURCE_IP and
3058 NAT_DETECTION_DESTINATION_IP. Those payloads can be used to
3059 detect if there is NAT between the hosts, and which end is behind
3060 the NAT. The location of the payloads in the IKE_SA_INIT packets
3061 are just after the Ni and Nr payloads (before the optional CERTREQ
3064 o {{ 3.10.1-16388 }} The data associated with the
3065 NAT_DETECTION_SOURCE_IP notification is a SHA-1 digest of the SPIs
3066 (in the order they appear in the header), IP address, and port on
3067 which this packet was sent. There MAY be multiple
3068 NAT_DETECTION_SOURCE_IP payloads in a message if the sender does
3069 not know which of several network attachments will be used to send
3072 o {{ 3.10.1-16389 }} The data associated with the
3073 NAT_DETECTION_DESTINATION_IP notification is a SHA-1 digest of the
3074 SPIs (in the order they appear in the header), IP address, and
3075 port to which this packet was sent.
3079 Kaufman, et al. Expires August 28, 2008 [Page 55]
3081 Internet-Draft IKEv2bis February 2008
3084 o {{ 3.10.1-16388 }} {{ 3.10.1-16389 }} The recipient of either the
3085 NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP
3086 notification MAY compare the supplied value to a SHA-1 hash of the
3087 SPIs, source IP address, and port, and if they don't match it
3088 SHOULD enable NAT traversal. In the case of a mismatching
3089 NAT_DETECTION_SOURCE_IP hash, the recipient MAY reject the
3090 connection attempt if NAT traversal is not supported. In the case
3091 of a mismatching NAT_DETECTION_DESTINATION_IP hash, it means that
3092 the system receiving the NAT_DETECTION_DESTINATION_IP payload is
3093 behind a NAT and that system SHOULD start sending keepalive
3094 packets as defined in [UDPENCAPS]; alternately, it MAY reject the
3095 connection attempt if NAT traversal is not supported.
3097 o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches
3098 the expected value of the source IP and port found from the IP
3099 header of the packet containing the payload, it means that the
3100 system sending those payloads is behind NAT (i.e., someone along
3101 the route changed the source address of the original packet to
3102 match the address of the NAT box). In this case, the system
3103 receiving the payloads should allow dynamic update of the other
3104 systems' IP address, as described later.
3106 o If the NAT_DETECTION_DESTINATION_IP payload received does not
3107 match the hash of the destination IP and port found from the IP
3108 header of the packet containing the payload, it means that the
3109 system receiving the NAT_DETECTION_DESTINATION_IP payload is
3110 behind a NAT. In this case, that system SHOULD start sending
3111 keepalive packets as explained in [UDPENCAPS].
3113 o The IKE initiator MUST check these payloads if present and if they
3114 do not match the addresses in the outer packet MUST tunnel all
3115 future IKE and ESP packets associated with this IKE_SA over UDP
3118 o To tunnel IKE packets over UDP port 4500, the IKE header has four
3119 octets of zero prepended and the result immediately follows the
3120 UDP header. To tunnel ESP packets over UDP port 4500, the ESP
3121 header immediately follows the UDP header. Since the first four
3122 octets of the ESP header contain the SPI, and the SPI cannot
3123 validly be zero, it is always possible to distinguish ESP and IKE
3126 o Implementations MUST process received UDP-encapsulated ESP packets
3127 even when no NAT was detected.
3129 o The original source and destination IP address required for the
3130 transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS])
3131 are obtained from the Traffic Selectors associated with the
3135 Kaufman, et al. Expires August 28, 2008 [Page 56]
3137 Internet-Draft IKEv2bis February 2008
3140 exchange. In the case of NAT traversal, the Traffic Selectors
3141 MUST contain exactly one IP address, which is then used as the
3142 original IP address.
3144 o There are cases where a NAT box decides to remove mappings that
3145 are still alive (for example, the keepalive interval is too long,
3146 or the NAT box is rebooted). To recover in these cases, hosts
3147 that are not behind a NAT SHOULD send all packets (including
3148 retransmission packets) to the IP address and port from the last
3149 valid authenticated packet from the other end (i.e., dynamically
3150 update the address). A host behind a NAT SHOULD NOT do this
3151 because it opens a DoS attack possibility. Any authenticated IKE
3152 packet or any authenticated UDP-encapsulated ESP packet can be
3153 used to detect that the IP address or the port has changed.
3155 Note that similar but probably not identical actions will likely be
3156 needed to make IKE work with Mobile IP, but such processing is not
3157 addressed by this document.
3159 2.24. Explicit Congestion Notification (ECN)
3161 When IPsec tunnels behave as originally specified in [IPSECARCH-OLD],
3162 ECN usage is not appropriate for the outer IP headers because tunnel
3163 decapsulation processing discards ECN congestion indications to the
3164 detriment of the network. ECN support for IPsec tunnels for IKEv1-
3165 based IPsec requires multiple operating modes and negotiation (see
3166 [ECN]). IKEv2 simplifies this situation by requiring that ECN be
3167 usable in the outer IP headers of all tunnel-mode IPsec SAs created
3168 by IKEv2. Specifically, tunnel encapsulators and decapsulators for
3169 all tunnel-mode SAs created by IKEv2 MUST support the ECN full-
3170 functionality option for tunnels specified in [ECN] and MUST
3171 implement the tunnel encapsulation and decapsulation processing
3172 specified in [IPSECARCH] to prevent discarding of ECN congestion
3176 3. Header and Payload Formats
3178 In the tables in this section, some cryptographic primitives and
3179 configuation attributes are marked as "UNSPECIFIED". These are items
3180 for which there are no known specifications and therefore
3181 interoperability is currently impossible. A future specification may
3182 describe their use, but until such specification is made,
3183 implementations SHOULD NOT attempt to use items marked as
3184 "UNSPECIFIED" in implementations that are meant to be interoperable.
3191 Kaufman, et al. Expires August 28, 2008 [Page 57]
3193 Internet-Draft IKEv2bis February 2008
3198 IKE messages use UDP ports 500 and/or 4500, with one IKE message per
3199 UDP datagram. Information from the beginning of the packet through
3200 the UDP header is largely ignored except that the IP addresses and
3201 UDP ports from the headers are reversed and used for return packets.
3202 When sent on UDP port 500, IKE messages begin immediately following
3203 the UDP header. When sent on UDP port 4500, IKE messages have
3204 prepended four octets of zero. These four octets of zero are not
3205 part of the IKE message and are not included in any of the length
3206 fields or checksums defined by IKE. Each IKE message begins with the
3207 IKE header, denoted HDR in this memo. Following the header are one
3208 or more IKE payloads each identified by a "Next Payload" field in the
3209 preceding payload. Payloads are processed in the order in which they
3210 appear in an IKE message by invoking the appropriate processing
3211 routine according to the "Next Payload" field in the IKE header and
3212 subsequently according to the "Next Payload" field in the IKE payload
3213 itself until a "Next Payload" field of zero indicates that no
3214 payloads follow. If a payload of type "Encrypted" is found, that
3215 payload is decrypted and its contents parsed as additional payloads.
3216 An Encrypted payload MUST be the last payload in a packet and an
3217 Encrypted payload MUST NOT contain another Encrypted payload.
3219 The Recipient SPI in the header identifies an instance of an IKE
3220 security association. It is therefore possible for a single instance
3221 of IKE to multiplex distinct sessions with multiple peers.
3223 All multi-octet fields representing integers are laid out in big
3224 endian order (also known as "most significant byte first", or
3225 "network byte order").
3227 The format of the IKE header is shown in Figure 4.
3247 Kaufman, et al. Expires August 28, 2008 [Page 58]
3249 Internet-Draft IKEv2bis February 2008
3253 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
3254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3255 | IKE_SA Initiator's SPI |
3257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3258 | IKE_SA Responder's SPI |
3260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3261 | Next Payload | MjVer | MnVer | Exchange Type | Flags |
3262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3268 Figure 4: IKE Header Format
3270 o Initiator's SPI (8 octets) - A value chosen by the initiator to
3271 identify a unique IKE security association. This value MUST NOT
3274 o Responder's SPI (8 octets) - A value chosen by the responder to
3275 identify a unique IKE security association. This value MUST be
3276 zero in the first message of an IKE Initial Exchange (including
3277 repeats of that message including a cookie). {{ The phrase "and
3278 MUST NOT be zero in any other message" was removed; Clarif-2.1 }}
3280 o Next Payload (1 octet) - Indicates the type of payload that
3281 immediately follows the header. The format and value of each
3282 payload are defined below.
3284 o Major Version (4 bits) - Indicates the major version of the IKE
3285 protocol in use. Implementations based on this version of IKE
3286 MUST set the Major Version to 2. Implementations based on
3287 previous versions of IKE and ISAKMP MUST set the Major Version to
3288 1. Implementations based on this version of IKE MUST reject or
3289 ignore messages containing a version number greater than 2.
3291 o Minor Version (4 bits) - Indicates the minor version of the IKE
3292 protocol in use. Implementations based on this version of IKE
3293 MUST set the Minor Version to 0. They MUST ignore the minor
3294 version number of received messages.
3296 o Exchange Type (1 octet) - Indicates the type of exchange being
3297 used. This constrains the payloads sent in each message and
3298 orderings of messages in an exchange.
3303 Kaufman, et al. Expires August 28, 2008 [Page 59]
3305 Internet-Draft IKEv2bis February 2008
3309 ----------------------------------
3315 RESERVED TO IANA 38-239
3318 o Flags (1 octet) - Indicates specific options that are set for the
3319 message. Presence of options are indicated by the appropriate bit
3320 in the flags field being set. The bits are defined LSB first, so
3321 bit 0 would be the least significant bit of the Flags octet. In
3322 the description below, a bit being 'set' means its value is '1',
3323 while 'cleared' means its value is '0'.
3325 * X(reserved) (bits 0-2) - These bits MUST be cleared when
3326 sending and MUST be ignored on receipt.
3328 * I(nitiator) (bit 3 of Flags) - This bit MUST be set in messages
3329 sent by the original initiator of the IKE_SA and MUST be
3330 cleared in messages sent by the original responder. It is used
3331 by the recipient to determine which eight octets of the SPI
3332 were generated by the recipient.
3334 * V(ersion) (bit 4 of Flags) - This bit indicates that the
3335 transmitter is capable of speaking a higher major version
3336 number of the protocol than the one indicated in the major
3337 version number field. Implementations of IKEv2 must clear this
3338 bit when sending and MUST ignore it in incoming messages.
3340 * R(esponse) (bit 5 of Flags) - This bit indicates that this
3341 message is a response to a message containing the same message
3342 ID. This bit MUST be cleared in all request messages and MUST
3343 be set in all responses. An IKE endpoint MUST NOT generate a
3344 response to a message that is marked as being a response.
3346 * X(reserved) (bits 6-7 of Flags) - These bits MUST be cleared
3347 when sending and MUST be ignored on receipt.
3349 o Message ID (4 octets) - Message identifier used to control
3350 retransmission of lost packets and matching of requests and
3351 responses. It is essential to the security of the protocol
3352 because it is used to prevent message replay attacks. See
3353 Section 2.1 and Section 2.2.
3359 Kaufman, et al. Expires August 28, 2008 [Page 60]
3361 Internet-Draft IKEv2bis February 2008
3364 o Length (4 octets) - Length of total message (header + payloads) in
3367 3.2. Generic Payload Header
3369 Each IKE payload defined in Section 3.3 through Section 3.16 begins
3370 with a generic payload header, shown in Figure 5. Figures for each
3371 payload below will include the generic payload header, but for
3372 brevity the description of each field will be omitted.
3375 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
3376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3377 | Next Payload |C| RESERVED | Payload Length |
3378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3380 Figure 5: Generic Payload Header
3382 The Generic Payload Header fields are defined as follows:
3384 o Next Payload (1 octet) - Identifier for the payload type of the
3385 next payload in the message. If the current payload is the last
3386 in the message, then this field will be 0. This field provides a
3387 "chaining" capability whereby additional payloads can be added to
3388 a message by appending it to the end of the message and setting
3389 the "Next Payload" field of the preceding payload to indicate the
3390 new payload's type. An Encrypted payload, which must always be
3391 the last payload of a message, is an exception. It contains data
3392 structures in the format of additional payloads. In the header of
3393 an Encrypted payload, the Next Payload field is set to the payload
3394 type of the first contained payload (instead of 0). The payload
3415 Kaufman, et al. Expires August 28, 2008 [Page 61]
3417 Internet-Draft IKEv2bis February 2008
3420 Next Payload Type Notation Value
3421 --------------------------------------------------
3424 Security Association SA 33
3426 Identification - Initiator IDi 35
3427 Identification - Responder IDr 36
3429 Certificate Request CERTREQ 38
3430 Authentication AUTH 39
3435 Traffic Selector - Initiator TSi 44
3436 Traffic Selector - Responder TSr 45
3439 Extensible Authentication EAP 48
3440 RESERVED TO IANA 49-127
3443 (Payload type values 1-32 should not be assigned in the
3444 future so that there is no overlap with the code assignments
3447 o Critical (1 bit) - MUST be set to zero if the sender wants the
3448 recipient to skip this payload if it does not understand the
3449 payload type code in the Next Payload field of the previous
3450 payload. MUST be set to one if the sender wants the recipient to
3451 reject this entire message if it does not understand the payload
3452 type. MUST be ignored by the recipient if the recipient
3453 understands the payload type code. MUST be set to zero for
3454 payload types defined in this document. Note that the critical
3455 bit applies to the current payload rather than the "next" payload
3456 whose type code appears in the first octet. The reasoning behind
3457 not setting the critical bit for payloads defined in this document
3458 is that all implementations MUST understand all payload types
3459 defined in this document and therefore must ignore the Critical
3460 bit's value. Skipped payloads are expected to have valid Next
3461 Payload and Payload Length fields.
3463 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on
3466 o Payload Length (2 octets) - Length in octets of the current
3467 payload, including the generic payload header.
3471 Kaufman, et al. Expires August 28, 2008 [Page 62]
3473 Internet-Draft IKEv2bis February 2008
3476 {{ Clarif-7.10 }} Many payloads contain fields marked as "RESERVED".
3477 Some payloads in IKEv2 (and historically in IKEv1) are not aligned to
3480 3.3. Security Association Payload
3482 The Security Association Payload, denoted SA in this memo, is used to
3483 negotiate attributes of a security association. Assembly of Security
3484 Association Payloads requires great peace of mind. An SA payload MAY
3485 contain multiple proposals. If there is more than one, they MUST be
3486 ordered from most preferred to least preferred. Each proposal
3487 contains a single IPsec protocol (where a protocol is IKE, ESP, or
3488 AH), each protocol MAY contain multiple transforms, and each
3489 transform MAY contain multiple attributes. When parsing an SA, an
3490 implementation MUST check that the total Payload Length is consistent
3491 with the payload's internal lengths and counts. Proposals,
3492 Transforms, and Attributes each have their own variable length
3493 encodings. They are nested such that the Payload Length of an SA
3494 includes the combined contents of the SA, Proposal, Transform, and
3495 Attribute information. The length of a Proposal includes the lengths
3496 of all Transforms and Attributes it contains. The length of a
3497 Transform includes the lengths of all Attributes it contains.
3499 The syntax of Security Associations, Proposals, Transforms, and
3500 Attributes is based on ISAKMP; however the semantics are somewhat
3501 different. The reason for the complexity and the hierarchy is to
3502 allow for multiple possible combinations of algorithms to be encoded
3503 in a single SA. Sometimes there is a choice of multiple algorithms,
3504 whereas other times there is a combination of algorithms. For
3505 example, an initiator might want to propose using ESP with either
3506 (3DES and HMAC_MD5) or (AES and HMAC_SHA1).
3508 One of the reasons the semantics of the SA payload has changed from
3509 ISAKMP and IKEv1 is to make the encodings more compact in common
3512 The Proposal structure contains within it a Proposal # and an IPsec
3513 protocol ID. Each structure MUST have a proposal number one (1)
3514 greater than the previous structure. The first Proposal in the
3515 initiator's SA payload MUST have a Proposal # of one (1). A proposal
3516 of AH or ESP would have two proposal structures, one for AH with
3517 Proposal #1 and one for ESP with Proposal #2.
3519 Each Proposal/Protocol structure is followed by one or more transform
3520 structures. The number of different transforms is generally
3521 determined by the Protocol. AH generally has two transforms:
3522 Extended Sequence Numbers (ESN) and an integrity check algorithm.
3523 ESP generally has three: ESN, an encryption algorithm and an
3527 Kaufman, et al. Expires August 28, 2008 [Page 63]
3529 Internet-Draft IKEv2bis February 2008
3532 integrity check algorithm. IKE generally has four transforms: a
3533 Diffie-Hellman group, an integrity check algorithm, a prf algorithm,
3534 and an encryption algorithm. If an algorithm that combines
3535 encryption and integrity protection is proposed, it MUST be proposed
3536 as an encryption algorithm and an integrity protection algorithm MUST
3537 NOT be proposed. For each Protocol, the set of permissible
3538 transforms is assigned transform ID numbers, which appear in the
3539 header of each transform.
3541 If there are multiple transforms with the same Transform Type, the
3542 proposal is an OR of those transforms. If there are multiple
3543 Transforms with different Transform Types, the proposal is an AND of
3544 the different groups. For example, to propose ESP with (3DES or AES-
3545 CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two
3546 Transform Type 1 candidates (one for 3DES and one for AEC-CBC) and
3547 two Transform Type 3 candidates (one for HMAC_MD5 and one for
3548 HMAC_SHA). This effectively proposes four combinations of
3549 algorithms. If the initiator wanted to propose only a subset of
3550 those, for example (3DES and HMAC_MD5) or (IDEA and HMAC_SHA), there
3551 is no way to encode that as multiple transforms within a single
3552 Proposal. Instead, the initiator would have to construct two
3553 different Proposals, each with two transforms.
3555 A given transform MAY have one or more Attributes. Attributes are
projects / strongswan.git / blob