4 Network Working Group P. Hoffman
5 Internet-Draft VPN Consortium
6 Expires: July 5, 2006 January 2006
9 Internet Key Exchange Protocol: IKEv2.1
10 draft-hoffman-ikev2-1-00.txt
14 By submitting this Internet-Draft, each author represents that any
15 applicable patent or other IPR claims of which he or she is aware
16 have been or will be disclosed, and any of which he or she becomes
17 aware will be disclosed, in accordance with Section 6 of BCP 79.
19 Internet-Drafts are working documents of the Internet Engineering
20 Task Force (IETF), its areas, and its working groups. Note that
21 other groups may also distribute working documents as Internet-
24 Internet-Drafts are draft documents valid for a maximum of six months
25 and may be updated, replaced, or obsoleted by other documents at any
26 time. It is inappropriate to use Internet-Drafts as reference
27 material or to cite them other than as "work in progress."
29 The list of current Internet-Drafts can be accessed at
30 http://www.ietf.org/ietf/1id-abstracts.txt.
32 The list of Internet-Draft Shadow Directories can be accessed at
33 http://www.ietf.org/shadow.html.
35 This Internet-Draft will expire on July 5, 2006.
39 Copyright (C) The Internet Society (2006).
43 This document describes version 2.1 of the Internet Key Exchange
44 (IKE) protocol. IKEv2.1 is heavily based on IKEv2 from RFC 4306
45 (edited by Charlie Kaufman), and includes all of the clarifications
46 from the "IKEv2 Clarifications" document (edited by Pasi Eronen and
47 Paul Hoffman). IKEv2.1 makes additional changes to those two
48 documents in places where IKEv2 was unclear and the clarifications
49 document did not commit to a particular protocol interpretation.
55 Hoffman Expires July 5, 2006 [Page 1]
57 Internet-Draft IKEv2 January 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 . 13
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. Introduction to IKEv2.1 . . . . . . . . . . . . . . . . . 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 Hoffman Expires July 5, 2006 [Page 2]
113 Internet-Draft IKEv2 January 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 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 107
148 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 107
149 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 108
150 8.1. Normative References . . . . . . . . . . . . . . . . . . 108
151 8.2. Informative References . . . . . . . . . . . . . . . . . 109
152 Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 112
153 Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 114
154 B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 114
155 B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 114
156 Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 115
157 C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 115
158 C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 116
159 C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 117
160 C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying
161 CHILD_SAs . . . . . . . . . . . . . . . . . . . . . . . . 118
162 C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA . . . . 118
163 C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 118
167 Hoffman Expires July 5, 2006 [Page 3]
169 Internet-Draft IKEv2 January 2006
172 Appendix D. Changes Between Internet Draft Versions . . . . . . 118
173 D.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 118
174 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 119
175 Intellectual Property and Copyright Statements . . . . . . . . . 119
223 Hoffman Expires July 5, 2006 [Page 4]
225 Internet-Draft IKEv2 January 2006
230 {{ An introduction to IKEv2.1 is given at the end of Section 1. It
231 is put there (instead of here) to preserve the section numbering of
232 the original IKEv2 document. }}
234 IP Security (IPsec) provides confidentiality, data integrity, access
235 control, and data source authentication to IP datagrams. These
236 services are provided by maintaining shared state between the source
237 and the sink of an IP datagram. This state defines, among other
238 things, the specific services provided to the datagram, which
239 cryptographic algorithms will be used to provide the services, and
240 the keys used as input to the cryptographic algorithms.
242 Establishing this shared state in a manual fashion does not scale
243 well. Therefore, a protocol to establish this state dynamically is
244 needed. This memo describes such a protocol -- the Internet Key
245 Exchange (IKE). This is version 2.1 of IKE. Version 1 of IKE was
246 defined in RFCs 2407 [DOI], 2408 [ISAKMP], and 2409 [IKEV1]. IKEv2
247 was defined in [IKEV2]. This single document is intended to replace
248 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 and IKEv2.1 rely on some of the
253 processing rules in [IPSECARCH], as described in various sections of
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 Hoffman Expires July 5, 2006 [Page 5]
281 Internet-Draft IKEv2 January 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 Hoffman Expires July 5, 2006 [Page 6]
337 Internet-Draft IKEv2 January 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 Hoffman Expires July 5, 2006 [Page 7]
393 Internet-Draft IKEv2 January 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 Hoffman Expires July 5, 2006 [Page 8]
449 Internet-Draft IKEv2 January 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 Hoffman Expires July 5, 2006 [Page 9]
505 Internet-Draft IKEv2 January 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 Hoffman Expires July 5, 2006 [Page 10]
561 Internet-Draft IKEv2 January 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 Hoffman Expires July 5, 2006 [Page 11]
617 Internet-Draft IKEv2 January 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 other value
627 than NONE. Implementations MUST leave the transform out entirely in
630 1.3. The CREATE_CHILD_SA Exchange
632 {{ This is a heavy rewrite of most of this section. The major
633 organization changes are described in Clarif-4.1 and Clarif-5.1. }}
635 The CREATE_CHILD_SA exchange is used to create new CHILD_SAs and to
636 rekey both IKE_SAs and CHILD_SAs. This exchange consists of a single
637 request/response pair, and some of its function was referred to as a
638 phase 2 exchange in IKEv1. It MAY be initiated by either end of the
639 IKE_SA after the initial exchanges are completed.
641 All messages following the initial exchange are cryptographically
642 protected using the cryptographic algorithms and keys negotiated in
643 the first two messages of the IKE exchange. These subsequent
644 messages use the syntax of the Encrypted Payload described in
645 Section 3.14. All subsequent messages included an Encrypted Payload,
646 even if they are referred to in the text as "empty". For both
647 messages in the CREATE_CHILD_SA, the message following the header is
648 encrypted and the message including the header is integrity protected
649 using the cryptographic algorithms negotiated for the IKE_SA.
651 The CREATE_CHILD_SA is used for rekeying IKE_SAs and CHILD_SAs. This
652 section describes the first part of rekeying, the creation of new
653 SAs; Section 2.8 covers the mechanics of rekeying, including moving
654 traffic from old to new SAs and the deletion of the old SAs. The two
655 sections must be read together to understand the entire process of
658 Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this
659 section the term initiator refers to the endpoint initiating this
660 exchange. An implementation MAY refuse all CREATE_CHILD_SA requests
663 The CREATE_CHILD_SA request MAY optionally contain a KE payload for
664 an additional Diffie-Hellman exchange to enable stronger guarantees
665 of forward secrecy for the CHILD_SA. The keying material for the
666 CHILD_SA is a function of SK_d established during the establishment
667 of the IKE_SA, the nonces exchanged during the CREATE_CHILD_SA
671 Hoffman Expires July 5, 2006 [Page 12]
673 Internet-Draft IKEv2 January 2006
676 exchange, and the Diffie-Hellman value (if KE payloads are included
677 in the CREATE_CHILD_SA exchange).
679 If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of
680 the SA offers MUST include the Diffie-Hellman group of the KEi. The
681 Diffie-Hellman group of the KEi MUST be an element of the group the
682 initiator expects the responder to accept (additional Diffie-Hellman
683 groups can be proposed). If the responder rejects the Diffie-Hellman
684 group of the KEi payload, the responder MUST reject the request and
685 indicate its preferred Diffie-Hellman group in the INVALID_KE_PAYLOAD
686 Notification payload. In the case of such a rejection, the
687 CREATE_CHILD_SA exchange fails, and the initiator will probably retry
688 the exchange with a Diffie-Hellman proposal and KEi in the group that
689 the responder gave in the INVALID_KE_PAYLOAD.
691 1.3.1. Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange
693 A CHILD_SA may be created by sending a CREATE_CHILD_SA request. The
694 CREATE_CHILD_SA request for creating a new CHILD_SA is:
697 -------------------------------------------------------------------
698 HDR, SK {SA, Ni, [KEi],
701 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
702 payload, optionally a Diffie-Hellman value in the KEi payload, and
703 the proposed traffic selectors for the proposed CHILD_SA in the TSi
706 The CREATE_CHILD_SA response for creating a new CHILD_SA is:
708 <-- HDR, SK {SA, Nr, [KEr],
711 The responder replies (using the same Message ID to respond) with the
712 accepted offer in an SA payload, and a Diffie-Hellman value in the
713 KEr payload if KEi was included in the request and the selected
714 cryptographic suite includes that group.
716 The traffic selectors for traffic to be sent on that SA are specified
717 in the TS payloads in the response, which may be a subset of what the
718 initiator of the CHILD_SA proposed.
720 1.3.2. Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange
722 The CREATE_CHILD_SA request for rekeying an IKE_SA is:
727 Hoffman Expires July 5, 2006 [Page 13]
729 Internet-Draft IKEv2 January 2006
733 -------------------------------------------------------------------
734 HDR, SK {SA, Ni, KEi} -->
736 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
737 payload, and a Diffie-Hellman value in the KEi payload. New
738 initiator and responder SPIs are supplied in the SPI fields.
740 The CREATE_CHILD_SA response for rekeying an IKE_SA is:
742 <-- HDR, SK {SA, Nr, KEr}
744 The responder replies (using the same Message ID to respond) with the
745 accepted offer in an SA payload, and a Diffie-Hellman value in the
746 KEr payload if the selected cryptographic suite includes that group.
748 The new IKE_SA has its message counters set to 0, regardless of what
749 they were in the earlier IKE_SA. The window size starts at 1 for any
752 KEi and KEr are required for rekeying an IKE_SA.
754 1.3.3. Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange
756 The CREATE_CHILD_SA request for rekeying a CHILD_SA is:
759 -------------------------------------------------------------------
760 HDR, SK {N, SA, Ni, [KEi],
763 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
764 payload, optionally a Diffie-Hellman value in the KEi payload, and
765 the proposed traffic selectors for the proposed CHILD_SA in the TSi
766 and TSr payloads. When rekeying an existing CHILD_SA, the leading N
767 payload of type REKEY_SA MUST be included and MUST give the SPI (as
768 they would be expected in the headers of inbound packets) of the SAs
771 The CREATE_CHILD_SA response for rekeying a CHILD_SA is:
773 <-- HDR, SK {SA, Nr, [KEr],
776 The responder replies (using the same Message ID to respond) with the
777 accepted offer in an SA payload, and a Diffie-Hellman value in the
778 KEr payload if KEi was included in the request and the selected
779 cryptographic suite includes that group.
783 Hoffman Expires July 5, 2006 [Page 14]
785 Internet-Draft IKEv2 January 2006
788 The traffic selectors for traffic to be sent on that SA are specified
789 in the TS payloads in the response, which may be a subset of what the
790 initiator of the CHILD_SA proposed.
792 1.4. The INFORMATIONAL Exchange
794 At various points during the operation of an IKE_SA, peers may desire
795 to convey control messages to each other regarding errors or
796 notifications of certain events. To accomplish this, IKE defines an
797 INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur
798 after the initial exchanges and are cryptographically protected with
801 Control messages that pertain to an IKE_SA MUST be sent under that
802 IKE_SA. Control messages that pertain to CHILD_SAs MUST be sent
803 under the protection of the IKE_SA which generated them (or its
804 successor if the IKE_SA was replaced for the purpose of rekeying).
806 Messages in an INFORMATIONAL exchange contain zero or more
807 Notification, Delete, and Configuration payloads. The Recipient of
808 an INFORMATIONAL exchange request MUST send some response (else the
809 Sender will assume the message was lost in the network and will
810 retransmit it). That response MAY be a message with no payloads.
811 The request message in an INFORMATIONAL exchange MAY also contain no
812 payloads. This is the expected way an endpoint can ask the other
813 endpoint to verify that it is alive.
815 {{ Clarif-5.6 }} ESP and AH SAs always exist in pairs, with one SA in
816 each direction. When an SA is closed, both members of the pair MUST
817 be closed (that is, deleted). When SAs are nested, as when data (and
818 IP headers if in tunnel mode) are encapsulated first with IPComp,
819 then with ESP, and finally with AH between the same pair of
820 endpoints, all of the SAs MUST be deleted together. Each endpoint
821 MUST close its incoming SAs and allow the other endpoint to close the
822 other SA in each pair. To delete an SA, an INFORMATIONAL exchange
823 with one or more delete payloads is sent listing the SPIs (as they
824 would be expected in the headers of inbound packets) of the SAs to be
825 deleted. The recipient MUST close the designated SAs. {{ Clarif-5.7
826 }} Note that you never send delete payloads for the two sides of an
827 SA in a single message. If you have many SAs to delete at the same
828 time (such as for nested SAs), you include delete payloads for in
829 inbound half of each SA in your Informational exchange.
831 Normally, the reply in the INFORMATIONAL exchange will contain delete
832 payloads for the paired SAs going in the other direction. There is
833 one exception. If by chance both ends of a set of SAs independently
834 decide to close them, each may send a delete payload and the two
835 requests may cross in the network. If a node receives a delete
839 Hoffman Expires July 5, 2006 [Page 15]
841 Internet-Draft IKEv2 January 2006
844 request for SAs for which it has already issued a delete request, it
845 MUST delete the outgoing SAs while processing the request and the
846 incoming SAs while processing the response. In that case, the
847 responses MUST NOT include delete payloads for the deleted SAs, since
848 that would result in duplicate deletion and could in theory delete
851 {{ Demoted the SHOULD }} Half-closed connections are anomalous and,
852 and a node with auditing capability will probably audit their
853 existence if they persist. Note that this specification nowhere
854 specifies time periods, so it is up to individual endpoints to decide
855 how long to wait. A node MAY refuse to accept incoming data on half-
856 closed connections but MUST NOT unilaterally close them and reuse the
857 SPIs. If connection state becomes sufficiently messed up, a node MAY
858 close the IKE_SA; doing so will implicitly close all SAs negotiated
859 under it. It can then rebuild the SAs it needs on a clean base under
860 a new IKE_SA. {{ Clarif-5.8 }} The response to a request that deletes
861 the IKE_SA is an empty Informational response.
863 The INFORMATIONAL exchange is defined as:
866 -------------------------------------------------------------------
869 <-- HDR, SK {[N,] [D,]
872 The processing of an INFORMATIONAL exchange is determined by its
875 1.5. Informational Messages outside of an IKE_SA
877 If an encrypted IKE packet arrives on port 500 or 4500 with an
878 unrecognized SPI, it could be because the receiving node has recently
879 crashed and lost state or because of some other system malfunction or
880 attack. If the receiving node has an active IKE_SA to the IP address
881 from whence the packet came, it MAY send a notification of the
882 wayward packet over that IKE_SA in an INFORMATIONAL exchange. If it
883 does not have such an IKE_SA, it MAY send an Informational message
884 without cryptographic protection to the source IP address. Such a
885 message is not part of an informational exchange, and the receiving
886 node MUST NOT respond to it. Doing so could cause a message loop.
888 {{ Clarif-7.7 }} There are two cases when such a one-way notification
889 is sent: INVALID_IKE_SPI and INVALID_SPI. These notifications are
890 sent outside of an IKE_SA. Note that such notifications are
891 explicitly not Informational exchanges; these are one-way messages
895 Hoffman Expires July 5, 2006 [Page 16]
897 Internet-Draft IKEv2 January 2006
900 that must not be responded to. In case of INVALID_IKE_SPI, the
901 message sent is a response message, and thus it is sent to the IP
902 address and port from whence it came with the same IKE SPIs and the
903 Message ID copied. In case of INVALID_SPI, however, there are no IKE
904 SPI values that would be meaningful to the recipient of such a
905 notification. Using zero values or random values are both
908 1.6. Requirements Terminology
910 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
911 "MAY" that appear in this document are to be interpreted as described
914 The term "Expert Review" is to be interpreted as defined in
917 1.7. Introduction to IKEv2.1
919 IKEv2.1 is very similar to IKEv2. Most of the differences between
920 this document at [IKEV2] are clarifications, mostly based on
921 [Clarif]. The changes listed in that document were discussed in the
922 IPsec Working Group and, after the Working Group was disbanded, on
923 the IPsec mailing list. That document contains detailed explanations
924 of areas that were unclear in IKEv2, and is thus useful to
925 implementers of IKEv2 and IKEv2.1.
927 In the body of this document, notes that are enclosed in double curly
928 braces {{ such as this }} point out changes from IKEv2. Changes that
929 come from [Clarif] are marked with the section from that document,
930 such as "{{ Clarif-2.10 }}".
932 This document also make the figures and references a bit more regular
935 IKEv2 developers have noted that the SHOULD-level requirements are
936 often unclear in that they don't say when it is OK to not obey the
937 requirements. They also have noted that there are MUST-level
938 requirements that are not related to interoperability. This document
939 has more explanation of some of these SHOULD-level requirements, and
940 some SHOULD-level and MUST-level requirements have been changed to
941 better match the definitions in [MUSTSHOULD]. All non-capitalized
942 uses of the words SHOULD and MUST now mean their normal English
943 sense, not the interoperability sense of [MUSTSHOULD].
945 IKEv2 (and IKEv1) developers have noted that there is a great deal of
946 material in the tables of codes in Section 3.10. This leads to
947 implementers not having all the needed information in the main body
951 Hoffman Expires July 5, 2006 [Page 17]
953 Internet-Draft IKEv2 January 2006
956 of the docment. A later version of this document may move much of
957 the material from those tables into the associated parts of the main
958 body of the document.
960 A later version of this document will probably have all the {{ }}
961 comments removed from the body of the document and instead appear in
965 2. IKE Protocol Details and Variations
967 IKE normally listens and sends on UDP port 500, though IKE messages
968 may also be received on UDP port 4500 with a slightly different
969 format (see Section 2.23). Since UDP is a datagram (unreliable)
970 protocol, IKE includes in its definition recovery from transmission
971 errors, including packet loss, packet replay, and packet forgery.
972 IKE is designed to function so long as (1) at least one of a series
973 of retransmitted packets reaches its destination before timing out;
974 and (2) the channel is not so full of forged and replayed packets so
975 as to exhaust the network or CPU capacities of either endpoint. Even
976 in the absence of those minimum performance requirements, IKE is
977 designed to fail cleanly (as though the network were broken).
979 Although IKEv2 messages are intended to be short, they contain
980 structures with no hard upper bound on size (in particular, X.509
981 certificates), and IKEv2 itself does not have a mechanism for
982 fragmenting large messages. IP defines a mechanism for fragmentation
983 of oversize UDP messages, but implementations vary in the maximum
984 message size supported. Furthermore, use of IP fragmentation opens
985 an implementation to denial of service attacks [DOSUDPPROT].
986 Finally, some NAT and/or firewall implementations may block IP
989 All IKEv2 implementations MUST be able to send, receive, and process
990 IKE messages that are up to 1280 bytes long, and they SHOULD be able
991 to send, receive, and process messages that are up to 3000 bytes
992 long. {{ Demoted the SHOULD }} IKEv2 implementations need to be aware
993 of the maximum UDP message size supported and MAY shorten messages by
994 leaving out some certificates or cryptographic suite proposals if
995 that will keep messages below the maximum. Use of the "Hash and URL"
996 formats rather than including certificates in exchanges where
997 possible can avoid most problems. {{ Demoted the SHOULD }}
998 Implementations and configuration need to keep in mind, however, that
999 if the URL lookups are possible only after the IPsec SA is
1000 established, recursion issues could prevent this technique from
1007 Hoffman Expires July 5, 2006 [Page 18]
1009 Internet-Draft IKEv2 January 2006
1012 2.1. Use of Retransmission Timers
1014 All messages in IKE exist in pairs: a request and a response. The
1015 setup of an IKE_SA normally consists of two request/response pairs.
1016 Once the IKE_SA is set up, either end of the security association may
1017 initiate requests at any time, and there can be many requests and
1018 responses "in flight" at any given moment. But each message is
1019 labeled as either a request or a response, and for each request/
1020 response pair one end of the security association is the initiator
1021 and the other is the responder.
1023 For every pair of IKE messages, the initiator is responsible for
1024 retransmission in the event of a timeout. The responder MUST never
1025 retransmit a response unless it receives a retransmission of the
1026 request. In that event, the responder MUST ignore the retransmitted
1027 request except insofar as it triggers a retransmission of the
1028 response. The initiator MUST remember each request until it receives
1029 the corresponding response. The responder MUST remember each
1030 response until it receives a request whose sequence number is larger
1031 than the sequence number in the response plus its window size (see
1034 IKE is a reliable protocol, in the sense that the initiator MUST
1035 retransmit a request until either it receives a corresponding reply
1036 OR it deems the IKE security association to have failed and it
1037 discards all state associated with the IKE_SA and any CHILD_SAs
1038 negotiated using that IKE_SA.
1040 {{ Clarif-7.5 }} All packets sent on port 4500 MUST begin with the
1041 prefix of four zeros; otherwise, the receiver won't know how to
1044 2.2. Use of Sequence Numbers for Message ID
1046 Every IKE message contains a Message ID as part of its fixed header.
1047 This Message ID is used to match up requests and responses, and to
1048 identify retransmissions of messages.
1050 The Message ID is a 32-bit quantity, which is zero for the first IKE
1051 request in each direction. {{ Clarif-3.11 }} When the IKE_AUTH
1052 exchange does not use EAP, the IKE_SA initial setup messages will
1053 always be numbered 0 and 1. When EAP is used, each pair of messages
1054 have their message numbers incremented; the first pair of AUTH
1055 messages will have an ID of 1, the second will be 2, and so on.
1057 Each endpoint in the IKE Security Association maintains two "current"
1058 Message IDs: the next one to be used for a request it initiates and
1059 the next one it expects to see in a request from the other end.
1063 Hoffman Expires July 5, 2006 [Page 19]
1065 Internet-Draft IKEv2 January 2006
1068 These counters increment as requests are generated and received.
1069 Responses always contain the same message ID as the corresponding
1070 request. That means that after the initial exchange, each integer n
1071 may appear as the message ID in four distinct messages: the nth
1072 request from the original IKE initiator, the corresponding response,
1073 the nth request from the original IKE responder, and the
1074 corresponding response. If the two ends make very different numbers
1075 of requests, the Message IDs in the two directions can be very
1076 different. There is no ambiguity in the messages, however, because
1077 the (I)nitiator and (R)esponse bits in the message header specify
1078 which of the four messages a particular one is.
1080 {{ Clarif-2.2 }} The Message ID for IKE_SA_INIT messages is always
1081 zero, including for retries of the message due to responses such as
1082 COOKIE and INVALID_KE_PAYLOAD.
1084 Note that Message IDs are cryptographically protected and provide
1085 protection against message replays. In the unlikely event that
1086 Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be
1087 closed. Rekeying an IKE_SA resets the sequence numbers.
1089 {{ Clarif-2.3 }} When a responder receives an IKE_SA_INIT request, it
1090 has to determine whether the packet is a retransmission belonging to
1091 an existing "half-open" IKE_SA (in which case the responder
1092 retransmits the same response), or a new request (in which case the
1093 responder creates a new IKE_SA and sends a fresh response). It is
1094 not sufficient to use the initiator's SPI and/or IP address to
1095 differentiate between the two cases because two different peers
1096 behind a single NAT could choose the same initiator SPI. Instead, a
1097 robust responder will do the IKE_SA lookup using the whole packet,
1098 its hash, or the Ni payload.
1100 2.3. Window Size for Overlapping Requests
1102 In order to maximize IKE throughput, an IKE endpoint MAY issue
1103 multiple requests before getting a response to any of them if the
1104 other endpoint has indicated its ability to handle such requests.
1105 For simplicity, an IKE implementation MAY choose to process requests
1106 strictly in order and/or wait for a response to one request before
1107 issuing another. Certain rules must be followed to ensure
1108 interoperability between implementations using different strategies.
1110 After an IKE_SA is set up, either end can initiate one or more
1111 requests. These requests may pass one another over the network. An
1112 IKE endpoint MUST be prepared to accept and process a request while
1113 it has a request outstanding in order to avoid a deadlock in this
1114 situation. {{ Changed the SHOULD to MUST }} An IKE endpoint MUST be
1115 prepared to accept and process multiple requests while it has a
1119 Hoffman Expires July 5, 2006 [Page 20]
1121 Internet-Draft IKEv2 January 2006
1124 request outstanding.
1126 An IKE endpoint MUST wait for a response to each of its messages
1127 before sending a subsequent message unless it has received a
1128 SET_WINDOW_SIZE Notify message from its peer informing it that the
1129 peer is prepared to maintain state for multiple outstanding messages
1130 in order to allow greater throughput.
1132 An IKE endpoint MUST NOT exceed the peer's stated window size for
1133 transmitted IKE requests. In other words, if the responder stated
1134 its window size is N, then when the initiator needs to make a request
1135 X, it MUST wait until it has received responses to all requests up
1136 through request X-N. An IKE endpoint MUST keep a copy of (or be able
1137 to regenerate exactly) each request it has sent until it receives the
1138 corresponding response. An IKE endpoint MUST keep a copy of (or be
1139 able to regenerate exactly) the number of previous responses equal to
1140 its declared window size in case its response was lost and the
1141 initiator requests its retransmission by retransmitting the request.
1143 An IKE endpoint supporting a window size greater than one should be
1144 capable of processing incoming requests out of order to maximize
1145 performance in the event of network failures or packet reordering.
1147 {{ Clarif-7.3 }} The window size is assumed to be a (possibly
1148 configurable) property of a particular implementation, and is not
1149 related to congestion control (unlike the window size in TCP, for
1150 example). In particular, it is not defined what the responder should
1151 do when it receives a SET_WINDOW_SIZE notification containing a
1152 smaller value than is currently in effect. Thus, there is currently
1153 no way to reduce the window size of an existing IKE_SA; you can only
1154 increase it. When rekeying an IKE_SA, the new IKE_SA starts with
1155 window size 1 until it is explicitly increased by sending a new
1156 SET_WINDOW_SIZE notification.
1158 2.4. State Synchronization and Connection Timeouts
1160 An IKE endpoint is allowed to forget all of its state associated with
1161 an IKE_SA and the collection of corresponding CHILD_SAs at any time.
1162 This is the anticipated behavior in the event of an endpoint crash
1163 and restart. It is important when an endpoint either fails or
1164 reinitializes its state that the other endpoint detect those
1165 conditions and not continue to waste network bandwidth by sending
1166 packets over discarded SAs and having them fall into a black hole.
1168 Since IKE is designed to operate in spite of Denial of Service (DoS)
1169 attacks from the network, an endpoint MUST NOT conclude that the
1170 other endpoint has failed based on any routing information (e.g.,
1171 ICMP messages) or IKE messages that arrive without cryptographic
1175 Hoffman Expires July 5, 2006 [Page 21]
1177 Internet-Draft IKEv2 January 2006
1180 protection (e.g., Notify messages complaining about unknown SPIs).
1181 An endpoint MUST conclude that the other endpoint has failed only
1182 when repeated attempts to contact it have gone unanswered for a
1183 timeout period or when a cryptographically protected INITIAL_CONTACT
1184 notification is received on a different IKE_SA to the same
1185 authenticated identity. {{ Demoted the SHOULD }} An endpoint should
1186 suspect that the other endpoint has failed based on routing
1187 information and initiate a request to see whether the other endpoint
1188 is alive. To check whether the other side is alive, IKE specifies an
1189 empty INFORMATIONAL message that (like all IKE requests) requires an
1190 acknowledgement (note that within the context of an IKE_SA, an
1191 "empty" message consists of an IKE header followed by an Encrypted
1192 payload that contains no payloads). If a cryptographically protected
1193 message has been received from the other side recently, unprotected
1194 notifications MAY be ignored. Implementations MUST limit the rate at
1195 which they take actions based on unprotected messages.
1197 Numbers of retries and lengths of timeouts are not covered in this
1198 specification because they do not affect interoperability. It is
1199 suggested that messages be retransmitted at least a dozen times over
1200 a period of at least several minutes before giving up on an SA, but
1201 different environments may require different rules. To be a good
1202 network citizen, retranmission times MUST increase exponentially to
1203 avoid flooding the network and making an existing congestion
1204 situation worse. If there has only been outgoing traffic on all of
1205 the SAs associated with an IKE_SA, it is essential to confirm
1206 liveness of the other endpoint to avoid black holes. If no
1207 cryptographically protected messages have been received on an IKE_SA
1208 or any of its CHILD_SAs recently, the system needs to perform a
1209 liveness check in order to prevent sending messages to a dead peer.
1210 Receipt of a fresh cryptographically protected message on an IKE_SA
1211 or any of its CHILD_SAs ensures liveness of the IKE_SA and all of its
1212 CHILD_SAs. Note that this places requirements on the failure modes
1213 of an IKE endpoint. An implementation MUST NOT continue sending on
1214 any SA if some failure prevents it from receiving on all of the
1215 associated SAs. If CHILD_SAs can fail independently from one another
1216 without the associated IKE_SA being able to send a delete message,
1217 then they MUST be negotiated by separate IKE_SAs.
1219 There is a Denial of Service attack on the initiator of an IKE_SA
1220 that can be avoided if the initiator takes the proper care. Since
1221 the first two messages of an SA setup are not cryptographically
1222 protected, an attacker could respond to the initiator's message
1223 before the genuine responder and poison the connection setup attempt.
1224 To prevent this, the initiator MAY be willing to accept multiple
1225 responses to its first message, treat each as potentially legitimate,
1226 respond to it, and then discard all the invalid half-open connections
1227 when it receives a valid cryptographically protected response to any
1231 Hoffman Expires July 5, 2006 [Page 22]
1233 Internet-Draft IKEv2 January 2006
1236 one of its requests. Once a cryptographically valid response is
1237 received, all subsequent responses should be ignored whether or not
1238 they are cryptographically valid.
1240 Note that with these rules, there is no reason to negotiate and agree
1241 upon an SA lifetime. If IKE presumes the partner is dead, based on
1242 repeated lack of acknowledgement to an IKE message, then the IKE SA
1243 and all CHILD_SAs set up through that IKE_SA are deleted.
1245 An IKE endpoint may at any time delete inactive CHILD_SAs to recover
1246 resources used to hold their state. If an IKE endpoint chooses to
1247 delete CHILD_SAs, it MUST send Delete payloads to the other end
1248 notifying it of the deletion. It MAY similarly time out the IKE_SA.
1249 {{ Clarified the SHOULD }} Closing the IKE_SA implicitly closes all
1250 associated CHILD_SAs. In this case, an IKE endpoint SHOULD send a
1251 Delete payload indicating that it has closed the IKE_SA unless the
1252 other endpoint is no longer responding.
1254 2.5. Version Numbers and Forward Compatibility
1256 {{ The version number is changed in the following paragraph, and the
1257 discussion of handling of multiple versions is also changed
1258 throughout the section. }}
1260 This document describes version 2.1 of IKE, meaning the major version
1261 number is 2 and the minor version number is 1. It is likely that
1262 some implementations will want to support version 1.0 and version 2.0
1263 and version 2.1, and in the future, other versions.
1265 The major version number should be incremented only if the packet
1266 formats or required actions have changed so dramatically that an
1267 older version node would not be able to interoperate with a newer
1268 version node if it simply ignored the fields it did not understand
1269 and took the actions specified in the older specification. The minor
1270 version number indicates new capabilities, and MUST be ignored by a
1271 node with a smaller minor version number, but used for informational
1272 purposes by the node with the larger minor version number. For
1273 example, it might indicate the ability to process a newly defined
1274 notification message. The node with the larger minor version number
1275 would simply note that its correspondent would not be able to
1276 understand that message and therefore would not send it.
1278 In the discussion of clarifications to IKEv2, it became clear that
1279 there was a need for additional "MUST" and "SHOULD" requirements.
1280 Some of those changes are reflected in IKEv2.1. Thus, the node with
1281 the higher version number may also need to note that its
1282 correspondent may not be following the same required actions, which
1283 could affect interoperability.
1287 Hoffman Expires July 5, 2006 [Page 23]
1289 Internet-Draft IKEv2 January 2006
1292 {{ Promoted the SHOULD }} If an endpoint receives a message with a
1293 higher major version number, it MUST drop the message and MUST send
1294 an unauthenticated notification message containing the highest
1295 version number it supports. If an endpoint supports major version n,
1296 and major version m, it MUST support all versions between n and m.
1297 If it receives a message with a major version that it supports, it
1298 MUST respond with that version number. In order to prevent two nodes
1299 from being tricked into corresponding with a lower major version
1300 number than the maximum that they both support, IKE has a flag that
1301 indicates that the node is capable of speaking a higher major version
1304 Thus, the major version number in the IKE header indicates the
1305 version number of the message, not the highest version number that
1306 the transmitter supports. If the initiator is capable of speaking
1307 versions n, n+1, and n+2, and the responder is capable of speaking
1308 versions n and n+1, then they will negotiate speaking n+1, where the
1309 initiator will set the flag indicating its ability to speak a higher
1310 version. If they mistakenly (perhaps through an active attacker
1311 sending error messages) negotiate to version n, then both will notice
1312 that the other side can support a higher version number, and they
1313 MUST break the connection and reconnect using version n+1.
1315 Note that IKEv1 does not follow these rules, because there is no way
1316 in v1 of noting that you are capable of speaking a higher version
1317 number. So an active attacker can trick two v2-capable nodes into
1318 speaking v1. {{ Demoted the SHOULD }} When a v2-capable node
1319 negotiates down to v1, it should note that fact in its logs.
1321 Also for forward compatibility, all fields marked RESERVED MUST be
1322 set to zero by an implementation running version 2.0 or later, and
1323 their content MUST be ignored by an implementation running version
1324 2.0 or later ("Be conservative in what you send and liberal in what
1325 you receive"). In this way, future versions of the protocol can use
1326 those fields in a way that is guaranteed to be ignored by
1327 implementations that do not understand them. Similarly, payload
1328 types that are not defined are reserved for future use;
1329 implementations of a version where they are undefined MUST skip over
1330 those payloads and ignore their contents.
1332 IKEv2 adds a "critical" flag to each payload header for further
1333 flexibility for forward compatibility. If the critical flag is set
1334 and the payload type is unrecognized, the message MUST be rejected
1335 and the response to the IKE request containing that payload MUST
1336 include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an
1337 unsupported critical payload was included. If the critical flag is
1338 not set and the payload type is unsupported, that payload MUST be
1343 Hoffman Expires July 5, 2006 [Page 24]
1345 Internet-Draft IKEv2 January 2006
1348 {{ Demoted the SHOULD }}Although new payload types may be added in
1349 the future and may appear interleaved with the fields defined in this
1350 specification, implementations MUST send the payloads defined in this
1351 specification in the order shown in the figures in Section 2 and
1352 implementations MAY reject as invalid a message with those payloads
1357 The term "cookies" originates with Karn and Simpson [PHOTURIS] in
1358 Photuris, an early proposal for key management with IPsec, and it has
1359 persisted. The Internet Security Association and Key Management
1360 Protocol (ISAKMP) [ISAKMP] fixed message header includes two eight-
1361 octet fields titled "cookies", and that syntax is used by both IKEv1
1362 and IKEv2 though in IKEv2 they are referred to as the IKE SPI and
1363 there is a new separate field in a Notify payload holding the cookie.
1364 The initial two eight-octet fields in the header are used as a
1365 connection identifier at the beginning of IKE packets. {{ Promoted
1366 the SHOULD }} Each endpoint chooses one of the two SPIs and MUST
1367 choose them so as to be unique identifiers of an IKE_SA. An SPI
1368 value of zero is special and indicates that the remote SPI value is
1369 not yet known by the sender.
1371 Unlike ESP and AH where only the recipient's SPI appears in the
1372 header of a message, in IKE the sender's SPI is also sent in every
1373 message. Since the SPI chosen by the original initiator of the
1374 IKE_SA is always sent first, an endpoint with multiple IKE_SAs open
1375 that wants to find the appropriate IKE_SA using the SPI it assigned
1376 must look at the I(nitiator) Flag bit in the header to determine
1377 whether it assigned the first or the second eight octets.
1379 In the first message of an initial IKE exchange, the initiator will
1380 not know the responder's SPI value and will therefore set that field
1383 An expected attack against IKE is state and CPU exhaustion, where the
1384 target is flooded with session initiation requests from forged IP
1385 addresses. This attack can be made less effective if an
1386 implementation of a responder uses minimal CPU and commits no state
1387 to an SA until it knows the initiator can receive packets at the
1388 address from which it claims to be sending them. To accomplish this,
1389 a responder SHOULD -- when it detects a large number of half-open
1390 IKE_SAs -- reject initial IKE messages unless they contain a Notify
1391 payload of type COOKIE. {{ Clarified the SHOULD }} If the responder
1392 wants to set up an SA, it SHOULD instead send an unprotected IKE
1393 message as a response and include COOKIE Notify payload with the
1394 cookie data to be returned. Initiators who receive such responses
1395 MUST retry the IKE_SA_INIT with a Notify payload of type COOKIE
1399 Hoffman Expires July 5, 2006 [Page 25]
1401 Internet-Draft IKEv2 January 2006
1404 containing the responder supplied cookie data as the first payload
1405 and all other payloads unchanged. The initial exchange will then be
1409 -------------------------------------------------------------------
1410 HDR(A,0), SAi1, KEi, Ni -->
1411 <-- HDR(A,0), N(COOKIE)
1412 HDR(A,0), N(COOKIE), SAi1,
1414 <-- HDR(A,B), SAr1, KEr,
1416 HDR(A,B), SK {IDi, [CERT,]
1417 [CERTREQ,] [IDr,] AUTH,
1419 <-- HDR(A,B), SK {IDr, [CERT,]
1420 AUTH, SAr2, TSi, TSr}
1422 The first two messages do not affect any initiator or responder state
1423 except for communicating the cookie. In particular, the message
1424 sequence numbers in the first four messages will all be zero and the
1425 message sequence numbers in the last two messages will be one. 'A'
1426 is the SPI assigned by the initiator, while 'B' is the SPI assigned
1429 {{ Clarif-2.1 }} Because the responder's SPI identifies security-
1430 related state held by the responder, and in this case no state is
1431 created, the responder sends a zero value for the responder's SPI.
1433 {{ Demoted the SHOULD }} An IKE implementation should implement its
1434 responder cookie generation in such a way as to not require any saved
1435 state to recognize its valid cookie when the second IKE_SA_INIT
1436 message arrives. The exact algorithms and syntax they use to
1437 generate cookies do not affect interoperability and hence are not
1438 specified here. The following is an example of how an endpoint could
1439 use cookies to implement limited DOS protection.
1441 A good way to do this is to set the responder cookie to be:
1443 Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)
1445 where <secret> is a randomly generated secret known only to the
1446 responder and periodically changed and | indicates concatenation.
1447 <VersionIDofSecret> should be changed whenever <secret> is
1448 regenerated. The cookie can be recomputed when the IKE_SA_INIT
1449 arrives the second time and compared to the cookie in the received
1450 message. If it matches, the responder knows that the cookie was
1451 generated since the last change to <secret> and that IPi must be the
1455 Hoffman Expires July 5, 2006 [Page 26]
1457 Internet-Draft IKEv2 January 2006
1460 same as the source address it saw the first time. Incorporating SPIi
1461 into the calculation ensures that if multiple IKE_SAs are being set
1462 up in parallel they will all get different cookies (assuming the
1463 initiator chooses unique SPIi's). Incorporating Ni into the hash
1464 ensures that an attacker who sees only message 2 can't successfully
1467 If a new value for <secret> is chosen while there are connections in
1468 the process of being initialized, an IKE_SA_INIT might be returned
1469 with other than the current <VersionIDofSecret>. The responder in
1470 that case MAY reject the message by sending another response with a
1471 new cookie or it MAY keep the old value of <secret> around for a
1472 short time and accept cookies computed from either one. {{ Demoted
1473 the SHOULD NOT }} The responder should not accept cookies
1474 indefinitely after <secret> is changed, since that would defeat part
1475 of the denial of service protection. {{ Demoted the SHOULD }} The
1476 responder should change the value of <secret> frequently, especially
1479 {{ Clarif-2.1 }} In addition to cookies, there are several cases
1480 where the IKE_SA_INIT exchange does not result in the creation of an
1481 IKE_SA (such as INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). In such a
1482 case, sending a zero value for the Responder's SPI is correct. If
1483 the responder sends a non-zero responder SPI, the initiator should
1484 not reject the response for only that reason.
1486 {{ Clarif-2.5 }} When one party receives an IKE_SA_INIT request
1487 containing a cookie whose contents do not match the value expected,
1488 that party MUST ignore the cookie and process the message as if no
1489 cookie had been included; usually this means sending a response
1490 containing a new cookie.
1492 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD
1494 {{ This section added by Clarif-2.4 }}
1496 There are two common reasons why the initiator may have to retry the
1497 IKE_SA_INIT exchange: the responder requests a cookie or wants a
1498 different Diffie-Hellman group than was included in the KEi payload.
1499 If the initiator receives a cookie from the responder, the initiator
1500 needs to decide whether or not tp include the cookie in only the next
1501 retry of the IKE_SA_INIT request, or in all subsequent retries as
1504 If the initiator includes the cookie only in the next retry, one
1505 additional roundtrip may be needed in some cases. An additional
1506 roundtrip is needed also if the initiator includes the cookie in all
1507 retries, but the responder does not support this. For instance, if
1511 Hoffman Expires July 5, 2006 [Page 27]
1513 Internet-Draft IKEv2 January 2006
1516 the responder includes the SAi1 and KEi payloads in cookie
1517 calculation, it will reject the request by sending a new cookie.
1519 If both peers support including the cookie in all retries, a slightly
1520 shorter exchange can happen. Implementations MUST support this
1521 shorter exchange, but MUST NOT assume other implementations also
1522 supports this shorter exchange.
1524 2.7. Cryptographic Algorithm Negotiation
1526 The payload type known as "SA" indicates a proposal for a set of
1527 choices of IPsec protocols (IKE, ESP, and/or AH) for the SA as well
1528 as cryptographic algorithms associated with each protocol.
1530 An SA payload consists of one or more proposals. Each proposal
1531 includes one or more protocols (usually one). Each protocol contains
1532 one or more transforms -- each specifying a cryptographic algorithm.
1533 Each transform contains zero or more attributes (attributes are
1534 needed only if the transform identifier does not completely specify
1535 the cryptographic algorithm).
1537 This hierarchical structure was designed to efficiently encode
1538 proposals for cryptographic suites when the number of supported
1539 suites is large because multiple values are acceptable for multiple
1540 transforms. The responder MUST choose a single suite, which MAY be
1541 any subset of the SA proposal following the rules below:
1543 Each proposal contains one or more protocols. If a proposal is
1544 accepted, the SA response MUST contain the same protocols in the same
1545 order as the proposal. The responder MUST accept a single proposal
1546 or reject them all and return an error. (Example: if a single
1547 proposal contains ESP and AH and that proposal is accepted, both ESP
1548 and AH MUST be accepted. If ESP and AH are included in separate
1549 proposals, the responder MUST accept only one of them).
1551 Each IPsec protocol proposal contains one or more transforms. Each
1552 transform contains a transform type. The accepted cryptographic
1553 suite MUST contain exactly one transform of each type included in the
1554 proposal. For example: if an ESP proposal includes transforms
1555 ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256,
1556 AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one
1557 of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six
1558 combinations are acceptable.
1560 Since the initiator sends its Diffie-Hellman value in the
1561 IKE_SA_INIT, it must guess the Diffie-Hellman group that the
1562 responder will select from its list of supported groups. If the
1563 initiator guesses wrong, the responder will respond with a Notify
1567 Hoffman Expires July 5, 2006 [Page 28]
1569 Internet-Draft IKEv2 January 2006
1572 payload of type INVALID_KE_PAYLOAD indicating the selected group. In
1573 this case, the initiator MUST retry the IKE_SA_INIT with the
1574 corrected Diffie-Hellman group. The initiator MUST again propose its
1575 full set of acceptable cryptographic suites because the rejection
1576 message was unauthenticated and otherwise an active attacker could
1577 trick the endpoints into negotiating a weaker suite than a stronger
1578 one that they both prefer.
1582 {{ Demoted the SHOULD }} IKE, ESP, and AH security associations use
1583 secret keys that should be used only for a limited amount of time and
1584 to protect a limited amount of data. This limits the lifetime of the
1585 entire security association. When the lifetime of a security
1586 association expires, the security association MUST NOT be used. If
1587 there is demand, new security associations MAY be established.
1588 Reestablishment of security associations to take the place of ones
1589 that expire is referred to as "rekeying".
1591 To allow for minimal IPsec implementations, the ability to rekey SAs
1592 without restarting the entire IKE_SA is optional. An implementation
1593 MAY refuse all CREATE_CHILD_SA requests within an IKE_SA. If an SA
1594 has expired or is about to expire and rekeying attempts using the
1595 mechanisms described here fail, an implementation MUST close the
1596 IKE_SA and any associated CHILD_SAs and then MAY start new ones. {{
1597 Demoted the SHOULD }} Implementations should support in-place
1598 rekeying of SAs, since doing so offers better performance and is
1599 likely to reduce the number of packets lost during the transition.
1601 To rekey a CHILD_SA within an existing IKE_SA, create a new,
1602 equivalent SA (see Section 2.17 below), and when the new one is
1603 established, delete the old one. To rekey an IKE_SA, establish a new
1604 equivalent IKE_SA (see Section 2.18 below) with the peer to whom the
1605 old IKE_SA is shared using a CREATE_CHILD_SA within the existing
1606 IKE_SA. An IKE_SA so created inherits all of the original IKE_SA's
1607 CHILD_SAs. Use the new IKE_SA for all control messages needed to
1608 maintain the CHILD_SAs created by the old IKE_SA, and delete the old
1609 IKE_SA. The Delete payload to delete itself MUST be the last request
1610 sent over an IKE_SA.
1612 {{ Demoted the SHOULD }} SAs should be rekeyed proactively, i.e., the
1613 new SA should be established before the old one expires and becomes
1614 unusable. Enough time should elapse between the time the new SA is
1615 established and the old one becomes unusable so that traffic can be
1616 switched over to the new SA.
1618 A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes
1619 were negotiated. In IKEv2, each end of the SA is responsible for
1623 Hoffman Expires July 5, 2006 [Page 29]
1625 Internet-Draft IKEv2 January 2006
1628 enforcing its own lifetime policy on the SA and rekeying the SA when
1629 necessary. If the two ends have different lifetime policies, the end
1630 with the shorter lifetime will end up always being the one to request
1631 the rekeying. If an SA bundle has been inactive for a long time and
1632 if an endpoint would not initiate the SA in the absence of traffic,
1633 the endpoint MAY choose to close the SA instead of rekeying it when
1634 its lifetime expires. {{ Demoted the SHOULD }} It should do so if
1635 there has been no traffic since the last time the SA was rekeyed.
1637 Note that IKEv2 deliberately allows parallel SAs with the same
1638 traffic selectors between common endpoints. One of the purposes of
1639 this is to support traffic quality of service (QoS) differences among
1640 the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and section 4.1 of
1641 [DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints
1642 and the traffic selectors may not uniquely identify an SA between
1643 those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on
1644 the basis of duplicate traffic selectors SHOULD NOT be used.
1646 {{ Demoted the SHOULD }} The node that initiated the surviving
1647 rekeyed SA should delete the replaced SA after the new one is
1650 There are timing windows -- particularly in the presence of lost
1651 packets -- where endpoints may not agree on the state of an SA. The
1652 responder to a CREATE_CHILD_SA MUST be prepared to accept messages on
1653 an SA before sending its response to the creation request, so there
1654 is no ambiguity for the initiator. The initiator MAY begin sending
1655 on an SA as soon as it processes the response. The initiator,
1656 however, cannot receive on a newly created SA until it receives and
1657 processes the response to its CREATE_CHILD_SA request. How, then, is
1658 the responder to know when it is OK to send on the newly created SA?
1660 From a technical correctness and interoperability perspective, the
1661 responder MAY begin sending on an SA as soon as it sends its response
1662 to the CREATE_CHILD_SA request. In some situations, however, this
1663 could result in packets unnecessarily being dropped, so an
1664 implementation MAY want to defer such sending.
1666 The responder can be assured that the initiator is prepared to
1667 receive messages on an SA if either (1) it has received a
1668 cryptographically valid message on the new SA, or (2) the new SA
1669 rekeys an existing SA and it receives an IKE request to close the
1670 replaced SA. {{ Clarif-5.10 }} When rekeying an SA, the responder
1671 SHOULD continue to send traffic on the old SA until one of those
1672 events occurs. When establishing a new SA, the responder MAY defer
1673 sending messages on a new SA until either it receives one or a
1674 timeout has occurred. {{ Demoted the SHOULD }} If an initiator
1675 receives a message on an SA for which it has not received a response
1679 Hoffman Expires July 5, 2006 [Page 30]
1681 Internet-Draft IKEv2 January 2006
1684 to its CREATE_CHILD_SA request, it should interpret that as a likely
1685 packet loss and retransmit the CREATE_CHILD_SA request. An initiator
1686 MAY send a dummy message on a newly created SA if it has no messages
1687 queued in order to assure the responder that the initiator is ready
1688 to receive messages.
1690 {{ Clarif-5.9 }} Throughout this document, "initiator" refers to the
1691 party who initiated the exchange being described, and "original
1692 initiator" refers to the party who initiated the whole IKE_SA. The
1693 "original initiator" always refers to the party who initiated the
1694 exchange which resulted in the current IKE_SA. In other words, if
1695 the the "original responder" starts rekeying the IKE_SA, that party
1696 becomes the "original initiator" of the new IKE_SA.
1698 2.8.1. Simultaneous CHILD_SA rekeying
1700 {{ The first two paragraphs were moved, and the rest was added, based
1703 If the two ends have the same lifetime policies, it is possible that
1704 both will initiate a rekeying at the same time (which will result in
1705 redundant SAs). To reduce the probability of this happening, the
1706 timing of rekeying requests SHOULD be jittered (delayed by a random
1707 amount of time after the need for rekeying is noticed).
1709 This form of rekeying may temporarily result in multiple similar SAs
1710 between the same pairs of nodes. When there are two SAs eligible to
1711 receive packets, a node MUST accept incoming packets through either
1712 SA. If redundant SAs are created though such a collision, the SA
1713 created with the lowest of the four nonces used in the two exchanges
1714 SHOULD be closed by the endpoint that created it. {{ Clarif-5.11 }}
1715 "Lowest" means an octet-by-octet, lexicographical comparison (instead
1716 of, for instance, comparing the nonces as large integers). In other
1717 words, start by comparing the first octet; if they're equal, move to
1718 the next octet, and so on. If you reach the end of one nonce, that
1719 nonce is the lower one.
1721 The following is an explanation on the impact this has on
1722 implementations. Assume that hosts A and B have an existing IPsec SA
1723 pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same
1727 -------------------------------------------------------------------
1728 send req1: N(REKEY_SA,SPIa1),
1729 SA(..,SPIa2,..),Ni1,.. -->
1730 <-- send req2: N(REKEY_SA,SPIb1),
1735 Hoffman Expires July 5, 2006 [Page 31]
1737 Internet-Draft IKEv2 January 2006
1742 At this point, A knows there is a simultaneous rekeying going on.
1743 However, it cannot yet know which of the exchanges will have the
1744 lowest nonce, so it will just note the situation and respond as
1747 send resp2: SA(..,SPIa3,..),
1751 Now B also knows that simultaneous rekeying is going on. It responds
1754 <-- send resp1: SA(..,SPIb3,..),
1759 At this point, there are three CHILD_SA pairs between A and B (the
1760 old one and two new ones). A and B can now compare the nonces.
1761 Suppose that the lowest nonce was Nr1 in message resp2; in this case,
1762 B (the sender of req2) deletes the redundant new SA, and A (the node
1763 that initiated the surviving rekeyed SA), deletes the old one.
1765 send req3: D(SPIa1) -->
1766 <-- send req4: D(SPIb2)
1768 <-- send resp4: D(SPIb1)
1770 send resp4: D(SPIa3) -->
1772 The rekeying is now finished.
1774 However, there is a second possible sequence of events that can
1775 happen if some packets are lost in the network, resulting in
1776 retransmissions. The rekeying begins as usual, but A's first packet
1791 Hoffman Expires July 5, 2006 [Page 32]
1793 Internet-Draft IKEv2 January 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 these 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 Hoffman Expires July 5, 2006 [Page 33]
1849 Internet-Draft IKEv2 January 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 Hoffman Expires July 5, 2006 [Page 34]
1905 Internet-Draft IKEv2 January 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 Hoffman Expires July 5, 2006 [Page 35]
1961 Internet-Draft IKEv2 January 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 Hoffman Expires July 5, 2006 [Page 36]
2017 Internet-Draft IKEv2 January 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 should not propose traffic
2041 selectors that violate its own policy. If this rule is not followed,
2042 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 Hoffman Expires July 5, 2006 [Page 37]
2073 Internet-Draft IKEv2 January 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 Hoffman Expires July 5, 2006 [Page 38]
2129 Internet-Draft IKEv2 January 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 Hoffman Expires July 5, 2006 [Page 39]
2185 Internet-Draft IKEv2 January 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 Hoffman Expires July 5, 2006 [Page 40]
2241 Internet-Draft IKEv2 January 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 Hoffman Expires July 5, 2006 [Page 41]
2297 Internet-Draft IKEv2 January 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 Hoffman Expires July 5, 2006 [Page 42]
2353 Internet-Draft IKEv2 January 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.8 }} 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. For
2387 this reason, these protocols are typically used to authenticate the
2388 initiator to the responder and MUST be used in conjunction with a
2389 public key signature based authentication of the responder to the
2390 initiator. These methods are often associated with mechanisms
2391 referred to as "Legacy Authentication" mechanisms.
2393 While this memo references [EAP] with the intent that new methods can
2394 be added in the future without updating this specification, some
2395 simpler variations are documented here and in Section 3.16. [EAP]
2396 defines an authentication protocol requiring a variable number of
2397 messages. Extensible Authentication is implemented in IKE as
2398 additional IKE_AUTH exchanges that MUST be completed in order to
2399 initialize the IKE_SA.
2401 An initiator indicates a desire to use extensible authentication by
2402 leaving out the AUTH payload from message 3. By including an IDi
2403 payload but not an AUTH payload, the initiator has declared an
2407 Hoffman Expires July 5, 2006 [Page 43]
2409 Internet-Draft IKEv2 January 2006
2412 identity but has not proven it. If the responder is willing to use
2413 an extensible authentication method, it will place an Extensible
2414 Authentication Protocol (EAP) payload in message 4 and defer sending
2415 SAr2, TSi, and TSr until initiator authentication is complete in a
2416 subsequent IKE_AUTH exchange. In the case of a minimal extensible
2417 authentication, the initial SA establishment will appear as follows:
2420 -------------------------------------------------------------------
2421 HDR, SAi1, KEi, Ni -->
2422 <-- HDR, SAr1, KEr, Nr, [CERTREQ]
2423 HDR, SK {IDi, [CERTREQ,]
2426 <-- HDR, SK {IDr, [CERT,] AUTH,
2429 <-- HDR, SK {EAP (success)}
2431 <-- HDR, SK {AUTH, SAr2, TSi, TSr }
2433 {{ Clarif-3.11 }} As described in Section 2.2, when EAP is used, each
2434 pair of IKE_SA initial setup messages will have their message numbers
2435 incremented; the first pair of AUTH messages will have an ID of 1,
2436 the second will be 2, and so on.
2438 For EAP methods that create a shared key as a side effect of
2439 authentication, that shared key MUST be used by both the initiator
2440 and responder to generate AUTH payloads in messages 7 and 8 using the
2441 syntax for shared secrets specified in Section 2.15. The shared key
2442 from EAP is the field from the EAP specification named MSK. The
2443 shared key generated during an IKE exchange MUST NOT be used for any
2446 EAP methods that do not establish a shared key SHOULD NOT be used, as
2447 they are subject to a number of man-in-the-middle attacks [EAPMITM]
2448 if these EAP methods are used in other protocols that do not use a
2449 server-authenticated tunnel. Please see the Security Considerations
2450 section for more details. If EAP methods that do not generate a
2451 shared key are used, the AUTH payloads in messages 7 and 8 MUST be
2452 generated using SK_pi and SK_pr, respectively.
2454 {{ Demoted the SHOULD }} The initiator of an IKE_SA using EAP needs
2455 to be capable of extending the initial protocol exchange to at least
2456 ten IKE_AUTH exchanges in the event the responder sends notification
2457 messages and/or retries the authentication prompt. Once the protocol
2458 exchange defined by the chosen EAP authentication method has
2459 successfully terminated, the responder MUST send an EAP payload
2463 Hoffman Expires July 5, 2006 [Page 44]
2465 Internet-Draft IKEv2 January 2006
2468 containing the Success message. Similarly, if the authentication
2469 method has failed, the responder MUST send an EAP payload containing
2470 the Failure message. The responder MAY at any time terminate the IKE
2471 exchange by sending an EAP payload containing the Failure message.
2473 Following such an extended exchange, the EAP AUTH payloads MUST be
2474 included in the two messages following the one containing the EAP
2477 {{ Clarif-3.5 }} When the initiator authentication uses EAP, it is
2478 possible that the contents of the IDi payload is used only for AAA
2479 routing purposes and selecting which EAP method to use. This value
2480 may be different from the identity authenticated by the EAP method.
2481 It is important that policy lookups and access control decisions use
2482 the actual authenticated identity. Often the EAP server is
2483 implemented in a separate AAA server that communicates with the IKEv2
2484 responder. In this case, the authenticated identity has to be sent
2485 from the AAA server to the IKEv2 responder.
2487 {{ Clarif-3.9 }} The information in Section 2.17 about PRFs with
2488 fixed-size keys also applies to EAP authentication. For instance, a
2489 PRF that requires a 128-bit key cannot be used with EAP because
2490 specifies that the MSK is at least 512 bits long.
2492 2.17. Generating Keying Material for CHILD_SAs
2494 A single CHILD_SA is created by the IKE_AUTH exchange, and additional
2495 CHILD_SAs can optionally be created in CREATE_CHILD_SA exchanges.
2496 Keying material for them is generated as follows:
2498 KEYMAT = prf+(SK_d, Ni | Nr)
2500 Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this
2501 request is the first CHILD_SA created or the fresh Ni and Nr from the
2502 CREATE_CHILD_SA exchange if this is a subsequent creation.
2504 For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman
2505 exchange, the keying material is defined as:
2507 KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr )
2509 where g^ir (new) is the shared secret from the ephemeral Diffie-
2510 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an
2511 octet string in big endian order padded with zeros in the high-order
2512 bits if necessary to make it the length of the modulus).
2514 A single CHILD_SA negotiation may result in multiple security
2515 associations. ESP and AH SAs exist in pairs (one in each direction),
2519 Hoffman Expires July 5, 2006 [Page 45]
2521 Internet-Draft IKEv2 January 2006
2524 and four SAs could be created in a single CHILD_SA negotiation if a
2525 combination of ESP and AH is being negotiated.
2527 Keying material MUST be taken from the expanded KEYMAT in the
2530 o All keys for SAs carrying data from the initiator to the responder
2531 are taken before SAs going in the reverse direction.
2533 o If multiple IPsec protocols are negotiated, keying material is
2534 taken in the order in which the protocol headers will appear in
2535 the encapsulated packet.
2537 o If a single protocol has both encryption and authentication keys,
2538 the encryption key is taken from the first octets of KEYMAT and
2539 the authentication key is taken from the next octets.
2541 Each cryptographic algorithm takes a fixed number of bits of keying
2542 material specified as part of the algorithm.
2544 2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA Exchange
2546 The CREATE_CHILD_SA exchange can be used to rekey an existing IKE_SA
2547 (see Section 2.8). {{ Clarif-5.3 }} New initiator and responder SPIs
2548 are supplied in the SPI fields in the Proposal structures inside the
2549 Security Association (SA) payloads (not the SPI fields in the IKE
2550 header). The TS payloads are omitted when rekeying an IKE_SA.
2551 SKEYSEED for the new IKE_SA is computed using SK_d from the existing
2554 SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)
2556 where g^ir (new) is the shared secret from the ephemeral Diffie-
2557 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an
2558 octet string in big endian order padded with zeros if necessary to
2559 make it the length of the modulus) and Ni and Nr are the two nonces
2560 stripped of any headers.
2562 {{ Clarif-5.5 }} The old and new IKE_SA may have selected a different
2563 PRF. Because the rekeying exchange belongs to the old IKE_SA, it is
2564 the old IKE_SA's PRF that is used. Note that this may not work if
2565 the new IKE_SA's PRF has a fixed key size because the output of the
2566 PRF may not be of the correct size.
2568 The new IKE_SA MUST reset its message counters to 0.
2570 SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as
2571 specified in Section 2.14.
2575 Hoffman Expires July 5, 2006 [Page 46]
2577 Internet-Draft IKEv2 January 2006
2580 2.19. Requesting an Internal Address on a Remote Network
2582 Most commonly occurring in the endpoint-to-security-gateway scenario,
2583 an endpoint may need an IP address in the network protected by the
2584 security gateway and may need to have that address dynamically
2585 assigned. A request for such a temporary address can be included in
2586 any request to create a CHILD_SA (including the implicit request in
2587 message 3) by including a CP payload.
2589 This function provides address allocation to an IPsec Remote Access
2590 Client (IRAC) trying to tunnel into a network protected by an IPsec
2591 Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an
2592 IKE_SA and a CHILD_SA, the IRAC MUST request the IRAS-controlled
2593 address (and optionally other information concerning the protected
2594 network) in the IKE_AUTH exchange. The IRAS may procure an address
2595 for the IRAC from any number of sources such as a DHCP/BOOTP server
2596 or its own address pool.
2599 -------------------------------------------------------------------
2600 HDR, SK {IDi, [CERT,]
2601 [CERTREQ,] [IDr,] AUTH,
2602 CP(CFG_REQUEST), SAi2,
2604 <-- HDR, SK {IDr, [CERT,] AUTH,
2605 CP(CFG_REPLY), SAr2,
2608 In all cases, the CP payload MUST be inserted before the SA payload.
2609 In variations of the protocol where there are multiple IKE_AUTH
2610 exchanges, the CP payloads MUST be inserted in the messages
2611 containing the SA payloads.
2613 CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute
2614 (either IPv4 or IPv6) but MAY contain any number of additional
2615 attributes the initiator wants returned in the response.
2617 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 Hoffman Expires July 5, 2006 [Page 47]
2633 Internet-Draft IKEv2 January 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 Hoffman Expires July 5, 2006 [Page 48]
2689 Internet-Draft IKEv2 January 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 Hoffman Expires July 5, 2006 [Page 49]
2745 Internet-Draft IKEv2 January 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 Hoffman Expires July 5, 2006 [Page 50]
2801 Internet-Draft IKEv2 January 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 Hoffman Expires July 5, 2006 [Page 51]
2857 Internet-Draft IKEv2 January 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 Hoffman Expires July 5, 2006 [Page 52]
2913 Internet-Draft IKEv2 January 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). {{ Promoted the SHOULD }} A host behind a NAT
2930 MUST NOT do this because it opens a DoS attack possibility. Any
2931 authenticated IKE packet or any authenticated UDP-encapsulated ESP
2932 packet can be used to detect that the IP address or the port has
2935 Note that similar but probably not identical actions will likely be
2936 needed to make IKE work with Mobile IP, but such processing is not
2937 addressed by this document.
2939 2.24. Explicit Congestion Notification (ECN)
2941 When IPsec tunnels behave as originally specified in [IPSECARCH-OLD],
2942 ECN usage is not appropriate for the outer IP headers because tunnel
2943 decapsulation processing discards ECN congestion indications to the
2944 detriment of the network. ECN support for IPsec tunnels for IKEv1-
2945 based IPsec requires multiple operating modes and negotiation (see
2946 [ECN]). IKEv2 simplifies this situation by requiring that ECN be
2947 usable in the outer IP headers of all tunnel-mode IPsec SAs created
2948 by IKEv2. Specifically, tunnel encapsulators and decapsulators for
2949 all tunnel-mode SAs created by IKEv2 MUST support the ECN full-
2950 functionality option for tunnels specified in [ECN] and MUST
2951 implement the tunnel encapsulation and decapsulation processing
2952 specified in [IPSECARCH] to prevent discarding of ECN congestion
2956 3. Header and Payload Formats
2960 IKE messages use UDP ports 500 and/or 4500, with one IKE message per
2961 UDP datagram. Information from the beginning of the packet through
2962 the UDP header is largely ignored except that the IP addresses and
2963 UDP ports from the headers are reversed and used for return packets.
2967 Hoffman Expires July 5, 2006 [Page 53]
2969 Internet-Draft IKEv2 January 2006
2972 When sent on UDP port 500, IKE messages begin immediately following
2973 the UDP header. When sent on UDP port 4500, IKE messages have
2974 prepended four octets of zero. These four octets of zero are not
2975 part of the IKE message and are not included in any of the length
2976 fields or checksums defined by IKE. Each IKE message begins with the
2977 IKE header, denoted HDR in this memo. Following the header are one
2978 or more IKE payloads each identified by a "Next Payload" field in the
2979 preceding payload. Payloads are processed in the order in which they
2980 appear in an IKE message by invoking the appropriate processing
2981 routine according to the "Next Payload" field in the IKE header and
2982 subsequently according to the "Next Payload" field in the IKE payload
2983 itself until a "Next Payload" field of zero indicates that no
2984 payloads follow. If a payload of type "Encrypted" is found, that
2985 payload is decrypted and its contents parsed as additional payloads.
2986 An Encrypted payload MUST be the last payload in a packet and an
2987 Encrypted payload MUST NOT contain another Encrypted payload.
2989 The Recipient SPI in the header identifies an instance of an IKE
2990 security association. It is therefore possible for a single instance
2991 of IKE to multiplex distinct sessions with multiple peers.
2993 All multi-octet fields representing integers are laid out in big
2994 endian order (aka most significant byte first, or network byte
2997 The format of the IKE header is shown in Figure 4.
3000 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
3001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3002 ! IKE_SA Initiator's SPI !
3004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3005 ! IKE_SA Responder's SPI !
3007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3008 ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags !
3009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3015 Figure 4: IKE Header Format
3017 o Initiator's SPI (8 octets) - A value chosen by the initiator to
3018 identify a unique IKE security association. This value MUST NOT
3023 Hoffman Expires July 5, 2006 [Page 54]
3025 Internet-Draft IKEv2 January 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 Hoffman Expires July 5, 2006 [Page 55]
3081 Internet-Draft IKEv2 January 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