4 Network Working Group C. Kaufman
5 Internet-Draft Microsoft
6 Expires: August 27, 2006 P. Hoffman
13 Internet Key Exchange Protocol: IKEv2
14 draft-hoffman-ikev2bis-00.txt
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 27, 2006.
43 Copyright (C) The Internet Society (2006).
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 the "IKEv2 Clarifications" document.
55 Kaufman, et al. Expires August 27, 2006 [Page 1]
57 Internet-Draft IKEv2bis February 2006
62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
63 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 6
64 1.1.1. Security Gateway to Security Gateway Tunnel . . . . . 7
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 . . . . . . . . . . . . . . . . . . . 9
68 1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 9
69 1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 12
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 . . . . . . . 16
77 1.6. Requirements Terminology . . . . . . . . . . . . . . . . 17
78 1.7. Differences Between RFC 4306 and This Document . . . . . 17
79 2. IKE Protocol Details and Variations . . . . . . . . . . . . . 18
80 2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 19
81 2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 19
82 2.3. Window Size for Overlapping Requests . . . . . . . . . . 20
83 2.4. State Synchronization and Connection Timeouts . . . . . . 21
84 2.5. Version Numbers and Forward Compatibility . . . . . . . . 23
85 2.6. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 25
86 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 27
87 2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 28
88 2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 29
89 2.8.1. Simultaneous CHILD_SA rekeying . . . . . . . . . . . 31
90 2.8.2. Rekeying the IKE_SA Versus Reauthentication . . . . . 33
91 2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 34
92 2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 37
93 2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 38
94 2.11. Address and Port Agility . . . . . . . . . . . . . . . . 38
95 2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 38
96 2.13. Generating Keying Material . . . . . . . . . . . . . . . 39
97 2.14. Generating Keying Material for the IKE_SA . . . . . . . . 40
98 2.15. Authentication of the IKE_SA . . . . . . . . . . . . . . 41
99 2.16. Extensible Authentication Protocol Methods . . . . . . . 43
100 2.17. Generating Keying Material for CHILD_SAs . . . . . . . . 45
101 2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA Exchange . . . . 46
102 2.19. Requesting an Internal Address on a Remote Network . . . 47
103 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 48
104 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 49
105 2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 50
106 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 50
107 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 53
111 Kaufman, et al. Expires August 27, 2006 [Page 2]
113 Internet-Draft IKEv2bis February 2006
116 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 53
117 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 53
118 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 56
119 3.3. Security Association Payload . . . . . . . . . . . . . . 58
120 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 60
121 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 62
122 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 64
123 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 65
124 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 66
125 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 67
126 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 68
127 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 69
128 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 71
129 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 74
130 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 76
131 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 77
132 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 77
133 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 78
134 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 84
135 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 85
136 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 86
137 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 88
138 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 90
139 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 92
140 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 94
141 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 97
142 3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 99
143 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 100
144 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 100
145 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 102
146 5. Security Considerations . . . . . . . . . . . . . . . . . . . 104
147 5.1. Traffic selector authorization . . . . . . . . . . . . . 107
148 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 108
149 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 108
150 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 109
151 8.1. Normative References . . . . . . . . . . . . . . . . . . 109
152 8.2. Informative References . . . . . . . . . . . . . . . . . 110
153 Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 114
154 Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 115
155 B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 115
156 B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 115
157 Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 116
158 C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 116
159 C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 117
160 C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 118
161 C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying
162 CHILD_SAs . . . . . . . . . . . . . . . . . . . . . . . . 119
163 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA . . . . 119
167 Kaufman, et al. Expires August 27, 2006 [Page 3]
169 Internet-Draft IKEv2bis February 2006
172 C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 119
173 Appendix D. Changes Between Internet Draft Versions . . . . . . 119
174 D.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 119
175 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 120
176 Intellectual Property and Copyright Statements . . . . . . . . . 120
223 Kaufman, et al. Expires August 27, 2006 [Page 4]
225 Internet-Draft IKEv2bis February 2006
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 the original
235 IP Security (IPsec) provides confidentiality, data integrity, access
236 control, and data source authentication to IP datagrams. These
237 services are provided by maintaining shared state between the source
238 and the sink of an IP datagram. This state defines, among other
239 things, the specific services provided to the datagram, which
240 cryptographic algorithms will be used to provide the services, and
241 the keys used as input to the cryptographic algorithms.
243 Establishing this shared state in a manual fashion does not scale
244 well. Therefore, a protocol to establish this state dynamically is
245 needed. This memo describes such a protocol -- the Internet Key
246 Exchange (IKE). Version 1 of IKE was defined in RFCs 2407 [DOI],
247 2408 [ISAKMP], and 2409 [IKEV1]. IKEv2 was defined in [IKEV2]. This
248 single document is intended to replace all three of those RFCs.
250 Definitions of the primitive terms in this document (such as Security
251 Association or SA) can be found in [IPSECARCH]. {{ Clarif-7.2 }} It
252 should be noted that parts of IKEv2 rely on some of the processing
253 rules in [IPSECARCH], as described in various sections of this
256 IKE performs mutual authentication between two parties and
257 establishes an IKE security association (SA) that includes shared
258 secret information that can be used to efficiently establish SAs for
259 Encapsulating Security Payload (ESP) [ESP] and/or Authentication
260 Header (AH) [AH] and a set of cryptographic algorithms to be used by
261 the SAs to protect the traffic that they carry. In this document,
262 the term "suite" or "cryptographic suite" refers to a complete set of
263 algorithms used to protect an SA. An initiator proposes one or more
264 suites by listing supported algorithms that can be combined into
265 suites in a mix-and-match fashion. IKE can also negotiate use of IP
266 Compression (IPComp) [IPCOMP] in connection with an ESP and/or AH SA.
267 We call the IKE SA an "IKE_SA". The SAs for ESP and/or AH that get
268 set up through that IKE_SA we call "CHILD_SAs".
270 All IKE communications consist of pairs of messages: a request and a
271 response. The pair is called an "exchange". We call the first
272 messages establishing an IKE_SA IKE_SA_INIT and IKE_AUTH exchanges
273 and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL
274 exchanges. In the common case, there is a single IKE_SA_INIT
275 exchange and a single IKE_AUTH exchange (a total of four messages) to
279 Kaufman, et al. Expires August 27, 2006 [Page 5]
281 Internet-Draft IKEv2bis February 2006
284 establish the IKE_SA and the first CHILD_SA. In exceptional cases,
285 there may be more than one of each of these exchanges. In all cases,
286 all IKE_SA_INIT exchanges MUST complete before any other exchange
287 type, then all IKE_AUTH exchanges MUST complete, and following that
288 any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur
289 in any order. In some scenarios, only a single CHILD_SA is needed
290 between the IPsec endpoints, and therefore there would be no
291 additional exchanges. Subsequent exchanges MAY be used to establish
292 additional CHILD_SAs between the same authenticated pair of endpoints
293 and to perform housekeeping functions.
295 IKE message flow always consists of a request followed by a response.
296 It is the responsibility of the requester to ensure reliability. If
297 the response is not received within a timeout interval, the requester
298 needs to retransmit the request (or abandon the connection).
300 The first request/response of an IKE session (IKE_SA_INIT) negotiates
301 security parameters for the IKE_SA, sends nonces, and sends Diffie-
304 The second request/response (IKE_AUTH) transmits identities, proves
305 knowledge of the secrets corresponding to the two identities, and
306 sets up an SA for the first (and often only) AH and/or ESP CHILD_SA.
308 The types of subsequent exchanges are CREATE_CHILD_SA (which creates
309 a CHILD_SA) and INFORMATIONAL (which deletes an SA, reports error
310 conditions, or does other housekeeping). Every request requires a
311 response. An INFORMATIONAL request with no payloads (other than the
312 empty Encrypted payload required by the syntax) is commonly used as a
313 check for liveness. These subsequent exchanges cannot be used until
314 the initial exchanges have completed.
316 In the description that follows, we assume that no errors occur.
317 Modifications to the flow should errors occur are described in
322 IKE is expected to be used to negotiate ESP and/or AH SAs in a number
323 of different scenarios, each with its own special requirements.
335 Kaufman, et al. Expires August 27, 2006 [Page 6]
337 Internet-Draft IKEv2bis February 2006
340 1.1.1. Security Gateway to Security Gateway Tunnel
342 +-+-+-+-+-+ +-+-+-+-+-+
344 Protected !Tunnel ! tunnel !Tunnel ! Protected
345 Subnet <-->!Endpoint !<---------->!Endpoint !<--> Subnet
347 +-+-+-+-+-+ +-+-+-+-+-+
349 Figure 1: Security Gateway to Security Gateway Tunnel
351 In this scenario, neither endpoint of the IP connection implements
352 IPsec, but network nodes between them protect traffic for part of the
353 way. Protection is transparent to the endpoints, and depends on
354 ordinary routing to send packets through the tunnel endpoints for
355 processing. Each endpoint would announce the set of addresses
356 "behind" it, and packets would be sent in tunnel mode where the inner
357 IP header would contain the IP addresses of the actual endpoints.
359 1.1.2. Endpoint-to-Endpoint Transport
361 +-+-+-+-+-+ +-+-+-+-+-+
362 ! ! IPsec transport ! !
363 !Protected! or tunnel mode SA !Protected!
364 !Endpoint !<---------------------------------------->!Endpoint !
366 +-+-+-+-+-+ +-+-+-+-+-+
368 Figure 2: Endpoint to Endpoint
370 In this scenario, both endpoints of the IP connection implement
371 IPsec, as required of hosts in [IPSECARCH]. Transport mode will
372 commonly be used with no inner IP header. If there is an inner IP
373 header, the inner addresses will be the same as the outer addresses.
374 A single pair of addresses will be negotiated for packets to be
375 protected by this SA. These endpoints MAY implement application
376 layer access controls based on the IPsec authenticated identities of
377 the participants. This scenario enables the end-to-end security that
378 has been a guiding principle for the Internet since [ARCHPRINC],
379 [TRANSPARENCY], and a method of limiting the inherent problems with
380 complexity in networks noted by [ARCHGUIDEPHIL]. Although this
381 scenario may not be fully applicable to the IPv4 Internet, it has
382 been deployed successfully in specific scenarios within intranets
383 using IKEv1. It should be more broadly enabled during the transition
384 to IPv6 and with the adoption of IKEv2.
386 It is possible in this scenario that one or both of the protected
387 endpoints will be behind a network address translation (NAT) node, in
391 Kaufman, et al. Expires August 27, 2006 [Page 7]
393 Internet-Draft IKEv2bis February 2006
396 which case the tunneled packets will have to be UDP encapsulated so
397 that port numbers in the UDP headers can be used to identify
398 individual endpoints "behind" the NAT (see Section 2.23).
400 1.1.3. Endpoint to Security Gateway Tunnel
402 +-+-+-+-+-+ +-+-+-+-+-+
403 ! ! IPsec ! ! Protected
404 !Protected! tunnel !Tunnel ! Subnet
405 !Endpoint !<------------------------>!Endpoint !<--- and/or
407 +-+-+-+-+-+ +-+-+-+-+-+
409 Figure 3: Endpoint to Security Gateway Tunnel
411 In this scenario, a protected endpoint (typically a portable roaming
412 computer) connects back to its corporate network through an IPsec-
413 protected tunnel. It might use this tunnel only to access
414 information on the corporate network, or it might tunnel all of its
415 traffic back through the corporate network in order to take advantage
416 of protection provided by a corporate firewall against Internet-based
417 attacks. In either case, the protected endpoint will want an IP
418 address associated with the security gateway so that packets returned
419 to it will go to the security gateway and be tunneled back. This IP
420 address may be static or may be dynamically allocated by the security
421 gateway. {{ Clarif-6.1 }} In support of the latter case, IKEv2
422 includes a mechanism (namely, configuration payloads) for the
423 initiator to request an IP address owned by the security gateway for
424 use for the duration of its SA.
426 In this scenario, packets will use tunnel mode. On each packet from
427 the protected endpoint, the outer IP header will contain the source
428 IP address associated with its current location (i.e., the address
429 that will get traffic routed to the endpoint directly), while the
430 inner IP header will contain the source IP address assigned by the
431 security gateway (i.e., the address that will get traffic routed to
432 the security gateway for forwarding to the endpoint). The outer
433 destination address will always be that of the security gateway,
434 while the inner destination address will be the ultimate destination
437 In this scenario, it is possible that the protected endpoint will be
438 behind a NAT. In that case, the IP address as seen by the security
439 gateway will not be the same as the IP address sent by the protected
440 endpoint, and packets will have to be UDP encapsulated in order to be
447 Kaufman, et al. Expires August 27, 2006 [Page 8]
449 Internet-Draft IKEv2bis February 2006
452 1.1.4. Other Scenarios
454 Other scenarios are possible, as are nested combinations of the
455 above. One notable example combines aspects of 1.1.1 and 1.1.3. A
456 subnet may make all external accesses through a remote security
457 gateway using an IPsec tunnel, where the addresses on the subnet are
458 routed to the security gateway by the rest of the Internet. An
459 example would be someone's home network being virtually on the
460 Internet with static IP addresses even though connectivity is
461 provided by an ISP that assigns a single dynamically assigned IP
462 address to the user's security gateway (where the static IP addresses
463 and an IPsec relay are provided by a third party located elsewhere).
465 1.2. The Initial Exchanges
467 Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH
468 exchanges (known in IKEv1 as Phase 1). These initial exchanges
469 normally consist of four messages, though in some scenarios that
470 number can grow. All communications using IKE consist of request/
471 response pairs. We'll describe the base exchange first, followed by
472 variations. The first pair of messages (IKE_SA_INIT) negotiate
473 cryptographic algorithms, exchange nonces, and do a Diffie-Hellman
476 The second pair of messages (IKE_AUTH) authenticate the previous
477 messages, exchange identities and certificates, and establish the
478 first CHILD_SA. Parts of these messages are encrypted and integrity
479 protected with keys established through the IKE_SA_INIT exchange, so
480 the identities are hidden from eavesdroppers and all fields in all
481 the messages are authenticated.
483 In the following descriptions, the payloads contained in the message
484 are indicated by names as listed below.
503 Kaufman, et al. Expires August 27, 2006 [Page 9]
505 Internet-Draft IKEv2bis February 2006
509 -----------------------------------------
512 CERTREQ Certificate Request
516 EAP Extensible Authentication
518 IDi Identification - Initiator
519 IDr Identification - Responder
523 SA Security Association
524 TSi Traffic Selector - Initiator
525 TSr Traffic Selector - Responder
528 The details of the contents of each payload are described in section
529 3. Payloads that may optionally appear will be shown in brackets,
530 such as [CERTREQ], indicate that optionally a certificate request
531 payload can be included.
533 {{ Clarif-7.10 }} Many payloads contain fields marked as "RESERVED".
534 Some payloads in IKEv2 (and historically in IKEv1) are not aligned to
537 The initial exchanges are as follows:
540 -------------------------------------------------------------------
541 HDR, SAi1, KEi, Ni -->
543 HDR contains the Security Parameter Indexes (SPIs), version numbers,
544 and flags of various sorts. The SAi1 payload states the
545 cryptographic algorithms the initiator supports for the IKE_SA. The
546 KE payload sends the initiator's Diffie-Hellman value. Ni is the
549 <-- HDR, SAr1, KEr, Nr, [CERTREQ]
551 The responder chooses a cryptographic suite from the initiator's
552 offered choices and expresses that choice in the SAr1 payload,
553 completes the Diffie-Hellman exchange with the KEr payload, and sends
554 its nonce in the Nr payload.
559 Kaufman, et al. Expires August 27, 2006 [Page 10]
561 Internet-Draft IKEv2bis February 2006
564 At this point in the negotiation, each party can generate SKEYSEED,
565 from which all keys are derived for that IKE_SA. All but the headers
566 of all the messages that follow are encrypted and integrity
567 protected. The keys used for the encryption and integrity protection
568 are derived from SKEYSEED and are known as SK_e (encryption) and SK_a
569 (authentication, a.k.a. integrity protection). A separate SK_e and
570 SK_a is computed for each direction. In addition to the keys SK_e
571 and SK_a derived from the DH value for protection of the IKE_SA,
572 another quantity SK_d is derived and used for derivation of further
573 keying material for CHILD_SAs. The notation SK { ... } indicates
574 that these payloads are encrypted and integrity protected using that
575 direction's SK_e and SK_a.
577 HDR, SK {IDi, [CERT,] [CERTREQ,]
581 The initiator asserts its identity with the IDi payload, proves
582 knowledge of the secret corresponding to IDi and integrity protects
583 the contents of the first message using the AUTH payload (see
584 Section 2.15). It might also send its certificate(s) in CERT
585 payload(s) and a list of its trust anchors in CERTREQ payload(s). If
586 any CERT payloads are included, the first certificate provided MUST
587 contain the public key used to verify the AUTH field. The optional
588 payload IDr enables the initiator to specify which of the responder's
589 identities it wants to talk to. This is useful when the machine on
590 which the responder is running is hosting multiple identities at the
591 same IP address. The initiator begins negotiation of a CHILD_SA
592 using the SAi2 payload. The final fields (starting with SAi2) are
593 described in the description of the CREATE_CHILD_SA exchange.
595 <-- HDR, SK {IDr, [CERT,] AUTH,
598 The responder asserts its identity with the IDr payload, optionally
599 sends one or more certificates (again with the certificate containing
600 the public key used to verify AUTH listed first), authenticates its
601 identity and protects the integrity of the second message with the
602 AUTH payload, and completes negotiation of a CHILD_SA with the
603 additional fields described below in the CREATE_CHILD_SA exchange.
605 The recipients of messages 3 and 4 MUST verify that all signatures
606 and MACs are computed correctly and that the names in the ID payloads
607 correspond to the keys used to generate the AUTH payload.
609 {{ Clarif-4.2}} If creating the CHILD_SA during the IKE_AUTH exchange
610 fails for some reason, the IKE_SA is still created as usual. The
611 list of responses in the IKE_AUTH exchange that do not prevent an
615 Kaufman, et al. Expires August 27, 2006 [Page 11]
617 Internet-Draft IKEv2bis February 2006
620 IKE_SA from being set up include at least the following:
621 NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,
622 INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED.
624 {{ Clarif-4.3 }} Note that IKE_AUTH messages do not contain KEi/KEr
625 or Ni/Nr payloads. Thus, the SA payload in IKE_AUTH exchange cannot
626 contain Transform Type 4 (Diffie-Hellman Group) with any value other
627 than NONE. Implementations SHOULD NOT send such a transform because
628 it cannot be interpreted consistently, and implementations SHOULD
629 ignore any such tranforms they receive.
631 1.3. The CREATE_CHILD_SA Exchange
633 {{ This is a heavy rewrite of most of this section. The major
634 organization changes are described in Clarif-4.1 and Clarif-5.1. }}
636 The CREATE_CHILD_SA exchange is used to create new CHILD_SAs and to
637 rekey both IKE_SAs and CHILD_SAs. This exchange consists of a single
638 request/response pair, and some of its function was referred to as a
639 phase 2 exchange in IKEv1. It MAY be initiated by either end of the
640 IKE_SA after the initial exchanges are completed.
642 All messages following the initial exchange are cryptographically
643 protected using the cryptographic algorithms and keys negotiated in
644 the first two messages of the IKE exchange. These subsequent
645 messages use the syntax of the Encrypted Payload described in
646 Section 3.14. All subsequent messages include an Encrypted Payload,
647 even if they are referred to in the text as "empty". For both
648 messages in the CREATE_CHILD_SA, the message following the header is
649 encrypted and the message including the header is integrity protected
650 using the cryptographic algorithms negotiated for the IKE_SA.
652 The CREATE_CHILD_SA is also used for rekeying IKE_SAs and CHILD_SAs.
653 An SA is rekeyed by creating a new SA and then deleting the old one.
654 This section describes the first part of rekeying, the creation of
655 new SAs; Section 2.8 covers the mechanics of rekeying, including
656 moving traffic from old to new SAs and the deletion of the old SAs.
657 The two sections must be read together to understand the entire
660 Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this
661 section the term initiator refers to the endpoint initiating this
662 exchange. An implementation MAY refuse all CREATE_CHILD_SA requests
665 The CREATE_CHILD_SA request MAY optionally contain a KE payload for
666 an additional Diffie-Hellman exchange to enable stronger guarantees
667 of forward secrecy for the CHILD_SA. The keying material for the
671 Kaufman, et al. Expires August 27, 2006 [Page 12]
673 Internet-Draft IKEv2bis February 2006
676 CHILD_SA is a function of SK_d established during the establishment
677 of the IKE_SA, the nonces exchanged during the CREATE_CHILD_SA
678 exchange, and the Diffie-Hellman value (if KE payloads are included
679 in the CREATE_CHILD_SA exchange).
681 If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of
682 the SA offers MUST include the Diffie-Hellman group of the KEi. The
683 Diffie-Hellman group of the KEi MUST be an element of the group the
684 initiator expects the responder to accept (additional Diffie-Hellman
685 groups can be proposed). If the responder rejects the Diffie-Hellman
686 group of the KEi payload, the responder MUST reject the request and
687 indicate its preferred Diffie-Hellman group in the INVALID_KE_PAYLOAD
688 Notification payload. In the case of such a rejection, the
689 CREATE_CHILD_SA exchange fails, and the initiator will probably retry
690 the exchange with a Diffie-Hellman proposal and KEi in the group that
691 the responder gave in the INVALID_KE_PAYLOAD.
693 1.3.1. Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange
695 A CHILD_SA may be created by sending a CREATE_CHILD_SA request. The
696 CREATE_CHILD_SA request for creating a new CHILD_SA is:
699 -------------------------------------------------------------------
700 HDR, SK {SA, Ni, [KEi],
703 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
704 payload, optionally a Diffie-Hellman value in the KEi payload, and
705 the proposed traffic selectors for the proposed CHILD_SA in the TSi
708 The CREATE_CHILD_SA response for creating a new CHILD_SA is:
710 <-- HDR, SK {SA, Nr, [KEr],
713 The responder replies (using the same Message ID to respond) with the
714 accepted offer in an SA payload, and a Diffie-Hellman value in the
715 KEr payload if KEi was included in the request and the selected
716 cryptographic suite includes that group.
718 The traffic selectors for traffic to be sent on that SA are specified
719 in the TS payloads in the response, which may be a subset of what the
720 initiator of the CHILD_SA proposed.
727 Kaufman, et al. Expires August 27, 2006 [Page 13]
729 Internet-Draft IKEv2bis February 2006
732 1.3.2. Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange
734 The CREATE_CHILD_SA request for rekeying an IKE_SA is:
737 -------------------------------------------------------------------
738 HDR, SK {SA, Ni, KEi} -->
740 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
741 payload, and a Diffie-Hellman value in the KEi payload. New
742 initiator and responder SPIs are supplied in the SPI fields.
744 The CREATE_CHILD_SA response for rekeying an IKE_SA is:
746 <-- HDR, SK {SA, Nr, KEr}
748 The responder replies (using the same Message ID to respond) with the
749 accepted offer in an SA payload, and a Diffie-Hellman value in the
750 KEr payload if the selected cryptographic suite includes that group.
752 The new IKE_SA has its message counters set to 0, regardless of what
753 they were in the earlier IKE_SA. The window size starts at 1 for any
756 KEi and KEr are required for rekeying an IKE_SA.
758 1.3.3. Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange
760 The CREATE_CHILD_SA request for rekeying a CHILD_SA is:
763 -------------------------------------------------------------------
764 HDR, SK {N, SA, Ni, [KEi],
767 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
768 payload, optionally a Diffie-Hellman value in the KEi payload, and
769 the proposed traffic selectors for the proposed CHILD_SA in the TSi
770 and TSr payloads. When rekeying an existing CHILD_SA, the leading N
771 payload of type REKEY_SA MUST be included and MUST give the SPI (as
772 they would be expected in the headers of inbound packets) of the SAs
775 The CREATE_CHILD_SA response for rekeying a CHILD_SA is:
777 <-- HDR, SK {SA, Nr, [KEr],
783 Kaufman, et al. Expires August 27, 2006 [Page 14]
785 Internet-Draft IKEv2bis February 2006
788 The responder replies (using the same Message ID to respond) with the
789 accepted offer in an SA payload, and a Diffie-Hellman value in the
790 KEr payload if KEi was included in the request and the selected
791 cryptographic suite includes that group.
793 The traffic selectors for traffic to be sent on that SA are specified
794 in the TS payloads in the response, which may be a subset of what the
795 initiator of the CHILD_SA proposed.
797 1.4. The INFORMATIONAL Exchange
799 At various points during the operation of an IKE_SA, peers may desire
800 to convey control messages to each other regarding errors or
801 notifications of certain events. To accomplish this, IKE defines an
802 INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur
803 after the initial exchanges and are cryptographically protected with
806 Control messages that pertain to an IKE_SA MUST be sent under that
807 IKE_SA. Control messages that pertain to CHILD_SAs MUST be sent
808 under the protection of the IKE_SA which generated them (or its
809 successor if the IKE_SA was replaced for the purpose of rekeying).
811 Messages in an INFORMATIONAL exchange contain zero or more
812 Notification, Delete, and Configuration payloads. The Recipient of
813 an INFORMATIONAL exchange request MUST send some response (else the
814 Sender will assume the message was lost in the network and will
815 retransmit it). That response MAY be a message with no payloads.
816 The request message in an INFORMATIONAL exchange MAY also contain no
817 payloads. This is the expected way an endpoint can ask the other
818 endpoint to verify that it is alive.
820 {{ Clarif-5.6 }} ESP and AH SAs always exist in pairs, with one SA in
821 each direction. When an SA is closed, both members of the pair MUST
822 be closed (that is, deleted). When SAs are nested, as when data (and
823 IP headers if in tunnel mode) are encapsulated first with IPComp,
824 then with ESP, and finally with AH between the same pair of
825 endpoints, all of the SAs MUST be deleted together. Each endpoint
826 MUST close its incoming SAs and allow the other endpoint to close the
827 other SA in each pair. To delete an SA, an INFORMATIONAL exchange
828 with one or more delete payloads is sent listing the SPIs (as they
829 would be expected in the headers of inbound packets) of the SAs to be
830 deleted. The recipient MUST close the designated SAs. {{ Clarif-5.7
831 }} Note that one never sends delete payloads for the two sides of an
832 SA in a single message. If there are many SAs to delete at the same
833 time (such as for nested SAs), one includes delete payloads for in
834 inbound half of each SA pair in your Informational exchange.
839 Kaufman, et al. Expires August 27, 2006 [Page 15]
841 Internet-Draft IKEv2bis February 2006
844 Normally, the reply in the INFORMATIONAL exchange will contain delete
845 payloads for the paired SAs going in the other direction. There is
846 one exception. If by chance both ends of a set of SAs independently
847 decide to close them, each may send a delete payload and the two
848 requests may cross in the network. If a node receives a delete
849 request for SAs for which it has already issued a delete request, it
850 MUST delete the outgoing SAs while processing the request and the
851 incoming SAs while processing the response. In that case, the
852 responses MUST NOT include delete payloads for the deleted SAs, since
853 that would result in duplicate deletion and could in theory delete
856 {{ Demoted the SHOULD }} Half-closed connections are anomalous, and a
857 node with auditing capability should probably audit their existence
858 if they persist. Note that this specification nowhere specifies time
859 periods, so it is up to individual endpoints to decide how long to
860 wait. A node MAY refuse to accept incoming data on half-closed
861 connections but MUST NOT unilaterally close them and reuse the SPIs.
862 If connection state becomes sufficiently messed up, a node MAY close
863 the IKE_SA; doing so will implicitly close all SAs negotiated under
864 it. It can then rebuild the SAs it needs on a clean base under a new
865 IKE_SA. {{ Clarif-5.8 }} The response to a request that deletes the
866 IKE_SA is an empty Informational response.
868 The INFORMATIONAL exchange is defined as:
871 -------------------------------------------------------------------
874 <-- HDR, SK {[N,] [D,]
877 The processing of an INFORMATIONAL exchange is determined by its
880 1.5. Informational Messages outside of an IKE_SA
882 If an encrypted IKE packet arrives on port 500 or 4500 with an
883 unrecognized SPI, it could be because the receiving node has recently
884 crashed and lost state or because of some other system malfunction or
885 attack. If the receiving node has an active IKE_SA to the IP address
886 from whence the packet came, it MAY send a notification of the
887 wayward packet over that IKE_SA in an INFORMATIONAL exchange. If it
888 does not have such an IKE_SA, it MAY send an Informational message
889 without cryptographic protection to the source IP address. Such a
890 message is not part of an informational exchange, and the receiving
891 node MUST NOT respond to it. Doing so could cause a message loop.
895 Kaufman, et al. Expires August 27, 2006 [Page 16]
897 Internet-Draft IKEv2bis February 2006
900 {{ Clarif-7.7 }} There are two cases when such a one-way notification
901 is sent: INVALID_IKE_SPI and INVALID_SPI. These notifications are
902 sent outside of an IKE_SA. Note that such notifications are
903 explicitly not Informational exchanges; these are one-way messages
904 that must not be responded to. In case of INVALID_IKE_SPI, the
905 message sent is a response message, and thus it is sent to the IP
906 address and port from whence it came with the same IKE SPIs and the
907 Message ID copied. In case of INVALID_SPI, however, there are no IKE
908 SPI values that would be meaningful to the recipient of such a
909 notification. Using zero values or random values are both
912 1.6. Requirements Terminology
914 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
915 "MAY" that appear in this document are to be interpreted as described
918 The term "Expert Review" is to be interpreted as defined in
921 1.7. Differences Between RFC 4306 and This Document
923 {{ Added this entire section, including this recursive remark. }}
925 This document contains clarifications and amplifications to IKEv2
926 [IKEV2]. The clarifications are mostly based on [Clarif]. The
927 changes listed in that document were discussed in the IPsec Working
928 Group and, after the Working Group was disbanded, on the IPsec
929 mailing list. That document contains detailed explanations of areas
930 that were unclear in IKEv2, and is thus useful to implementers of
933 The protocol described in this document retains the same major
934 version number (2) and minor version number (0) as was used in RFC
937 In the body of this document, notes that are enclosed in double curly
938 braces {{ such as this }} point out changes from IKEv2. Changes that
939 come from [Clarif] are marked with the section from that document,
940 such as "{{ Clarif-2.10 }}".
942 This document also make the figures and references a bit more regular
945 IKEv2 developers have noted that the SHOULD-level requirements are
946 often unclear in that they don't say when it is OK to not obey the
947 requirements. They also have noted that there are MUST-level
951 Kaufman, et al. Expires August 27, 2006 [Page 17]
953 Internet-Draft IKEv2bis February 2006
956 requirements that are not related to interoperability. This document
957 has more explanation of some of these requirements. All non-
958 capitalized uses of the words SHOULD and MUST now mean their normal
959 English sense, not the interoperability sense of [MUSTSHOULD].
961 IKEv2 (and IKEv1) developers have noted that there is a great deal of
962 material in the tables of codes in Section 3.10. This leads to
963 implementers not having all the needed information in the main body
964 of the docment. A later version of this document may move much of
965 the material from those tables into the associated parts of the main
966 body of the document.
968 A later version of this document will probably have all the {{ }}
969 comments removed from the body of the document and instead appear in
973 2. IKE Protocol Details and Variations
975 IKE normally listens and sends on UDP port 500, though IKE messages
976 may also be received on UDP port 4500 with a slightly different
977 format (see Section 2.23). Since UDP is a datagram (unreliable)
978 protocol, IKE includes in its definition recovery from transmission
979 errors, including packet loss, packet replay, and packet forgery.
980 IKE is designed to function so long as (1) at least one of a series
981 of retransmitted packets reaches its destination before timing out;
982 and (2) the channel is not so full of forged and replayed packets so
983 as to exhaust the network or CPU capacities of either endpoint. Even
984 in the absence of those minimum performance requirements, IKE is
985 designed to fail cleanly (as though the network were broken).
987 Although IKEv2 messages are intended to be short, they contain
988 structures with no hard upper bound on size (in particular, X.509
989 certificates), and IKEv2 itself does not have a mechanism for
990 fragmenting large messages. IP defines a mechanism for fragmentation
991 of oversize UDP messages, but implementations vary in the maximum
992 message size supported. Furthermore, use of IP fragmentation opens
993 an implementation to denial of service attacks [DOSUDPPROT].
994 Finally, some NAT and/or firewall implementations may block IP
997 All IKEv2 implementations MUST be able to send, receive, and process
998 IKE messages that are up to 1280 bytes long, and they SHOULD be able
999 to send, receive, and process messages that are up to 3000 bytes
1000 long. {{ Demoted the SHOULD }} IKEv2 implementations need to be aware
1001 of the maximum UDP message size supported and MAY shorten messages by
1002 leaving out some certificates or cryptographic suite proposals if
1003 that will keep messages below the maximum. Use of the "Hash and URL"
1007 Kaufman, et al. Expires August 27, 2006 [Page 18]
1009 Internet-Draft IKEv2bis February 2006
1012 formats rather than including certificates in exchanges where
1013 possible can avoid most problems. {{ Demoted the SHOULD }}
1014 Implementations and configuration need to keep in mind, however, that
1015 if the URL lookups are possible only after the IPsec SA is
1016 established, recursion issues could prevent this technique from
1019 {{ Clarif-7.5 }} All packets sent on port 4500 MUST begin with the
1020 prefix of four zeros; otherwise, the receiver won't know how to
1023 2.1. Use of Retransmission Timers
1025 All messages in IKE exist in pairs: a request and a response. The
1026 setup of an IKE_SA normally consists of two request/response pairs.
1027 Once the IKE_SA is set up, either end of the security association may
1028 initiate requests at any time, and there can be many requests and
1029 responses "in flight" at any given moment. But each message is
1030 labeled as either a request or a response, and for each request/
1031 response pair one end of the security association is the initiator
1032 and the other is the responder.
1034 For every pair of IKE messages, the initiator is responsible for
1035 retransmission in the event of a timeout. The responder MUST never
1036 retransmit a response unless it receives a retransmission of the
1037 request. In that event, the responder MUST ignore the retransmitted
1038 request except insofar as it triggers a retransmission of the
1039 response. The initiator MUST remember each request until it receives
1040 the corresponding response. The responder MUST remember each
1041 response until it receives a request whose sequence number is larger
1042 than the sequence number in the response plus its window size (see
1045 IKE is a reliable protocol, in the sense that the initiator MUST
1046 retransmit a request until either it receives a corresponding reply
1047 OR it deems the IKE security association to have failed and it
1048 discards all state associated with the IKE_SA and any CHILD_SAs
1049 negotiated using that IKE_SA.
1051 2.2. Use of Sequence Numbers for Message ID
1053 Every IKE message contains a Message ID as part of its fixed header.
1054 This Message ID is used to match up requests and responses, and to
1055 identify retransmissions of messages.
1057 The Message ID is a 32-bit quantity, which is zero for the first IKE
1058 request in each direction. {{ Clarif-3.10 }} When the IKE_AUTH
1059 exchange does not use EAP, the IKE_SA initial setup messages will
1063 Kaufman, et al. Expires August 27, 2006 [Page 19]
1065 Internet-Draft IKEv2bis February 2006
1068 always be numbered 0 and 1. When EAP is used, each pair of messages
1069 have their message numbers incremented; the first pair of AUTH
1070 messages will have an ID of 1, the second will be 2, and so on.
1072 Each endpoint in the IKE Security Association maintains two "current"
1073 Message IDs: the next one to be used for a request it initiates and
1074 the next one it expects to see in a request from the other end.
1075 These counters increment as requests are generated and received.
1076 Responses always contain the same message ID as the corresponding
1077 request. That means that after the initial exchange, each integer n
1078 may appear as the message ID in four distinct messages: the nth
1079 request from the original IKE initiator, the corresponding response,
1080 the nth request from the original IKE responder, and the
1081 corresponding response. If the two ends make very different numbers
1082 of requests, the Message IDs in the two directions can be very
1083 different. There is no ambiguity in the messages, however, because
1084 the (I)nitiator and (R)esponse bits in the message header specify
1085 which of the four messages a particular one is.
1087 {{ Clarif-2.2 }} The Message ID for IKE_SA_INIT messages is always
1088 zero, including for retries of the message due to responses such as
1089 COOKIE and INVALID_KE_PAYLOAD.
1091 Note that Message IDs are cryptographically protected and provide
1092 protection against message replays. In the unlikely event that
1093 Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be
1094 closed. Rekeying an IKE_SA resets the sequence numbers.
1096 {{ Clarif-2.3 }} When a responder receives an IKE_SA_INIT request, it
1097 has to determine whether the packet is a retransmission belonging to
1098 an existing "half-open" IKE_SA (in which case the responder
1099 retransmits the same response), or a new request (in which case the
1100 responder creates a new IKE_SA and sends a fresh response), or it is
1101 a retransmission of a now-opened IKE_SA (in whcih case the responder
1102 ignores it). It is not sufficient to use the initiator's SPI and/or
1103 IP address to differentiate between the two cases because two
1104 different peers behind a single NAT could choose the same initiator
1105 SPI. Instead, a robust responder will do the IKE_SA lookup using the
1106 whole packet, its hash, or the Ni payload.
1108 2.3. Window Size for Overlapping Requests
1110 In order to maximize IKE throughput, an IKE endpoint MAY issue
1111 multiple requests before getting a response to any of them if the
1112 other endpoint has indicated its ability to handle such requests.
1113 For simplicity, an IKE implementation MAY choose to process requests
1114 strictly in order and/or wait for a response to one request before
1115 issuing another. Certain rules must be followed to ensure
1119 Kaufman, et al. Expires August 27, 2006 [Page 20]
1121 Internet-Draft IKEv2bis February 2006
1124 interoperability between implementations using different strategies.
1126 After an IKE_SA is set up, either end can initiate one or more
1127 requests. These requests may pass one another over the network. An
1128 IKE endpoint MUST be prepared to accept and process a request while
1129 it has a request outstanding in order to avoid a deadlock in this
1130 situation. {{ Downgraded the SHOULD }} An IKE endpoint may also
1131 accept and process multiple requests while it has a request
1134 An IKE endpoint MUST wait for a response to each of its messages
1135 before sending a subsequent message unless it has received a
1136 SET_WINDOW_SIZE Notify message from its peer informing it that the
1137 peer is prepared to maintain state for multiple outstanding messages
1138 in order to allow greater throughput.
1140 An IKE endpoint MUST NOT exceed the peer's stated window size for
1141 transmitted IKE requests. In other words, if the responder stated
1142 its window size is N, then when the initiator needs to make a request
1143 X, it MUST wait until it has received responses to all requests up
1144 through request X-N. An IKE endpoint MUST keep a copy of (or be able
1145 to regenerate exactly) each request it has sent until it receives the
1146 corresponding response. An IKE endpoint MUST keep a copy of (or be
1147 able to regenerate exactly) the number of previous responses equal to
1148 its declared window size in case its response was lost and the
1149 initiator requests its retransmission by retransmitting the request.
1151 An IKE endpoint supporting a window size greater than one ought to be
1152 capable of processing incoming requests out of order to maximize
1153 performance in the event of network failures or packet reordering.
1155 {{ Clarif-7.3 }} The window size is normally a (possibly
1156 configurable) property of a particular implementation, and is not
1157 related to congestion control (unlike the window size in TCP, for
1158 example). In particular, it is not defined what the responder should
1159 do when it receives a SET_WINDOW_SIZE notification containing a
1160 smaller value than is currently in effect. Thus, there is currently
1161 no way to reduce the window size of an existing IKE_SA; you can only
1162 increase it. When rekeying an IKE_SA, the new IKE_SA starts with
1163 window size 1 until it is explicitly increased by sending a new
1164 SET_WINDOW_SIZE notification.
1166 2.4. State Synchronization and Connection Timeouts
1168 An IKE endpoint is allowed to forget all of its state associated with
1169 an IKE_SA and the collection of corresponding CHILD_SAs at any time.
1170 This is the anticipated behavior in the event of an endpoint crash
1171 and restart. It is important when an endpoint either fails or
1175 Kaufman, et al. Expires August 27, 2006 [Page 21]
1177 Internet-Draft IKEv2bis February 2006
1180 reinitializes its state that the other endpoint detect those
1181 conditions and not continue to waste network bandwidth by sending
1182 packets over discarded SAs and having them fall into a black hole.
1184 Since IKE is designed to operate in spite of Denial of Service (DoS)
1185 attacks from the network, an endpoint MUST NOT conclude that the
1186 other endpoint has failed based on any routing information (e.g.,
1187 ICMP messages) or IKE messages that arrive without cryptographic
1188 protection (e.g., Notify messages complaining about unknown SPIs).
1189 An endpoint MUST conclude that the other endpoint has failed only
1190 when repeated attempts to contact it have gone unanswered for a
1191 timeout period or when a cryptographically protected INITIAL_CONTACT
1192 notification is received on a different IKE_SA to the same
1193 authenticated identity. {{ Demoted the SHOULD }} An endpoint should
1194 suspect that the other endpoint has failed based on routing
1195 information and initiate a request to see whether the other endpoint
1196 is alive. To check whether the other side is alive, IKE specifies an
1197 empty INFORMATIONAL message that (like all IKE requests) requires an
1198 acknowledgement (note that within the context of an IKE_SA, an
1199 "empty" message consists of an IKE header followed by an Encrypted
1200 payload that contains no payloads). If a cryptographically protected
1201 message has been received from the other side recently, unprotected
1202 notifications MAY be ignored. Implementations MUST limit the rate at
1203 which they take actions based on unprotected messages.
1205 Numbers of retries and lengths of timeouts are not covered in this
1206 specification because they do not affect interoperability. It is
1207 suggested that messages be retransmitted at least a dozen times over
1208 a period of at least several minutes before giving up on an SA, but
1209 different environments may require different rules. To be a good
1210 network citizen, retranmission times MUST increase exponentially to
1211 avoid flooding the network and making an existing congestion
1212 situation worse. If there has only been outgoing traffic on all of
1213 the SAs associated with an IKE_SA, it is essential to confirm
1214 liveness of the other endpoint to avoid black holes. If no
1215 cryptographically protected messages have been received on an IKE_SA
1216 or any of its CHILD_SAs recently, the system needs to perform a
1217 liveness check in order to prevent sending messages to a dead peer.
1218 Receipt of a fresh cryptographically protected message on an IKE_SA
1219 or any of its CHILD_SAs ensures liveness of the IKE_SA and all of its
1220 CHILD_SAs. Note that this places requirements on the failure modes
1221 of an IKE endpoint. An implementation MUST NOT continue sending on
1222 any SA if some failure prevents it from receiving on all of the
1223 associated SAs. If CHILD_SAs can fail independently from one another
1224 without the associated IKE_SA being able to send a delete message,
1225 then they MUST be negotiated by separate IKE_SAs.
1227 There is a Denial of Service attack on the initiator of an IKE_SA
1231 Kaufman, et al. Expires August 27, 2006 [Page 22]
1233 Internet-Draft IKEv2bis February 2006
1236 that can be avoided if the initiator takes the proper care. Since
1237 the first two messages of an SA setup are not cryptographically
1238 protected, an attacker could respond to the initiator's message
1239 before the genuine responder and poison the connection setup attempt.
1240 To prevent this, the initiator MAY be willing to accept multiple
1241 responses to its first message, treat each as potentially legitimate,
1242 respond to it, and then discard all the invalid half-open connections
1243 when it receives a valid cryptographically protected response to any
1244 one of its requests. Once a cryptographically valid response is
1245 received, all subsequent responses should be ignored whether or not
1246 they are cryptographically valid.
1248 Note that with these rules, there is no reason to negotiate and agree
1249 upon an SA lifetime. If IKE presumes the partner is dead, based on
1250 repeated lack of acknowledgement to an IKE message, then the IKE SA
1251 and all CHILD_SAs set up through that IKE_SA are deleted.
1253 An IKE endpoint may at any time delete inactive CHILD_SAs to recover
1254 resources used to hold their state. If an IKE endpoint chooses to
1255 delete CHILD_SAs, it MUST send Delete payloads to the other end
1256 notifying it of the deletion. It MAY similarly time out the IKE_SA.
1257 {{ Clarified the SHOULD }} Closing the IKE_SA implicitly closes all
1258 associated CHILD_SAs. In this case, an IKE endpoint SHOULD send a
1259 Delete payload indicating that it has closed the IKE_SA unless the
1260 other endpoint is no longer responding.
1262 2.5. Version Numbers and Forward Compatibility
1264 This document describes version 2.0 of IKE, meaning the major version
1265 number is 2 and the minor version number is 0. {{ Restated the
1266 relationship to RFC 4306 }} This document is a clarification of
1267 [IKEV2]. It is likely that some implementations will want to support
1268 version 1.0 and version 2.0, and in the future, other versions.
1270 The major version number should be incremented only if the packet
1271 formats or required actions have changed so dramatically that an
1272 older version node would not be able to interoperate with a newer
1273 version node if it simply ignored the fields it did not understand
1274 and took the actions specified in the older specification. The minor
1275 version number indicates new capabilities, and MUST be ignored by a
1276 node with a smaller minor version number, but used for informational
1277 purposes by the node with the larger minor version number. For
1278 example, it might indicate the ability to process a newly defined
1279 notification message. The node with the larger minor version number
1280 would simply note that its correspondent would not be able to
1281 understand that message and therefore would not send it.
1283 If an endpoint receives a message with a higher major version number,
1287 Kaufman, et al. Expires August 27, 2006 [Page 23]
1289 Internet-Draft IKEv2bis February 2006
1292 it MUST drop the message and SHOULD send an unauthenticated
1293 notification message containing the highest version number it
1294 supports. If an endpoint supports major version n, and major version
1295 m, it MUST support all versions between n and m. If it receives a
1296 message with a major version that it supports, it MUST respond with
1297 that version number. In order to prevent two nodes from being
1298 tricked into corresponding with a lower major version number than the
1299 maximum that they both support, IKE has a flag that indicates that
1300 the node is capable of speaking a higher major version number.
1302 Thus, the major version number in the IKE header indicates the
1303 version number of the message, not the highest version number that
1304 the transmitter supports. If the initiator is capable of speaking
1305 versions n, n+1, and n+2, and the responder is capable of speaking
1306 versions n and n+1, then they will negotiate speaking n+1, where the
1307 initiator will set the flag indicating its ability to speak a higher
1308 version. If they mistakenly (perhaps through an active attacker
1309 sending error messages) negotiate to version n, then both will notice
1310 that the other side can support a higher version number, and they
1311 MUST break the connection and reconnect using version n+1.
1313 Note that IKEv1 does not follow these rules, because there is no way
1314 in v1 of noting that you are capable of speaking a higher version
1315 number. So an active attacker can trick two v2-capable nodes into
1316 speaking v1. {{ Demoted the SHOULD }} When a v2-capable node
1317 negotiates down to v1, it should note that fact in its logs.
1319 Also for forward compatibility, all fields marked RESERVED MUST be
1320 set to zero by an implementation running version 2.0 or later, and
1321 their content MUST be ignored by an implementation running version
1322 2.0 or later ("Be conservative in what you send and liberal in what
1323 you receive"). In this way, future versions of the protocol can use
1324 those fields in a way that is guaranteed to be ignored by
1325 implementations that do not understand them. Similarly, payload
1326 types that are not defined are reserved for future use;
1327 implementations of a version where they are undefined MUST skip over
1328 those payloads and ignore their contents.
1330 IKEv2 adds a "critical" flag to each payload header for further
1331 flexibility for forward compatibility. If the critical flag is set
1332 and the payload type is unrecognized, the message MUST be rejected
1333 and the response to the IKE request containing that payload MUST
1334 include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an
1335 unsupported critical payload was included. If the critical flag is
1336 not set and the payload type is unsupported, that payload MUST be
1339 {{ Demoted the SHOULD in the second clause }}Although new payload
1343 Kaufman, et al. Expires August 27, 2006 [Page 24]
1345 Internet-Draft IKEv2bis February 2006
1348 types may be added in the future and may appear interleaved with the
1349 fields defined in this specification, implementations MUST send the
1350 payloads defined in this specification in the order shown in the
1351 figures in Section 2; implementations are explicitly allowed to
1352 reject as invalid a message with those payloads in any other order.
1356 The term "cookies" originates with Karn and Simpson [PHOTURIS] in
1357 Photuris, an early proposal for key management with IPsec, and it has
1358 persisted. The Internet Security Association and Key Management
1359 Protocol (ISAKMP) [ISAKMP] fixed message header includes two eight-
1360 octet fields titled "cookies", and that syntax is used by both IKEv1
1361 and IKEv2 though in IKEv2 they are referred to as the IKE SPI and
1362 there is a new separate field in a Notify payload holding the cookie.
1363 The initial two eight-octet fields in the header are used as a
1364 connection identifier at the beginning of IKE packets. {{ Demoted the
1365 SHOULD }} Each endpoint chooses one of the two SPIs and needs to
1366 choose them so as to be unique identifiers of an IKE_SA. An SPI
1367 value of zero is special and indicates that the remote SPI value is
1368 not yet known by the sender.
1370 Unlike ESP and AH where only the recipient's SPI appears in the
1371 header of a message, in IKE the sender's SPI is also sent in every
1372 message. Since the SPI chosen by the original initiator of the
1373 IKE_SA is always sent first, an endpoint with multiple IKE_SAs open
1374 that wants to find the appropriate IKE_SA using the SPI it assigned
1375 must look at the I(nitiator) Flag bit in the header to determine
1376 whether it assigned the first or the second eight octets.
1378 In the first message of an initial IKE exchange, the initiator will
1379 not know the responder's SPI value and will therefore set that field
1382 An expected attack against IKE is state and CPU exhaustion, where the
1383 target is flooded with session initiation requests from forged IP
1384 addresses. This attack can be made less effective if an
1385 implementation of a responder uses minimal CPU and commits no state
1386 to an SA until it knows the initiator can receive packets at the
1387 address from which it claims to be sending them. To accomplish this,
1388 a responder SHOULD -- when it detects a large number of half-open
1389 IKE_SAs -- reject initial IKE messages unless they contain a Notify
1390 payload of type COOKIE. {{ Clarified the SHOULD }} If the responder
1391 wants to set up an SA, it SHOULD instead send an unprotected IKE
1392 message as a response and include COOKIE Notify payload with the
1393 cookie data to be returned. Initiators who receive such responses
1394 MUST retry the IKE_SA_INIT with a Notify payload of type COOKIE
1395 containing the responder supplied cookie data as the first payload
1399 Kaufman, et al. Expires August 27, 2006 [Page 25]
1401 Internet-Draft IKEv2bis February 2006
1404 and all other payloads unchanged. The initial exchange will then be
1408 -------------------------------------------------------------------
1409 HDR(A,0), SAi1, KEi, Ni -->
1410 <-- HDR(A,0), N(COOKIE)
1411 HDR(A,0), N(COOKIE), SAi1,
1413 <-- HDR(A,B), SAr1, KEr,
1415 HDR(A,B), SK {IDi, [CERT,]
1416 [CERTREQ,] [IDr,] AUTH,
1418 <-- HDR(A,B), SK {IDr, [CERT,]
1419 AUTH, SAr2, TSi, TSr}
1421 The first two messages do not affect any initiator or responder state
1422 except for communicating the cookie. In particular, the message
1423 sequence numbers in the first four messages will all be zero and the
1424 message sequence numbers in the last two messages will be one. 'A'
1425 is the SPI assigned by the initiator, while 'B' is the SPI assigned
1428 {{ Clarif-2.1 }} Because the responder's SPI identifies security-
1429 related state held by the responder, and in this case no state is
1430 created, the responder sends a zero value for the responder's SPI.
1432 {{ Demoted the SHOULD }} An IKE implementation should implement its
1433 responder cookie generation in such a way as to not require any saved
1434 state to recognize its valid cookie when the second IKE_SA_INIT
1435 message arrives. The exact algorithms and syntax they use to
1436 generate cookies do not affect interoperability and hence are not
1437 specified here. The following is an example of how an endpoint could
1438 use cookies to implement limited DOS protection.
1440 A good way to do this is to set the responder cookie to be:
1442 Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)
1444 where <secret> is a randomly generated secret known only to the
1445 responder and periodically changed and | indicates concatenation.
1446 <VersionIDofSecret> should be changed whenever <secret> is
1447 regenerated. The cookie can be recomputed when the IKE_SA_INIT
1448 arrives the second time and compared to the cookie in the received
1449 message. If it matches, the responder knows that the cookie was
1450 generated since the last change to <secret> and that IPi must be the
1451 same as the source address it saw the first time. Incorporating SPIi
1455 Kaufman, et al. Expires August 27, 2006 [Page 26]
1457 Internet-Draft IKEv2bis February 2006
1460 into the calculation ensures that if multiple IKE_SAs are being set
1461 up in parallel they will all get different cookies (assuming the
1462 initiator chooses unique SPIi's). Incorporating Ni into the hash
1463 ensures that an attacker who sees only message 2 can't successfully
1466 If a new value for <secret> is chosen while there are connections in
1467 the process of being initialized, an IKE_SA_INIT might be returned
1468 with other than the current <VersionIDofSecret>. The responder in
1469 that case MAY reject the message by sending another response with a
1470 new cookie or it MAY keep the old value of <secret> around for a
1471 short time and accept cookies computed from either one. {{ Demoted
1472 the SHOULD NOT }} The responder should not accept cookies
1473 indefinitely after <secret> is changed, since that would defeat part
1474 of the denial of service protection. {{ Demoted the SHOULD }} The
1475 responder should change the value of <secret> frequently, especially
1478 {{ Clarif-2.1 }} In addition to cookies, there are several cases
1479 where the IKE_SA_INIT exchange does not result in the creation of an
1480 IKE_SA (such as INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). In such a
1481 case, sending a zero value for the Responder's SPI is correct. If
1482 the responder sends a non-zero responder SPI, the initiator should
1483 not reject the response for only that reason.
1485 {{ Clarif-2.5 }} When one party receives an IKE_SA_INIT request
1486 containing a cookie whose contents do not match the value expected,
1487 that party MUST ignore the cookie and process the message as if no
1488 cookie had been included; usually this means sending a response
1489 containing a new cookie.
1491 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD
1493 {{ This section added by Clarif-2.4 }}
1495 There are two common reasons why the initiator may have to retry the
1496 IKE_SA_INIT exchange: the responder requests a cookie or wants a
1497 different Diffie-Hellman group than was included in the KEi payload.
1498 If the initiator receives a cookie from the responder, the initiator
1499 needs to decide whether or not to include the cookie in only the next
1500 retry of the IKE_SA_INIT request, or in all subsequent retries as
1503 If the initiator includes the cookie only in the next retry, one
1504 additional roundtrip may be needed in some cases. An additional
1505 roundtrip is needed also if the initiator includes the cookie in all
1506 retries, but the responder does not support this. For instance, if
1507 the responder includes the SAi1 and KEi payloads in cookie
1511 Kaufman, et al. Expires August 27, 2006 [Page 27]
1513 Internet-Draft IKEv2bis February 2006
1516 calculation, it will reject the request by sending a new cookie.
1518 If both peers support including the cookie in all retries, a slightly
1519 shorter exchange can happen. Implementations SHOULD support this
1520 shorter exchange, but MUST NOT fail if other implementations do not
1521 support this shorter exchange.
1523 2.7. Cryptographic Algorithm Negotiation
1525 The payload type known as "SA" indicates a proposal for a set of
1526 choices of IPsec protocols (IKE, ESP, and/or AH) for the SA as well
1527 as cryptographic algorithms associated with each protocol.
1529 An SA payload consists of one or more proposals. Each proposal
1530 includes one or more protocols (usually one). Each protocol contains
1531 one or more transforms -- each specifying a cryptographic algorithm.
1532 Each transform contains zero or more attributes (attributes are
1533 needed only if the transform identifier does not completely specify
1534 the cryptographic algorithm).
1536 This hierarchical structure was designed to efficiently encode
1537 proposals for cryptographic suites when the number of supported
1538 suites is large because multiple values are acceptable for multiple
1539 transforms. The responder MUST choose a single suite, which MAY be
1540 any subset of the SA proposal following the rules below:
1542 Each proposal contains one or more protocols. If a proposal is
1543 accepted, the SA response MUST contain the same protocols in the same
1544 order as the proposal. The responder MUST accept a single proposal
1545 or reject them all and return an error. (Example: if a single
1546 proposal contains ESP and AH and that proposal is accepted, both ESP
1547 and AH MUST be accepted. If ESP and AH are included in separate
1548 proposals, the responder MUST accept only one of them).
1550 Each IPsec protocol proposal contains one or more transforms. Each
1551 transform contains a transform type. The accepted cryptographic
1552 suite MUST contain exactly one transform of each type included in the
1553 proposal. For example: if an ESP proposal includes transforms
1554 ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256,
1555 AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one
1556 of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six
1557 combinations are acceptable.
1559 Since the initiator sends its Diffie-Hellman value in the
1560 IKE_SA_INIT, it must guess the Diffie-Hellman group that the
1561 responder will select from its list of supported groups. If the
1562 initiator guesses wrong, the responder will respond with a Notify
1563 payload of type INVALID_KE_PAYLOAD indicating the selected group. In
1567 Kaufman, et al. Expires August 27, 2006 [Page 28]
1569 Internet-Draft IKEv2bis February 2006
1572 this case, the initiator MUST retry the IKE_SA_INIT with the
1573 corrected Diffie-Hellman group. The initiator MUST again propose its
1574 full set of acceptable cryptographic suites because the rejection
1575 message was unauthenticated and otherwise an active attacker could
1576 trick the endpoints into negotiating a weaker suite than a stronger
1577 one that they both prefer.
1581 {{ Demoted the SHOULD }} IKE, ESP, and AH security associations use
1582 secret keys that should be used only for a limited amount of time and
1583 to protect a limited amount of data. This limits the lifetime of the
1584 entire security association. When the lifetime of a security
1585 association expires, the security association MUST NOT be used. If
1586 there is demand, new security associations MAY be established.
1587 Reestablishment of security associations to take the place of ones
1588 that expire is referred to as "rekeying".
1590 To allow for minimal IPsec implementations, the ability to rekey SAs
1591 without restarting the entire IKE_SA is optional. An implementation
1592 MAY refuse all CREATE_CHILD_SA requests within an IKE_SA. If an SA
1593 has expired or is about to expire and rekeying attempts using the
1594 mechanisms described here fail, an implementation MUST close the
1595 IKE_SA and any associated CHILD_SAs and then MAY start new ones. {{
1596 Demoted the SHOULD }} Implementations may wish to support in-place
1597 rekeying of SAs, since doing so offers better performance and is
1598 likely to reduce the number of packets lost during the transition.
1600 To rekey a CHILD_SA within an existing IKE_SA, create a new,
1601 equivalent SA (see Section 2.17 below), and when the new one is
1602 established, delete the old one. To rekey an IKE_SA, establish a new
1603 equivalent IKE_SA (see Section 2.18 below) with the peer to whom the
1604 old IKE_SA is shared using a CREATE_CHILD_SA within the existing
1605 IKE_SA. An IKE_SA so created inherits all of the original IKE_SA's
1606 CHILD_SAs. Use the new IKE_SA for all control messages needed to
1607 maintain the CHILD_SAs created by the old IKE_SA, and delete the old
1608 IKE_SA. The Delete payload to delete itself MUST be the last request
1609 sent over an IKE_SA.
1611 {{ Demoted the SHOULD }} SAs should be rekeyed proactively, i.e., the
1612 new SA should be established before the old one expires and becomes
1613 unusable. Enough time should elapse between the time the new SA is
1614 established and the old one becomes unusable so that traffic can be
1615 switched over to the new SA.
1617 A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes
1618 were negotiated. In IKEv2, each end of the SA is responsible for
1619 enforcing its own lifetime policy on the SA and rekeying the SA when
1623 Kaufman, et al. Expires August 27, 2006 [Page 29]
1625 Internet-Draft IKEv2bis February 2006
1628 necessary. If the two ends have different lifetime policies, the end
1629 with the shorter lifetime will end up always being the one to request
1630 the rekeying. If an SA bundle has been inactive for a long time and
1631 if an endpoint would not initiate the SA in the absence of traffic,
1632 the endpoint MAY choose to close the SA instead of rekeying it when
1633 its lifetime expires. {{ Demoted the SHOULD }} It should do so if
1634 there has been no traffic since the last time the SA was rekeyed.
1636 Note that IKEv2 deliberately allows parallel SAs with the same
1637 traffic selectors between common endpoints. One of the purposes of
1638 this is to support traffic quality of service (QoS) differences among
1639 the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and section 4.1 of
1640 [DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints
1641 and the traffic selectors may not uniquely identify an SA between
1642 those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on
1643 the basis of duplicate traffic selectors SHOULD NOT be used.
1645 {{ Demoted the SHOULD }} The node that initiated the surviving
1646 rekeyed SA should delete the replaced SA after the new one is
1649 There are timing windows -- particularly in the presence of lost
1650 packets -- where endpoints may not agree on the state of an SA. The
1651 responder to a CREATE_CHILD_SA MUST be prepared to accept messages on
1652 an SA before sending its response to the creation request, so there
1653 is no ambiguity for the initiator. The initiator MAY begin sending
1654 on an SA as soon as it processes the response. The initiator,
1655 however, cannot receive on a newly created SA until it receives and
1656 processes the response to its CREATE_CHILD_SA request. How, then, is
1657 the responder to know when it is OK to send on the newly created SA?
1659 From a technical correctness and interoperability perspective, the
1660 responder MAY begin sending on an SA as soon as it sends its response
1661 to the CREATE_CHILD_SA request. In some situations, however, this
1662 could result in packets unnecessarily being dropped, so an
1663 implementation MAY want to defer such sending.
1665 The responder can be assured that the initiator is prepared to
1666 receive messages on an SA if either (1) it has received a
1667 cryptographically valid message on the new SA, or (2) the new SA
1668 rekeys an existing SA and it receives an IKE request to close the
1669 replaced SA. When rekeying an SA, the responder continues to send
1670 traffic on the old SA until one of those events occurs. When
1671 establishing a new SA, the responder MAY defer sending messages on a
1672 new SA until either it receives one or a timeout has occurred. {{
1673 Demoted the SHOULD }} If an initiator receives a message on an SA for
1674 which it has not received a response to its CREATE_CHILD_SA request,
1675 it interprets that as a likely packet loss and retransmits the
1679 Kaufman, et al. Expires August 27, 2006 [Page 30]
1681 Internet-Draft IKEv2bis February 2006
1684 CREATE_CHILD_SA request. An initiator MAY send a dummy message on a
1685 newly created SA if it has no messages queued in order to assure the
1686 responder that the initiator is ready to receive messages.
1688 {{ Clarif-5.9 }} Throughout this document, "initiator" refers to the
1689 party who initiated the exchange being described, and "original
1690 initiator" refers to the party who initiated the whole IKE_SA. The
1691 "original initiator" always refers to the party who initiated the
1692 exchange which resulted in the current IKE_SA. In other words, if
1693 the the "original responder" starts rekeying the IKE_SA, that party
1694 becomes the "original initiator" of the new IKE_SA.
1696 2.8.1. Simultaneous CHILD_SA rekeying
1698 {{ The first two paragraphs were moved, and the rest was added, based
1701 If the two ends have the same lifetime policies, it is possible that
1702 both will initiate a rekeying at the same time (which will result in
1703 redundant SAs). To reduce the probability of this happening, the
1704 timing of rekeying requests SHOULD be jittered (delayed by a random
1705 amount of time after the need for rekeying is noticed).
1707 This form of rekeying may temporarily result in multiple similar SAs
1708 between the same pairs of nodes. When there are two SAs eligible to
1709 receive packets, a node MUST accept incoming packets through either
1710 SA. If redundant SAs are created though such a collision, the SA
1711 created with the lowest of the four nonces used in the two exchanges
1712 SHOULD be closed by the endpoint that created it. {{ Clarif-5.10 }}
1713 "Lowest" means an octet-by-octet, lexicographical comparison (instead
1714 of, for instance, comparing the nonces as large integers). In other
1715 words, start by comparing the first octet; if they're equal, move to
1716 the next octet, and so on. If you reach the end of one nonce, that
1717 nonce is the lower one.
1719 The following is an explanation on the impact this has on
1720 implementations. Assume that hosts A and B have an existing IPsec SA
1721 pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same
1725 -------------------------------------------------------------------
1726 send req1: N(REKEY_SA,SPIa1),
1727 SA(..,SPIa2,..),Ni1,.. -->
1728 <-- send req2: N(REKEY_SA,SPIb1),
1735 Kaufman, et al. Expires August 27, 2006 [Page 31]
1737 Internet-Draft IKEv2bis February 2006
1740 At this point, A knows there is a simultaneous rekeying going on.
1741 However, it cannot yet know which of the exchanges will have the
1742 lowest nonce, so it will just note the situation and respond as
1745 send resp2: SA(..,SPIa3,..),
1749 Now B also knows that simultaneous rekeying is going on. It responds
1752 <-- send resp1: SA(..,SPIb3,..),
1757 At this point, there are three CHILD_SA pairs between A and B (the
1758 old one and two new ones). A and B can now compare the nonces.
1759 Suppose that the lowest nonce was Nr1 in message resp2; in this case,
1760 B (the sender of req2) deletes the redundant new SA, and A (the node
1761 that initiated the surviving rekeyed SA), deletes the old one.
1763 send req3: D(SPIa1) -->
1764 <-- send req4: D(SPIb2)
1766 <-- send resp4: D(SPIb1)
1768 send resp4: D(SPIa3) -->
1770 The rekeying is now finished.
1772 However, there is a second possible sequence of events that can
1773 happen if some packets are lost in the network, resulting in
1774 retransmissions. The rekeying begins as usual, but A's first packet
1791 Kaufman, et al. Expires August 27, 2006 [Page 32]
1793 Internet-Draft IKEv2bis February 2006
1797 -------------------------------------------------------------------
1798 send req1: N(REKEY_SA,SPIa1),
1801 <-- send req2: N(REKEY_SA,SPIb1),
1804 send resp2: SA(..,SPIa3,..),
1807 <-- send req3: D(SPIb1)
1809 send resp3: D(SPIa1) -->
1812 From B's point of view, the rekeying is now completed, and since it
1813 has not yet received A's req1, it does not even know that there was
1814 simultaneous rekeying. However, A will continue retransmitting the
1815 message, and eventually it will reach B.
1820 To B, it looks like A is trying to rekey an SA that no longer exists;
1821 thus, B responds to the request with something non-fatal such as
1824 <-- send resp1: N(NO_PROPOSAL_CHOSEN)
1827 When A receives this error, it already knows there was simultaneous
1828 rekeying, so it can ignore the error message.
1830 2.8.2. Rekeying the IKE_SA Versus Reauthentication
1832 {{ Added this section from Clarif-5.2 }}
1834 Rekeying the IKE_SA and reauthentication are different concepts in
1835 IKEv2. Rekeying the IKE_SA establishes new keys for the IKE_SA and
1836 resets the Message ID counters, but it does not authenticate the
1837 parties again (no AUTH or EAP payloads are involved).
1839 Although rekeying the IKE_SA may be important in some environments,
1840 reauthentication (the verification that the parties still have access
1841 to the long-term credentials) is often more important.
1843 IKEv2 does not have any special support for reauthentication.
1847 Kaufman, et al. Expires August 27, 2006 [Page 33]
1849 Internet-Draft IKEv2bis February 2006
1852 Reauthentication is done by creating a new IKE_SA from scratch (using
1853 IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify
1854 payloads), creating new CHILD_SAs within the new IKE_SA (without
1855 REKEY_SA notify payloads), and finally deleting the old IKE_SA (which
1856 deletes the old CHILD_SAs as well).
1858 This means that reauthentication also establishes new keys for the
1859 IKE_SA and CHILD_SAs. Therefore, while rekeying can be performed
1860 more often than reauthentication, the situation where "authentication
1861 lifetime" is shorter than "key lifetime" does not make sense.
1863 While creation of a new IKE_SA can be initiated by either party
1864 (initiator or responder in the original IKE_SA), the use of EAP
1865 authentication and/or configuration payloads means in practice that
1866 reauthentication has to be initiated by the same party as the
1867 original IKE_SA. IKEv2 does not currently allow the responder to
1868 request reauthentication in this case; however, there is ongoing work
1869 to add this functionality [REAUTH].
1871 2.9. Traffic Selector Negotiation
1873 {{ Clarif-7.2 }} When an RFC4301-compliant IPsec subsystem receives
1874 an IP packet and matches a "protect" selector in its Security Policy
1875 Database (SPD), the subsystem protects that packet with IPsec. When
1876 no SA exists yet, it is the task of IKE to create it. Maintenance of
1877 a system's SPD is outside the scope of IKE (see [PFKEY] for an
1878 example protocol), though some implementations might update their SPD
1879 in connection with the running of IKE (for an example scenario, see
1882 Traffic Selector (TS) payloads allow endpoints to communicate some of
1883 the information from their SPD to their peers. TS payloads specify
1884 the selection criteria for packets that will be forwarded over the
1885 newly set up SA. This can serve as a consistency check in some
1886 scenarios to assure that the SPDs are consistent. In others, it
1887 guides the dynamic update of the SPD.
1889 Two TS payloads appear in each of the messages in the exchange that
1890 creates a CHILD_SA pair. Each TS payload contains one or more
1891 Traffic Selectors. Each Traffic Selector consists of an address
1892 range (IPv4 or IPv6), a port range, and an IP protocol ID. In
1893 support of the scenario described in Section 1.1.3, an initiator may
1894 request that the responder assign an IP address and tell the
1895 initiator what it is. {{ Clarif-6.1 }} That request is done using
1896 configuration payloads, not traffic selectors. An address in a TSi
1897 payload in a response does not mean that the responder has assigned
1898 that address to the initiator: it only means that if packets matching
1899 these traffic selectors are sent by the initiator, IPsec processing
1903 Kaufman, et al. Expires August 27, 2006 [Page 34]
1905 Internet-Draft IKEv2bis February 2006
1908 can be performed as agreed for this SA.
1910 IKEv2 allows the responder to choose a subset of the traffic proposed
1911 by the initiator. This could happen when the configurations of the
1912 two endpoints are being updated but only one end has received the new
1913 information. Since the two endpoints may be configured by different
1914 people, the incompatibility may persist for an extended period even
1915 in the absence of errors. It also allows for intentionally different
1916 configurations, as when one end is configured to tunnel all addresses
1917 and depends on the other end to have the up-to-date list.
1919 The first of the two TS payloads is known as TSi (Traffic Selector-
1920 initiator). The second is known as TSr (Traffic Selector-responder).
1921 TSi specifies the source address of traffic forwarded from (or the
1922 destination address of traffic forwarded to) the initiator of the
1923 CHILD_SA pair. TSr specifies the destination address of the traffic
1924 forwarded to (or the source address of the traffic forwarded from)
1925 the responder of the CHILD_SA pair. For example, if the original
1926 initiator request the creation of a CHILD_SA pair, and wishes to
1927 tunnel all traffic from subnet 192.0.1.* on the initiator's side to
1928 subnet 192.0.2.* on the responder's side, the initiator would include
1929 a single traffic selector in each TS payload. TSi would specify the
1930 address range (192.0.1.0 - 192.0.1.255) and TSr would specify the
1931 address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was
1932 acceptable to the responder, it would send identical TS payloads
1933 back. (Note: The IP address range 192.0.2.* has been reserved for
1934 use in examples in RFCs and similar documents. This document needed
1935 two such ranges, and so also used 192.0.1.*. This should not be
1936 confused with any actual address.)
1938 The responder is allowed to narrow the choices by selecting a subset
1939 of the traffic, for instance by eliminating or narrowing the range of
1940 one or more members of the set of traffic selectors, provided the set
1941 does not become the NULL set.
1943 It is possible for the responder's policy to contain multiple smaller
1944 ranges, all encompassed by the initiator's traffic selector, and with
1945 the responder's policy being that each of those ranges should be sent
1946 over a different SA. Continuing the example above, the responder
1947 might have a policy of being willing to tunnel those addresses to and
1948 from the initiator, but might require that each address pair be on a
1949 separately negotiated CHILD_SA. If the initiator generated its
1950 request in response to an incoming packet from 192.0.1.43 to
1951 192.0.2.123, there would be no way for the responder to determine
1952 which pair of addresses should be included in this tunnel, and it
1953 would have to make a guess or reject the request with a status of
1954 SINGLE_PAIR_REQUIRED.
1959 Kaufman, et al. Expires August 27, 2006 [Page 35]
1961 Internet-Draft IKEv2bis February 2006
1964 {{ Clarif-4.11 }} Few implementations will have policies that require
1965 separate SAs for each address pair. Because of this, if only some
1966 part (or parts) of the TSi/TSr proposed by the initiator is (are)
1967 acceptable to the responder, responders SHOULD narrow TSi/TSr to an
1968 acceptable subset rather than use SINGLE_PAIR_REQUIRED.
1970 To enable the responder to choose the appropriate range in this case,
1971 if the initiator has requested the SA due to a data packet, the
1972 initiator SHOULD include as the first traffic selector in each of TSi
1973 and TSr a very specific traffic selector including the addresses in
1974 the packet triggering the request. In the example, the initiator
1975 would include in TSi two traffic selectors: the first containing the
1976 address range (192.0.1.43 - 192.0.1.43) and the source port and IP
1977 protocol from the packet and the second containing (192.0.1.0 -
1978 192.0.1.255) with all ports and IP protocols. The initiator would
1979 similarly include two traffic selectors in TSr.
1981 If the responder's policy does not allow it to accept the entire set
1982 of traffic selectors in the initiator's request, but does allow him
1983 to accept the first selector of TSi and TSr, then the responder MUST
1984 narrow the traffic selectors to a subset that includes the
1985 initiator's first choices. In this example, the responder might
1986 respond with TSi being (192.0.1.43 - 192.0.1.43) with all ports and
1989 If the initiator creates the CHILD_SA pair not in response to an
1990 arriving packet, but rather, say, upon startup, then there may be no
1991 specific addresses the initiator prefers for the initial tunnel over
1992 any other. In that case, the first values in TSi and TSr MAY be
1993 ranges rather than specific values, and the responder chooses a
1994 subset of the initiator's TSi and TSr that are acceptable. If more
1995 than one subset is acceptable but their union is not, the responder
1996 MUST accept some subset and MAY include a Notify payload of type
1997 ADDITIONAL_TS_POSSIBLE to indicate that the initiator might want to
1998 try again. This case will occur only when the initiator and
1999 responder are configured differently from one another. If the
2000 initiator and responder agree on the granularity of tunnels, the
2001 initiator will never request a tunnel wider than the responder will
2002 accept. {{ Demoted the SHOULD }} Such misconfigurations should be
2003 recorded in error logs.
2005 {{ Clarif-4.10 }} A concise summary of the narrowing process is:
2007 o If the responder's policy does not allow any part of the traffic
2008 covered by TSi/TSr, it responds with TS_UNACCEPTABLE.
2010 o If the responder's policy allows the entire set of traffic covered
2011 by TSi/TSr, no narrowing is necessary, and the responder can
2015 Kaufman, et al. Expires August 27, 2006 [Page 36]
2017 Internet-Draft IKEv2bis February 2006
2020 return the same TSi/TSr values.
2022 o Otherwise, narrowing is needed. If the responder's policy allows
2023 all traffic covered by TSi[1]/TSr[1] (the first traffic selectors
2024 in TSi/TSr) but not entire TSi/TSr, the responder narrows to an
2025 acceptable subset of TSi/TSr that includes TSi[1]/TSr[1].
2027 o If the responder's policy does not allow all traffic covered by
2028 TSi[1]/TSr[1], but does allow some parts of TSi/TSr, it narrows to
2029 an acceptable subset of TSi/TSr.
2031 In the last two cases, there may be several subsets that are
2032 acceptable (but their union is not); in this case, the responder
2033 arbitrarily chooses one of them, and includes ADDITIONAL_TS_POSSIBLE
2034 notification in the response.
2036 2.9.1. Traffic Selectors Violating Own Policy
2040 When creating a new SA, the initiator needs to avoid proposing
2041 traffic selectors that violate its own policy. If this rule is not
2042 followed, valid traffic may be dropped.
2044 This is best illustrated by an example. Suppose that host A has a
2045 policy whose effect is that traffic to 192.0.1.66 is sent via host B
2046 encrypted using AES, and traffic to all other hosts in 192.0.1.0/24
2047 is also sent via B, but must use 3DES. Suppose also that host B
2048 accepts any combination of AES and 3DES.
2050 If host A now proposes an SA that uses 3DES, and includes TSr
2051 containing (192.0.1.0-192.0.1.0.255), this will be accepted by host
2052 B. Now, host B can also use this SA to send traffic from 192.0.1.66,
2053 but those packets will be dropped by A since it requires the use of
2054 AES for those traffic. Even if host A creates a new SA only for
2055 192.0.1.66 that uses AES, host B may freely continue to use the first
2056 SA for the traffic. In this situation, when proposing the SA, host A
2057 should have followed its own policy, and included a TSr containing
2058 ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead.
2060 In general, if (1) the initiator makes a proposal "for traffic X
2061 (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator
2062 does not actually accept traffic X' with SA, and (3) the initiator
2063 would be willing to accept traffic X' with some SA' (!=SA), valid
2064 traffic can be unnecessarily dropped since the responder can apply
2065 either SA or SA' to traffic X'.
2071 Kaufman, et al. Expires August 27, 2006 [Page 37]
2073 Internet-Draft IKEv2bis February 2006
2078 The IKE_SA_INIT messages each contain a nonce. These nonces are used
2079 as inputs to cryptographic functions. The CREATE_CHILD_SA request
2080 and the CREATE_CHILD_SA response also contain nonces. These nonces
2081 are used to add freshness to the key derivation technique used to
2082 obtain keys for CHILD_SA, and to ensure creation of strong pseudo-
2083 random bits from the Diffie-Hellman key. Nonces used in IKEv2 MUST
2084 be randomly chosen, MUST be at least 128 bits in size, and MUST be at
2085 least half the key size of the negotiated prf. ("prf" refers to
2086 "pseudo-random function", one of the cryptographic algorithms
2087 negotiated in the IKE exchange.) {{ Clarif-7.4 }} However, the
2088 initiator chooses the nonce before the outcome of the negotiation is
2089 known. Because of that, the nonce has to be long enough for all the
2090 PRFs being proposed. If the same random number source is used for
2091 both keys and nonces, care must be taken to ensure that the latter
2092 use does not compromise the former.
2094 2.11. Address and Port Agility
2096 IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and
2097 AH associations for the same IP addresses it runs over. The IP
2098 addresses and ports in the outer header are, however, not themselves
2099 cryptographically protected, and IKE is designed to work even through
2100 Network Address Translation (NAT) boxes. An implementation MUST
2101 accept incoming requests even if the source port is not 500 or 4500,
2102 and MUST respond to the address and port from which the request was
2103 received. It MUST specify the address and port at which the request
2104 was received as the source address and port in the response. IKE
2105 functions identically over IPv4 or IPv6.
2107 2.12. Reuse of Diffie-Hellman Exponentials
2109 IKE generates keying material using an ephemeral Diffie-Hellman
2110 exchange in order to gain the property of "perfect forward secrecy".
2111 This means that once a connection is closed and its corresponding
2112 keys are forgotten, even someone who has recorded all of the data
2113 from the connection and gets access to all of the long-term keys of
2114 the two endpoints cannot reconstruct the keys used to protect the
2115 conversation without doing a brute force search of the session key
2118 Achieving perfect forward secrecy requires that when a connection is
2119 closed, each endpoint MUST forget not only the keys used by the
2120 connection but also any information that could be used to recompute
2121 those keys. In particular, it MUST forget the secrets used in the
2122 Diffie-Hellman calculation and any state that may persist in the
2123 state of a pseudo-random number generator that could be used to
2127 Kaufman, et al. Expires August 27, 2006 [Page 38]
2129 Internet-Draft IKEv2bis February 2006
2132 recompute the Diffie-Hellman secrets.
2134 Since the computing of Diffie-Hellman exponentials is computationally
2135 expensive, an endpoint may find it advantageous to reuse those
2136 exponentials for multiple connection setups. There are several
2137 reasonable strategies for doing this. An endpoint could choose a new
2138 exponential only periodically though this could result in less-than-
2139 perfect forward secrecy if some connection lasts for less than the
2140 lifetime of the exponential. Or it could keep track of which
2141 exponential was used for each connection and delete the information
2142 associated with the exponential only when some corresponding
2143 connection was closed. This would allow the exponential to be reused
2144 without losing perfect forward secrecy at the cost of maintaining
2147 Decisions as to whether and when to reuse Diffie-Hellman exponentials
2148 is a private decision in the sense that it will not affect
2149 interoperability. An implementation that reuses exponentials MAY
2150 choose to remember the exponential used by the other endpoint on past
2151 exchanges and if one is reused to avoid the second half of the
2154 2.13. Generating Keying Material
2156 In the context of the IKE_SA, four cryptographic algorithms are
2157 negotiated: an encryption algorithm, an integrity protection
2158 algorithm, a Diffie-Hellman group, and a pseudo-random function
2159 (prf). The pseudo-random function is used for the construction of
2160 keying material for all of the cryptographic algorithms used in both
2161 the IKE_SA and the CHILD_SAs.
2163 We assume that each encryption algorithm and integrity protection
2164 algorithm uses a fixed-size key and that any randomly chosen value of
2165 that fixed size can serve as an appropriate key. For algorithms that
2166 accept a variable length key, a fixed key size MUST be specified as
2167 part of the cryptographic transform negotiated. For algorithms for
2168 which not all values are valid keys (such as DES or 3DES with key
2169 parity), the algorithm by which keys are derived from arbitrary
2170 values MUST be specified by the cryptographic transform. For
2171 integrity protection functions based on Hashed Message Authentication
2172 Code (HMAC), the fixed key size is the size of the output of the
2173 underlying hash function. When the prf function takes a variable
2174 length key, variable length data, and produces a fixed-length output
2175 (e.g., when using HMAC), the formulas in this document apply. When
2176 the key for the prf function has fixed length, the data provided as a
2177 key is truncated or padded with zeros as necessary unless exceptional
2178 processing is explained following the formula.
2183 Kaufman, et al. Expires August 27, 2006 [Page 39]
2185 Internet-Draft IKEv2bis February 2006
2188 Keying material will always be derived as the output of the
2189 negotiated prf algorithm. Since the amount of keying material needed
2190 may be greater than the size of the output of the prf algorithm, we
2191 will use the prf iteratively. We will use the terminology prf+ to
2192 describe the function that outputs a pseudo-random stream based on
2193 the inputs to a prf as follows: (where | indicates concatenation)
2195 prf+ (K,S) = T1 | T2 | T3 | T4 | ...
2198 T1 = prf (K, S | 0x01)
2199 T2 = prf (K, T1 | S | 0x02)
2200 T3 = prf (K, T2 | S | 0x03)
2201 T4 = prf (K, T3 | S | 0x04)
2203 continuing as needed to compute all required keys. The keys are
2204 taken from the output string without regard to boundaries (e.g., if
2205 the required keys are a 256-bit Advanced Encryption Standard (AES)
2206 key and a 160-bit HMAC key, and the prf function generates 160 bits,
2207 the AES key will come from T1 and the beginning of T2, while the HMAC
2208 key will come from the rest of T2 and the beginning of T3).
2210 The constant concatenated to the end of each string feeding the prf
2211 is a single octet. prf+ in this document is not defined beyond 255
2212 times the size of the prf output.
2214 2.14. Generating Keying Material for the IKE_SA
2216 The shared keys are computed as follows. A quantity called SKEYSEED
2217 is calculated from the nonces exchanged during the IKE_SA_INIT
2218 exchange and the Diffie-Hellman shared secret established during that
2219 exchange. SKEYSEED is used to calculate seven other secrets: SK_d
2220 used for deriving new keys for the CHILD_SAs established with this
2221 IKE_SA; SK_ai and SK_ar used as a key to the integrity protection
2222 algorithm for authenticating the component messages of subsequent
2223 exchanges; SK_ei and SK_er used for encrypting (and of course
2224 decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are
2225 used when generating an AUTH payload.
2227 SKEYSEED and its derivatives are computed as follows:
2229 SKEYSEED = prf(Ni | Nr, g^ir)
2231 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr }
2232 = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )
2234 (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er,
2235 SK_pi, and SK_pr are taken in order from the generated bits of the
2239 Kaufman, et al. Expires August 27, 2006 [Page 40]
2241 Internet-Draft IKEv2bis February 2006
2244 prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman
2245 exchange. g^ir is represented as a string of octets in big endian
2246 order padded with zeros if necessary to make it the length of the
2247 modulus. Ni and Nr are the nonces, stripped of any headers. If the
2248 negotiated prf takes a fixed-length key and the lengths of Ni and Nr
2249 do not add up to that length, half the bits must come from Ni and
2250 half from Nr, taking the first bits of each.
2252 The two directions of traffic flow use different keys. The keys used
2253 to protect messages from the original initiator are SK_ai and SK_ei.
2254 The keys used to protect messages in the other direction are SK_ar
2255 and SK_er. Each algorithm takes a fixed number of bits of keying
2256 material, which is specified as part of the algorithm. For integrity
2257 algorithms based on a keyed hash, the key size is always equal to the
2258 length of the output of the underlying hash function.
2260 2.15. Authentication of the IKE_SA
2262 When not using extensible authentication (see Section 2.16), the
2263 peers are authenticated by having each sign (or MAC using a shared
2264 secret as the key) a block of data. For the responder, the octets to
2265 be signed start with the first octet of the first SPI in the header
2266 of the second message and end with the last octet of the last payload
2267 in the second message. Appended to this (for purposes of computing
2268 the signature) are the initiator's nonce Ni (just the value, not the
2269 payload containing it), and the value prf(SK_pr,IDr') where IDr' is
2270 the responder's ID payload excluding the fixed header. Note that
2271 neither the nonce Ni nor the value prf(SK_pr,IDr') are transmitted.
2272 Similarly, the initiator signs the first message, starting with the
2273 first octet of the first SPI in the header and ending with the last
2274 octet of the last payload. Appended to this (for purposes of
2275 computing the signature) are the responder's nonce Nr, and the value
2276 prf(SK_pi,IDi'). In the above calculation, IDi' and IDr' are the
2277 entire ID payloads excluding the fixed header. It is critical to the
2278 security of the exchange that each side sign the other side's nonce.
2282 The initiator's signed octets can be described as:
2284 InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
2285 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
2286 RealIKEHDR = SPIi | SPIr | . . . | Length
2287 RealMessage1 = RealIKEHDR | RestOfMessage1
2288 NonceRPayload = PayloadHeader | NonceRData
2289 InitiatorIDPayload = PayloadHeader | RestOfIDPayload
2290 RestOfInitIDPayload = IDType | RESERVED | InitIDData
2291 MACedIDForI = prf(SK_pi, RestOfInitIDPayload)
2295 Kaufman, et al. Expires August 27, 2006 [Page 41]
2297 Internet-Draft IKEv2bis February 2006
2300 The responder's signed octets can be described as:
2302 ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
2303 GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
2304 RealIKEHDR = SPIi | SPIr | . . . | Length
2305 RealMessage2 = RealIKEHDR | RestOfMessage2
2306 NonceIPayload = PayloadHeader | NonceIData
2307 ResponderIDPayload = PayloadHeader | RestOfIDPayload
2308 RestOfRespIDPayload = IDType | RESERVED | InitIDData
2309 MACedIDForR = prf(SK_pr, RestOfRespIDPayload)
2311 Note that all of the payloads are included under the signature,
2312 including any payload types not defined in this document. If the
2313 first message of the exchange is sent twice (the second time with a
2314 responder cookie and/or a different Diffie-Hellman group), it is the
2315 second version of the message that is signed.
2317 Optionally, messages 3 and 4 MAY include a certificate, or
2318 certificate chain providing evidence that the key used to compute a
2319 digital signature belongs to the name in the ID payload. The
2320 signature or MAC will be computed using algorithms dictated by the
2321 type of key used by the signer, and specified by the Auth Method
2322 field in the Authentication payload. There is no requirement that
2323 the initiator and responder sign with the same cryptographic
2324 algorithms. The choice of cryptographic algorithms depends on the
2325 type of key each has. In particular, the initiator may be using a
2326 shared key while the responder may have a public signature key and
2327 certificate. It will commonly be the case (but it is not required)
2328 that if a shared secret is used for authentication that the same key
2329 is used in both directions. Note that it is a common but typically
2330 insecure practice to have a shared key derived solely from a user-
2331 chosen password without incorporating another source of randomness.
2333 This is typically insecure because user-chosen passwords are unlikely
2334 to have sufficient unpredictability to resist dictionary attacks and
2335 these attacks are not prevented in this authentication method.
2336 (Applications using password-based authentication for bootstrapping
2337 and IKE_SA should use the authentication method in Section 2.16,
2338 which is designed to prevent off-line dictionary attacks.) {{ Demoted
2339 the SHOULD }} The pre-shared key needs to contain as much
2340 unpredictability as the strongest key being negotiated. In the case
2341 of a pre-shared key, the AUTH value is computed as:
2343 AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), <msg octets>)
2345 where the string "Key Pad for IKEv2" is 17 ASCII characters without
2346 null termination. The shared secret can be variable length. The pad
2347 string is added so that if the shared secret is derived from a
2351 Kaufman, et al. Expires August 27, 2006 [Page 42]
2353 Internet-Draft IKEv2bis February 2006
2356 password, the IKE implementation need not store the password in
2357 cleartext, but rather can store the value prf(Shared Secret,"Key Pad
2358 for IKEv2"), which could not be used as a password equivalent for
2359 protocols other than IKEv2. As noted above, deriving the shared
2360 secret from a password is not secure. This construction is used
2361 because it is anticipated that people will do it anyway. The
2362 management interface by which the Shared Secret is provided MUST
2363 accept ASCII strings of at least 64 octets and MUST NOT add a null
2364 terminator before using them as shared secrets. It MUST also accept
2365 a hex encoding of the Shared Secret. The management interface MAY
2366 accept other encodings if the algorithm for translating the encoding
2367 to a binary string is specified.
2369 {{ Clarif-3.7 }} If the negotiated prf takes a fixed-size key, the
2370 shared secret MUST be of that fixed size. This requirement means
2371 that it is difficult to use these PRFs with shared key authentication
2372 because it limits the shared secrets that can be used. Thus, PRFs
2373 that require a fixed-size key SHOULD NOT be used with shared key
2374 authentication. For example, PRF_AES128_CBC [PRFAES128CBC]
2375 originally used fixed key sizes; that RFC has been updated to handle
2376 variable key sizes in [PRFAES128CBC-bis]. Note that Section 2.13
2377 also contains text that is related to PRFs with fixed key size.
2378 However, the text in that section applies only to the prf+
2381 2.16. Extensible Authentication Protocol Methods
2383 In addition to authentication using public key signatures and shared
2384 secrets, IKE supports authentication using methods defined in RFC
2385 3748 [EAP]. Typically, these methods are asymmetric (designed for a
2386 user authenticating to a server), and they may not be mutual. {{ In
2387 the next sentence, changed "public key signature based" to "strong"
2388 }} For this reason, these protocols are typically used to
2389 authenticate the initiator to the responder and MUST be used in
2390 conjunction with a strong authentication of the responder to the
2391 initiator. These methods are often associated with mechanisms
2392 referred to as "Legacy Authentication" mechanisms.
2394 While this memo references [EAP] with the intent that new methods can
2395 be added in the future without updating this specification, some
2396 simpler variations are documented here and in Section 3.16. [EAP]
2397 defines an authentication protocol requiring a variable number of
2398 messages. Extensible Authentication is implemented in IKE as
2399 additional IKE_AUTH exchanges that MUST be completed in order to
2400 initialize the IKE_SA.
2402 An initiator indicates a desire to use extensible authentication by
2403 leaving out the AUTH payload from message 3. By including an IDi
2407 Kaufman, et al. Expires August 27, 2006 [Page 43]
2409 Internet-Draft IKEv2bis February 2006
2412 payload but not an AUTH payload, the initiator has declared an
2413 identity but has not proven it. If the responder is willing to use
2414 an extensible authentication method, it will place an Extensible
2415 Authentication Protocol (EAP) payload in message 4 and defer sending
2416 SAr2, TSi, and TSr until initiator authentication is complete in a
2417 subsequent IKE_AUTH exchange. In the case of a minimal extensible
2418 authentication, the initial SA establishment will appear as follows:
2421 -------------------------------------------------------------------
2422 HDR, SAi1, KEi, Ni -->
2423 <-- HDR, SAr1, KEr, Nr, [CERTREQ]
2424 HDR, SK {IDi, [CERTREQ,]
2427 <-- HDR, SK {IDr, [CERT,] AUTH,
2430 <-- HDR, SK {EAP (success)}
2432 <-- HDR, SK {AUTH, SAr2, TSi, TSr }
2434 {{ Clarif-3.10 }} As described in Section 2.2, when EAP is used, each
2435 pair of IKE_SA initial setup messages will have their message numbers
2436 incremented; the first pair of AUTH messages will have an ID of 1,
2437 the second will be 2, and so on.
2439 For EAP methods that create a shared key as a side effect of
2440 authentication, that shared key MUST be used by both the initiator
2441 and responder to generate AUTH payloads in messages 7 and 8 using the
2442 syntax for shared secrets specified in Section 2.15. The shared key
2443 from EAP is the field from the EAP specification named MSK. The
2444 shared key generated during an IKE exchange MUST NOT be used for any
2447 EAP methods that do not establish a shared key SHOULD NOT be used, as
2448 they are subject to a number of man-in-the-middle attacks [EAPMITM]
2449 if these EAP methods are used in other protocols that do not use a
2450 server-authenticated tunnel. Please see the Security Considerations
2451 section for more details. If EAP methods that do not generate a
2452 shared key are used, the AUTH payloads in messages 7 and 8 MUST be
2453 generated using SK_pi and SK_pr, respectively.
2455 {{ Demoted the SHOULD }} The initiator of an IKE_SA using EAP needs
2456 to be capable of extending the initial protocol exchange to at least
2457 ten IKE_AUTH exchanges in the event the responder sends notification
2458 messages and/or retries the authentication prompt. Once the protocol
2459 exchange defined by the chosen EAP authentication method has
2463 Kaufman, et al. Expires August 27, 2006 [Page 44]
2465 Internet-Draft IKEv2bis February 2006
2468 successfully terminated, the responder MUST send an EAP payload
2469 containing the Success message. Similarly, if the authentication
2470 method has failed, the responder MUST send an EAP payload containing
2471 the Failure message. The responder MAY at any time terminate the IKE
2472 exchange by sending an EAP payload containing the Failure message.
2474 Following such an extended exchange, the EAP AUTH payloads MUST be
2475 included in the two messages following the one containing the EAP
2478 {{ Clarif-3.5 }} When the initiator authentication uses EAP, it is
2479 possible that the contents of the IDi payload is used only for AAA
2480 routing purposes and selecting which EAP method to use. This value
2481 may be different from the identity authenticated by the EAP method.
2482 It is important that policy lookups and access control decisions use
2483 the actual authenticated identity. Often the EAP server is
2484 implemented in a separate AAA server that communicates with the IKEv2
2485 responder. In this case, the authenticated identity has to be sent
2486 from the AAA server to the IKEv2 responder.
2488 {{ Clarif-3.8 }} The information in Section 2.17 about PRFs with
2489 fixed-size keys also applies to EAP authentication. For instance, a
2490 PRF that requires a 128-bit key cannot be used with EAP because
2491 specifies that the MSK is at least 512 bits long.
2493 2.17. Generating Keying Material for CHILD_SAs
2495 A single CHILD_SA is created by the IKE_AUTH exchange, and additional
2496 CHILD_SAs can optionally be created in CREATE_CHILD_SA exchanges.
2497 Keying material for them is generated as follows:
2499 KEYMAT = prf+(SK_d, Ni | Nr)
2501 Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this
2502 request is the first CHILD_SA created or the fresh Ni and Nr from the
2503 CREATE_CHILD_SA exchange if this is a subsequent creation.
2505 For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman
2506 exchange, the keying material is defined as:
2508 KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr )
2510 where g^ir (new) is the shared secret from the ephemeral Diffie-
2511 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an
2512 octet string in big endian order padded with zeros in the high-order
2513 bits if necessary to make it the length of the modulus).
2515 A single CHILD_SA negotiation may result in multiple security
2519 Kaufman, et al. Expires August 27, 2006 [Page 45]
2521 Internet-Draft IKEv2bis February 2006
2524 associations. ESP and AH SAs exist in pairs (one in each direction),
2525 and four SAs could be created in a single CHILD_SA negotiation if a
2526 combination of ESP and AH is being negotiated.
2528 Keying material MUST be taken from the expanded KEYMAT in the
2531 o All keys for SAs carrying data from the initiator to the responder
2532 are taken before SAs going in the reverse direction.
2534 o If multiple IPsec protocols are negotiated, keying material is
2535 taken in the order in which the protocol headers will appear in
2536 the encapsulated packet.
2538 o If a single protocol has both encryption and authentication keys,
2539 the encryption key is taken from the first octets of KEYMAT and
2540 the authentication key is taken from the next octets.
2542 Each cryptographic algorithm takes a fixed number of bits of keying
2543 material specified as part of the algorithm.
2545 2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA Exchange
2547 The CREATE_CHILD_SA exchange can be used to rekey an existing IKE_SA
2548 (see Section 2.8). {{ Clarif-5.3 }} New initiator and responder SPIs
2549 are supplied in the SPI fields in the Proposal structures inside the
2550 Security Association (SA) payloads (not the SPI fields in the IKE
2551 header). The TS payloads are omitted when rekeying an IKE_SA.
2552 SKEYSEED for the new IKE_SA is computed using SK_d from the existing
2555 SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)
2557 where g^ir (new) is the shared secret from the ephemeral Diffie-
2558 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an
2559 octet string in big endian order padded with zeros if necessary to
2560 make it the length of the modulus) and Ni and Nr are the two nonces
2561 stripped of any headers.
2563 {{ Clarif-5.5 }} The old and new IKE_SA may have selected a different
2564 PRF. Because the rekeying exchange belongs to the old IKE_SA, it is
2565 the old IKE_SA's PRF that is used. Note that this may not work if
2566 the new IKE_SA's PRF has a fixed key size because the output of the
2567 PRF may not be of the correct size.
2569 The new IKE_SA MUST reset its message counters to 0.
2571 SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as
2575 Kaufman, et al. Expires August 27, 2006 [Page 46]
2577 Internet-Draft IKEv2bis February 2006
2580 specified in Section 2.14.
2582 2.19. Requesting an Internal Address on a Remote Network
2584 Most commonly occurring in the endpoint-to-security-gateway scenario,
2585 an endpoint may need an IP address in the network protected by the
2586 security gateway and may need to have that address dynamically
2587 assigned. A request for such a temporary address can be included in
2588 any request to create a CHILD_SA (including the implicit request in
2589 message 3) by including a CP payload.
2591 This function provides address allocation to an IPsec Remote Access
2592 Client (IRAC) trying to tunnel into a network protected by an IPsec
2593 Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an
2594 IKE_SA and a CHILD_SA, the IRAC MUST request the IRAS-controlled
2595 address (and optionally other information concerning the protected
2596 network) in the IKE_AUTH exchange. The IRAS may procure an address
2597 for the IRAC from any number of sources such as a DHCP/BOOTP server
2598 or its own address pool.
2601 -------------------------------------------------------------------
2602 HDR, SK {IDi, [CERT,]
2603 [CERTREQ,] [IDr,] AUTH,
2604 CP(CFG_REQUEST), SAi2,
2606 <-- HDR, SK {IDr, [CERT,] AUTH,
2607 CP(CFG_REPLY), SAr2,
2610 In all cases, the CP payload MUST be inserted before the SA payload.
2611 In variations of the protocol where there are multiple IKE_AUTH
2612 exchanges, the CP payloads MUST be inserted in the messages
2613 containing the SA payloads.
2615 CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute
2616 (either IPv4 or IPv6) but MAY contain any number of additional
2617 attributes the initiator wants returned in the response.
2619 For example, message from initiator to responder:
2623 TSi = (0, 0-65535,0.0.0.0-255.255.255.255)
2624 TSr = (0, 0-65535,0.0.0.0-255.255.255.255)
2626 NOTE: Traffic Selectors contain (protocol, port range, address
2631 Kaufman, et al. Expires August 27, 2006 [Page 47]
2633 Internet-Draft IKEv2bis February 2006
2636 Message from responder to initiator:
2639 INTERNAL_ADDRESS(192.0.2.202)
2640 INTERNAL_NETMASK(255.255.255.0)
2641 INTERNAL_SUBNET(192.0.2.0/255.255.255.0)
2642 TSi = (0, 0-65535,192.0.2.202-192.0.2.202)
2643 TSr = (0, 0-65535,192.0.2.0-192.0.2.255)
2645 All returned values will be implementation dependent. As can be seen
2646 in the above example, the IRAS MAY also send other attributes that
2647 were not included in CP(CFG_REQUEST) and MAY ignore the non-
2648 mandatory attributes that it does not support.
2650 The responder MUST NOT send a CFG_REPLY without having first received
2651 a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS
2652 to perform an unnecessary configuration lookup if the IRAC cannot
2653 process the REPLY. In the case where the IRAS's configuration
2654 requires that CP be used for a given identity IDi, but IRAC has
2655 failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and
2656 terminate the IKE exchange with a FAILED_CP_REQUIRED error.
2658 2.20. Requesting the Peer's Version
2660 An IKE peer wishing to inquire about the other peer's IKE software
2661 version information MAY use the method below. This is an example of
2662 a configuration request within an INFORMATIONAL exchange, after the
2663 IKE_SA and first CHILD_SA have been created.
2665 An IKE implementation MAY decline to give out version information
2666 prior to authentication or even after authentication to prevent
2667 trolling in case some implementation is known to have some security
2668 weakness. In that case, it MUST either return an empty string or no
2669 CP payload if CP is not supported.
2672 -------------------------------------------------------------------
2673 HDR, SK{CP(CFG_REQUEST)} -->
2674 <-- HDR, SK{CP(CFG_REPLY)}
2677 APPLICATION_VERSION("")
2679 CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar
2687 Kaufman, et al. Expires August 27, 2006 [Page 48]
2689 Internet-Draft IKEv2bis February 2006
2692 2.21. Error Handling
2694 There are many kinds of errors that can occur during IKE processing.
2695 If a request is received that is badly formatted or unacceptable for
2696 reasons of policy (e.g., no matching cryptographic algorithms), the
2697 response MUST contain a Notify payload indicating the error. If an
2698 error occurs outside the context of an IKE request (e.g., the node is
2699 getting ESP messages on a nonexistent SPI), the node SHOULD initiate
2700 an INFORMATIONAL exchange with a Notify payload describing the
2703 Errors that occur before a cryptographically protected IKE_SA is
2704 established must be handled very carefully. There is a trade-off
2705 between wanting to be helpful in diagnosing a problem and responding
2706 to it and wanting to avoid being a dupe in a denial of service attack
2707 based on forged messages.
2709 If a node receives a message on UDP port 500 or 4500 outside the
2710 context of an IKE_SA known to it (and not a request to start one), it
2711 may be the result of a recent crash of the node. If the message is
2712 marked as a response, the node MAY audit the suspicious event but
2713 MUST NOT respond. If the message is marked as a request, the node
2714 MAY audit the suspicious event and MAY send a response. If a
2715 response is sent, the response MUST be sent to the IP address and
2716 port from whence it came with the same IKE SPIs and the Message ID
2717 copied. The response MUST NOT be cryptographically protected and
2718 MUST contain a Notify payload indicating INVALID_IKE_SPI.
2720 A node receiving such an unprotected Notify payload MUST NOT respond
2721 and MUST NOT change the state of any existing SAs. The message might
2722 be a forgery or might be a response the genuine correspondent was
2723 tricked into sending. {{ Demoted two SHOULDs }} A node should treat
2724 such a message (and also a network message like ICMP destination
2725 unreachable) as a hint that there might be problems with SAs to that
2726 IP address and should initiate a liveness test for any such IKE_SA.
2727 An implementation SHOULD limit the frequency of such tests to avoid
2728 being tricked into participating in a denial of service attack.
2730 A node receiving a suspicious message from an IP address with which
2731 it has an IKE_SA MAY send an IKE Notify payload in an IKE
2732 INFORMATIONAL exchange over that SA. {{ Demoted the SHOULD }} The
2733 recipient MUST NOT change the state of any SAs as a result, but may
2734 wish to audit the event to aid in diagnosing malfunctions. A node
2735 MUST limit the rate at which it will send messages in response to
2736 unprotected messages.
2743 Kaufman, et al. Expires August 27, 2006 [Page 49]
2745 Internet-Draft IKEv2bis February 2006
2750 Use of IP compression [IPCOMP] can be negotiated as part of the setup
2751 of a CHILD_SA. While IP compression involves an extra header in each
2752 packet and a compression parameter index (CPI), the virtual
2753 "compression association" has no life outside the ESP or AH SA that
2754 contains it. Compression associations disappear when the
2755 corresponding ESP or AH SA goes away. It is not explicitly mentioned
2756 in any DELETE payload.
2758 Negotiation of IP compression is separate from the negotiation of
2759 cryptographic parameters associated with a CHILD_SA. A node
2760 requesting a CHILD_SA MAY advertise its support for one or more
2761 compression algorithms through one or more Notify payloads of type
2762 IPCOMP_SUPPORTED. The response MAY indicate acceptance of a single
2763 compression algorithm with a Notify payload of type IPCOMP_SUPPORTED.
2764 These payloads MUST NOT occur in messages that do not contain SA
2767 Although there has been discussion of allowing multiple compression
2768 algorithms to be accepted and to have different compression
2769 algorithms available for the two directions of a CHILD_SA,
2770 implementations of this specification MUST NOT accept an IPComp
2771 algorithm that was not proposed, MUST NOT accept more than one, and
2772 MUST NOT compress using an algorithm other than one proposed and
2773 accepted in the setup of the CHILD_SA.
2775 A side effect of separating the negotiation of IPComp from
2776 cryptographic parameters is that it is not possible to propose
2777 multiple cryptographic suites and propose IP compression with some of
2778 them but not others.
2782 Network Address Translation (NAT) gateways are a controversial
2783 subject. This section briefly describes what they are and how they
2784 are likely to act on IKE traffic. Many people believe that NATs are
2785 evil and that we should not design our protocols so as to make them
2786 work better. IKEv2 does specify some unintuitive processing rules in
2787 order that NATs are more likely to work.
2789 NATs exist primarily because of the shortage of IPv4 addresses,
2790 though there are other rationales. IP nodes that are "behind" a NAT
2791 have IP addresses that are not globally unique, but rather are
2792 assigned from some space that is unique within the network behind the
2793 NAT but that are likely to be reused by nodes behind other NATs.
2794 Generally, nodes behind NATs can communicate with other nodes behind
2795 the same NAT and with nodes with globally unique addresses, but not
2799 Kaufman, et al. Expires August 27, 2006 [Page 50]
2801 Internet-Draft IKEv2bis February 2006
2804 with nodes behind other NATs. There are exceptions to that rule.
2805 When those nodes make connections to nodes on the real Internet, the
2806 NAT gateway "translates" the IP source address to an address that
2807 will be routed back to the gateway. Messages to the gateway from the
2808 Internet have their destination addresses "translated" to the
2809 internal address that will route the packet to the correct endnode.
2811 NATs are designed to be "transparent" to endnodes. Neither software
2812 on the node behind the NAT nor the node on the Internet requires
2813 modification to communicate through the NAT. Achieving this
2814 transparency is more difficult with some protocols than with others.
2815 Protocols that include IP addresses of the endpoints within the
2816 payloads of the packet will fail unless the NAT gateway understands
2817 the protocol and modifies the internal references as well as those in
2818 the headers. Such knowledge is inherently unreliable, is a network
2819 layer violation, and often results in subtle problems.
2821 Opening an IPsec connection through a NAT introduces special
2822 problems. If the connection runs in transport mode, changing the IP
2823 addresses on packets will cause the checksums to fail and the NAT
2824 cannot correct the checksums because they are cryptographically
2825 protected. Even in tunnel mode, there are routing problems because
2826 transparently translating the addresses of AH and ESP packets
2827 requires special logic in the NAT and that logic is heuristic and
2828 unreliable in nature. For that reason, IKEv2 can negotiate UDP
2829 encapsulation of IKE and ESP packets. This encoding is slightly less
2830 efficient but is easier for NATs to process. In addition, firewalls
2831 may be configured to pass IPsec traffic over UDP but not ESP/AH or
2834 It is a common practice of NATs to translate TCP and UDP port numbers
2835 as well as addresses and use the port numbers of inbound packets to
2836 decide which internal node should get a given packet. For this
2837 reason, even though IKE packets MUST be sent from and to UDP port
2838 500, they MUST be accepted coming from any port and responses MUST be
2839 sent to the port from whence they came. This is because the ports
2840 may be modified as the packets pass through NATs. Similarly, IP
2841 addresses of the IKE endpoints are generally not included in the IKE
2842 payloads because the payloads are cryptographically protected and
2843 could not be transparently modified by NATs.
2845 Port 4500 is reserved for UDP-encapsulated ESP and IKE. When working
2846 through a NAT, it is generally better to pass IKE packets over port
2847 4500 because some older NATs handle IKE traffic on port 500 cleverly
2848 in an attempt to transparently establish IPsec connections between
2849 endpoints that don't handle NAT traversal themselves. Such NATs may
2850 interfere with the straightforward NAT traversal envisioned by this
2851 document. {{ Clarif-7.6 }} An IPsec endpoint that discovers a NAT
2855 Kaufman, et al. Expires August 27, 2006 [Page 51]
2857 Internet-Draft IKEv2bis February 2006
2860 between it and its correspondent MUST send all subsequent traffic
2861 from port 4500, which NATs should not treat specially (as they might
2864 The specific requirements for supporting NAT traversal [NATREQ] are
2865 listed below. Support for NAT traversal is optional. In this
2866 section only, requirements listed as MUST apply only to
2867 implementations supporting NAT traversal.
2869 o IKE MUST listen on port 4500 as well as port 500. IKE MUST
2870 respond to the IP address and port from which packets arrived.
2872 o Both IKE initiator and responder MUST include in their IKE_SA_INIT
2873 packets Notify payloads of type NAT_DETECTION_SOURCE_IP and
2874 NAT_DETECTION_DESTINATION_IP. Those payloads can be used to
2875 detect if there is NAT between the hosts, and which end is behind
2876 the NAT. The location of the payloads in the IKE_SA_INIT packets
2877 are just after the Ni and Nr payloads (before the optional CERTREQ
2880 o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches
2881 the hash of the source IP and port found from the IP header of the
2882 packet containing the payload, it means that the other end is
2883 behind NAT (i.e., someone along the route changed the source
2884 address of the original packet to match the address of the NAT
2885 box). In this case, this end should allow dynamic update of the
2886 other ends IP address, as described later.
2888 o If the NAT_DETECTION_DESTINATION_IP payload received does not
2889 match the hash of the destination IP and port found from the IP
2890 header of the packet containing the payload, it means that this
2891 end is behind a NAT. In this case, this end SHOULD start sending
2892 keepalive packets as explained in [UDPENCAPS].
2894 o The IKE initiator MUST check these payloads if present and if they
2895 do not match the addresses in the outer packet MUST tunnel all
2896 future IKE and ESP packets associated with this IKE_SA over UDP
2899 o To tunnel IKE packets over UDP port 4500, the IKE header has four
2900 octets of zero prepended and the result immediately follows the
2901 UDP header. To tunnel ESP packets over UDP port 4500, the ESP
2902 header immediately follows the UDP header. Since the first four
2903 bytes of the ESP header contain the SPI, and the SPI cannot
2904 validly be zero, it is always possible to distinguish ESP and IKE
2911 Kaufman, et al. Expires August 27, 2006 [Page 52]
2913 Internet-Draft IKEv2bis February 2006
2916 o The original source and destination IP address required for the
2917 transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS])
2918 are obtained from the Traffic Selectors associated with the
2919 exchange. In the case of NAT traversal, the Traffic Selectors
2920 MUST contain exactly one IP address, which is then used as the
2921 original IP address.
2923 o There are cases where a NAT box decides to remove mappings that
2924 are still alive (for example, the keepalive interval is too long,
2925 or the NAT box is rebooted). To recover in these cases, hosts
2926 that are not behind a NAT SHOULD send all packets (including
2927 retransmission packets) to the IP address and port from the last
2928 valid authenticated packet from the other end (i.e., dynamically
2929 update the address). A host behind a NAT SHOULD NOT do this
2930 because it opens a DoS attack possibility. Any authenticated IKE
2931 packet or any authenticated UDP-encapsulated ESP packet can be
2932 used to detect that the IP address or the port has changed.
2934 Note that similar but probably not identical actions will likely be
2935 needed to make IKE work with Mobile IP, but such processing is not
2936 addressed by this document.
2938 2.24. Explicit Congestion Notification (ECN)
2940 When IPsec tunnels behave as originally specified in [IPSECARCH-OLD],
2941 ECN usage is not appropriate for the outer IP headers because tunnel
2942 decapsulation processing discards ECN congestion indications to the
2943 detriment of the network. ECN support for IPsec tunnels for IKEv1-
2944 based IPsec requires multiple operating modes and negotiation (see
2945 [ECN]). IKEv2 simplifies this situation by requiring that ECN be
2946 usable in the outer IP headers of all tunnel-mode IPsec SAs created
2947 by IKEv2. Specifically, tunnel encapsulators and decapsulators for
2948 all tunnel-mode SAs created by IKEv2 MUST support the ECN full-
2949 functionality option for tunnels specified in [ECN] and MUST
2950 implement the tunnel encapsulation and decapsulation processing
2951 specified in [IPSECARCH] to prevent discarding of ECN congestion
2955 3. Header and Payload Formats
2959 IKE messages use UDP ports 500 and/or 4500, with one IKE message per
2960 UDP datagram. Information from the beginning of the packet through
2961 the UDP header is largely ignored except that the IP addresses and
2962 UDP ports from the headers are reversed and used for return packets.
2963 When sent on UDP port 500, IKE messages begin immediately following
2967 Kaufman, et al. Expires August 27, 2006 [Page 53]
2969 Internet-Draft IKEv2bis February 2006
2972 the UDP header. When sent on UDP port 4500, IKE messages have
2973 prepended four octets of zero. These four octets of zero are not
2974 part of the IKE message and are not included in any of the length
2975 fields or checksums defined by IKE. Each IKE message begins with the
2976 IKE header, denoted HDR in this memo. Following the header are one
2977 or more IKE payloads each identified by a "Next Payload" field in the
2978 preceding payload. Payloads are processed in the order in which they
2979 appear in an IKE message by invoking the appropriate processing
2980 routine according to the "Next Payload" field in the IKE header and
2981 subsequently according to the "Next Payload" field in the IKE payload
2982 itself until a "Next Payload" field of zero indicates that no
2983 payloads follow. If a payload of type "Encrypted" is found, that
2984 payload is decrypted and its contents parsed as additional payloads.
2985 An Encrypted payload MUST be the last payload in a packet and an
2986 Encrypted payload MUST NOT contain another Encrypted payload.
2988 The Recipient SPI in the header identifies an instance of an IKE
2989 security association. It is therefore possible for a single instance
2990 of IKE to multiplex distinct sessions with multiple peers.
2992 All multi-octet fields representing integers are laid out in big
2993 endian order (aka most significant byte first, or network byte
2996 The format of the IKE header is shown in Figure 4.
2999 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
3000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3001 ! IKE_SA Initiator's SPI !
3003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3004 ! IKE_SA Responder's SPI !
3006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3007 ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags !
3008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3014 Figure 4: IKE Header Format
3016 o Initiator's SPI (8 octets) - A value chosen by the initiator to
3017 identify a unique IKE security association. This value MUST NOT
3023 Kaufman, et al. Expires August 27, 2006 [Page 54]
3025 Internet-Draft IKEv2bis February 2006
3028 o Responder's SPI (8 octets) - A value chosen by the responder to
3029 identify a unique IKE security association. This value MUST be
3030 zero in the first message of an IKE Initial Exchange (including
3031 repeats of that message including a cookie). {{ The phrase "and
3032 MUST NOT be zero in any other message" was removed; Clarif-2.1 }}
3034 o Next Payload (1 octet) - Indicates the type of payload that
3035 immediately follows the header. The format and value of each
3036 payload are defined below.
3038 o Major Version (4 bits) - Indicates the major version of the IKE
3039 protocol in use. Implementations based on this version of IKE
3040 MUST set the Major Version to 2. Implementations based on
3041 previous versions of IKE and ISAKMP MUST set the Major Version to
3042 1. Implementations based on this version of IKE MUST reject or
3043 ignore messages containing a version number greater than 2.
3045 o Minor Version (4 bits) - Indicates the minor version of the IKE
3046 protocol in use. Implementations based on this version of IKE
3047 MUST set the Minor Version to 0. They MUST ignore the minor
3048 version number of received messages.
3050 o Exchange Type (1 octet) - Indicates the type of exchange being
3051 used. This constrains the payloads sent in each message and
3052 orderings of messages in an exchange.
3055 ----------------------------------
3061 RESERVED TO IANA 38-239
3062 Reserved for private use 240-255
3064 o Flags (1 octet) - Indicates specific options that are set for the
3065 message. Presence of options are indicated by the appropriate bit
3066 in the flags field being set. The bits are defined LSB first, so
3067 bit 0 would be the least significant bit of the Flags octet. In
3068 the description below, a bit being 'set' means its value is '1',
3069 while 'cleared' means its value is '0'.
3071 * X(reserved) (bits 0-2) - These bits MUST be cleared when
3072 sending and MUST be ignored on receipt.
3074 * I(nitiator) (bit 3 of Flags) - This bit MUST be set in messages
3075 sent by the original initiator of the IKE_SA and MUST be
3079 Kaufman, et al. Expires August 27, 2006 [Page 55]
3081 Internet-Draft IKEv2bis February 2006
3084 cleared in messages sent by the original responder. It is used
3085 by the recipient to determine which eight octets of the SPI
3086 were generated by the recipient.
3088 * V(ersion) (bit 4 of Flags) - This bit indicates that the
3089 transmitter is capable of speaking a higher major version
3090 number of the protocol than the one indicated in the major
3091 version number field. Implementations of IKEv2 must clear this
3092 bit when sending and MUST ignore it in incoming messages.
3094 * R(esponse) (bit 5 of Flags) - This bit indicates that this
3095 message is a response to a message containing the same message
3096 ID. This bit MUST be cleared in all request messages and MUST
3097 be set in all responses. An IKE endpoint MUST NOT generate a
3098 response to a message that is marked as being a response.
3100 * X(reserved) (bits 6-7 of Flags) - These bits MUST be cleared
3101 when sending and MUST be ignored on receipt.
3103 o Message ID (4 octets) - Message identifier used to control
3104 retransmission of lost packets and matching of requests and
3105 responses. It is essential to the security of the protocol
3106 because it is used to prevent message replay attacks. See
3107 Section 2.1 and Section 2.2.
3109 o Length (4 octets) - Length of total message (header + payloads) in
projects / strongswan.git / blob