7 Network Working Group C. Kaufman, Ed.
8 Request for Comments: 4306 Microsoft
9 Obsoletes: 2407, 2408, 2409 December 2005
10 Category: Standards Track
13 Internet Key Exchange (IKEv2) Protocol
17 This document specifies an Internet standards track protocol for the
18 Internet community, and requests discussion and suggestions for
19 improvements. Please refer to the current edition of the "Internet
20 Official Protocol Standards" (STD 1) for the standardization state
21 and status of this protocol. Distribution of this memo is unlimited.
25 Copyright (C) The Internet Society (2005).
29 This document describes version 2 of the Internet Key Exchange (IKE)
30 protocol. IKE is a component of IPsec used for performing mutual
31 authentication and establishing and maintaining security associations
34 This version of the IKE specification combines the contents of what
35 were previously separate documents, including Internet Security
36 Association and Key Management Protocol (ISAKMP, RFC 2408), IKE (RFC
37 2409), the Internet Domain of Interpretation (DOI, RFC 2407), Network
38 Address Translation (NAT) Traversal, Legacy authentication, and
39 remote address acquisition.
41 Version 2 of IKE does not interoperate with version 1, but it has
42 enough of the header format in common that both versions can
43 unambiguously run over the same UDP port.
58 Kaufman Standards Track [Page 1]
60 RFC 4306 IKEv2 December 2005
65 1. Introduction ....................................................3
66 1.1. Usage Scenarios ............................................5
67 1.2. The Initial Exchanges ......................................7
68 1.3. The CREATE_CHILD_SA Exchange ...............................9
69 1.4. The INFORMATIONAL Exchange ................................11
70 1.5. Informational Messages outside of an IKE_SA ...............12
71 2. IKE Protocol Details and Variations ............................12
72 2.1. Use of Retransmission Timers ..............................13
73 2.2. Use of Sequence Numbers for Message ID ....................14
74 2.3. Window Size for Overlapping Requests ......................14
75 2.4. State Synchronization and Connection Timeouts .............15
76 2.5. Version Numbers and Forward Compatibility .................17
77 2.6. Cookies ...................................................18
78 2.7. Cryptographic Algorithm Negotiation .......................21
79 2.8. Rekeying ..................................................22
80 2.9. Traffic Selector Negotiation ..............................24
81 2.10. Nonces ...................................................26
82 2.11. Address and Port Agility .................................26
83 2.12. Reuse of Diffie-Hellman Exponentials .....................27
84 2.13. Generating Keying Material ...............................27
85 2.14. Generating Keying Material for the IKE_SA ................28
86 2.15. Authentication of the IKE_SA .............................29
87 2.16. Extensible Authentication Protocol Methods ...............31
88 2.17. Generating Keying Material for CHILD_SAs .................33
89 2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA exchange ........34
90 2.19. Requesting an Internal Address on a Remote Network .......34
91 2.20. Requesting the Peer's Version ............................35
92 2.21. Error Handling ...........................................36
93 2.22. IPComp ...................................................37
94 2.23. NAT Traversal ............................................38
95 2.24. Explicit Congestion Notification (ECN) ...................40
96 3. Header and Payload Formats .....................................41
97 3.1. The IKE Header ............................................41
98 3.2. Generic Payload Header ....................................44
99 3.3. Security Association Payload ..............................46
100 3.4. Key Exchange Payload ......................................56
101 3.5. Identification Payloads ...................................56
102 3.6. Certificate Payload .......................................59
103 3.7. Certificate Request Payload ...............................61
104 3.8. Authentication Payload ....................................63
105 3.9. Nonce Payload .............................................64
106 3.10. Notify Payload ...........................................64
107 3.11. Delete Payload ...........................................72
108 3.12. Vendor ID Payload ........................................73
109 3.13. Traffic Selector Payload .................................74
110 3.14. Encrypted Payload ........................................77
114 Kaufman Standards Track [Page 2]
116 RFC 4306 IKEv2 December 2005
119 3.15. Configuration Payload ....................................79
120 3.16. Extensible Authentication Protocol (EAP) Payload .........84
121 4. Conformance Requirements .......................................85
122 5. Security Considerations ........................................88
123 6. IANA Considerations ............................................90
124 7. Acknowledgements ...............................................91
125 8. References .....................................................91
126 8.1. Normative References ......................................91
127 8.2. Informative References ....................................92
128 Appendix A: Summary of Changes from IKEv1 .........................96
129 Appendix B: Diffie-Hellman Groups .................................97
130 B.1. Group 1 - 768 Bit MODP ....................................97
131 B.2. Group 2 - 1024 Bit MODP ...................................97
135 IP Security (IPsec) provides confidentiality, data integrity, access
136 control, and data source authentication to IP datagrams. These
137 services are provided by maintaining shared state between the source
138 and the sink of an IP datagram. This state defines, among other
139 things, the specific services provided to the datagram, which
140 cryptographic algorithms will be used to provide the services, and
141 the keys used as input to the cryptographic algorithms.
143 Establishing this shared state in a manual fashion does not scale
144 well. Therefore, a protocol to establish this state dynamically is
145 needed. This memo describes such a protocol -- the Internet Key
146 Exchange (IKE). This is version 2 of IKE. Version 1 of IKE was
147 defined in RFCs 2407, 2408, and 2409 [Pip98, MSST98, HC98]. This
148 single document is intended to replace all three of those RFCs.
150 Definitions of the primitive terms in this document (such as Security
151 Association or SA) can be found in [RFC4301].
153 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
154 "MAY" that appear in this document are to be interpreted as described
157 The term "Expert Review" is to be interpreted as defined in
160 IKE performs mutual authentication between two parties and
161 establishes an IKE security association (SA) that includes shared
162 secret information that can be used to efficiently establish SAs for
163 Encapsulating Security Payload (ESP) [RFC4303] and/or Authentication
164 Header (AH) [RFC4302] and a set of cryptographic algorithms to be
165 used by the SAs to protect the traffic that they carry. In this
166 document, the term "suite" or "cryptographic suite" refers to a
170 Kaufman Standards Track [Page 3]
172 RFC 4306 IKEv2 December 2005
175 complete set of algorithms used to protect an SA. An initiator
176 proposes one or more suites by listing supported algorithms that can
177 be combined into suites in a mix-and-match fashion. IKE can also
178 negotiate use of IP Compression (IPComp) [IPCOMP] in connection with
179 an ESP and/or AH SA. We call the IKE SA an "IKE_SA". The SAs for
180 ESP and/or AH that get set up through that IKE_SA we call
183 All IKE communications consist of pairs of messages: a request and a
184 response. The pair is called an "exchange". We call the first
185 messages establishing an IKE_SA IKE_SA_INIT and IKE_AUTH exchanges
186 and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL
187 exchanges. In the common case, there is a single IKE_SA_INIT
188 exchange and a single IKE_AUTH exchange (a total of four messages) to
189 establish the IKE_SA and the first CHILD_SA. In exceptional cases,
190 there may be more than one of each of these exchanges. In all cases,
191 all IKE_SA_INIT exchanges MUST complete before any other exchange
192 type, then all IKE_AUTH exchanges MUST complete, and following that
193 any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur
194 in any order. In some scenarios, only a single CHILD_SA is needed
195 between the IPsec endpoints, and therefore there would be no
196 additional exchanges. Subsequent exchanges MAY be used to establish
197 additional CHILD_SAs between the same authenticated pair of endpoints
198 and to perform housekeeping functions.
200 IKE message flow always consists of a request followed by a response.
201 It is the responsibility of the requester to ensure reliability. If
202 the response is not received within a timeout interval, the requester
203 needs to retransmit the request (or abandon the connection).
205 The first request/response of an IKE session (IKE_SA_INIT) negotiates
206 security parameters for the IKE_SA, sends nonces, and sends Diffie-
209 The second request/response (IKE_AUTH) transmits identities, proves
210 knowledge of the secrets corresponding to the two identities, and
211 sets up an SA for the first (and often only) AH and/or ESP CHILD_SA.
213 The types of subsequent exchanges are CREATE_CHILD_SA (which creates
214 a CHILD_SA) and INFORMATIONAL (which deletes an SA, reports error
215 conditions, or does other housekeeping). Every request requires a
216 response. An INFORMATIONAL request with no payloads (other than the
217 empty Encrypted payload required by the syntax) is commonly used as a
218 check for liveness. These subsequent exchanges cannot be used until
219 the initial exchanges have completed.
226 Kaufman Standards Track [Page 4]
228 RFC 4306 IKEv2 December 2005
231 In the description that follows, we assume that no errors occur.
232 Modifications to the flow should errors occur are described in
237 IKE is expected to be used to negotiate ESP and/or AH SAs in a number
238 of different scenarios, each with its own special requirements.
240 1.1.1. Security Gateway to Security Gateway Tunnel
242 +-+-+-+-+-+ +-+-+-+-+-+
244 Protected !Tunnel ! tunnel !Tunnel ! Protected
245 Subnet <-->!Endpoint !<---------->!Endpoint !<--> Subnet
247 +-+-+-+-+-+ +-+-+-+-+-+
249 Figure 1: Security Gateway to Security Gateway Tunnel
251 In this scenario, neither endpoint of the IP connection implements
252 IPsec, but network nodes between them protect traffic for part of the
253 way. Protection is transparent to the endpoints, and depends on
254 ordinary routing to send packets through the tunnel endpoints for
255 processing. Each endpoint would announce the set of addresses
256 "behind" it, and packets would be sent in tunnel mode where the inner
257 IP header would contain the IP addresses of the actual endpoints.
259 1.1.2. Endpoint-to-Endpoint Transport
261 +-+-+-+-+-+ +-+-+-+-+-+
262 ! ! IPsec transport ! !
263 !Protected! or tunnel mode SA !Protected!
264 !Endpoint !<---------------------------------------->!Endpoint !
266 +-+-+-+-+-+ +-+-+-+-+-+
268 Figure 2: Endpoint to Endpoint
270 In this scenario, both endpoints of the IP connection implement
271 IPsec, as required of hosts in [RFC4301]. Transport mode will
272 commonly be used with no inner IP header. If there is an inner IP
273 header, the inner addresses will be the same as the outer addresses.
274 A single pair of addresses will be negotiated for packets to be
275 protected by this SA. These endpoints MAY implement application
276 layer access controls based on the IPsec authenticated identities of
277 the participants. This scenario enables the end-to-end security that
278 has been a guiding principle for the Internet since [RFC1958],
282 Kaufman Standards Track [Page 5]
284 RFC 4306 IKEv2 December 2005
287 [RFC2775], and a method of limiting the inherent problems with
288 complexity in networks noted by [RFC3439]. Although this scenario
289 may not be fully applicable to the IPv4 Internet, it has been
290 deployed successfully in specific scenarios within intranets using
291 IKEv1. It should be more broadly enabled during the transition to
292 IPv6 and with the adoption of IKEv2.
294 It is possible in this scenario that one or both of the protected
295 endpoints will be behind a network address translation (NAT) node, in
296 which case the tunneled packets will have to be UDP encapsulated so
297 that port numbers in the UDP headers can be used to identify
298 individual endpoints "behind" the NAT (see section 2.23).
300 1.1.3. Endpoint to Security Gateway Tunnel
302 +-+-+-+-+-+ +-+-+-+-+-+
303 ! ! IPsec ! ! Protected
304 !Protected! tunnel !Tunnel ! Subnet
305 !Endpoint !<------------------------>!Endpoint !<--- and/or
307 +-+-+-+-+-+ +-+-+-+-+-+
309 Figure 3: Endpoint to Security Gateway Tunnel
311 In this scenario, a protected endpoint (typically a portable roaming
312 computer) connects back to its corporate network through an IPsec-
313 protected tunnel. It might use this tunnel only to access
314 information on the corporate network, or it might tunnel all of its
315 traffic back through the corporate network in order to take advantage
316 of protection provided by a corporate firewall against Internet-based
317 attacks. In either case, the protected endpoint will want an IP
318 address associated with the security gateway so that packets returned
319 to it will go to the security gateway and be tunneled back. This IP
320 address may be static or may be dynamically allocated by the security
321 gateway. In support of the latter case, IKEv2 includes a mechanism
322 for the initiator to request an IP address owned by the security
323 gateway for use for the duration of its SA.
325 In this scenario, packets will use tunnel mode. On each packet from
326 the protected endpoint, the outer IP header will contain the source
327 IP address associated with its current location (i.e., the address
328 that will get traffic routed to the endpoint directly), while the
329 inner IP header will contain the source IP address assigned by the
330 security gateway (i.e., the address that will get traffic routed to
331 the security gateway for forwarding to the endpoint). The outer
332 destination address will always be that of the security gateway,
333 while the inner destination address will be the ultimate destination
338 Kaufman Standards Track [Page 6]
340 RFC 4306 IKEv2 December 2005
343 In this scenario, it is possible that the protected endpoint will be
344 behind a NAT. In that case, the IP address as seen by the security
345 gateway will not be the same as the IP address sent by the protected
346 endpoint, and packets will have to be UDP encapsulated in order to be
349 1.1.4. Other Scenarios
351 Other scenarios are possible, as are nested combinations of the
352 above. One notable example combines aspects of 1.1.1 and 1.1.3. A
353 subnet may make all external accesses through a remote security
354 gateway using an IPsec tunnel, where the addresses on the subnet are
355 routed to the security gateway by the rest of the Internet. An
356 example would be someone's home network being virtually on the
357 Internet with static IP addresses even though connectivity is
358 provided by an ISP that assigns a single dynamically assigned IP
359 address to the user's security gateway (where the static IP addresses
360 and an IPsec relay are provided by a third party located elsewhere).
362 1.2. The Initial Exchanges
364 Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH
365 exchanges (known in IKEv1 as Phase 1). These initial exchanges
366 normally consist of four messages, though in some scenarios that
367 number can grow. All communications using IKE consist of
368 request/response pairs. We'll describe the base exchange first,
369 followed by variations. The first pair of messages (IKE_SA_INIT)
370 negotiate cryptographic algorithms, exchange nonces, and do a
371 Diffie-Hellman exchange [DH].
373 The second pair of messages (IKE_AUTH) authenticate the previous
374 messages, exchange identities and certificates, and establish the
375 first CHILD_SA. Parts of these messages are encrypted and integrity
376 protected with keys established through the IKE_SA_INIT exchange, so
377 the identities are hidden from eavesdroppers and all fields in all
378 the messages are authenticated.
380 In the following descriptions, the payloads contained in the message
381 are indicated by names as listed below.
387 CERTREQ Certificate Request
394 Kaufman Standards Track [Page 7]
396 RFC 4306 IKEv2 December 2005
399 EAP Extensible Authentication
401 IDi Identification - Initiator
402 IDr Identification - Responder
406 SA Security Association
407 TSi Traffic Selector - Initiator
408 TSr Traffic Selector - Responder
411 The details of the contents of each payload are described in section
412 3. Payloads that may optionally appear will be shown in brackets,
413 such as [CERTREQ], indicate that optionally a certificate request
414 payload can be included.
416 The initial exchanges are as follows:
419 ----------- -----------
420 HDR, SAi1, KEi, Ni -->
422 HDR contains the Security Parameter Indexes (SPIs), version numbers,
423 and flags of various sorts. The SAi1 payload states the
424 cryptographic algorithms the initiator supports for the IKE_SA. The
425 KE payload sends the initiator's Diffie-Hellman value. Ni is the
428 <-- HDR, SAr1, KEr, Nr, [CERTREQ]
430 The responder chooses a cryptographic suite from the initiator's
431 offered choices and expresses that choice in the SAr1 payload,
432 completes the Diffie-Hellman exchange with the KEr payload, and sends
433 its nonce in the Nr payload.
435 At this point in the negotiation, each party can generate SKEYSEED,
436 from which all keys are derived for that IKE_SA. All but the headers
437 of all the messages that follow are encrypted and integrity
438 protected. The keys used for the encryption and integrity protection
439 are derived from SKEYSEED and are known as SK_e (encryption) and SK_a
440 (authentication, a.k.a. integrity protection). A separate SK_e and
441 SK_a is computed for each direction. In addition to the keys SK_e
442 and SK_a derived from the DH value for protection of the IKE_SA,
443 another quantity SK_d is derived and used for derivation of further
444 keying material for CHILD_SAs. The notation SK { ... } indicates
445 that these payloads are encrypted and integrity protected using that
446 direction's SK_e and SK_a.
450 Kaufman Standards Track [Page 8]
452 RFC 4306 IKEv2 December 2005
455 HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
456 AUTH, SAi2, TSi, TSr} -->
458 The initiator asserts its identity with the IDi payload, proves
459 knowledge of the secret corresponding to IDi and integrity protects
460 the contents of the first message using the AUTH payload (see section
461 2.15). It might also send its certificate(s) in CERT payload(s) and
462 a list of its trust anchors in CERTREQ payload(s). If any CERT
463 payloads are included, the first certificate provided MUST contain
464 the public key used to verify the AUTH field. The optional payload
465 IDr enables the initiator to specify which of the responder's
466 identities it wants to talk to. This is useful when the machine on
467 which the responder is running is hosting multiple identities at the
468 same IP address. The initiator begins negotiation of a CHILD_SA
469 using the SAi2 payload. The final fields (starting with SAi2) are
470 described in the description of the CREATE_CHILD_SA exchange.
472 <-- HDR, SK {IDr, [CERT,] AUTH,
475 The responder asserts its identity with the IDr payload, optionally
476 sends one or more certificates (again with the certificate containing
477 the public key used to verify AUTH listed first), authenticates its
478 identity and protects the integrity of the second message with the
479 AUTH payload, and completes negotiation of a CHILD_SA with the
480 additional fields described below in the CREATE_CHILD_SA exchange.
482 The recipients of messages 3 and 4 MUST verify that all signatures
483 and MACs are computed correctly and that the names in the ID payloads
484 correspond to the keys used to generate the AUTH payload.
486 1.3. The CREATE_CHILD_SA Exchange
488 This exchange consists of a single request/response pair, and was
489 referred to as a phase 2 exchange in IKEv1. It MAY be initiated by
490 either end of the IKE_SA after the initial exchanges are completed.
492 All messages following the initial exchange are cryptographically
493 protected using the cryptographic algorithms and keys negotiated in
494 the first two messages of the IKE exchange. These subsequent
495 messages use the syntax of the Encrypted Payload described in section
496 3.14. All subsequent messages included an Encrypted Payload, even if
497 they are referred to in the text as "empty".
499 Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this
500 section the term "initiator" refers to the endpoint initiating this
506 Kaufman Standards Track [Page 9]
508 RFC 4306 IKEv2 December 2005
511 A CHILD_SA is created by sending a CREATE_CHILD_SA request. The
512 CREATE_CHILD_SA request MAY optionally contain a KE payload for an
513 additional Diffie-Hellman exchange to enable stronger guarantees of
514 forward secrecy for the CHILD_SA. The keying material for the
515 CHILD_SA is a function of SK_d established during the establishment
516 of the IKE_SA, the nonces exchanged during the CREATE_CHILD_SA
517 exchange, and the Diffie-Hellman value (if KE payloads are included
518 in the CREATE_CHILD_SA exchange).
520 In the CHILD_SA created as part of the initial exchange, a second KE
521 payload and nonce MUST NOT be sent. The nonces from the initial
522 exchange are used in computing the keys for the CHILD_SA.
524 The CREATE_CHILD_SA request contains:
527 ----------- -----------
528 HDR, SK {[N], SA, Ni, [KEi],
531 The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
532 payload, optionally a Diffie-Hellman value in the KEi payload, and
533 the proposed traffic selectors in the TSi and TSr payloads. If this
534 CREATE_CHILD_SA exchange is rekeying an existing SA other than the
535 IKE_SA, the leading N payload of type REKEY_SA MUST identify the SA
536 being rekeyed. If this CREATE_CHILD_SA exchange is not rekeying an
537 existing SA, the N payload MUST be omitted. If the SA offers include
538 different Diffie-Hellman groups, KEi MUST be an element of the group
539 the initiator expects the responder to accept. If it guesses wrong,
540 the CREATE_CHILD_SA exchange will fail, and it will have to retry
541 with a different KEi.
543 The message following the header is encrypted and the message
544 including the header is integrity protected using the cryptographic
545 algorithms negotiated for the IKE_SA.
547 The CREATE_CHILD_SA response contains:
549 <-- HDR, SK {SA, Nr, [KEr],
552 The responder replies (using the same Message ID to respond) with the
553 accepted offer in an SA payload, and a Diffie-Hellman value in the
554 KEr payload if KEi was included in the request and the selected
555 cryptographic suite includes that group. If the responder chooses a
556 cryptographic suite with a different group, it MUST reject the
557 request. The initiator SHOULD repeat the request, but now with a KEi
558 payload from the group the responder selected.
562 Kaufman Standards Track [Page 10]
564 RFC 4306 IKEv2 December 2005
567 The traffic selectors for traffic to be sent on that SA are specified
568 in the TS payloads, which may be a subset of what the initiator of
569 the CHILD_SA proposed. Traffic selectors are omitted if this
570 CREATE_CHILD_SA request is being used to change the key of the
573 1.4. The INFORMATIONAL Exchange
575 At various points during the operation of an IKE_SA, peers may desire
576 to convey control messages to each other regarding errors or
577 notifications of certain events. To accomplish this, IKE defines an
578 INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur
579 after the initial exchanges and are cryptographically protected with
582 Control messages that pertain to an IKE_SA MUST be sent under that
583 IKE_SA. Control messages that pertain to CHILD_SAs MUST be sent
584 under the protection of the IKE_SA which generated them (or its
585 successor if the IKE_SA was replaced for the purpose of rekeying).
587 Messages in an INFORMATIONAL exchange contain zero or more
588 Notification, Delete, and Configuration payloads. The Recipient of
589 an INFORMATIONAL exchange request MUST send some response (else the
590 Sender will assume the message was lost in the network and will
591 retransmit it). That response MAY be a message with no payloads.
592 The request message in an INFORMATIONAL exchange MAY also contain no
593 payloads. This is the expected way an endpoint can ask the other
594 endpoint to verify that it is alive.
596 ESP and AH SAs always exist in pairs, with one SA in each direction.
597 When an SA is closed, both members of the pair MUST be closed. When
598 SAs are nested, as when data (and IP headers if in tunnel mode) are
599 encapsulated first with IPComp, then with ESP, and finally with AH
600 between the same pair of endpoints, all of the SAs MUST be deleted
601 together. Each endpoint MUST close its incoming SAs and allow the
602 other endpoint to close the other SA in each pair. To delete an SA,
603 an INFORMATIONAL exchange with one or more delete payloads is sent
604 listing the SPIs (as they would be expected in the headers of inbound
605 packets) of the SAs to be deleted. The recipient MUST close the
606 designated SAs. Normally, the reply in the INFORMATIONAL exchange
607 will contain delete payloads for the paired SAs going in the other
608 direction. There is one exception. If by chance both ends of a set
609 of SAs independently decide to close them, each may send a delete
610 payload and the two requests may cross in the network. If a node
611 receives a delete request for SAs for which it has already issued a
612 delete request, it MUST delete the outgoing SAs while processing the
613 request and the incoming SAs while processing the response. In that
618 Kaufman Standards Track [Page 11]
620 RFC 4306 IKEv2 December 2005
623 case, the responses MUST NOT include delete payloads for the deleted
624 SAs, since that would result in duplicate deletion and could in
625 theory delete the wrong SA.
627 A node SHOULD regard half-closed connections as anomalous and audit
628 their existence should they persist. Note that this specification
629 nowhere specifies time periods, so it is up to individual endpoints
630 to decide how long to wait. A node MAY refuse to accept incoming
631 data on half-closed connections but MUST NOT unilaterally close them
632 and reuse the SPIs. If connection state becomes sufficiently messed
633 up, a node MAY close the IKE_SA; doing so will implicitly close all
634 SAs negotiated under it. It can then rebuild the SAs it needs on a
635 clean base under a new IKE_SA.
637 The INFORMATIONAL exchange is defined as:
640 ----------- -----------
641 HDR, SK {[N,] [D,] [CP,] ...} -->
642 <-- HDR, SK {[N,] [D,] [CP], ...}
644 The processing of an INFORMATIONAL exchange is determined by its
647 1.5. Informational Messages outside of an IKE_SA
649 If an encrypted IKE packet arrives on port 500 or 4500 with an
650 unrecognized SPI, it could be because the receiving node has recently
651 crashed and lost state or because of some other system malfunction or
652 attack. If the receiving node has an active IKE_SA to the IP address
653 from whence the packet came, it MAY send a notification of the
654 wayward packet over that IKE_SA in an INFORMATIONAL exchange. If it
655 does not have such an IKE_SA, it MAY send an Informational message
656 without cryptographic protection to the source IP address. Such a
657 message is not part of an informational exchange, and the receiving
658 node MUST NOT respond to it. Doing so could cause a message loop.
660 2. IKE Protocol Details and Variations
662 IKE normally listens and sends on UDP port 500, though IKE messages
663 may also be received on UDP port 4500 with a slightly different
664 format (see section 2.23). Since UDP is a datagram (unreliable)
665 protocol, IKE includes in its definition recovery from transmission
666 errors, including packet loss, packet replay, and packet forgery.
667 IKE is designed to function so long as (1) at least one of a series
668 of retransmitted packets reaches its destination before timing out;
669 and (2) the channel is not so full of forged and replayed packets so
674 Kaufman Standards Track [Page 12]
676 RFC 4306 IKEv2 December 2005
679 as to exhaust the network or CPU capacities of either endpoint. Even
680 in the absence of those minimum performance requirements, IKE is
681 designed to fail cleanly (as though the network were broken).
683 Although IKEv2 messages are intended to be short, they contain
684 structures with no hard upper bound on size (in particular, X.509
685 certificates), and IKEv2 itself does not have a mechanism for
686 fragmenting large messages. IP defines a mechanism for fragmentation
687 of oversize UDP messages, but implementations vary in the maximum
688 message size supported. Furthermore, use of IP fragmentation opens
689 an implementation to denial of service attacks [KPS03]. Finally,
690 some NAT and/or firewall implementations may block IP fragments.
692 All IKEv2 implementations MUST be able to send, receive, and process
693 IKE messages that are up to 1280 bytes long, and they SHOULD be able
694 to send, receive, and process messages that are up to 3000 bytes
695 long. IKEv2 implementations SHOULD be aware of the maximum UDP
696 message size supported and MAY shorten messages by leaving out some
697 certificates or cryptographic suite proposals if that will keep
698 messages below the maximum. Use of the "Hash and URL" formats rather
699 than including certificates in exchanges where possible can avoid
700 most problems. Implementations and configuration should keep in
701 mind, however, that if the URL lookups are possible only after the
702 IPsec SA is established, recursion issues could prevent this
703 technique from working.
705 2.1. Use of Retransmission Timers
707 All messages in IKE exist in pairs: a request and a response. The
708 setup of an IKE_SA normally consists of two request/response pairs.
709 Once the IKE_SA is set up, either end of the security association may
710 initiate requests at any time, and there can be many requests and
711 responses "in flight" at any given moment. But each message is
712 labeled as either a request or a response, and for each
713 request/response pair one end of the security association is the
714 initiator and the other is the responder.
716 For every pair of IKE messages, the initiator is responsible for
717 retransmission in the event of a timeout. The responder MUST never
718 retransmit a response unless it receives a retransmission of the
719 request. In that event, the responder MUST ignore the retransmitted
720 request except insofar as it triggers a retransmission of the
721 response. The initiator MUST remember each request until it receives
722 the corresponding response. The responder MUST remember each
723 response until it receives a request whose sequence number is larger
724 than the sequence number in the response plus its window size (see
730 Kaufman Standards Track [Page 13]
732 RFC 4306 IKEv2 December 2005
735 IKE is a reliable protocol, in the sense that the initiator MUST
736 retransmit a request until either it receives a corresponding reply
737 OR it deems the IKE security association to have failed and it
738 discards all state associated with the IKE_SA and any CHILD_SAs
739 negotiated using that IKE_SA.
741 2.2. Use of Sequence Numbers for Message ID
743 Every IKE message contains a Message ID as part of its fixed header.
744 This Message ID is used to match up requests and responses, and to
745 identify retransmissions of messages.
747 The Message ID is a 32-bit quantity, which is zero for the first IKE
748 request in each direction. The IKE_SA initial setup messages will
749 always be numbered 0 and 1. Each endpoint in the IKE Security
750 Association maintains two "current" Message IDs: the next one to be
751 used for a request it initiates and the next one it expects to see in
752 a request from the other end. These counters increment as requests
753 are generated and received. Responses always contain the same
754 message ID as the corresponding request. That means that after the
755 initial exchange, each integer n may appear as the message ID in four
756 distinct messages: the nth request from the original IKE initiator,
757 the corresponding response, the nth request from the original IKE
758 responder, and the corresponding response. If the two ends make very
759 different numbers of requests, the Message IDs in the two directions
760 can be very different. There is no ambiguity in the messages,
761 however, because the (I)nitiator and (R)esponse bits in the message
762 header specify which of the four messages a particular one is.
764 Note that Message IDs are cryptographically protected and provide
765 protection against message replays. In the unlikely event that
766 Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be
767 closed. Rekeying an IKE_SA resets the sequence numbers.
769 2.3. Window Size for Overlapping Requests
771 In order to maximize IKE throughput, an IKE endpoint MAY issue
772 multiple requests before getting a response to any of them if the
773 other endpoint has indicated its ability to handle such requests.
774 For simplicity, an IKE implementation MAY choose to process requests
775 strictly in order and/or wait for a response to one request before
776 issuing another. Certain rules must be followed to ensure
777 interoperability between implementations using different strategies.
779 After an IKE_SA is set up, either end can initiate one or more
780 requests. These requests may pass one another over the network. An
781 IKE endpoint MUST be prepared to accept and process a request while
786 Kaufman Standards Track [Page 14]
788 RFC 4306 IKEv2 December 2005
791 it has a request outstanding in order to avoid a deadlock in this
792 situation. An IKE endpoint SHOULD be prepared to accept and process
793 multiple requests while it has a request outstanding.
795 An IKE endpoint MUST wait for a response to each of its messages
796 before sending a subsequent message unless it has received a
797 SET_WINDOW_SIZE Notify message from its peer informing it that the
798 peer is prepared to maintain state for multiple outstanding messages
799 in order to allow greater throughput.
801 An IKE endpoint MUST NOT exceed the peer's stated window size for
802 transmitted IKE requests. In other words, if the responder stated
803 its window size is N, then when the initiator needs to make a request
804 X, it MUST wait until it has received responses to all requests up
805 through request X-N. An IKE endpoint MUST keep a copy of (or be able
806 to regenerate exactly) each request it has sent until it receives the
807 corresponding response. An IKE endpoint MUST keep a copy of (or be
808 able to regenerate exactly) the number of previous responses equal to
809 its declared window size in case its response was lost and the
810 initiator requests its retransmission by retransmitting the request.
812 An IKE endpoint supporting a window size greater than one SHOULD be
813 capable of processing incoming requests out of order to maximize
814 performance in the event of network failures or packet reordering.
816 2.4. State Synchronization and Connection Timeouts
818 An IKE endpoint is allowed to forget all of its state associated with
819 an IKE_SA and the collection of corresponding CHILD_SAs at any time.
820 This is the anticipated behavior in the event of an endpoint crash
821 and restart. It is important when an endpoint either fails or
822 reinitializes its state that the other endpoint detect those
823 conditions and not continue to waste network bandwidth by sending
824 packets over discarded SAs and having them fall into a black hole.
826 Since IKE is designed to operate in spite of Denial of Service (DoS)
827 attacks from the network, an endpoint MUST NOT conclude that the
828 other endpoint has failed based on any routing information (e.g.,
829 ICMP messages) or IKE messages that arrive without cryptographic
830 protection (e.g., Notify messages complaining about unknown SPIs).
831 An endpoint MUST conclude that the other endpoint has failed only
832 when repeated attempts to contact it have gone unanswered for a
833 timeout period or when a cryptographically protected INITIAL_CONTACT
834 notification is received on a different IKE_SA to the same
835 authenticated identity. An endpoint SHOULD suspect that the other
836 endpoint has failed based on routing information and initiate a
837 request to see whether the other endpoint is alive. To check whether
838 the other side is alive, IKE specifies an empty INFORMATIONAL message
842 Kaufman Standards Track [Page 15]
844 RFC 4306 IKEv2 December 2005
847 that (like all IKE requests) requires an acknowledgement (note that
848 within the context of an IKE_SA, an "empty" message consists of an
849 IKE header followed by an Encrypted payload that contains no
850 payloads). If a cryptographically protected message has been
851 received from the other side recently, unprotected notifications MAY
852 be ignored. Implementations MUST limit the rate at which they take
853 actions based on unprotected messages.
855 Numbers of retries and lengths of timeouts are not covered in this
856 specification because they do not affect interoperability. It is
857 suggested that messages be retransmitted at least a dozen times over
858 a period of at least several minutes before giving up on an SA, but
859 different environments may require different rules. To be a good
860 network citizen, retranmission times MUST increase exponentially to
861 avoid flooding the network and making an existing congestion
862 situation worse. If there has only been outgoing traffic on all of
863 the SAs associated with an IKE_SA, it is essential to confirm
864 liveness of the other endpoint to avoid black holes. If no
865 cryptographically protected messages have been received on an IKE_SA
866 or any of its CHILD_SAs recently, the system needs to perform a
867 liveness check in order to prevent sending messages to a dead peer.
868 Receipt of a fresh cryptographically protected message on an IKE_SA
869 or any of its CHILD_SAs ensures liveness of the IKE_SA and all of its
870 CHILD_SAs. Note that this places requirements on the failure modes
871 of an IKE endpoint. An implementation MUST NOT continue sending on
872 any SA if some failure prevents it from receiving on all of the
873 associated SAs. If CHILD_SAs can fail independently from one another
874 without the associated IKE_SA being able to send a delete message,
875 then they MUST be negotiated by separate IKE_SAs.
877 There is a Denial of Service attack on the initiator of an IKE_SA
878 that can be avoided if the initiator takes the proper care. Since
879 the first two messages of an SA setup are not cryptographically
880 protected, an attacker could respond to the initiator's message
881 before the genuine responder and poison the connection setup attempt.
882 To prevent this, the initiator MAY be willing to accept multiple
883 responses to its first message, treat each as potentially legitimate,
884 respond to it, and then discard all the invalid half-open connections
885 when it receives a valid cryptographically protected response to any
886 one of its requests. Once a cryptographically valid response is
887 received, all subsequent responses should be ignored whether or not
888 they are cryptographically valid.
890 Note that with these rules, there is no reason to negotiate and agree
891 upon an SA lifetime. If IKE presumes the partner is dead, based on
892 repeated lack of acknowledgement to an IKE message, then the IKE SA
893 and all CHILD_SAs set up through that IKE_SA are deleted.
898 Kaufman Standards Track [Page 16]
900 RFC 4306 IKEv2 December 2005
903 An IKE endpoint may at any time delete inactive CHILD_SAs to recover
904 resources used to hold their state. If an IKE endpoint chooses to
905 delete CHILD_SAs, it MUST send Delete payloads to the other end
906 notifying it of the deletion. It MAY similarly time out the IKE_SA.
907 Closing the IKE_SA implicitly closes all associated CHILD_SAs. In
908 this case, an IKE endpoint SHOULD send a Delete payload indicating
909 that it has closed the IKE_SA.
911 2.5. Version Numbers and Forward Compatibility
913 This document describes version 2.0 of IKE, meaning the major version
914 number is 2 and the minor version number is zero. It is likely that
915 some implementations will want to support both version 1.0 and
916 version 2.0, and in the future, other versions.
918 The major version number should be incremented only if the packet
919 formats or required actions have changed so dramatically that an
920 older version node would not be able to interoperate with a newer
921 version node if it simply ignored the fields it did not understand
922 and took the actions specified in the older specification. The minor
923 version number indicates new capabilities, and MUST be ignored by a
924 node with a smaller minor version number, but used for informational
925 purposes by the node with the larger minor version number. For
926 example, it might indicate the ability to process a newly defined
927 notification message. The node with the larger minor version number
928 would simply note that its correspondent would not be able to
929 understand that message and therefore would not send it.
931 If an endpoint receives a message with a higher major version number,
932 it MUST drop the message and SHOULD send an unauthenticated
933 notification message containing the highest version number it
934 supports. If an endpoint supports major version n, and major version
935 m, it MUST support all versions between n and m. If it receives a
936 message with a major version that it supports, it MUST respond with
937 that version number. In order to prevent two nodes from being
938 tricked into corresponding with a lower major version number than the
939 maximum that they both support, IKE has a flag that indicates that
940 the node is capable of speaking a higher major version number.
942 Thus, the major version number in the IKE header indicates the
943 version number of the message, not the highest version number that
944 the transmitter supports. If the initiator is capable of speaking
945 versions n, n+1, and n+2, and the responder is capable of speaking
946 versions n and n+1, then they will negotiate speaking n+1, where the
947 initiator will set the flag indicating its ability to speak a higher
948 version. If they mistakenly (perhaps through an active attacker
954 Kaufman Standards Track [Page 17]
956 RFC 4306 IKEv2 December 2005
959 sending error messages) negotiate to version n, then both will notice
960 that the other side can support a higher version number, and they
961 MUST break the connection and reconnect using version n+1.
963 Note that IKEv1 does not follow these rules, because there is no way
964 in v1 of noting that you are capable of speaking a higher version
965 number. So an active attacker can trick two v2-capable nodes into
966 speaking v1. When a v2-capable node negotiates down to v1, it SHOULD
967 note that fact in its logs.
969 Also for forward compatibility, all fields marked RESERVED MUST be
970 set to zero by a version 2.0 implementation and their content MUST be
971 ignored by a version 2.0 implementation ("Be conservative in what you
972 send and liberal in what you receive"). In this way, future versions
973 of the protocol can use those fields in a way that is guaranteed to
974 be ignored by implementations that do not understand them.
975 Similarly, payload types that are not defined are reserved for future
976 use; implementations of version 2.0 MUST skip over those payloads and
977 ignore their contents.
979 IKEv2 adds a "critical" flag to each payload header for further
980 flexibility for forward compatibility. If the critical flag is set
981 and the payload type is unrecognized, the message MUST be rejected
982 and the response to the IKE request containing that payload MUST
983 include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an
984 unsupported critical payload was included. If the critical flag is
985 not set and the payload type is unsupported, that payload MUST be
988 Although new payload types may be added in the future and may appear
989 interleaved with the fields defined in this specification,
990 implementations MUST send the payloads defined in this specification
991 in the order shown in the figures in section 2 and implementations
992 SHOULD reject as invalid a message with those payloads in any other
997 The term "cookies" originates with Karn and Simpson [RFC2522] in
998 Photuris, an early proposal for key management with IPsec, and it has
999 persisted. The Internet Security Association and Key Management
1000 Protocol (ISAKMP) [MSST98] fixed message header includes two eight-
1001 octet fields titled "cookies", and that syntax is used by both IKEv1
1002 and IKEv2 though in IKEv2 they are referred to as the IKE SPI and
1003 there is a new separate field in a Notify payload holding the cookie.
1004 The initial two eight-octet fields in the header are used as a
1005 connection identifier at the beginning of IKE packets. Each endpoint
1010 Kaufman Standards Track [Page 18]
1012 RFC 4306 IKEv2 December 2005
1015 chooses one of the two SPIs and SHOULD choose them so as to be unique
1016 identifiers of an IKE_SA. An SPI value of zero is special and
1017 indicates that the remote SPI value is not yet known by the sender.
1019 Unlike ESP and AH where only the recipient's SPI appears in the
1020 header of a message, in IKE the sender's SPI is also sent in every
1021 message. Since the SPI chosen by the original initiator of the
1022 IKE_SA is always sent first, an endpoint with multiple IKE_SAs open
1023 that wants to find the appropriate IKE_SA using the SPI it assigned
1024 must look at the I(nitiator) Flag bit in the header to determine
1025 whether it assigned the first or the second eight octets.
1027 In the first message of an initial IKE exchange, the initiator will
1028 not know the responder's SPI value and will therefore set that field
1031 An expected attack against IKE is state and CPU exhaustion, where the
1032 target is flooded with session initiation requests from forged IP
1033 addresses. This attack can be made less effective if an
1034 implementation of a responder uses minimal CPU and commits no state
1035 to an SA until it knows the initiator can receive packets at the
1036 address from which it claims to be sending them. To accomplish this,
1037 a responder SHOULD -- when it detects a large number of half-open
1038 IKE_SAs -- reject initial IKE messages unless they contain a Notify
1039 payload of type COOKIE. It SHOULD instead send an unprotected IKE
1040 message as a response and include COOKIE Notify payload with the
1041 cookie data to be returned. Initiators who receive such responses
1042 MUST retry the IKE_SA_INIT with a Notify payload of type COOKIE
1043 containing the responder supplied cookie data as the first payload
1044 and all other payloads unchanged. The initial exchange will then be
1048 ----------- -----------
1049 HDR(A,0), SAi1, KEi, Ni -->
1051 <-- HDR(A,0), N(COOKIE)
1053 HDR(A,0), N(COOKIE), SAi1, KEi, Ni -->
1055 <-- HDR(A,B), SAr1, KEr, Nr, [CERTREQ]
1057 HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,]
1058 AUTH, SAi2, TSi, TSr} -->
1060 <-- HDR(A,B), SK {IDr, [CERT,] AUTH,
1066 Kaufman Standards Track [Page 19]
1068 RFC 4306 IKEv2 December 2005
1071 The first two messages do not affect any initiator or responder state
1072 except for communicating the cookie. In particular, the message
1073 sequence numbers in the first four messages will all be zero and the
1074 message sequence numbers in the last two messages will be one. 'A' is
1075 the SPI assigned by the initiator, while 'B' is the SPI assigned by
1078 An IKE implementation SHOULD implement its responder cookie
1079 generation in such a way as to not require any saved state to
1080 recognize its valid cookie when the second IKE_SA_INIT message
1081 arrives. The exact algorithms and syntax they use to generate
1082 cookies do not affect interoperability and hence are not specified
1083 here. The following is an example of how an endpoint could use
1084 cookies to implement limited DOS protection.
1086 A good way to do this is to set the responder cookie to be:
1088 Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)
1090 where <secret> is a randomly generated secret known only to the
1091 responder and periodically changed and | indicates concatenation.
1092 <VersionIDofSecret> should be changed whenever <secret> is
1093 regenerated. The cookie can be recomputed when the IKE_SA_INIT
1094 arrives the second time and compared to the cookie in the received
1095 message. If it matches, the responder knows that the cookie was
1096 generated since the last change to <secret> and that IPi must be the
1097 same as the source address it saw the first time. Incorporating SPIi
1098 into the calculation ensures that if multiple IKE_SAs are being set
1099 up in parallel they will all get different cookies (assuming the
1100 initiator chooses unique SPIi's). Incorporating Ni into the hash
1101 ensures that an attacker who sees only message 2 can't successfully
1104 If a new value for <secret> is chosen while there are connections in
1105 the process of being initialized, an IKE_SA_INIT might be returned
1106 with other than the current <VersionIDofSecret>. The responder in
1107 that case MAY reject the message by sending another response with a
1108 new cookie or it MAY keep the old value of <secret> around for a
1109 short time and accept cookies computed from either one. The
1110 responder SHOULD NOT accept cookies indefinitely after <secret> is
1111 changed, since that would defeat part of the denial of service
1112 protection. The responder SHOULD change the value of <secret>
1113 frequently, especially if under attack.
1122 Kaufman Standards Track [Page 20]
1124 RFC 4306 IKEv2 December 2005
1127 2.7. Cryptographic Algorithm Negotiation
1129 The payload type known as "SA" indicates a proposal for a set of
1130 choices of IPsec protocols (IKE, ESP, and/or AH) for the SA as well
1131 as cryptographic algorithms associated with each protocol.
1133 An SA payload consists of one or more proposals. Each proposal
1134 includes one or more protocols (usually one). Each protocol contains
1135 one or more transforms -- each specifying a cryptographic algorithm.
1136 Each transform contains zero or more attributes (attributes are
1137 needed only if the transform identifier does not completely specify
1138 the cryptographic algorithm).
1140 This hierarchical structure was designed to efficiently encode
1141 proposals for cryptographic suites when the number of supported
1142 suites is large because multiple values are acceptable for multiple
1143 transforms. The responder MUST choose a single suite, which MAY be
1144 any subset of the SA proposal following the rules below:
1146 Each proposal contains one or more protocols. If a proposal is
1147 accepted, the SA response MUST contain the same protocols in the
1148 same order as the proposal. The responder MUST accept a single
1149 proposal or reject them all and return an error. (Example: if a
1150 single proposal contains ESP and AH and that proposal is accepted,
1151 both ESP and AH MUST be accepted. If ESP and AH are included in
1152 separate proposals, the responder MUST accept only one of them).
1154 Each IPsec protocol proposal contains one or more transforms.
1155 Each transform contains a transform type. The accepted
1156 cryptographic suite MUST contain exactly one transform of each
1157 type included in the proposal. For example: if an ESP proposal
1158 includes transforms ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES
1159 w/keysize 256, AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted
1160 suite MUST contain one of the ENCR_ transforms and one of the
1161 AUTH_ transforms. Thus, six combinations are acceptable.
1163 Since the initiator sends its Diffie-Hellman value in the
1164 IKE_SA_INIT, it must guess the Diffie-Hellman group that the
1165 responder will select from its list of supported groups. If the
1166 initiator guesses wrong, the responder will respond with a Notify
1167 payload of type INVALID_KE_PAYLOAD indicating the selected group. In
1168 this case, the initiator MUST retry the IKE_SA_INIT with the
1169 corrected Diffie-Hellman group. The initiator MUST again propose its
1170 full set of acceptable cryptographic suites because the rejection
1171 message was unauthenticated and otherwise an active attacker could
1172 trick the endpoints into negotiating a weaker suite than a stronger
1173 one that they both prefer.
1178 Kaufman Standards Track [Page 21]
1180 RFC 4306 IKEv2 December 2005
1185 IKE, ESP, and AH security associations use secret keys that SHOULD be
1186 used only for a limited amount of time and to protect a limited
1187 amount of data. This limits the lifetime of the entire security
1188 association. When the lifetime of a security association expires,
1189 the security association MUST NOT be used. If there is demand, new
1190 security associations MAY be established. Reestablishment of
1191 security associations to take the place of ones that expire is
1192 referred to as "rekeying".
1194 To allow for minimal IPsec implementations, the ability to rekey SAs
1195 without restarting the entire IKE_SA is optional. An implementation
1196 MAY refuse all CREATE_CHILD_SA requests within an IKE_SA. If an SA
1197 has expired or is about to expire and rekeying attempts using the
1198 mechanisms described here fail, an implementation MUST close the
1199 IKE_SA and any associated CHILD_SAs and then MAY start new ones.
1200 Implementations SHOULD support in-place rekeying of SAs, since doing
1201 so offers better performance and is likely to reduce the number of
1202 packets lost during the transition.
1204 To rekey a CHILD_SA within an existing IKE_SA, create a new,
1205 equivalent SA (see section 2.17 below), and when the new one is
1206 established, delete the old one. To rekey an IKE_SA, establish a new
1207 equivalent IKE_SA (see section 2.18 below) with the peer to whom the
1208 old IKE_SA is shared using a CREATE_CHILD_SA within the existing
1209 IKE_SA. An IKE_SA so created inherits all of the original IKE_SA's
1210 CHILD_SAs. Use the new IKE_SA for all control messages needed to
1211 maintain the CHILD_SAs created by the old IKE_SA, and delete the old
1212 IKE_SA. The Delete payload to delete itself MUST be the last request
1213 sent over an IKE_SA.
1215 SAs SHOULD be rekeyed proactively, i.e., the new SA should be
1216 established before the old one expires and becomes unusable. Enough
1217 time should elapse between the time the new SA is established and the
1218 old one becomes unusable so that traffic can be switched over to the
1221 A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes
1222 were negotiated. In IKEv2, each end of the SA is responsible for
1223 enforcing its own lifetime policy on the SA and rekeying the SA when
1224 necessary. If the two ends have different lifetime policies, the end
1225 with the shorter lifetime will end up always being the one to request
1226 the rekeying. If an SA bundle has been inactive for a long time and
1227 if an endpoint would not initiate the SA in the absence of traffic,
1228 the endpoint MAY choose to close the SA instead of rekeying it when
1229 its lifetime expires. It SHOULD do so if there has been no traffic
1230 since the last time the SA was rekeyed.
1234 Kaufman Standards Track [Page 22]
1236 RFC 4306 IKEv2 December 2005
1239 If the two ends have the same lifetime policies, it is possible that
1240 both will initiate a rekeying at the same time (which will result in
1241 redundant SAs). To reduce the probability of this happening, the
1242 timing of rekeying requests SHOULD be jittered (delayed by a random
1243 amount of time after the need for rekeying is noticed).
1245 This form of rekeying may temporarily result in multiple similar SAs
1246 between the same pairs of nodes. When there are two SAs eligible to
1247 receive packets, a node MUST accept incoming packets through either
1248 SA. If redundant SAs are created though such a collision, the SA
1249 created with the lowest of the four nonces used in the two exchanges
1250 SHOULD be closed by the endpoint that created it.
1252 Note that IKEv2 deliberately allows parallel SAs with the same
1253 traffic selectors between common endpoints. One of the purposes of
1254 this is to support traffic quality of service (QoS) differences among
1255 the SAs (see [RFC2474], [RFC2475], and section 4.1 of [RFC2983]).
1256 Hence unlike IKEv1, the combination of the endpoints and the traffic
1257 selectors may not uniquely identify an SA between those endpoints, so
1258 the IKEv1 rekeying heuristic of deleting SAs on the basis of
1259 duplicate traffic selectors SHOULD NOT be used.
1261 The node that initiated the surviving rekeyed SA SHOULD delete the
1262 replaced SA after the new one is established.
1264 There are timing windows -- particularly in the presence of lost
1265 packets -- where endpoints may not agree on the state of an SA. The
1266 responder to a CREATE_CHILD_SA MUST be prepared to accept messages on
1267 an SA before sending its response to the creation request, so there
1268 is no ambiguity for the initiator. The initiator MAY begin sending
1269 on an SA as soon as it processes the response. The initiator,
1270 however, cannot receive on a newly created SA until it receives and
1271 processes the response to its CREATE_CHILD_SA request. How, then, is
1272 the responder to know when it is OK to send on the newly created SA?
1274 From a technical correctness and interoperability perspective, the
1275 responder MAY begin sending on an SA as soon as it sends its response
1276 to the CREATE_CHILD_SA request. In some situations, however, this
1277 could result in packets unnecessarily being dropped, so an
1278 implementation MAY want to defer such sending.
1280 The responder can be assured that the initiator is prepared to
1281 receive messages on an SA if either (1) it has received a
1282 cryptographically valid message on the new SA, or (2) the new SA
1283 rekeys an existing SA and it receives an IKE request to close the
1284 replaced SA. When rekeying an SA, the responder SHOULD continue to
1285 send messages on the old SA until one of those events occurs. When
1286 establishing a new SA, the responder MAY defer sending messages on a
1290 Kaufman Standards Track [Page 23]
1292 RFC 4306 IKEv2 December 2005
1295 new SA until either it receives one or a timeout has occurred. If an
1296 initiator receives a message on an SA for which it has not received a
1297 response to its CREATE_CHILD_SA request, it SHOULD interpret that as
1298 a likely packet loss and retransmit the CREATE_CHILD_SA request. An
1299 initiator MAY send a dummy message on a newly created SA if it has no
1300 messages queued in order to assure the responder that the initiator
1301 is ready to receive messages.
1303 2.9. Traffic Selector Negotiation
1305 When an IP packet is received by an RFC4301-compliant IPsec subsystem
1306 and matches a "protect" selector in its Security Policy Database
1307 (SPD), the subsystem MUST protect that packet with IPsec. When no SA
1308 exists yet, it is the task of IKE to create it. Maintenance of a
1309 system's SPD is outside the scope of IKE (see [PFKEY] for an example
1310 protocol), though some implementations might update their SPD in
1311 connection with the running of IKE (for an example scenario, see
1314 Traffic Selector (TS) payloads allow endpoints to communicate some of
1315 the information from their SPD to their peers. TS payloads specify
1316 the selection criteria for packets that will be forwarded over the
1317 newly set up SA. This can serve as a consistency check in some
1318 scenarios to assure that the SPDs are consistent. In others, it
1319 guides the dynamic update of the SPD.
1321 Two TS payloads appear in each of the messages in the exchange that
1322 creates a CHILD_SA pair. Each TS payload contains one or more
1323 Traffic Selectors. Each Traffic Selector consists of an address
1324 range (IPv4 or IPv6), a port range, and an IP protocol ID. In
1325 support of the scenario described in section 1.1.3, an initiator may
1326 request that the responder assign an IP address and tell the
1327 initiator what it is.
1329 IKEv2 allows the responder to choose a subset of the traffic proposed
1330 by the initiator. This could happen when the configurations of the
1331 two endpoints are being updated but only one end has received the new
1332 information. Since the two endpoints may be configured by different
1333 people, the incompatibility may persist for an extended period even
1334 in the absence of errors. It also allows for intentionally different
1335 configurations, as when one end is configured to tunnel all addresses
1336 and depends on the other end to have the up-to-date list.
1338 The first of the two TS payloads is known as TSi (Traffic Selector-
1339 initiator). The second is known as TSr (Traffic Selector-responder).
1340 TSi specifies the source address of traffic forwarded from (or the
1341 destination address of traffic forwarded to) the initiator of the
1342 CHILD_SA pair. TSr specifies the destination address of the traffic
1346 Kaufman Standards Track [Page 24]
1348 RFC 4306 IKEv2 December 2005
1351 forwarded to (or the source address of the traffic forwarded from)
1352 the responder of the CHILD_SA pair. For example, if the original
1353 initiator request the creation of a CHILD_SA pair, and wishes to
1354 tunnel all traffic from subnet 192.0.1.* on the initiator's side to
1355 subnet 192.0.2.* on the responder's side, the initiator would include
1356 a single traffic selector in each TS payload. TSi would specify the
1357 address range (192.0.1.0 - 192.0.1.255) and TSr would specify the
1358 address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was
1359 acceptable to the responder, it would send identical TS payloads
1360 back. (Note: The IP address range 192.0.2.* has been reserved for
1361 use in examples in RFCs and similar documents. This document needed
1362 two such ranges, and so also used 192.0.1.*. This should not be
1363 confused with any actual address.)
1365 The responder is allowed to narrow the choices by selecting a subset
1366 of the traffic, for instance by eliminating or narrowing the range of
1367 one or more members of the set of traffic selectors, provided the set
1368 does not become the NULL set.
1370 It is possible for the responder's policy to contain multiple smaller
1371 ranges, all encompassed by the initiator's traffic selector, and with
1372 the responder's policy being that each of those ranges should be sent
1373 over a different SA. Continuing the example above, the responder
1374 might have a policy of being willing to tunnel those addresses to and
1375 from the initiator, but might require that each address pair be on a
1376 separately negotiated CHILD_SA. If the initiator generated its
1377 request in response to an incoming packet from 192.0.1.43 to
1378 192.0.2.123, there would be no way for the responder to determine
1379 which pair of addresses should be included in this tunnel, and it
1380 would have to make a guess or reject the request with a status of
1381 SINGLE_PAIR_REQUIRED.
1383 To enable the responder to choose the appropriate range in this case,
1384 if the initiator has requested the SA due to a data packet, the
1385 initiator SHOULD include as the first traffic selector in each of TSi
1386 and TSr a very specific traffic selector including the addresses in
1387 the packet triggering the request. In the example, the initiator
1388 would include in TSi two traffic selectors: the first containing the
1389 address range (192.0.1.43 - 192.0.1.43) and the source port and IP
1390 protocol from the packet and the second containing (192.0.1.0 -
1391 192.0.1.255) with all ports and IP protocols. The initiator would
1392 similarly include two traffic selectors in TSr.
1394 If the responder's policy does not allow it to accept the entire set
1395 of traffic selectors in the initiator's request, but does allow him
1396 to accept the first selector of TSi and TSr, then the responder MUST
1397 narrow the traffic selectors to a subset that includes the
1402 Kaufman Standards Track [Page 25]
1404 RFC 4306 IKEv2 December 2005
1407 initiator's first choices. In this example, the responder might
1408 respond with TSi being (192.0.1.43 - 192.0.1.43) with all ports and
1411 If the initiator creates the CHILD_SA pair not in response to an
1412 arriving packet, but rather, say, upon startup, then there may be no
1413 specific addresses the initiator prefers for the initial tunnel over
1414 any other. In that case, the first values in TSi and TSr MAY be
1415 ranges rather than specific values, and the responder chooses a
1416 subset of the initiator's TSi and TSr that are acceptable. If more
1417 than one subset is acceptable but their union is not, the responder
1418 MUST accept some subset and MAY include a Notify payload of type
1419 ADDITIONAL_TS_POSSIBLE to indicate that the initiator might want to
1420 try again. This case will occur only when the initiator and
1421 responder are configured differently from one another. If the
1422 initiator and responder agree on the granularity of tunnels, the
1423 initiator will never request a tunnel wider than the responder will
1424 accept. Such misconfigurations SHOULD be recorded in error logs.
1428 The IKE_SA_INIT messages each contain a nonce. These nonces are used
1429 as inputs to cryptographic functions. The CREATE_CHILD_SA request
1430 and the CREATE_CHILD_SA response also contain nonces. These nonces
1431 are used to add freshness to the key derivation technique used to
1432 obtain keys for CHILD_SA, and to ensure creation of strong pseudo-
1433 random bits from the Diffie-Hellman key. Nonces used in IKEv2 MUST
1434 be randomly chosen, MUST be at least 128 bits in size, and MUST be at
1435 least half the key size of the negotiated prf. ("prf" refers to
1436 "pseudo-random function", one of the cryptographic algorithms
1437 negotiated in the IKE exchange.) If the same random number source is
1438 used for both keys and nonces, care must be taken to ensure that the
1439 latter use does not compromise the former.
1441 2.11. Address and Port Agility
1443 IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and
1444 AH associations for the same IP addresses it runs over. The IP
1445 addresses and ports in the outer header are, however, not themselves
1446 cryptographically protected, and IKE is designed to work even through
1447 Network Address Translation (NAT) boxes. An implementation MUST
1448 accept incoming requests even if the source port is not 500 or 4500,
1449 and MUST respond to the address and port from which the request was
1450 received. It MUST specify the address and port at which the request
1451 was received as the source address and port in the response. IKE
1452 functions identically over IPv4 or IPv6.
1458 Kaufman Standards Track [Page 26]
1460 RFC 4306 IKEv2 December 2005
1463 2.12. Reuse of Diffie-Hellman Exponentials
1465 IKE generates keying material using an ephemeral Diffie-Hellman
1466 exchange in order to gain the property of "perfect forward secrecy".
1467 This means that once a connection is closed and its corresponding
1468 keys are forgotten, even someone who has recorded all of the data
1469 from the connection and gets access to all of the long-term keys of
1470 the two endpoints cannot reconstruct the keys used to protect the
1471 conversation without doing a brute force search of the session key
1474 Achieving perfect forward secrecy requires that when a connection is
1475 closed, each endpoint MUST forget not only the keys used by the
1476 connection but also any information that could be used to recompute
1477 those keys. In particular, it MUST forget the secrets used in the
1478 Diffie-Hellman calculation and any state that may persist in the
1479 state of a pseudo-random number generator that could be used to
1480 recompute the Diffie-Hellman secrets.
1482 Since the computing of Diffie-Hellman exponentials is computationally
1483 expensive, an endpoint may find it advantageous to reuse those
1484 exponentials for multiple connection setups. There are several
1485 reasonable strategies for doing this. An endpoint could choose a new
1486 exponential only periodically though this could result in less-than-
1487 perfect forward secrecy if some connection lasts for less than the
1488 lifetime of the exponential. Or it could keep track of which
1489 exponential was used for each connection and delete the information
1490 associated with the exponential only when some corresponding
1491 connection was closed. This would allow the exponential to be reused
1492 without losing perfect forward secrecy at the cost of maintaining
1495 Decisions as to whether and when to reuse Diffie-Hellman exponentials
1496 is a private decision in the sense that it will not affect
1497 interoperability. An implementation that reuses exponentials MAY
1498 choose to remember the exponential used by the other endpoint on past
1499 exchanges and if one is reused to avoid the second half of the
1502 2.13. Generating Keying Material
1504 In the context of the IKE_SA, four cryptographic algorithms are
1505 negotiated: an encryption algorithm, an integrity protection
1506 algorithm, a Diffie-Hellman group, and a pseudo-random function
1507 (prf). The pseudo-random function is used for the construction of
1508 keying material for all of the cryptographic algorithms used in both
1509 the IKE_SA and the CHILD_SAs.
1514 Kaufman Standards Track [Page 27]
1516 RFC 4306 IKEv2 December 2005
1519 We assume that each encryption algorithm and integrity protection
1520 algorithm uses a fixed-size key and that any randomly chosen value of
1521 that fixed size can serve as an appropriate key. For algorithms that
1522 accept a variable length key, a fixed key size MUST be specified as
1523 part of the cryptographic transform negotiated. For algorithms for
1524 which not all values are valid keys (such as DES or 3DES with key
1525 parity), the algorithm by which keys are derived from arbitrary
1526 values MUST be specified by the cryptographic transform. For
1527 integrity protection functions based on Hashed Message Authentication
1528 Code (HMAC), the fixed key size is the size of the output of the
1529 underlying hash function. When the prf function takes a variable
1530 length key, variable length data, and produces a fixed-length output
1531 (e.g., when using HMAC), the formulas in this document apply. When
1532 the key for the prf function has fixed length, the data provided as a
1533 key is truncated or padded with zeros as necessary unless exceptional
1534 processing is explained following the formula.
1536 Keying material will always be derived as the output of the
1537 negotiated prf algorithm. Since the amount of keying material needed
1538 may be greater than the size of the output of the prf algorithm, we
1539 will use the prf iteratively. We will use the terminology prf+ to
1540 describe the function that outputs a pseudo-random stream based on
1541 the inputs to a prf as follows: (where | indicates concatenation)
1543 prf+ (K,S) = T1 | T2 | T3 | T4 | ...
1546 T1 = prf (K, S | 0x01)
1547 T2 = prf (K, T1 | S | 0x02)
1548 T3 = prf (K, T2 | S | 0x03)
1549 T4 = prf (K, T3 | S | 0x04)
1551 continuing as needed to compute all required keys. The keys are
1552 taken from the output string without regard to boundaries (e.g., if
1553 the required keys are a 256-bit Advanced Encryption Standard (AES)
1554 key and a 160-bit HMAC key, and the prf function generates 160 bits,
1555 the AES key will come from T1 and the beginning of T2, while the HMAC
1556 key will come from the rest of T2 and the beginning of T3).
1558 The constant concatenated to the end of each string feeding the prf
1559 is a single octet. prf+ in this document is not defined beyond 255
1560 times the size of the prf output.
1562 2.14. Generating Keying Material for the IKE_SA
1564 The shared keys are computed as follows. A quantity called SKEYSEED
1565 is calculated from the nonces exchanged during the IKE_SA_INIT
1566 exchange and the Diffie-Hellman shared secret established during that
1570 Kaufman Standards Track [Page 28]
1572 RFC 4306 IKEv2 December 2005
1575 exchange. SKEYSEED is used to calculate seven other secrets: SK_d
1576 used for deriving new keys for the CHILD_SAs established with this
1577 IKE_SA; SK_ai and SK_ar used as a key to the integrity protection
1578 algorithm for authenticating the component messages of subsequent
1579 exchanges; SK_ei and SK_er used for encrypting (and of course
1580 decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are
1581 used when generating an AUTH payload.
1583 SKEYSEED and its derivatives are computed as follows:
1585 SKEYSEED = prf(Ni | Nr, g^ir)
1587 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } = prf+
1588 (SKEYSEED, Ni | Nr | SPIi | SPIr )
1590 (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er,
1591 SK_pi, and SK_pr are taken in order from the generated bits of the
1592 prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman
1593 exchange. g^ir is represented as a string of octets in big endian
1594 order padded with zeros if necessary to make it the length of the
1595 modulus. Ni and Nr are the nonces, stripped of any headers. If the
1596 negotiated prf takes a fixed-length key and the lengths of Ni and Nr
1597 do not add up to that length, half the bits must come from Ni and
1598 half from Nr, taking the first bits of each.
1600 The two directions of traffic flow use different keys. The keys used
1601 to protect messages from the original initiator are SK_ai and SK_ei.
1602 The keys used to protect messages in the other direction are SK_ar
1603 and SK_er. Each algorithm takes a fixed number of bits of keying
1604 material, which is specified as part of the algorithm. For integrity
1605 algorithms based on a keyed hash, the key size is always equal to the
1606 length of the output of the underlying hash function.
1608 2.15. Authentication of the IKE_SA
1610 When not using extensible authentication (see section 2.16), the
1611 peers are authenticated by having each sign (or MAC using a shared
1612 secret as the key) a block of data. For the responder, the octets to
1613 be signed start with the first octet of the first SPI in the header
1614 of the second message and end with the last octet of the last payload
1615 in the second message. Appended to this (for purposes of computing
1616 the signature) are the initiator's nonce Ni (just the value, not the
1617 payload containing it), and the value prf(SK_pr,IDr') where IDr' is
1618 the responder's ID payload excluding the fixed header. Note that
1619 neither the nonce Ni nor the value prf(SK_pr,IDr') are transmitted.
1620 Similarly, the initiator signs the first message, starting with the
1621 first octet of the first SPI in the header and ending with the last
1622 octet of the last payload. Appended to this (for purposes of
1626 Kaufman Standards Track [Page 29]
1628 RFC 4306 IKEv2 December 2005
1631 computing the signature) are the responder's nonce Nr, and the value
1632 prf(SK_pi,IDi'). In the above calculation, IDi' and IDr' are the
1633 entire ID payloads excluding the fixed header. It is critical to the
1634 security of the exchange that each side sign the other side's nonce.
1636 Note that all of the payloads are included under the signature,
1637 including any payload types not defined in this document. If the
1638 first message of the exchange is sent twice (the second time with a
1639 responder cookie and/or a different Diffie-Hellman group), it is the
1640 second version of the message that is signed.
1642 Optionally, messages 3 and 4 MAY include a certificate, or
1643 certificate chain providing evidence that the key used to compute a
1644 digital signature belongs to the name in the ID payload. The
1645 signature or MAC will be computed using algorithms dictated by the
1646 type of key used by the signer, and specified by the Auth Method
1647 field in the Authentication payload. There is no requirement that
1648 the initiator and responder sign with the same cryptographic
1649 algorithms. The choice of cryptographic algorithms depends on the
1650 type of key each has. In particular, the initiator may be using a
1651 shared key while the responder may have a public signature key and
1652 certificate. It will commonly be the case (but it is not required)
1653 that if a shared secret is used for authentication that the same key
1654 is used in both directions. Note that it is a common but typically
1655 insecure practice to have a shared key derived solely from a user-
1656 chosen password without incorporating another source of randomness.
1658 This is typically insecure because user-chosen passwords are unlikely
1659 to have sufficient unpredictability to resist dictionary attacks and
1660 these attacks are not prevented in this authentication method.
1661 (Applications using password-based authentication for bootstrapping
1662 and IKE_SA should use the authentication method in section 2.16,
1663 which is designed to prevent off-line dictionary attacks.) The pre-
1664 shared key SHOULD contain as much unpredictability as the strongest
1665 key being negotiated. In the case of a pre-shared key, the AUTH
1666 value is computed as:
1668 AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), <msg octets>)
1670 where the string "Key Pad for IKEv2" is 17 ASCII characters without
1671 null termination. The shared secret can be variable length. The pad
1672 string is added so that if the shared secret is derived from a
1673 password, the IKE implementation need not store the password in
1674 cleartext, but rather can store the value prf(Shared Secret,"Key Pad
1675 for IKEv2"), which could not be used as a password equivalent for
1676 protocols other than IKEv2. As noted above, deriving the shared
1677 secret from a password is not secure. This construction is used
1678 because it is anticipated that people will do it anyway. The
1682 Kaufman Standards Track [Page 30]
1684 RFC 4306 IKEv2 December 2005
1687 management interface by which the Shared Secret is provided MUST
1688 accept ASCII strings of at least 64 octets and MUST NOT add a null
1689 terminator before using them as shared secrets. It MUST also accept
1690 a HEX encoding of the Shared Secret. The management interface MAY
1691 accept other encodings if the algorithm for translating the encoding
1692 to a binary string is specified. If the negotiated prf takes a
1693 fixed-size key, the shared secret MUST be of that fixed size.
1695 2.16. Extensible Authentication Protocol Methods
1697 In addition to authentication using public key signatures and shared
1698 secrets, IKE supports authentication using methods defined in RFC
1699 3748 [EAP]. Typically, these methods are asymmetric (designed for a
1700 user authenticating to a server), and they may not be mutual. For
1701 this reason, these protocols are typically used to authenticate the
1702 initiator to the responder and MUST be used in conjunction with a
1703 public key signature based authentication of the responder to the
1704 initiator. These methods are often associated with mechanisms
1705 referred to as "Legacy Authentication" mechanisms.
1707 While this memo references [EAP] with the intent that new methods can
1708 be added in the future without updating this specification, some
1709 simpler variations are documented here and in section 3.16. [EAP]
1710 defines an authentication protocol requiring a variable number of
1711 messages. Extensible Authentication is implemented in IKE as
1712 additional IKE_AUTH exchanges that MUST be completed in order to
1713 initialize the IKE_SA.
1715 An initiator indicates a desire to use extensible authentication by
1716 leaving out the AUTH payload from message 3. By including an IDi
1717 payload but not an AUTH payload, the initiator has declared an
1718 identity but has not proven it. If the responder is willing to use
1719 an extensible authentication method, it will place an Extensible
1720 Authentication Protocol (EAP) payload in message 4 and defer sending
1721 SAr2, TSi, and TSr until initiator authentication is complete in a
1722 subsequent IKE_AUTH exchange. In the case of a minimal extensible
1723 authentication, the initial SA establishment will appear as follows:
1738 Kaufman Standards Track [Page 31]
1740 RFC 4306 IKEv2 December 2005
1744 ----------- -----------
1745 HDR, SAi1, KEi, Ni -->
1747 <-- HDR, SAr1, KEr, Nr, [CERTREQ]
1749 HDR, SK {IDi, [CERTREQ,] [IDr,]
1752 <-- HDR, SK {IDr, [CERT,] AUTH,
1757 <-- HDR, SK {EAP (success)}
1761 <-- HDR, SK {AUTH, SAr2, TSi, TSr }
1763 For EAP methods that create a shared key as a side effect of
1764 authentication, that shared key MUST be used by both the initiator
1765 and responder to generate AUTH payloads in messages 7 and 8 using the
1766 syntax for shared secrets specified in section 2.15. The shared key
1767 from EAP is the field from the EAP specification named MSK. The
1768 shared key generated during an IKE exchange MUST NOT be used for any
1771 EAP methods that do not establish a shared key SHOULD NOT be used, as
1772 they are subject to a number of man-in-the-middle attacks [EAPMITM]
1773 if these EAP methods are used in other protocols that do not use a
1774 server-authenticated tunnel. Please see the Security Considerations
1775 section for more details. If EAP methods that do not generate a
1776 shared key are used, the AUTH payloads in messages 7 and 8 MUST be
1777 generated using SK_pi and SK_pr, respectively.
1779 The initiator of an IKE_SA using EAP SHOULD be capable of extending
1780 the initial protocol exchange to at least ten IKE_AUTH exchanges in
1781 the event the responder sends notification messages and/or retries
1782 the authentication prompt. Once the protocol exchange defined by the
1783 chosen EAP authentication method has successfully terminated, the
1784 responder MUST send an EAP payload containing the Success message.
1785 Similarly, if the authentication method has failed, the responder
1786 MUST send an EAP payload containing the Failure message. The
1787 responder MAY at any time terminate the IKE exchange by sending an
1788 EAP payload containing the Failure message.
1794 Kaufman Standards Track [Page 32]
1796 RFC 4306 IKEv2 December 2005
1799 Following such an extended exchange, the EAP AUTH payloads MUST be
1800 included in the two messages following the one containing the EAP
1803 2.17. Generating Keying Material for CHILD_SAs
1805 A single CHILD_SA is created by the IKE_AUTH exchange, and additional
1806 CHILD_SAs can optionally be created in CREATE_CHILD_SA exchanges.
1807 Keying material for them is generated as follows:
1809 KEYMAT = prf+(SK_d, Ni | Nr)
1811 Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this
1812 request is the first CHILD_SA created or the fresh Ni and Nr from the
1813 CREATE_CHILD_SA exchange if this is a subsequent creation.
1815 For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman
1816 exchange, the keying material is defined as:
1818 KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr )
1820 where g^ir (new) is the shared secret from the ephemeral Diffie-
1821 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an
1822 octet string in big endian order padded with zeros in the high-order
1823 bits if necessary to make it the length of the modulus).
1825 A single CHILD_SA negotiation may result in multiple security
1826 associations. ESP and AH SAs exist in pairs (one in each direction),
1827 and four SAs could be created in a single CHILD_SA negotiation if a
1828 combination of ESP and AH is being negotiated.
1830 Keying material MUST be taken from the expanded KEYMAT in the
1833 All keys for SAs carrying data from the initiator to the responder
1834 are taken before SAs going in the reverse direction.
1836 If multiple IPsec protocols are negotiated, keying material is
1837 taken in the order in which the protocol headers will appear in
1838 the encapsulated packet.
1840 If a single protocol has both encryption and authentication keys,
1841 the encryption key is taken from the first octets of KEYMAT and
1842 the authentication key is taken from the next octets.
1844 Each cryptographic algorithm takes a fixed number of bits of keying
1845 material specified as part of the algorithm.
1850 Kaufman Standards Track [Page 33]
1852 RFC 4306 IKEv2 December 2005
1855 2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA exchange
1857 The CREATE_CHILD_SA exchange can be used to rekey an existing IKE_SA
1858 (see section 2.8). New initiator and responder SPIs are supplied in
1859 the SPI fields. The TS payloads are omitted when rekeying an IKE_SA.
1860 SKEYSEED for the new IKE_SA is computed using SK_d from the existing
1863 SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)
1865 where g^ir (new) is the shared secret from the ephemeral Diffie-
1866 Hellman exchange of this CREATE_CHILD_SA exchange (represented as an
1867 octet string in big endian order padded with zeros if necessary to
1868 make it the length of the modulus) and Ni and Nr are the two nonces
1869 stripped of any headers.
1871 The new IKE_SA MUST reset its message counters to 0.
1873 SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as
1874 specified in section 2.14.
1876 2.19. Requesting an Internal Address on a Remote Network
1878 Most commonly occurring in the endpoint-to-security-gateway scenario,
1879 an endpoint may need an IP address in the network protected by the
1880 security gateway and may need to have that address dynamically
1881 assigned. A request for such a temporary address can be included in
1882 any request to create a CHILD_SA (including the implicit request in
1883 message 3) by including a CP payload.
1885 This function provides address allocation to an IPsec Remote Access
1886 Client (IRAC) trying to tunnel into a network protected by an IPsec
1887 Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an
1888 IKE_SA and a CHILD_SA, the IRAC MUST request the IRAS-controlled
1889 address (and optionally other information concerning the protected
1890 network) in the IKE_AUTH exchange. The IRAS may procure an address
1891 for the IRAC from any number of sources such as a DHCP/BOOTP server
1892 or its own address pool.
1895 ----------------------------- ---------------------------
1896 HDR, SK {IDi, [CERT,] [CERTREQ,]
1897 [IDr,] AUTH, CP(CFG_REQUEST),
1900 <-- HDR, SK {IDr, [CERT,] AUTH,
1901 CP(CFG_REPLY), SAr2,
1906 Kaufman Standards Track [Page 34]
1908 RFC 4306 IKEv2 December 2005
1911 In all cases, the CP payload MUST be inserted before the SA payload.
1912 In variations of the protocol where there are multiple IKE_AUTH
1913 exchanges, the CP payloads MUST be inserted in the messages
1914 containing the SA payloads.
1916 CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute
1917 (either IPv4 or IPv6) but MAY contain any number of additional
1918 attributes the initiator wants returned in the response.
1920 For example, message from initiator to responder:
1922 INTERNAL_ADDRESS(0.0.0.0)
1923 INTERNAL_NETMASK(0.0.0.0)
1924 INTERNAL_DNS(0.0.0.0)
1925 TSi = (0, 0-65535,0.0.0.0-255.255.255.255)
1926 TSr = (0, 0-65535,0.0.0.0-255.255.255.255)
1928 NOTE: Traffic Selectors contain (protocol, port range, address
1931 Message from responder to initiator:
1934 INTERNAL_ADDRESS(192.0.2.202)
1935 INTERNAL_NETMASK(255.255.255.0)
1936 INTERNAL_SUBNET(192.0.2.0/255.255.255.0)
1937 TSi = (0, 0-65535,192.0.2.202-192.0.2.202)
1938 TSr = (0, 0-65535,192.0.2.0-192.0.2.255)
1940 All returned values will be implementation dependent. As can be seen
1941 in the above example, the IRAS MAY also send other attributes that
1942 were not included in CP(CFG_REQUEST) and MAY ignore the non-mandatory
1943 attributes that it does not support.
1945 The responder MUST NOT send a CFG_REPLY without having first received
1946 a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS
1947 to perform an unnecessary configuration lookup if the IRAC cannot
1948 process the REPLY. In the case where the IRAS's configuration
1949 requires that CP be used for a given identity IDi, but IRAC has
1950 failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and
1951 terminate the IKE exchange with a FAILED_CP_REQUIRED error.
1953 2.20. Requesting the Peer's Version
1955 An IKE peer wishing to inquire about the other peer's IKE software
1956 version information MAY use the method below. This is an example of
1957 a configuration request within an INFORMATIONAL exchange, after the
1958 IKE_SA and first CHILD_SA have been created.
1962 Kaufman Standards Track [Page 35]
1964 RFC 4306 IKEv2 December 2005
1967 An IKE implementation MAY decline to give out version information
1968 prior to authentication or even after authentication to prevent
1969 trolling in case some implementation is known to have some security
1970 weakness. In that case, it MUST either return an empty string or no
1971 CP payload if CP is not supported.
1974 ----------------------------- --------------------------
1975 HDR, SK{CP(CFG_REQUEST)} -->
1976 <-- HDR, SK{CP(CFG_REPLY)}
1979 APPLICATION_VERSION("")
1981 CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar
1984 2.21. Error Handling
1986 There are many kinds of errors that can occur during IKE processing.
1987 If a request is received that is badly formatted or unacceptable for
1988 reasons of policy (e.g., no matching cryptographic algorithms), the
1989 response MUST contain a Notify payload indicating the error. If an
1990 error occurs outside the context of an IKE request (e.g., the node is
1991 getting ESP messages on a nonexistent SPI), the node SHOULD initiate
1992 an INFORMATIONAL exchange with a Notify payload describing the
1995 Errors that occur before a cryptographically protected IKE_SA is
1996 established must be handled very carefully. There is a trade-off
1997 between wanting to be helpful in diagnosing a problem and responding
1998 to it and wanting to avoid being a dupe in a denial of service attack
1999 based on forged messages.
2001 If a node receives a message on UDP port 500 or 4500 outside the
2002 context of an IKE_SA known to it (and not a request to start one), it
2003 may be the result of a recent crash of the node. If the message is
2004 marked as a response, the node MAY audit the suspicious event but
2005 MUST NOT respond. If the message is marked as a request, the node
2006 MAY audit the suspicious event and MAY send a response. If a
2007 response is sent, the response MUST be sent to the IP address and
2008 port from whence it came with the same IKE SPIs and the Message ID
2009 copied. The response MUST NOT be cryptographically protected and
2010 MUST contain a Notify payload indicating INVALID_IKE_SPI.
2012 A node receiving such an unprotected Notify payload MUST NOT respond
2013 and MUST NOT change the state of any existing SAs. The message might
2014 be a forgery or might be a response the genuine correspondent was
2018 Kaufman Standards Track [Page 36]
2020 RFC 4306 IKEv2 December 2005
2023 tricked into sending. A node SHOULD treat such a message (and also a
2024 network message like ICMP destination unreachable) as a hint that
2025 there might be problems with SAs to that IP address and SHOULD
2026 initiate a liveness test for any such IKE_SA. An implementation
2027 SHOULD limit the frequency of such tests to avoid being tricked into
2028 participating in a denial of service attack.
2030 A node receiving a suspicious message from an IP address with which
2031 it has an IKE_SA MAY send an IKE Notify payload in an IKE
2032 INFORMATIONAL exchange over that SA. The recipient MUST NOT change
2033 the state of any SA's as a result but SHOULD audit the event to aid
2034 in diagnosing malfunctions. A node MUST limit the rate at which it
2035 will send messages in response to unprotected messages.
2039 Use of IP compression [IPCOMP] can be negotiated as part of the setup
2040 of a CHILD_SA. While IP compression involves an extra header in each
2041 packet and a compression parameter index (CPI), the virtual
2042 "compression association" has no life outside the ESP or AH SA that
2043 contains it. Compression associations disappear when the
2044 corresponding ESP or AH SA goes away. It is not explicitly mentioned
2045 in any DELETE payload.
2047 Negotiation of IP compression is separate from the negotiation of
2048 cryptographic parameters associated with a CHILD_SA. A node
2049 requesting a CHILD_SA MAY advertise its support for one or more
2050 compression algorithms through one or more Notify payloads of type
2051 IPCOMP_SUPPORTED. The response MAY indicate acceptance of a single
2052 compression algorithm with a Notify payload of type IPCOMP_SUPPORTED.
2053 These payloads MUST NOT occur in messages that do not contain SA
2056 Although there has been discussion of allowing multiple compression
2057 algorithms to be accepted and to have different compression
2058 algorithms available for the two directions of a CHILD_SA,
2059 implementations of this specification MUST NOT accept an IPComp
2060 algorithm that was not proposed, MUST NOT accept more than one, and
2061 MUST NOT compress using an algorithm other than one proposed and
2062 accepted in the setup of the CHILD_SA.
2064 A side effect of separating the negotiation of IPComp from
2065 cryptographic parameters is that it is not possible to propose
2066 multiple cryptographic suites and propose IP compression with some of
2067 them but not others.
2074 Kaufman Standards Track [Page 37]
2076 RFC 4306 IKEv2 December 2005
2081 Network Address Translation (NAT) gateways are a controversial
2082 subject. This section briefly describes what they are and how they
2083 are likely to act on IKE traffic. Many people believe that NATs are
2084 evil and that we should not design our protocols so as to make them
2085 work better. IKEv2 does specify some unintuitive processing rules in
2086 order that NATs are more likely to work.
2088 NATs exist primarily because of the shortage of IPv4 addresses,
2089 though there are other rationales. IP nodes that are "behind" a NAT
2090 have IP addresses that are not globally unique, but rather are
2091 assigned from some space that is unique within the network behind the
2092 NAT but that are likely to be reused by nodes behind other NATs.
2093 Generally, nodes behind NATs can communicate with other nodes behind
2094 the same NAT and with nodes with globally unique addresses, but not
2095 with nodes behind other NATs. There are exceptions to that rule.
2096 When those nodes make connections to nodes on the real Internet, the
2097 NAT gateway "translates" the IP source address to an address that
2098 will be routed back to the gateway. Messages to the gateway from the
2099 Internet have their destination addresses "translated" to the
2100 internal address that will route the packet to the correct endnode.
2102 NATs are designed to be "transparent" to endnodes. Neither software
2103 on the node behind the NAT nor the node on the Internet requires
2104 modification to communicate through the NAT. Achieving this
2105 transparency is more difficult with some protocols than with others.
2106 Protocols that include IP addresses of the endpoints within the
2107 payloads of the packet will fail unless the NAT gateway understands
2108 the protocol and modifies the internal references as well as those in
2109 the headers. Such knowledge is inherently unreliable, is a network
2110 layer violation, and often results in subtle problems.
2112 Opening an IPsec connection through a NAT introduces special
2113 problems. If the connection runs in transport mode, changing the IP
2114 addresses on packets will cause the checksums to fail and the NAT
2115 cannot correct the checksums because they are cryptographically
2116 protected. Even in tunnel mode, there are routing problems because
2117 transparently translating the addresses of AH and ESP packets
2118 requires special logic in the NAT and that logic is heuristic and
2119 unreliable in nature. For that reason, IKEv2 can negotiate UDP
2120 encapsulation of IKE and ESP packets. This encoding is slightly less
2121 efficient but is easier for NATs to process. In addition, firewalls
2122 may be configured to pass IPsec traffic over UDP but not ESP/AH or
2130 Kaufman Standards Track [Page 38]
2132 RFC 4306 IKEv2 December 2005
2135 It is a common practice of NATs to translate TCP and UDP port numbers
2136 as well as addresses and use the port numbers of inbound packets to
2137 decide which internal node should get a given packet. For this
2138 reason, even though IKE packets MUST be sent from and to UDP port
2139 500, they MUST be accepted coming from any port and responses MUST be
2140 sent to the port from whence they came. This is because the ports
2141 may be modified as the packets pass through NATs. Similarly, IP
2142 addresses of the IKE endpoints are generally not included in the IKE
2143 payloads because the payloads are cryptographically protected and
2144 could not be transparently modified by NATs.
2146 Port 4500 is reserved for UDP-encapsulated ESP and IKE. When working
2147 through a NAT, it is generally better to pass IKE packets over port
2148 4500 because some older NATs handle IKE traffic on port 500 cleverly
2149 in an attempt to transparently establish IPsec connections between
2150 endpoints that don't handle NAT traversal themselves. Such NATs may
2151 interfere with the straightforward NAT traversal envisioned by this
2152 document, so an IPsec endpoint that discovers a NAT between it and
2153 its correspondent MUST send all subsequent traffic to and from port
2154 4500, which NATs should not treat specially (as they might with port
2157 The specific requirements for supporting NAT traversal [RFC3715] are
2158 listed below. Support for NAT traversal is optional. In this
2159 section only, requirements listed as MUST apply only to
2160 implementations supporting NAT traversal.
2162 IKE MUST listen on port 4500 as well as port 500. IKE MUST
2163 respond to the IP address and port from which packets arrived.
2165 Both IKE initiator and responder MUST include in their IKE_SA_INIT
2166 packets Notify payloads of type NAT_DETECTION_SOURCE_IP and
2167 NAT_DETECTION_DESTINATION_IP. Those payloads can be used to
2168 detect if there is NAT between the hosts, and which end is behind
2169 the NAT. The location of the payloads in the IKE_SA_INIT packets
2170 are just after the Ni and Nr payloads (before the optional CERTREQ
2173 If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches
2174 the hash of the source IP and port found from the IP header of the
2175 packet containing the payload, it means that the other end is
2176 behind NAT (i.e., someone along the route changed the source
2177 address of the original packet to match the address of the NAT
2178 box). In this case, this end should allow dynamic update of the
2179 other ends IP address, as described later.
2186 Kaufman Standards Track [Page 39]
2188 RFC 4306 IKEv2 December 2005
2191 If the NAT_DETECTION_DESTINATION_IP payload received does not
2192 match the hash of the destination IP and port found from the IP
2193 header of the packet containing the payload, it means that this
2194 end is behind a NAT. In this case, this end SHOULD start sending
2195 keepalive packets as explained in [Hutt05].
2197 The IKE initiator MUST check these payloads if present and if they
2198 do not match the addresses in the outer packet MUST tunnel all
2199 future IKE and ESP packets associated with this IKE_SA over UDP
2202 To tunnel IKE packets over UDP port 4500, the IKE header has four
2203 octets of zero prepended and the result immediately follows the
2204 UDP header. To tunnel ESP packets over UDP port 4500, the ESP
2205 header immediately follows the UDP header. Since the first four
2206 bytes of the ESP header contain the SPI, and the SPI cannot
2207 validly be zero, it is always possible to distinguish ESP and IKE
2210 The original source and destination IP address required for the
2211 transport mode TCP and UDP packet checksum fixup (see [Hutt05])
2212 are obtained from the Traffic Selectors associated with the
2213 exchange. In the case of NAT traversal, the Traffic Selectors
2214 MUST contain exactly one IP address, which is then used as the
2215 original IP address.
2217 There are cases where a NAT box decides to remove mappings that
2218 are still alive (for example, the keepalive interval is too long,
2219 or the NAT box is rebooted). To recover in these cases, hosts
2220 that are not behind a NAT SHOULD send all packets (including
2221 retransmission packets) to the IP address and port from the last
2222 valid authenticated packet from the other end (i.e., dynamically
2223 update the address). A host behind a NAT SHOULD NOT do this
2224 because it opens a DoS attack possibility. Any authenticated IKE
2225 packet or any authenticated UDP-encapsulated ESP packet can be
2226 used to detect that the IP address or the port has changed.
2228 Note that similar but probably not identical actions will likely
2229 be needed to make IKE work with Mobile IP, but such processing is
2230 not addressed by this document.
2232 2.24. Explicit Congestion Notification (ECN)
2234 When IPsec tunnels behave as originally specified in [RFC2401], ECN
2235 usage is not appropriate for the outer IP headers because tunnel
2236 decapsulation processing discards ECN congestion indications to the
2237 detriment of the network. ECN support for IPsec tunnels for IKEv1-
2238 based IPsec requires multiple operating modes and negotiation (see
2242 Kaufman Standards Track [Page 40]
2244 RFC 4306 IKEv2 December 2005
2247 [RFC3168]). IKEv2 simplifies this situation by requiring that ECN be
2248 usable in the outer IP headers of all tunnel-mode IPsec SAs created
2249 by IKEv2. Specifically, tunnel encapsulators and decapsulators for
2250 all tunnel-mode SAs created by IKEv2 MUST support the ECN full-
2251 functionality option for tunnels specified in [RFC3168] and MUST
2252 implement the tunnel encapsulation and decapsulation processing
2253 specified in [RFC4301] to prevent discarding of ECN congestion
2256 3. Header and Payload Formats
2260 IKE messages use UDP ports 500 and/or 4500, with one IKE message per
2261 UDP datagram. Information from the beginning of the packet through
2262 the UDP header is largely ignored except that the IP addresses and
2263 UDP ports from the headers are reversed and used for return packets.
2264 When sent on UDP port 500, IKE messages begin immediately following
2265 the UDP header. When sent on UDP port 4500, IKE messages have
2266 prepended four octets of zero. These four octets of zero are not
2267 part of the IKE message and are not included in any of the length
2268 fields or checksums defined by IKE. Each IKE message begins with the
2269 IKE header, denoted HDR in this memo. Following the header are one
2270 or more IKE payloads each identified by a "Next Payload" field in the
2271 preceding payload. Payloads are processed in the order in which they
2272 appear in an IKE message by invoking the appropriate processing
2273 routine according to the "Next Payload" field in the IKE header and
2274 subsequently according to the "Next Payload" field in the IKE payload
2275 itself until a "Next Payload" field of zero indicates that no
2276 payloads follow. If a payload of type "Encrypted" is found, that
2277 payload is decrypted and its contents parsed as additional payloads.
2278 An Encrypted payload MUST be the last payload in a packet and an
2279 Encrypted payload MUST NOT contain another Encrypted payload.
2281 The Recipient SPI in the header identifies an instance of an IKE
2282 security association. It is therefore possible for a single instance
2283 of IKE to multiplex distinct sessions with multiple peers.
2285 All multi-octet fields representing integers are laid out in big
2286 endian order (aka most significant byte first, or network byte
2289 The format of the IKE header is shown in Figure 4.
2298 Kaufman Standards Track [Page 41]
2300 RFC 4306 IKEv2 December 2005
2304 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
2305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2306 ! IKE_SA Initiator's SPI !
2308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2309 ! IKE_SA Responder's SPI !
2311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2312 ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags !
2313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2319 Figure 4: IKE Header Format
2321 o Initiator's SPI (8 octets) - A value chosen by the
2322 initiator to identify a unique IKE security association. This
2323 value MUST NOT be zero.
2325 o Responder's SPI (8 octets) - A value chosen by the
2326 responder to identify a unique IKE security association. This
2327 value MUST be zero in the first message of an IKE Initial
2328 Exchange (including repeats of that message including a
2329 cookie) and MUST NOT be zero in any other message.
2331 o Next Payload (1 octet) - Indicates the type of payload that
2332 immediately follows the header. The format and value of each
2333 payload are defined below.
2335 o Major Version (4 bits) - Indicates the major version of the IKE
2336 protocol in use. Implementations based on this version of IKE
2337 MUST set the Major Version to 2. Implementations based on
2338 previous versions of IKE and ISAKMP MUST set the Major Version
2339 to 1. Implementations based on this version of IKE MUST reject
2340 or ignore messages containing a version number greater than
2343 o Minor Version (4 bits) - Indicates the minor version of the
2344 IKE protocol in use. Implementations based on this version of
2345 IKE MUST set the Minor Version to 0. They MUST ignore the
2346 minor version number of received messages.
2348 o Exchange Type (1 octet) - Indicates the type of exchange being
2349 used. This constrains the payloads sent in each message and
2350 orderings of messages in an exchange.
2354 Kaufman Standards Track [Page 42]
2356 RFC 4306 IKEv2 December 2005
2366 RESERVED TO IANA 38-239
2367 Reserved for private use 240-255
2369 o Flags (1 octet) - Indicates specific options that are set
2370 for the message. Presence of options are indicated by the
2371 appropriate bit in the flags field being set. The bits are
2372 defined LSB first, so bit 0 would be the least significant
2373 bit of the Flags octet. In the description below, a bit
2374 being 'set' means its value is '1', while 'cleared' means
2377 -- X(reserved) (bits 0-2) - These bits MUST be cleared
2378 when sending and MUST be ignored on receipt.
2380 -- I(nitiator) (bit 3 of Flags) - This bit MUST be set in
2381 messages sent by the original initiator of the IKE_SA
2382 and MUST be cleared in messages sent by the original
2383 responder. It is used by the recipient to determine
2384 which eight octets of the SPI were generated by the
2387 -- V(ersion) (bit 4 of Flags) - This bit indicates that
2388 the transmitter is capable of speaking a higher major
2389 version number of the protocol than the one indicated
2390 in the major version number field. Implementations of
2391 IKEv2 must clear this bit when sending and MUST ignore
2392 it in incoming messages.
2394 -- R(esponse) (bit 5 of Flags) - This bit indicates that
2395 this message is a response to a message containing
2396 the same message ID. This bit MUST be cleared in all
2397 request messages and MUST be set in all responses.
2398 An IKE endpoint MUST NOT generate a response to a
2399 message that is marked as being a response.
2401 -- X(reserved) (bits 6-7 of Flags) - These bits MUST be
2402 cleared when sending and MUST be ignored on receipt.
2410 Kaufman Standards Track [Page 43]
2412 RFC 4306 IKEv2 December 2005
2415 o Message ID (4 octets) - Message identifier used to control
2416 retransmission of lost packets and matching of requests and
2417 responses. It is essential to the security of the protocol
2418 because it is used to prevent message replay attacks.
2419 See sections 2.1 and 2.2.
2421 o Length (4 octets) - Length of total message (header + payloads)
2424 3.2. Generic Payload Header
2426 Each IKE payload defined in sections 3.3 through 3.16 begins with a
2427 generic payload header, shown in Figure 5. Figures for each payload
2428 below will include the generic payload header, but for brevity the
2429 description of each field will be omitted.
2432 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
2433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2434 ! Next Payload !C! RESERVED ! Payload Length !
2435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2437 Figure 5: Generic Payload Header
2439 The Generic Payload Header fields are defined as follows:
2441 o Next Payload (1 octet) - Identifier for the payload type of the
2442 next payload in the message. If the current payload is the last
2443 in the message, then this field will be 0. This field provides a
2444 "chaining" capability whereby additional payloads can be added to
2445 a message by appending it to the end of the message and setting
2446 the "Next Payload" field of the preceding payload to indicate the
2447 new payload's type. An Encrypted payload, which must always be
2448 the last payload of a message, is an exception. It contains data
2449 structures in the format of additional payloads. In the header of
2450 an Encrypted payload, the Next Payload field is set to the payload
2451 type of the first contained payload (instead of 0).
2455 Next Payload Type Notation Value
2460 Security Association SA 33
2462 Identification - Initiator IDi 35
2466 Kaufman Standards Track [Page 44]
2468 RFC 4306 IKEv2 December 2005
2471 Identification - Responder IDr 36
2473 Certificate Request CERTREQ 38
2474 Authentication AUTH 39
2479 Traffic Selector - Initiator TSi 44
2480 Traffic Selector - Responder TSr 45
2483 Extensible Authentication EAP 48
2484 RESERVED TO IANA 49-127
2487 Payload type values 1-32 should not be used so that there is no
2488 overlap with the code assignments for IKEv1. Payload type values
2489 49-127 are reserved to IANA for future assignment in IKEv2 (see
2490 section 6). Payload type values 128-255 are for private use among
2491 mutually consenting parties.
2493 o Critical (1 bit) - MUST be set to zero if the sender wants the
2494 recipient to skip this payload if it does not understand the
2495 payload type code in the Next Payload field of the previous
2496 payload. MUST be set to one if the sender wants the recipient to
2497 reject this entire message if it does not understand the payload
2498 type. MUST be ignored by the recipient if the recipient
2499 understands the payload type code. MUST be set to zero for
2500 payload types defined in this document. Note that the critical
2501 bit applies to the current payload rather than the "next" payload
2502 whose type code appears in the first octet. The reasoning behind
2503 not setting the critical bit for payloads defined in this document
2504 is that all implementations MUST understand all payload types
2505 defined in this document and therefore must ignore the Critical
2506 bit's value. Skipped payloads are expected to have valid Next
2507 Payload and Payload Length fields.
2509 o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on
2512 o Payload Length (2 octets) - Length in octets of the current
2513 payload, including the generic payload header.
2522 Kaufman Standards Track [Page 45]
2524 RFC 4306 IKEv2 December 2005
2527 3.3. Security Association Payload
2529 The Security Association Payload, denoted SA in this memo, is used to
2530 negotiate attributes of a security association. Assembly of Security
2531 Association Payloads requires great peace of mind. An SA payload MAY
2532 contain multiple proposals. If there is more than one, they MUST be
2533 ordered from most preferred to least preferred. Each proposal may
2534 contain multiple IPsec protocols (where a protocol is IKE, ESP, or
2535 AH), each protocol MAY contain multiple transforms, and each
2536 transform MAY contain multiple attributes. When parsing an SA, an
2537 implementation MUST check that the total Payload Length is consistent
2538 with the payload's internal lengths and counts. Proposals,
2539 Transforms, and Attributes each have their own variable length
2540 encodings. They are nested such that the Payload Length of an SA
2541 includes the combined contents of the SA, Proposal, Transform, and
2542 Attribute information. The length of a Proposal includes the lengths
2543 of all Transforms and Attributes it contains. The length of a
2544 Transform includes the lengths of all Attributes it contains.
2546 The syntax of Security Associations, Proposals, Transforms, and
2547 Attributes is based on ISAKMP; however, the semantics are somewhat
2548 different. The reason for the complexity and the hierarchy is to
2549 allow for multiple possible combinations of algorithms to be encoded
2550 in a single SA. Sometimes there is a choice of multiple algorithms,
2551 whereas other times there is a combination of algorithms. For
2552 example, an initiator might want to propose using (AH w/MD5 and ESP
2553 w/3DES) OR (ESP w/MD5 and 3DES).
2555 One of the reasons the semantics of the SA payload has changed from
2556 ISAKMP and IKEv1 is to make the encodings more compact in common
2559 The Proposal structure contains within it a Proposal # and an IPsec
2560 protocol ID. Each structure MUST have the same Proposal # as the
2561 previous one or be one (1) greater. The first Proposal MUST have a
2562 Proposal # of one (1). If two successive structures have the same
2563 Proposal number, it means that the proposal consists of the first
2564 structure AND the second. So a proposal of AH AND ESP would have two
2565 proposal structures, one for AH and one for ESP and both would have
2566 Proposal #1. A proposal of AH OR ESP would have two proposal
2567 structures, one for AH with Proposal #1 and one for ESP with Proposal
2570 Each Proposal/Protocol structure is followed by one or more transform
2571 structures. The number of different transforms is generally
2572 determined by the Protocol. AH generally has a single transform: an
2573 integrity check algorithm. ESP generally has two: an encryption
2574 algorithm and an integrity check algorithm. IKE generally has four
2578 Kaufman Standards Track [Page 46]
2580 RFC 4306 IKEv2 December 2005
2583 transforms: a Diffie-Hellman group, an integrity check algorithm, a
2584 prf algorithm, and an encryption algorithm. If an algorithm that
2585 combines encryption and integrity protection is proposed, it MUST be
2586 proposed as an encryption algorithm and an integrity protection
2587 algorithm MUST NOT be proposed. For each Protocol, the set of
2588 permissible transforms is assigned transform ID numbers, which appear
2589 in the header of each transform.
2591 If there are multiple transforms with the same Transform Type, the
2592 proposal is an OR of those transforms. If there are multiple
2593 Transforms with different Transform Types, the proposal is an AND of
2594 the different groups. For example, to propose ESP with (3DES or
2595 IDEA) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two
2596 Transform Type 1 candidates (one for 3DES and one for IDEA) and two
2597 Transform Type 2 candidates (one for HMAC_MD5 and one for HMAC_SHA).
2598 This effectively proposes four combinations of algorithms. If the
2599 initiator wanted to propose only a subset of those, for example (3DES
2600 and HMAC_MD5) or (IDEA and HMAC_SHA), there is no way to encode that
2601 as multiple transforms within a single Proposal. Instead, the
2602 initiator would have to construct two different Proposals, each with
2605 A given transform MAY have one or more Attributes. Attributes are
2606 necessary when the transform can be used in more than one way, as
2607 when an encryption algorithm has a variable key size. The transform
2608 would specify the algorithm and the attribute would specify the key
2609 size. Most transforms do not have attributes. A transform MUST NOT
2610 have multiple attributes of the same type. To propose alternate
2611 values for an attribute (for example, multiple key sizes for the AES
2612 encryption algorithm), and implementation MUST include multiple
2613 Transforms with the same Transform Type each with a single Attribute.
2615 Note that the semantics of Transforms and Attributes are quite
2616 different from those in IKEv1. In IKEv1, a single Transform carried
2617 multiple algorithms for a protocol with one carried in the Transform
2618 and the others carried in the Attributes.
2621 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
2622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2623 ! Next Payload !C! RESERVED ! Payload Length !
2624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2630 Figure 6: Security Association Payload
2634 Kaufman Standards Track [Page 47]
2636 RFC 4306 IKEv2 December 2005
2639 o Proposals (variable) - One or more proposal substructures.
2641 The payload type for the Security Association Payload is thirty
2644 3.3.1. Proposal Substructure
2647 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
2648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2649 ! 0 (last) or 2 ! RESERVED ! Proposal Length !
2650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2651 ! Proposal # ! Protocol ID ! SPI Size !# of Transforms!
2652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2660 Figure 7: Proposal Substructure
2662 o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the
2663 last Proposal Substructure in the SA. This syntax is inherited
2664 from ISAKMP, but is unnecessary because the last Proposal could
2665 be identified from the length of the SA. The value (2)
2666 corresponds to a Payload Type of Proposal in IKEv1, and the
2667 first 4 octets of the Proposal structure are designed to look
2668 somewhat like the header of a Payload.
2670 o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on
2673 o Proposal Length (2 octets) - Length of this proposal, including
2674 all transforms and attributes that follow.
2676 o Proposal # (1 octet) - When a proposal is made, the first
2677 proposal in an SA payload MUST be #1, and subsequent proposals
2678 MUST either be the same as the previous proposal (indicating an
2679 AND of the two proposals) or one more than the previous
2680 proposal (indicating an OR of the two proposals). When a
2681 proposal is accepted, all of the proposal numbers in the SA
2682 payload MUST be the same and MUST match the number on the
2683 proposal sent that was accepted.
2690 Kaufman Standards Track [Page 48]
2692 RFC 4306 IKEv2 December 2005
2695 o Protocol ID (1 octet) - Specifies the IPsec protocol identifier
2696 for the current negotiation. The defined values are:
2698 Protocol Protocol ID
2703 RESERVED TO IANA 4-200
2706 o SPI Size (1 octet) - For an initial IKE_SA negotiation, this
2707 field MUST be zero; the SPI is obtained from the outer header.
2708 During subsequent negotiations, it is equal to the size, in
2709 octets, of the SPI of the corresponding protocol (8 for IKE, 4
2712 o # of Transforms (1 octet) - Specifies the number of transforms
2715 o SPI (variable) - The sending entity's SPI. Even if the SPI Size
2716 is not a multiple of 4 octets, there is no padding applied to
2717 the payload. When the SPI Size field is zero, this field is
2718 not present in the Security Association payload.
2720 o Transforms (variable) - One or more transform substructures.
2722 3.3.2. Transform Substructure
2725 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
2726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2727 ! 0 (last) or 3 ! RESERVED ! Transform Length !
2728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2729 !Transform Type ! RESERVED ! Transform ID !
2730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2732 ~ Transform Attributes ~
2734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2736 Figure 8: Transform Substructure
2738 o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the
2739 last Transform Substructure in the Proposal. This syntax is
2740 inherited from ISAKMP, but is unnecessary because the last
2741 Proposal could be identified from the length of the SA. The
2746 Kaufman Standards Track [Page 49]
2748 RFC 4306 IKEv2 December 2005
2751 value (3) corresponds to a Payload Type of Transform in IKEv1,
2752 and the first 4 octets of the Transform structure are designed
2753 to look somewhat like the header of a Payload.
2755 o RESERVED - MUST be sent as zero; MUST be ignored on receipt.
2757 o Transform Length - The length (in octets) of the Transform
2758 Substructure including Header and Attributes.
2760 o Transform Type (1 octet) - The type of transform being
2761 specified in this transform. Different protocols support
2762 different transform types. For some protocols, some of the
2763 transforms may be optional. If a transform is optional and the
2764 initiator wishes to propose that the transform be omitted, no
2765 transform of the given type is included in the proposal. If
2766 the initiator wishes to make use of the transform optional to
2767 the responder, it includes a transform substructure with
2768 transform ID = 0 as one of the options.
2770 o Transform ID (2 octets) - The specific instance of the
2771 transform type being proposed.
2773 Transform Type Values
2778 Encryption Algorithm (ENCR) 1 (IKE and ESP)
2779 Pseudo-random Function (PRF) 2 (IKE)
2780 Integrity Algorithm (INTEG) 3 (IKE, AH, optional in ESP)
2781 Diffie-Hellman Group (D-H) 4 (IKE, optional in AH & ESP)
2782 Extended Sequence Numbers (ESN) 5 (AH and ESP)
2783 RESERVED TO IANA 6-240
2786 For Transform Type 1 (Encryption Algorithm), defined Transform IDs
2789 Name Number Defined In
2791 ENCR_DES_IV64 1 (RFC1827)
2792 ENCR_DES 2 (RFC2405), [DES]
2793 ENCR_3DES 3 (RFC2451)
2794 ENCR_RC5 4 (RFC2451)
2795 ENCR_IDEA 5 (RFC2451), [IDEA]
2796 ENCR_CAST 6 (RFC2451)
2797 ENCR_BLOWFISH 7 (RFC2451)
2798 ENCR_3IDEA 8 (RFC2451)
2802 Kaufman Standards Track [Page 50]
2804 RFC 4306 IKEv2 December 2005
2809 ENCR_NULL 11 (RFC2410)
2810 ENCR_AES_CBC 12 (RFC3602)
2811 ENCR_AES_CTR 13 (RFC3664)
2813 values 14-1023 are reserved to IANA. Values 1024-65535 are
2814 for private use among mutually consenting parties.
2816 For Transform Type 2 (Pseudo-random Function), defined Transform IDs
2819 Name Number Defined In
2821 PRF_HMAC_MD5 1 (RFC2104), [MD5]
2822 PRF_HMAC_SHA1 2 (RFC2104), [SHA]
2823 PRF_HMAC_TIGER 3 (RFC2104)
2824 PRF_AES128_XCBC 4 (RFC3664)
2826 values 5-1023 are reserved to IANA. Values 1024-65535 are for
2827 private use among mutually consenting parties.
2829 For Transform Type 3 (Integrity Algorithm), defined Transform IDs
2832 Name Number Defined In
2834 AUTH_HMAC_MD5_96 1 (RFC2403)
2835 AUTH_HMAC_SHA1_96 2 (RFC2404)
2837 AUTH_KPDK_MD5 4 (RFC1826)
2838 AUTH_AES_XCBC_96 5 (RFC3566)
2840 values 6-1023 are reserved to IANA. Values 1024-65535 are for
2841 private use among mutually consenting parties.
2843 For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs
2848 Defined in Appendix B 1 - 2
2850 Defined in [ADDGROUP] 5
2851 RESERVED TO IANA 6 - 13
2852 Defined in [ADDGROUP] 14 - 18
2853 RESERVED TO IANA 19 - 1023
2854 PRIVATE USE 1024-65535
2858 Kaufman Standards Track [Page 51]
2860 RFC 4306 IKEv2 December 2005
2863 For Transform Type 5 (Extended Sequence Numbers), defined Transform
2867 No Extended Sequence Numbers 0
2868 Extended Sequence Numbers 1
2871 3.3.3. Valid Transform Types by Protocol
2873 The number and type of transforms that accompany an SA payload are
2874 dependent on the protocol in the SA itself. An SA payload proposing
2875 the establishment of an SA has the following mandatory and optional
2876 transform types. A compliant implementation MUST understand all
2877 mandatory and optional types for each protocol it supports (though it
2878 need not accept proposals with unacceptable suites). A proposal MAY
2879 omit the optional types if the only value for them it will accept is
2882 Protocol Mandatory Types Optional Types
2883 IKE ENCR, PRF, INTEG, D-H
2884 ESP ENCR, ESN INTEG, D-H
2887 3.3.4. Mandatory Transform IDs
2889 The specification of suites that MUST and SHOULD be supported for
2890 interoperability has been removed from this document because they are
2891 likely to change more rapidly than this document evolves.
2893 An important lesson learned from IKEv1 is that no system should only
2894 implement the mandatory algorithms and expect them to be the best
2895 choice for all customers. For example, at the time that this
2896 document was written, many IKEv1 implementers were starting to
2897 migrate to AES in Cipher Block Chaining (CBC) mode for Virtual
2898 Private Network (VPN) applications. Many IPsec systems based on
2899 IKEv2 will implement AES, additional Diffie-Hellman groups, and
2900 additional hash algorithms, and some IPsec customers already require
2901 these algorithms in addition to the ones listed above.
2903 It is likely that IANA will add additional transforms in the future,
2904 and some users may want to use private suites, especially for IKE
2905 where implementations should be capable of supporting different
2906 parameters, up to certain size limits. In support of this goal, all
2907 implementations of IKEv2 SHOULD include a management facility that
2908 allows specification (by a user or system administrator) of Diffie-
2909 Hellman (DH) parameters (the generator, modulus, and exponent lengths
2910 and values) for new DH groups. Implementations SHOULD provide a
2914 Kaufman Standards Track [Page 52]
2916 RFC 4306 IKEv2 December 2005
2919 management interface via which these parameters and the associated
2920 transform IDs may be entered (by a user or system administrator), to
2921 enable negotiating such groups.
2923 All implementations of IKEv2 MUST include a management facility that
2924 enables a user or system administrator to specify the suites that are
2925 acceptable for use with IKE. Upon receipt of a payload with a set of
2926 transform IDs, the implementation MUST compare the transmitted
2927 transform IDs against those locally configured via the management
2928 controls, to verify that the proposed suite is acceptable based on
2929 local policy. The implementation MUST reject SA proposals that are
2930 not authorized by these IKE suite controls. Note that cryptographic
2931 suites that MUST be implemented need not be configured as acceptable
2934 3.3.5. Transform Attributes
2936 Each transform in a Security Association payload may include
2937 attributes that modify or complete the specification of the
2938 transform. These attributes are type/value pairs and are defined
2939 below. For example, if an encryption algorithm has a variable-length
2940 key, the key length to be used may be specified as an attribute.
2941 Attributes can have a value with a fixed two octet length or a
2942 variable-length value. For the latter, the attribute is encoded as
2946 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
2947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2948 !A! Attribute Type ! AF=0 Attribute Length !
2949 !F! ! AF=1 Attribute Value !
2950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2951 ! AF=0 Attribute Value !
2952 ! AF=1 Not Transmitted !
2953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2955 Figure 9: Data Attributes
2957 o Attribute Type (2 octets) - Unique identifier for each type of
2958 attribute (see below).
2960 The most significant bit of this field is the Attribute Format
2961 bit (AF). It indicates whether the data attributes follow the
2962 Type/Length/Value (TLV) format or a shortened Type/Value (TV)
2963 format. If the AF bit is zero (0), then the Data Attributes
2964 are of the Type/Length/Value (TLV) form. If the AF bit is a
2965 one (1), then the Data Attributes are of the Type/Value form.
2970 Kaufman Standards Track [Page 53]
2972 RFC 4306 IKEv2 December 2005
2975 o Attribute Length (2 octets) - Length in octets of the Attribute
2976 Value. When the AF bit is a one (1), the Attribute Value is
2977 only 2 octets and the Attribute Length field is not present.
2979 o Attribute Value (variable length) - Value of the Attribute
2980 associated with the Attribute Type. If the AF bit is a zero
2981 (0), this field has a variable length defined by the Attribute
2982 Length field. If the AF bit is a one (1), the Attribute Value
2983 has a length of 2 octets.
2985 Note that only a single attribute type (Key Length) is defined, and
2986 it is fixed length. The variable-length encoding specification is
2987 included only for future extensions. The only algorithms defined in
2988 this document that accept attributes are the AES-based encryption,
2989 integrity, and pseudo-random functions, which require a single
2990 attribute specifying key width.
2992 Attributes described as basic MUST NOT be encoded using the
2993 variable-length encoding. Variable-length attributes MUST NOT be
2994 encoded as basic even if their value can fit into two octets. NOTE:
2995 This is a change from IKEv1, where increased flexibility may have
2996 simplified the composer of messages but certainly complicated the
2999 Attribute Type Value Attribute Format
3000 --------------------------------------------------------------
3001 RESERVED 0-13 Key Length (in bits)
3002 14 TV RESERVED 15-17
3003 RESERVED TO IANA 18-16383 PRIVATE USE
3006 Values 0-13 and 15-17 were used in a similar context in IKEv1 and
3007 should not be assigned except to matching values. Values 18-16383
3008 are reserved to IANA. Values 16384-32767 are for private use among
3009 mutually consenting parties.
3013 When using an Encryption Algorithm that has a variable-length key,
3014 this attribute specifies the key length in bits (MUST use network
3015 byte order). This attribute MUST NOT be used when the specified
3016 Encryption Algorithm uses a fixed-length key.
3026 Kaufman Standards Track [Page 54]
3028 RFC 4306 IKEv2 December 2005
3031 3.3.6. Attribute Negotiation
3033 During security association negotiation, initiators present offers to
3034 responders. Responders MUST select a single complete set of
3035 parameters from the offers (or reject all offers if none are
3036 acceptable). If there are multiple proposals, the responder MUST
3037 choose a single proposal number and return all of the Proposal
3038 substructures with that Proposal number. If there are multiple
3039 Transforms with the same type, the responder MUST choose a single
3040 one. Any attributes of a selected transform MUST be returned
3041 unmodified. The initiator of an exchange MUST check that the
3042 accepted offer is consistent with one of its proposals, and if not
3043 that response MUST be rejected.
3045 Negotiating Diffie-Hellman groups presents some special challenges.
3046 SA offers include proposed attributes and a Diffie-Hellman public
3047 number (KE) in the same message. If in the initial exchange the
3048 initiator offers to use one of several Diffie-Hellman groups, it
3049 SHOULD pick the one the responder is most likely to accept and
3050 include a KE corresponding to that group. If the guess turns out to
3051 be wrong, the responder will indicate the correct group in the
3052 response and the initiator SHOULD pick an element of that group for
3053 its KE value when retrying the first message. It SHOULD, however,
3054 continue to propose its full supported set of groups in order to
3055 prevent a man-in-the-middle downgrade attack.
3057 Implementation Note:
3059 Certain negotiable attributes can have ranges or could have
3060 multiple acceptable values. These include the key length of a
3061 variable key length symmetric cipher. To further interoperability
3062 and to support upgrading endpoints independently, implementers of
3063 this protocol SHOULD accept values that they deem to supply
3064 greater security. For instance, if a peer is configured to accept
3065 a variable-length cipher with a key length of X bits and is
3066 offered that cipher with a larger key length, the implementation
3067 SHOULD accept the offer if it supports use of the longer key.
3069 Support of this capability allows an implementation to express a
3070 concept of "at least" a certain level of security -- "a key length of
3071 _at least_ X bits for cipher Y".
3082 Kaufman Standards Track [Page 55]
3084 RFC 4306 IKEv2 December 2005
3087 3.4. Key Exchange Payload
3089 The Key Exchange Payload, denoted KE in this memo, is used to
3090 exchange Diffie-Hellman public numbers as part of a Diffie-Hellman
3091 key exchange. The Key Exchange Payload consists of the IKE generic
3092 payload header followed by the Diffie-Hellman public value itself.
3095 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
3096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3097 ! Next Payload !C! RESERVED ! Payload Length !
3098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3099 ! DH Group # ! RESERVED !
3100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3102 ~ Key Exchange Data ~
3104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3106 Figure 10: Key Exchange Payload Format
3108 A key exchange payload is constructed by copying one's Diffie-Hellman
3109 public value into the "Key Exchange Data" portion of the payload.
3110 The length of the Diffie-Hellman public value MUST be equal to the
3111 length of the prime modulus over which the exponentiation was
3112 performed, prepending zero bits to the value if necessary.
3114 The DH Group # identifies the Diffie-Hellman group in which the Key
3115 Exchange Data was computed (see section 3.3.2). If the selected
3116 proposal uses a different Diffie-Hellman group, the message MUST be
3117 rejected with a Notify payload of type INVALID_KE_PAYLOAD.
3119 The payload type for the Key Exchange payload is thirty four (34).
3121 3.5. Identification Payloads
3123 The Identification Payloads, denoted IDi and IDr in this memo, allow
3124 peers to assert an identity to one another. This identity may be
3125 used for policy lookup, but does not necessarily have to match
3126 anything in the CERT payload; both fields may be used by an
3127 implementation to perform access control decisions.
3129 NOTE: In IKEv1, two ID payloads were used in each direction to hold
3130 Traffic Selector (TS) information for data passing over the SA. In
3131 IKEv2, this information is carried in TS payloads (see section 3.13).
3138 Kaufman Standards Track [Page 56]
3140 RFC 4306 IKEv2 December 2005
3143 The Identification Payload consists of the IKE generic payload header
3144 followed by identification fields as follows:
3147 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
3148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3149 ! Next Payload !C! RESERVED ! Payload Length !
3150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3151 ! ID Type ! RESERVED |
3152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3154 ~ Identification Data ~
3156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3158 Figure 11: Identification Payload Format
3160 o ID Type (1 octet) - Specifies the type of Identification being
3163 o RESERVED - MUST be sent as zero; MUST be ignored on receipt.
3165 o Identification Data (variable length) - Value, as indicated by the
3166 Identification Type. The length of the Identification Data is
3167 computed from the size in the ID payload header.
3169 The payload types for the Identification Payload are thirty five (35)
3170 for IDi and thirty six (36) for IDr.
3172 The following table lists the assigned values for the Identification
3173 Type field, followed by a description of the Identification Data
3182 A single four (4) octet IPv4 address.
3186 A fully-qualified domain name string. An example of a
3187 ID_FQDN is, "example.com". The string MUST not contain any
3188 terminators (e.g., NULL, CR, etc.).
3194 Kaufman Standards Track [Page 57]
3196 RFC 4306 IKEv2 December 2005
3201 A fully-qualified RFC822 email address string, An example of
3202 a ID_RFC822_ADDR is, "jsmith@example.com". The string MUST
3203 not contain any terminators.
3209 A single sixteen (16) octet IPv6 address.
3211 Reserved to IANA 6 - 8
3215 The binary Distinguished Encoding Rules (DER) encoding of an
3216 ASN.1 X.500 Distinguished Name [X.501].
3220 The binary DER encoding of an ASN.1 X.500 GeneralName
3225 An opaque octet stream which may be used to pass vendor-
3226 specific information necessary to do certain proprietary
3227 types of identification.
3229 Reserved to IANA 12-200
3231 Reserved for private use 201-255
3233 Two implementations will interoperate only if each can generate a
3234 type of ID acceptable to the other. To assure maximum
3235 interoperability, implementations MUST be configurable to send at
3236 least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and
3237 MUST be configurable to accept all of these types. Implementations
3238 SHOULD be capable of generating and accepting all of these types.
3239 IPv6-capable implementations MUST additionally be configurable to
3240 accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable
3241 to send only ID_IPV6_ADDR.
3250 Kaufman Standards Track [Page 58]
3252 RFC 4306 IKEv2 December 2005
3255 3.6. Certificate Payload
3257 The Certificate Payload, denoted CERT in this memo, provides a means
3258 to transport certificates or other authentication-related information
3259 via IKE. Certificate payloads SHOULD be included in an exchange if
3260 certificates are available to the sender unless the peer has
3261 indicated an ability to retrieve this information from elsewhere
3262 using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the
3263 term "Certificate Payload" is somewhat misleading, because not all
3264 authentication mechanisms use certificates and data other than
3265 certificates may be passed in this payload.
3267 The Certificate Payload is defined as follows:
3270 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
3271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3272 ! Next Payload !C! RESERVED ! Payload Length !
3273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3276 ~ Certificate Data ~
3278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3280 Figure 12: Certificate Payload Format
3282 o Certificate Encoding (1 octet) - This field indicates the type
3283 of certificate or certificate-related information contained in
3284 the Certificate Data field.
3286 Certificate Encoding Value
3287 -------------------- -----
3289 PKCS #7 wrapped X.509 certificate 1
3292 X.509 Certificate - Signature 4
3294 Certificate Revocation List (CRL) 7
3295 Authority Revocation List (ARL) 8
3297 X.509 Certificate - Attribute 10
3299 Hash and URL of X.509 certificate 12
3300 Hash and URL of X.509 bundle 13
3301 RESERVED to IANA 14 - 200
3302 PRIVATE USE 201 - 255
3306 Kaufman Standards Track [Page 59]
3308 RFC 4306 IKEv2 December 2005
3311 o Certificate Data (variable length) - Actual encoding of
3312 certificate data. The type of certificate is indicated by the
3313 Certificate Encoding field.
3315 The payload type for the Certificate Payload is thirty seven (37).
3317 Specific syntax is for some of the certificate type codes above is
3318 not defined in this document. The types whose syntax is defined in
3321 X.509 Certificate - Signature (4) contains a DER encoded X.509
3322 certificate whose public key is used to validate the sender's AUTH
3325 Certificate Revocation List (7) contains a DER encoded X.509
3326 certificate revocation list.
3328 Raw RSA Key (11) contains a PKCS #1 encoded RSA key (see [RSA] and
3331 Hash and URL encodings (12-13) allow IKE messages to remain short
3332 by replacing long data structures with a 20 octet SHA-1 hash (see
3333 [SHA]) of the replaced value followed by a variable-length URL
3334 that resolves to the DER encoded data structure itself. This
3335 improves efficiency when the endpoints have certificate data
3336 cached and makes IKE less subject to denial of service attacks
3337 that become easier to mount when IKE messages are large enough to
3338 require IP fragmentation [KPS03].
3340 Use the following ASN.1 definition for an X.509 bundle:
3343 { iso(1) identified-organization(3) dod(6) internet(1)
3344 security(5) mechanisms(5) pkix(7) id-mod(0)
3345 id-mod-cert-bundle(34) }
3347 DEFINITIONS EXPLICIT TAGS ::=
3351 Certificate, CertificateList
3352 FROM PKIX1Explicit88
3353 { iso(1) identified-organization(3) dod(6)
3354 internet(1) security(5) mechanisms(5) pkix(7)
3355 id-mod(0) id-pkix1-explicit(18) } ;
3362 Kaufman Standards Track [Page 60]
3364 RFC 4306 IKEv2 December 2005
3367 CertificateOrCRL ::= CHOICE {
3368 cert [0] Certificate,
3369 crl [1] CertificateList }
3371 CertificateBundle ::= SEQUENCE OF CertificateOrCRL
3375 Implementations MUST be capable of being configured to send and
3376 accept up to four X.509 certificates in support of authentication,
3377 and also MUST be capable of being configured to send and accept the
3378 first two Hash and URL formats (with HTTP URLs). Implementations
3379 SHOULD be capable of being configured to send and accept Raw RSA
3380 keys. If multiple certificates are sent, the first certificate MUST
3381 contain the public key used to sign the AUTH payload. The other
3382 certificates may be sent in any order.
3384 3.7. Certificate Request Payload
3386 The Certificate Request Payload, denoted CERTREQ in this memo,
3387 provides a means to request preferred certificates via IKE and can
3388 appear in the IKE_INIT_SA response and/or the IKE_AUTH request.
3389 Certificate Request payloads MAY be included in an exchange when the
3390 sender needs to get the certificate of the receiver. If multiple CAs
3391 are trusted and the cert encoding does not allow a list, then
3392 multiple Certificate Request payloads SHOULD be transmitted.
3394 The Certificate Request Payload is defined as follows:
3397 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
3398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3399 ! Next Payload !C! RESERVED ! Payload Length !
3400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3403 ~ Certification Authority ~
3405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3407 Figure 13: Certificate Request Payload Format
3409 o Certificate Encoding (1 octet) - Contains an encoding of the type
3410 or format of certificate requested. Values are listed in section
3418 Kaufman Standards Track [Page 61]
3420 RFC 4306 IKEv2 December 2005
3423 o Certification Authority (variable length) - Contains an encoding
3424 of an acceptable certification authority for the type of
3425 certificate requested.
3427 The payload type for the Certificate Request Payload is thirty eight
3430 The Certificate Encoding field has the same values as those defined
3431 in section 3.6. The Certification Authority field contains an
3432 indicator of trusted authorities for this certificate type. The
3433 Certification Authority value is a concatenated list of SHA-1 hashes
3434 of the public keys of trusted Certification Authorities (CAs). Each
3435 is encoded as the SHA-1 hash of the Subject Public Key Info element
3436 (see section 4.1.2.7 of [RFC3280]) from each Trust Anchor
3437 certificate. The twenty-octet hashes are concatenated and included
3438 with no other formatting.
3440 Note that the term "Certificate Request" is somewhat misleading, in
3441 that values other than certificates are defined in a "Certificate"
3442 payload and requests for those values can be present in a Certificate
3443 Request Payload. The syntax of the Certificate Request payload in
3444 such cases is not defined in this document.
3446 The Certificate Request Payload is processed by inspecting the "Cert
3447 Encoding" field to determine whether the processor has any
3448 certificates of this type. If so, the "Certification Authority"
3449 field is inspected to determine if the processor has any certificates
3450 that can be validated up to one of the specified certification
3451 authorities. This can be a chain of certificates.
3453 If an end-entity certificate exists that satisfies the criteria
3454 specified in the CERTREQ, a certificate or certificate chain SHOULD
3455 be sent back to the certificate requestor if the recipient of the
3458 - is configured to use certificate authentication,
3460 - is allowed to send a CERT payload,
3462 - has matching CA trust policy governing the current negotiation, and
3464 - has at least one time-wise and usage appropriate end-entity
3465 certificate chaining to a CA provided in the CERTREQ.
3467 Certificate revocation checking must be considered during the
3468 chaining process used to select a certificate. Note that even if two
3469 peers are configured to use two different CAs, cross-certification
3470 relationships should be supported by appropriate selection logic.
3474 Kaufman Standards Track [Page 62]
3476 RFC 4306 IKEv2 December 2005
3479 The intent is not to prevent communication through the strict
3480 adherence of selection of a certificate based on CERTREQ, when an
3481 alternate certificate could be selected by the sender that would
3482 still enable the recipient to successfully validate and trust it
3483 through trust conveyed by cross-certification, CRLs, or other out-
3484 of-band configured means. Thus, the processing of a CERTREQ should
3485 be seen as a suggestion for a certificate to select, not a mandated
3486 one. If no certificates exist, then the CERTREQ is ignored. This is
3487 not an error condition of the protocol. There may be cases where
3488 there is a preferred CA sent in the CERTREQ, but an alternate might
3489 be acceptable (perhaps after prompting a human operator).
3491 3.8. Authentication Payload
3493 The Authentication Payload, denoted AUTH in this memo, contains data
3494 used for authentication purposes. The syntax of the Authentication
3495 data varies according to the Auth Method as specified below.
3497 The Authentication Payload is defined as follows:
3500 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
3501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3502 ! Next Payload !C! RESERVED ! Payload Length !
3503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3504 ! Auth Method ! RESERVED !
3505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3507 ~ Authentication Data ~
3509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3511 Figure 14: Authentication Payload Format
3513 o Auth Method (1 octet) - Specifies the method of authentication
3514 used. Values defined are:
3516 RSA Digital Signature (1) - Computed as specified in section
3517 2.15 using an RSA private key over a PKCS#1 padded hash (see
3520 Shared Key Message Integrity Code (2) - Computed as specified in
3521 section 2.15 using the shared key associated with the identity
3522 in the ID payload and the negotiated prf function
3524 DSS Digital Signature (3) - Computed as specified in section
3525 2.15 using a DSS private key (see [DSS]) over a SHA-1 hash.
3530 Kaufman Standards Track [Page 63]
3532 RFC 4306 IKEv2 December 2005
3535 The values 0 and 4-200 are reserved to IANA. The values 201-255
3536 are available for private use.
3538 o Authentication Data (variable length) - see section 2.15.
3540 The payload type for the Authentication Payload is thirty nine (39).
3544 The Nonce Payload, denoted Ni and Nr in this memo for the initiator's
3545 and responder's nonce respectively, contains random data used to
3546 guarantee liveness during an exchange and protect against replay
3549 The Nonce Payload is defined as follows:
3552 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
3553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3554 ! Next Payload !C! RESERVED ! Payload Length !
3555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3561 Figure 15: Nonce Payload Format
3563 o Nonce Data (variable length) - Contains the random data generated
3564 by the transmitting entity.
3566 The payload type for the Nonce Payload is forty (40).
3568 The size of a Nonce MUST be between 16 and 256 octets inclusive.
3569 Nonce values MUST NOT be reused.
3571 3.10. Notify Payload
3573 The Notify Payload, denoted N in this document, is used to transmit
3574 informational data, such as error conditions and state transitions,
3575 to an IKE peer. A Notify Payload may appear in a response message
3576 (usually specifying why a request was rejected), in an INFORMATIONAL
3577 Exchange (to report an error not in an IKE request), or in any other
3578 message to indicate sender capabilities or to modify the meaning of
3586 Kaufman Standards Track [Page 64]
3588 RFC 4306 IKEv2 December 2005
3591 The Notify Payload is defined as follows:
3594 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
3595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3596 ! Next Payload !C! RESERVED ! Payload Length !
3597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3598 ! Protocol ID ! SPI Size ! Notify Message Type !
3599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3601 ~ Security Parameter Index (SPI) ~
3603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3605 ~ Notification Data ~
3607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3609 Figure 16: Notify Payload Format
3611 o Protocol ID (1 octet) - If this notification concerns an existing
3612 SA, this field indicates the type of that SA. For IKE_SA
3613 notifications, this field MUST be one (1). For notifications
3614 concerning IPsec SAs this field MUST contain either (2) to
3615 indicate AH or (3) to indicate ESP. For notifications that do not
3616 relate to an existing SA, this field MUST be sent as zero and MUST
3617 be ignored on receipt. All other values for this field are
3618 reserved to IANA for future assignment.
3620 o SPI Size (1 octet) - Length in octets of the SPI as defined by the
3621 IPsec protocol ID or zero if no SPI is applicable. For a
3622 notification concerning the IKE_SA, the SPI Size MUST be zero.
3624 o Notify Message Type (2 octets) - Specifies the type of
3625 notification message.
3627 o SPI (variable length) - Security Parameter Index.
3629 o Notification Data (variable length) - Informational or error data
3630 transmitted in addition to the Notify Message Type. Values for
3631 this field are type specific (see below).
3633 The payload type for the Notify Payload is forty one (41).
3642 Kaufman Standards Track [Page 65]
3644 RFC 4306 IKEv2 December 2005
3647 3.10.1. Notify Message Types
3649 Notification information can be error messages specifying why an SA
3650 could not be established. It can also be status data that a process
3651 managing an SA database wishes to communicate with a peer process.
3652 The table below lists the Notification messages and their
3653 corresponding values. The number of different error statuses was
3654 greatly reduced from IKEv1 both for simplification and to avoid
3655 giving configuration information to probers.
3657 Types in the range 0 - 16383 are intended for reporting errors. An
3658 implementation receiving a Notify payload with one of these types
3659 that it does not recognize in a response MUST assume that the
3660 corresponding request has failed entirely. Unrecognized error types
3661 in a request and status types in a request or response MUST be
3662 ignored except that they SHOULD be logged.
3664 Notify payloads with status types MAY be added to any message and
3665 MUST be ignored if not recognized. They are intended to indicate
3666 capabilities, and as part of SA negotiation are used to negotiate
3667 non-cryptographic parameters.
3669 NOTIFY MESSAGES - ERROR TYPES Value
3670 ----------------------------- -----
3673 UNSUPPORTED_CRITICAL_PAYLOAD 1
3675 Sent if the payload has the "critical" bit set and the
3676 payload type is not recognized. Notification Data contains
3677 the one-octet payload type.
3681 Indicates an IKE message was received with an unrecognized
3682 destination SPI. This usually indicates that the recipient
3683 has rebooted and forgotten the existence of an IKE_SA.
3685 INVALID_MAJOR_VERSION 5
3687 Indicates the recipient cannot handle the version of IKE
3688 specified in the header. The closest version number that
3689 the recipient can support will be in the reply header.
3693 Indicates the IKE message that was received was invalid
3694 because some type, length, or value was out of range or
3698 Kaufman Standards Track [Page 66]
3700 RFC 4306 IKEv2 December 2005
3703 because the request was rejected for policy reasons. To
3704 avoid a denial of service attack using forged messages, this
3705 status may only be returned for and in an encrypted packet
3706 if the message ID and cryptographic checksum were valid. To
3707 avoid leaking information to someone probing a node, this
3708 status MUST be sent in response to any error not covered by
3709 one of the other status types. To aid debugging, more
3710 detailed error information SHOULD be written to a console or
3713 INVALID_MESSAGE_ID 9
3715 Sent when an IKE message ID outside the supported window is
3716 received. This Notify MUST NOT be sent in a response; the
3717 invalid request MUST NOT be acknowledged. Instead, inform
3718 the other side by initiating an INFORMATIONAL exchange with
3719 Notification data containing the four octet invalid message
3720 ID. Sending this notification is optional, and
3721 notifications of this type MUST be rate limited.
3725 MAY be sent in an IKE INFORMATIONAL exchange when a node
3726 receives an ESP or AH packet with an invalid SPI. The
3727 Notification Data contains the SPI of the invalid packet.
3728 This usually indicates a node has rebooted and forgotten an
3729 SA. If this Informational Message is sent outside the
3730 context of an IKE_SA, it should be used by the recipient
3731 only as a "hint" that something might be wrong (because it
3732 could easily be forged).
3734 NO_PROPOSAL_CHOSEN 14
3736 None of the proposed crypto suites was acceptable.
3738 INVALID_KE_PAYLOAD 17
3740 The D-H Group # field in the KE payload is not the group #
3741 selected by the responder for this exchange. There are two
3742 octets of data associated with this notification: the
3743 accepted D-H Group # in big endian order.
3745 AUTHENTICATION_FAILED 24
3747 Sent in the response to an IKE_AUTH message when for some
3748 reason the authentication failed. There is no associated
3754 Kaufman Standards Track [Page 67]
3756 RFC 4306 IKEv2 December 2005
3759 SINGLE_PAIR_REQUIRED 34
3761 This error indicates that a CREATE_CHILD_SA request is
3762 unacceptable because its sender is only willing to accept
3763 traffic selectors specifying a single pair of addresses. The
3764 requestor is expected to respond by requesting an SA for only
3765 the specific traffic it is trying to forward.
3767 NO_ADDITIONAL_SAS 35
3769 This error indicates that a CREATE_CHILD_SA request is
3770 unacceptable because the responder is unwilling to accept any
3771 more CHILD_SAs on this IKE_SA. Some minimal implementations may
3772 only accept a single CHILD_SA setup in the context of an initial
3773 IKE exchange and reject any subsequent attempts to add more.
3775 INTERNAL_ADDRESS_FAILURE 36
3777 Indicates an error assigning an internal address (i.e.,
3778 INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the
3779 processing of a Configuration Payload by a responder. If this
3780 error is generated within an IKE_AUTH exchange, no CHILD_SA will
3783 FAILED_CP_REQUIRED 37
3785 Sent by responder in the case where CP(CFG_REQUEST) was expected
3786 but not received, and so is a conflict with locally configured
3787 policy. There is no associated data.
3791 Indicates that none of the addresses/protocols/ports in the
3792 supplied traffic selectors is acceptable.
3794 INVALID_SELECTORS 39
3796 MAY be sent in an IKE INFORMATIONAL exchange when a node
3797 receives an ESP or AH packet whose selectors do not match
3798 those of the SA on which it was delivered (and that caused
3799 the packet to be dropped). The Notification Data contains
3800 the start of the offending packet (as in ICMP messages) and
3801 the SPI field of the notification is set to match the SPI of
3804 RESERVED TO IANA - Error types 40 - 8191
3806 Private Use - Errors 8192 - 16383
3810 Kaufman Standards Track [Page 68]
3812 RFC 4306 IKEv2 December 2005
3815 NOTIFY MESSAGES - STATUS TYPES Value
3816 ------------------------------ -----
3818 INITIAL_CONTACT 16384
3820 This notification asserts that this IKE_SA is the only
3821 IKE_SA currently active between the authenticated
3822 identities. It MAY be sent when an IKE_SA is established
3823 after a crash, and the recipient MAY use this information to
3824 delete any other IKE_SAs it has to the same authenticated
3825 identity without waiting for a timeout. This notification
3826 MUST NOT be sent by an entity that may be replicated (e.g.,
3827 a roaming user's credentials where the user is allowed to
3828 connect to the corporate firewall from two remote systems at
3831 SET_WINDOW_SIZE 16385
3833 This notification asserts that the sending endpoint is
3834 capable of keeping state for multiple outstanding exchanges,
3835 permitting the recipient to send multiple requests before
3836 getting a response to the first. The data associated with a
3837 SET_WINDOW_SIZE notification MUST be 4 octets long and
3838 contain the big endian representation of the number of
3839 messages the sender promises to keep. Window size is always
3840 one until the initial exchanges complete.
3842 ADDITIONAL_TS_POSSIBLE 16386
3844 This notification asserts that the sending endpoint narrowed
3845 the proposed traffic selectors but that other traffic
3846 selectors would also have been acceptable, though only in a
3847 separate SA (see section 2.9). There is no data associated
3848 with this Notify type. It may be sent only as an additional
3849 payload in a message including accepted TSs.
3851 IPCOMP_SUPPORTED 16387
3853 This notification may be included only in a message
3854 containing an SA payload negotiating a CHILD_SA and
3855 indicates a willingness by its sender to use IPComp on this
3856 SA. The data associated with this notification includes a
3857 two-octet IPComp CPI followed by a one-octet transform ID
3858 optionally followed by attributes whose length and format
3859 are defined by that transform ID. A message proposing an SA
3860 may contain multiple IPCOMP_SUPPORTED notifications to
3861 indicate multiple supported algorithms. A message accepting
3862 an SA may contain at most one.
3866 Kaufman Standards Track [Page 69]
3868 RFC 4306 IKEv2 December 2005
3871 The transform IDs currently defined are:
3873 NAME NUMBER DEFINED IN
3874 ----------- ------ -----------
3877 IPCOMP_DEFLATE 2 RFC 2394
3878 IPCOMP_LZS 3 RFC 2395
3879 IPCOMP_LZJH 4 RFC 3051
3881 values 5-240 are reserved to IANA. Values 241-255 are
3882 for private use among mutually consenting parties.
3884 NAT_DETECTION_SOURCE_IP 16388
3886 This notification is used by its recipient to determine
3887 whether the source is behind a NAT box. The data associated
3888 with this notification is a SHA-1 digest of the SPIs (in the
3889 order they appear in the header), IP address, and port on
3890 which this packet was sent. There MAY be multiple Notify
3891 payloads of this type in a message if the sender does not
3892 know which of several network attachments will be used to
3893 send the packet. The recipient of this notification MAY
3894 compare the supplied value to a SHA-1 hash of the SPIs,
3895 source IP address, and port, and if they don't match it
3896 SHOULD enable NAT traversal (see section 2.23).
3897 Alternately, it MAY reject the connection attempt if NAT
3898 traversal is not supported.
3900 NAT_DETECTION_DESTINATION_IP 16389
3902 This notification is used by its recipient to determine
3903 whether it is behind a NAT box. The data associated with
3904 this notification is a SHA-1 digest of the SPIs (in the
3905 order they appear in the header), IP address, and port to
3906 which this packet was sent. The recipient of this
3907 notification MAY compare the supplied value to a hash of the
3908 SPIs, destination IP address, and port, and if they don't
3909 match it SHOULD invoke NAT traversal (see section 2.23). If
3910 they don't match, it means that this end is behind a NAT and
3911 this end SHOULD start sending keepalive packets as defined
3912 in [Hutt05]. Alternately, it MAY reject the connection
3913 attempt if NAT traversal is not supported.
3922 Kaufman Standards Track [Page 70]
3924 RFC 4306 IKEv2 December 2005
3929 This notification MAY be included in an IKE_SA_INIT
3930 response. It indicates that the request should be retried
3931 with a copy of this notification as the first payload. This
3932 notification MUST be included in an IKE_SA_INIT request
3933 retry if a COOKIE notification was included in the initial
3934 response. The data associated with this notification MUST
3935 be between 1 and 64 octets in length (inclusive).
3937 USE_TRANSPORT_MODE 16391
3939 This notification MAY be included in a request message that
3940 also includes an SA payload requesting a CHILD_SA. It
3941 requests that the CHILD_SA use transport mode rather than
3942 tunnel mode for the SA created. If the request is accepted,
3943 the response MUST also include a notification of type
3944 USE_TRANSPORT_MODE. If the responder declines the request,
3945 the CHILD_SA will be established in tunnel mode. If this is
3946 unacceptable to the initiator, the initiator MUST delete the
3947 SA. Note: Except when using this option to negotiate
3948 transport mode, all CHILD_SAs will use tunnel mode.
3950 Note: The ECN decapsulation modifications specified in
3951 [RFC4301] MUST be performed for every tunnel mode SA created
3954 HTTP_CERT_LOOKUP_SUPPORTED 16392
3956 This notification MAY be included in any message that can
3957 include a CERTREQ payload and indicates that the sender is
3958 capable of looking up certificates based on an HTTP-based
3959 URL (and hence presumably would prefer to receive
3960 certificate specifications in that format).
3964 This notification MUST be included in a CREATE_CHILD_SA
3965 exchange if the purpose of the exchange is to replace an
3966 existing ESP or AH SA. The SPI field identifies the SA
3967 being rekeyed. There is no data.
3969 ESP_TFC_PADDING_NOT_SUPPORTED 16394
3971 This notification asserts that the sending endpoint will NOT
3972 accept packets that contain Flow Confidentiality (TFC)
3978 Kaufman Standards Track [Page 71]
3980 RFC 4306 IKEv2 December 2005
3983 NON_FIRST_FRAGMENTS_ALSO 16395
3985 Used for fragmentation control. See [RFC4301] for
3988 RESERVED TO IANA - STATUS TYPES 16396 - 40959
3990 Private Use - STATUS TYPES 40960 - 65535
3992 3.11. Delete Payload
3994 The Delete Payload, denoted D in this memo, contains a protocol-
3995 specific security association identifier that the sender has removed
3996 from its security association database and is, therefore, no longer
3997 valid. Figure 17 shows the format of the Delete Payload. It is
3998 possible to send multiple SPIs in a Delete payload; however, each SPI
3999 MUST be for the same protocol. Mixing of protocol identifiers MUST
4000 NOT be performed in a Delete payload. It is permitted, however, to
4001 include multiple Delete payloads in a single INFORMATIONAL exchange
4002 where each Delete payload lists SPIs for a different protocol.
4004 Deletion of the IKE_SA is indicated by a protocol ID of 1 (IKE) but
4005 no SPIs. Deletion of a CHILD_SA, such as ESP or AH, will contain the
4006 IPsec protocol ID of that protocol (2 for AH, 3 for ESP), and the SPI
4007 is the SPI the sending endpoint would expect in inbound ESP or AH
4010 The Delete Payload is defined as follows:
4013 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
4014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4015 ! Next Payload !C! RESERVED ! Payload Length !
4016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4017 ! Protocol ID ! SPI Size ! # of SPIs !
4018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4020 ~ Security Parameter Index(es) (SPI) ~
4022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4024 Figure 17: Delete Payload Format
4026 o Protocol ID (1 octet) - Must be 1 for an IKE_SA, 2 for AH, or 3
4034 Kaufman Standards Track [Page 72]
4036 RFC 4306 IKEv2 December 2005
4039 o SPI Size (1 octet) - Length in octets of the SPI as defined by the
4040 protocol ID. It MUST be zero for IKE (SPI is in message header)
4041 or four for AH and ESP.
4043 o # of SPIs (2 octets) - The number of SPIs contained in the Delete
4044 payload. The size of each SPI is defined by the SPI Size field.
4046 o Security Parameter Index(es) (variable length) - Identifies the
4047 specific security association(s) to delete. The length of this
4048 field is determined by the SPI Size and # of SPIs fields.
4050 The payload type for the Delete Payload is forty two (42).
4052 3.12. Vendor ID Payload
4054 The Vendor ID Payload, denoted V in this memo, contains a vendor
4055 defined constant. The constant is used by vendors to identify and
4056 recognize remote instances of their implementations. This mechanism
4057 allows a vendor to experiment with new features while maintaining
4058 backward compatibility.
4060 A Vendor ID payload MAY announce that the sender is capable to
4061 accepting certain extensions to the protocol, or it MAY simply
4062 identify the implementation as an aid in debugging. A Vendor ID
4063 payload MUST NOT change the interpretation of any information defined
4064 in this specification (i.e., the critical bit MUST be set to 0).
4065 Multiple Vendor ID payloads MAY be sent. An implementation is NOT
4066 REQUIRED to send any Vendor ID payload at all.
4068 A Vendor ID payload may be sent as part of any message. Reception of
4069 a familiar Vendor ID payload allows an implementation to make use of
4070 Private USE numbers described throughout this memo -- private
4071 payloads, private exchanges, private notifications, etc. Unfamiliar
4072 Vendor IDs MUST be ignored.
4074 Writers of Internet-Drafts who wish to extend this protocol MUST
4075 define a Vendor ID payload to announce the ability to implement the
4076 extension in the Internet-Draft. It is expected that Internet-Drafts
4077 that gain acceptance and are standardized will be given "magic
4078 numbers" out of the Future Use range by IANA, and the requirement to
4079 use a Vendor ID will go away.
4090 Kaufman Standards Track [Page 73]
4092 RFC 4306 IKEv2 December 2005
4095 The Vendor ID Payload fields are defined as follows:
4098 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
4099 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4100 ! Next Payload !C! RESERVED ! Payload Length !
4101 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4107 Figure 18: Vendor ID Payload Format
4109 o Vendor ID (variable length) - It is the responsibility of the
4110 person choosing the Vendor ID to assure its uniqueness in spite of
4111 the absence of any central registry for IDs. Good practice is to
4112 include a company name, a person name, or some such. If you want
4113 to show off, you might include the latitude and longitude and time
4114 where you were when you chose the ID and some random input. A
4115 message digest of a long unique string is preferable to the long
4116 unique string itself.
4118 The payload type for the Vendor ID Payload is forty three (43).
4120 3.13. Traffic Selector Payload
4122 The Traffic Selector Payload, denoted TS in this memo, allows peers
4123 to identify packet flows for processing by IPsec security services.
4124 The Traffic Selector Payload consists of the IKE generic payload
4125 header followed by individual traffic selectors as follows:
4128 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
4129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4130 ! Next Payload !C! RESERVED ! Payload Length !
4131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4132 ! Number of TSs ! RESERVED !
4133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4135 ~ <Traffic Selectors> ~
4137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4139 Figure 19: Traffic Selectors Payload Format
4141 o Number of TSs (1 octet) - Number of traffic selectors being
4146 Kaufman Standards Track [Page 74]
4148 RFC 4306 IKEv2 December 2005
4151 o RESERVED - This field MUST be sent as zero and MUST be ignored on
4154 o Traffic Selectors (variable length) - One or more individual
4157 The length of the Traffic Selector payload includes the TS header and
4158 all the traffic selectors.
4160 The payload type for the Traffic Selector payload is forty four (44)
4161 for addresses at the initiator's end of the SA and forty five (45)
4162 for addresses at the responder's end.
4164 3.13.1. Traffic Selector
4167 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
4168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4169 ! TS Type !IP Protocol ID*| Selector Length |
4170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4171 | Start Port* | End Port* |
4172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4174 ~ Starting Address* ~
4176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4182 Figure 20: Traffic Selector
4184 * Note: All fields other than TS Type and Selector Length depend on
4185 the TS Type. The fields shown are for TS Types 7 and 8, the only two
4186 values currently defined.
4188 o TS Type (one octet) - Specifies the type of traffic selector.
4190 o IP protocol ID (1 octet) - Value specifying an associated IP
4191 protocol ID (e.g., UDP/TCP/ICMP). A value of zero means that the
4192 protocol ID is not relevant to this traffic selector -- the SA can
4193 carry all protocols.
4195 o Selector Length - Specifies the length of this Traffic Selector
4196 Substructure including the header.
4202 Kaufman Standards Track [Page 75]
4204 RFC 4306 IKEv2 December 2005
4207 o Start Port (2 octets) - Value specifying the smallest port number
4208 allowed by this Traffic Selector. For protocols for which port is
4209 undefined, or if all ports are allowed, this field MUST be zero.
4210 For the ICMP protocol, the two one-octet fields Type and Code are
4211 treated as a single 16-bit integer (with Type in the most
4212 significant eight bits and Code in the least significant eight
4213 bits) port number for the purposes of filtering based on this
4216 o End Port (2 octets) - Value specifying the largest port number
4217 allowed by this Traffic Selector. For protocols for which port is
4218 undefined, or if all ports are allowed, this field MUST be 65535.
4219 For the ICMP protocol, the two one-octet fields Type and Code are
4220 treated as a single 16-bit integer (with Type in the most
4221 significant eight bits and Code in the least significant eight
4222 bits) port number for the purposed of filtering based on this
4225 o Starting Address - The smallest address included in this Traffic
4226 Selector (length determined by TS type).
4228 o Ending Address - The largest address included in this Traffic
4229 Selector (length determined by TS type).
4231 Systems that are complying with [RFC4301] that wish to indicate "ANY"
4232 ports MUST set the start port to 0 and the end port to 65535; note
4233 that according to [RFC4301], "ANY" includes "OPAQUE". Systems
4234 working with [RFC4301] that wish to indicate "OPAQUE" ports, but not
4235 "ANY" ports, MUST set the start port to 65535 and the end port to 0.
4237 The following table lists the assigned values for the Traffic
4238 Selector Type field and the corresponding Address Selector Data.
4244 TS_IPV4_ADDR_RANGE 7
4246 A range of IPv4 addresses, represented by two four-octet
4247 values. The first value is the beginning IPv4 address
4248 (inclusive) and the second value is the ending IPv4 address
4249 (inclusive). All addresses falling between the two
4250 specified addresses are considered to be within the list.
4258 Kaufman Standards Track [Page 76]
4260 RFC 4306 IKEv2 December 2005
4263 TS_IPV6_ADDR_RANGE 8
4265 A range of IPv6 addresses, represented by two sixteen-octet
4266 values. The first value is the beginning IPv6 address
4267 (inclusive) and the second value is the ending IPv6 address
4268 (inclusive). All addresses falling between the two
4269 specified addresses are considered to be within the list.
4271 RESERVED TO IANA 9-240
4274 3.14. Encrypted Payload
4276 The Encrypted Payload, denoted SK{...} or E in this memo, contains
4277 other payloads in encrypted form. The Encrypted Payload, if present
4278 in a message, MUST be the last payload in the message. Often, it is
4279 the only payload in the message.
4281 The algorithms for encryption and integrity protection are negotiated
4282 during IKE_SA setup, and the keys are computed as specified in
4283 sections 2.14 and 2.18.
4285 The encryption and integrity protection algorithms are modeled after
4286 the ESP algorithms described in RFCs 2104 [KBC96], 4303 [RFC4303],
4287 and 2451 [ESPCBC]. This document completely specifies the
4288 cryptographic processing of IKE data, but those documents should be
4289 consulted for design rationale. We require a block cipher with a
4290 fixed block size and an integrity check algorithm that computes a
4291 fixed-length checksum over a variable size message.
4293 The payload type for an Encrypted payload is forty six (46). The
4294 Encrypted Payload consists of the IKE generic payload header followed
4295 by individual fields as follows:
4314 Kaufman Standards Track [Page 77]
4316 RFC 4306 IKEv2 December 2005
4320 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
4321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4322 ! Next Payload !C! RESERVED ! Payload Length !
4323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4324 ! Initialization Vector !
4325 ! (length is block size for encryption algorithm) !
4326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4327 ~ Encrypted IKE Payloads ~
4328 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4329 ! ! Padding (0-255 octets) !
4330 +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
4332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4333 ~ Integrity Checksum Data ~
4334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4336 Figure 21: Encrypted Payload Format
4338 o Next Payload - The payload type of the first embedded payload.
4339 Note that this is an exception in the standard header format,
4340 since the Encrypted payload is the last payload in the message and
4341 therefore the Next Payload field would normally be zero. But
4342 because the content of this payload is embedded payloads and there
4343 was no natural place to put the type of the first one, that type
4346 o Payload Length - Includes the lengths of the header, IV, Encrypted
4347 IKE Payloads, Padding, Pad Length, and Integrity Checksum Data.
4349 o Initialization Vector - A randomly chosen value whose length is
4350 equal to the block length of the underlying encryption algorithm.
4351 Recipients MUST accept any value. Senders SHOULD either pick this
4352 value pseudo-randomly and independently for each message or use
4353 the final ciphertext block of the previous message sent. Senders
4354 MUST NOT use the same value for each message, use a sequence of
4355 values with low hamming distance (e.g., a sequence number), or use
4356 ciphertext from a received message.
4358 o IKE Payloads are as specified earlier in this section. This field
4359 is encrypted with the negotiated cipher.
4361 o Padding MAY contain any value chosen by the sender, and MUST have
4362 a length that makes the combination of the Payloads, the Padding,
4363 and the Pad Length to be a multiple of the encryption block size.
4364 This field is encrypted with the negotiated cipher.
4370 Kaufman Standards Track [Page 78]
4372 RFC 4306 IKEv2 December 2005
4375 o Pad Length is the length of the Padding field. The sender SHOULD
4376 set the Pad Length to the minimum value that makes the combination
4377 of the Payloads, the Padding, and the Pad Length a multiple of the
4378 block size, but the recipient MUST accept any length that results
4379 in proper alignment. This field is encrypted with the negotiated
4382 o Integrity Checksum Data is the cryptographic checksum of the
4383 entire message starting with the Fixed IKE Header through the Pad
4384 Length. The checksum MUST be computed over the encrypted message.
4385 Its length is determined by the integrity algorithm negotiated.
4387 3.15. Configuration Payload
4389 The Configuration payload, denoted CP in this document, is used to
4390 exchange configuration information between IKE peers. The exchange
4391 is for an IRAC to request an internal IP address from an IRAS and to
4392 exchange other information of the sort that one would acquire with
4393 Dynamic Host Configuration Protocol (DHCP) if the IRAC were directly
4396 Configuration payloads are of type CFG_REQUEST/CFG_REPLY or
4397 CFG_SET/CFG_ACK (see CFG Type in the payload description below).
4398 CFG_REQUEST and CFG_SET payloads may optionally be added to any IKE
4399 request. The IKE response MUST include either a corresponding
4400 CFG_REPLY or CFG_ACK or a Notify payload with an error type
4401 indicating why the request could not be honored. An exception is
4402 that a minimal implementation MAY ignore all CFG_REQUEST and CFG_SET
4403 payloads, so a response message without a corresponding CFG_REPLY or
4404 CFG_ACK MUST be accepted as an indication that the request was not
4407 "CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information
4408 from its peer. If an attribute in the CFG_REQUEST Configuration
4409 Payload is not zero-length, it is taken as a suggestion for that
4410 attribute. The CFG_REPLY Configuration Payload MAY return that
4411 value, or a new one. It MAY also add new attributes and not include
4412 some requested ones. Requestors MUST ignore returned attributes that
4413 they do not recognize.
4415 Some attributes MAY be multi-valued, in which case multiple attribute
4416 values of the same type are sent and/or returned. Generally, all
4417 values of an attribute are returned when the attribute is requested.
4418 For some attributes (in this version of the specification only
4419 internal addresses), multiple requests indicates a request that
4420 multiple values be assigned. For these attributes, the number of
4421 values returned SHOULD NOT exceed the number requested.
4426 Kaufman Standards Track [Page 79]
4428 RFC 4306 IKEv2 December 2005
4431 If the data type requested in a CFG_REQUEST is not recognized or not
4432 supported, the responder MUST NOT return an error type but rather
4433 MUST either send a CFG_REPLY that MAY be empty or a reply not
4434 containing a CFG_REPLY payload at all. Error returns are reserved
4435 for cases where the request is recognized but cannot be performed as
4436 requested or the request is badly formatted.
4438 "CFG_SET/CFG_ACK" allows an IKE endpoint to push configuration data
4439 to its peer. In this case, the CFG_SET Configuration Payload
4440 contains attributes the initiator wants its peer to alter. The
4441 responder MUST return a Configuration Payload if it accepted any of
4442 the configuration data and it MUST contain the attributes that the
4443 responder accepted with zero-length data. Those attributes that it
4444 did not accept MUST NOT be in the CFG_ACK Configuration Payload. If
4445 no attributes were accepted, the responder MUST return either an
4446 empty CFG_ACK payload or a response message without a CFG_ACK
4447 payload. There are currently no defined uses for the CFG_SET/CFG_ACK
4448 exchange, though they may be used in connection with extensions based
4449 on Vendor IDs. An minimal implementation of this specification MAY
4450 ignore CFG_SET payloads.
4452 Extensions via the CP payload SHOULD NOT be used for general purpose
4453 management. Its main intent is to provide a bootstrap mechanism to
4454 exchange information within IPsec from IRAS to IRAC. While it MAY be
4455 useful to use such a method to exchange information between some
4456 Security Gateways (SGW) or small networks, existing management
4457 protocols such as DHCP [DHCP], RADIUS [RADIUS], SNMP, or LDAP [LDAP]
4458 should be preferred for enterprise management as well as subsequent
4459 information exchanges.
4461 The Configuration Payload is defined as follows:
4464 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
4465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4466 ! Next Payload !C! RESERVED ! Payload Length !
4467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4468 ! CFG Type ! RESERVED !
4469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4471 ~ Configuration Attributes ~
4473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4475 Figure 22: Configuration Payload Format
4477 The payload type for the Configuration Payload is forty seven (47).
4482 Kaufman Standards Track [Page 80]
4484 RFC 4306 IKEv2 December 2005
4487 o CFG Type (1 octet) - The type of exchange represented by the
4488 Configuration Attributes.
4498 values 5-127 are reserved to IANA. Values 128-255 are for private
4499 use among mutually consenting parties.
4501 o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on
4504 o Configuration Attributes (variable length) - These are type length
4505 values specific to the Configuration Payload and are defined
4506 below. There may be zero or more Configuration Attributes in this
4509 3.15.1. Configuration Attributes
4512 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
4513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4514 !R| Attribute Type ! Length |
4515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4521 Figure 23: Configuration Attribute Format
4523 o Reserved (1 bit) - This bit MUST be set to zero and MUST be
4526 o Attribute Type (15 bits) - A unique identifier for each of the
4527 Configuration Attribute Types.
4529 o Length (2 octets) - Length in octets of Value.
4531 o Value (0 or more octets) - The variable-length value of this
4532 Configuration Attribute.
4538 Kaufman Standards Track [Page 81]
4540 RFC 4306 IKEv2 December 2005
4543 The following attribute types have been defined:
4546 Attribute Type Value Valued Length
4547 ======================= ===== ====== ==================
4549 INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets
4550 INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets
4551 INTERNAL_IP4_DNS 3 YES 0 or 4 octets
4552 INTERNAL_IP4_NBNS 4 YES 0 or 4 octets
4553 INTERNAL_ADDRESS_EXPIRY 5 NO 0 or 4 octets
4554 INTERNAL_IP4_DHCP 6 YES 0 or 4 octets
4555 APPLICATION_VERSION 7 NO 0 or more
4556 INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets
4558 INTERNAL_IP6_DNS 10 YES 0 or 16 octets
4559 INTERNAL_IP6_NBNS 11 YES 0 or 16 octets
4560 INTERNAL_IP6_DHCP 12 YES 0 or 16 octets
4561 INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets
4562 SUPPORTED_ATTRIBUTES 14 NO Multiple of 2
4563 INTERNAL_IP6_SUBNET 15 YES 17 octets
4565 * These attributes may be multi-valued on return only if multiple
4566 values were requested.
4568 Types 16-16383 are reserved to IANA. Values 16384-32767 are for
4569 private use among mutually consenting parties.
4571 o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the
4572 internal network, sometimes called a red node address or
4573 private address and MAY be a private address on the Internet.
4574 In a request message, the address specified is a requested
4575 address (or zero if no specific address is requested). If a
4576 specific address is requested, it likely indicates that a
4577 previous connection existed with this address and the requestor
4578 would like to reuse that address. With IPv6, a requestor MAY
4579 supply the low-order address bytes it wants to use. Multiple
4580 internal addresses MAY be requested by requesting multiple
4581 internal address attributes. The responder MAY only send up to
4582 the number of addresses requested. The INTERNAL_IP6_ADDRESS is
4583 made up of two fields: the first is a sixteen-octet IPv6
4584 address and the second is a one-octet prefix-length as defined
4587 The requested address is valid until the expiry time defined
4588 with the INTERNAL_ADDRESS EXPIRY attribute or there are no
4589 IKE_SAs between the peers.
4594 Kaufman Standards Track [Page 82]
4596 RFC 4306 IKEv2 December 2005
4599 o INTERNAL_IP4_NETMASK - The internal network's netmask. Only
4600 one netmask is allowed in the request and reply messages (e.g.,
4601 255.255.255.0), and it MUST be used only with an
4602 INTERNAL_IP4_ADDRESS attribute.
4604 o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a
4605 DNS server within the network. Multiple DNS servers MAY be
4606 requested. The responder MAY respond with zero or more DNS
4609 o INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS - Specifies an address of
4610 a NetBios Name Server (WINS) within the network. Multiple NBNS
4611 servers MAY be requested. The responder MAY respond with zero
4612 or more NBNS server attributes.
4614 o INTERNAL_ADDRESS_EXPIRY - Specifies the number of seconds that
4615 the host can use the internal IP address. The host MUST renew
4616 the IP address before this expiry time. Only one of these
4617 attributes MAY be present in the reply.
4619 o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to
4620 send any internal DHCP requests to the address contained within
4621 the attribute. Multiple DHCP servers MAY be requested. The
4622 responder MAY respond with zero or more DHCP server attributes.
4624 o APPLICATION_VERSION - The version or application information of
4625 the IPsec host. This is a string of printable ASCII characters
4626 that is NOT null terminated.
4628 o INTERNAL_IP4_SUBNET - The protected sub-networks that this
4629 edge-device protects. This attribute is made up of two fields:
4630 the first is an IP address and the second is a netmask.
4631 Multiple sub-networks MAY be requested. The responder MAY
4632 respond with zero or more sub-network attributes.
4634 o SUPPORTED_ATTRIBUTES - When used within a Request, this
4635 attribute MUST be zero-length and specifies a query to the
4636 responder to reply back with all of the attributes that it
4637 supports. The response contains an attribute that contains a
4638 set of attribute identifiers each in 2 octets. The length
4639 divided by 2 (octets) would state the number of supported
4640 attributes contained in the response.
4650 Kaufman Standards Track [Page 83]
4652 RFC 4306 IKEv2 December 2005
4655 o INTERNAL_IP6_SUBNET - The protected sub-networks that this
4656 edge-device protects. This attribute is made up of two fields:
4657 the first is a sixteen-octet IPv6 address and the second is a
4658 one-octet prefix-length as defined in [ADDRIPV6]. Multiple
4659 sub-networks MAY be requested. The responder MAY respond with
4660 zero or more sub-network attributes.
4662 Note that no recommendations are made in this document as to how
4663 an implementation actually figures out what information to send in
4664 a reply. That is, we do not recommend any specific method of an
4665 IRAS determining which DNS server should be returned to a
4668 3.16. Extensible Authentication Protocol (EAP) Payload
4670 The Extensible Authentication Protocol Payload, denoted EAP in this
4671 memo, allows IKE_SAs to be authenticated using the protocol defined
4672 in RFC 3748 [EAP] and subsequent extensions to that protocol. The
4673 full set of acceptable values for the payload is defined elsewhere,
4674 but a short summary of RFC 3748 is included here to make this
4675 document stand alone in the common cases.
4678 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
4679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4680 ! Next Payload !C! RESERVED ! Payload Length !
4681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4687 Figure 24: EAP Payload Format
4689 The payload type for an EAP Payload is forty eight (48).
4692 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
4693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4694 ! Code ! Identifier ! Length !
4695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4696 ! Type ! Type_Data...
4697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
4699 Figure 25: EAP Message Format
4701 o Code (1 octet) indicates whether this message is a Request (1),
4702 Response (2), Success (3), or Failure (4).
4706 Kaufman Standards Track [Page 84]
4708 RFC 4306 IKEv2 December 2005
4711 o Identifier (1 octet) is used in PPP to distinguish replayed
4712 messages from repeated ones. Since in IKE, EAP runs over a
4713 reliable protocol, it serves no function here. In a response
4714 message, this octet MUST be set to match the identifier in the
4715 corresponding request. In other messages, this field MAY be set
4718 o Length (2 octets) is the length of the EAP message and MUST be
4719 four less than the Payload Length of the encapsulating payload.
4721 o Type (1 octet) is present only if the Code field is Request (1) or
4722 Response (2). For other codes, the EAP message length MUST be
4723 four octets and the Type and Type_Data fields MUST NOT be present.
4724 In a Request (1) message, Type indicates the data being requested.
4725 In a Response (2) message, Type MUST either be Nak or match the
4726 type of the data requested. The following types are defined in
4731 3 Nak (Response Only)
4733 5 One-Time Password (OTP)
4734 6 Generic Token Card
4736 o Type_Data (Variable Length) varies with the Type of Request and
4737 the associated Response. For the documentation of the EAP
4740 Note that since IKE passes an indication of initiator identity in
4741 message 3 of the protocol, the responder SHOULD NOT send EAP Identity
4742 requests. The initiator SHOULD, however, respond to such requests if
4745 4. Conformance Requirements
4747 In order to assure that all implementations of IKEv2 can
4748 interoperate, there are "MUST support" requirements in addition to
4749 those listed elsewhere. Of course, IKEv2 is a security protocol, and
4750 one of its major functions is to allow only authorized parties to
4751 successfully complete establishment of SAs. So a particular
4752 implementation may be configured with any of a number of restrictions
4753 concerning algorithms and trusted authorities that will prevent
4754 universal interoperability.
4762 Kaufman Standards Track [Page 85]
4764 RFC 4306 IKEv2 December 2005
4767 IKEv2 is designed to permit minimal implementations that can
4768 interoperate with all compliant implementations. There are a series
4769 of optional features that can easily be ignored by a particular
4770 implementation if it does not support that feature. Those features
4773 Ability to negotiate SAs through a NAT and tunnel the resulting
4776 Ability to request (and respond to a request for) a temporary IP
4777 address on the remote end of a tunnel.
4779 Ability to support various types of legacy authentication.
4781 Ability to support window sizes greater than one.
4783 Ability to establish multiple ESP and/or AH SAs within a single
4786 Ability to rekey SAs.
4788 To assure interoperability, all implementations MUST be capable of
4789 parsing all payload types (if only to skip over them) and to ignore
4790 payload types that it does not support unless the critical bit is set
4791 in the payload header. If the critical bit is set in an unsupported
4792 payload header, all implementations MUST reject the messages
4793 containing those payloads.
4795 Every implementation MUST be capable of doing four-message
4796 IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE,
4797 one for ESP and/or AH). Implementations MAY be initiate-only or
4798 respond-only if appropriate for their platform. Every implementation
4799 MUST be capable of responding to an INFORMATIONAL exchange, but a
4800 minimal implementation MAY respond to any INFORMATIONAL message with
4801 an empty INFORMATIONAL reply (note that within the context of an
4802 IKE_SA, an "empty" message consists of an IKE header followed by an
4803 Encrypted payload with no payloads contained in it). A minimal
4804 implementation MAY support the CREATE_CHILD_SA exchange only in so
4805 far as to recognize requests and reject them with a Notify payload of
4806 type NO_ADDITIONAL_SAS. A minimal implementation need not be able to
4807 initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA
4808 expires (based on locally configured values of either lifetime or
4809 octets passed), and implementation MAY either try to renew it with a
4810 CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and
4811 create a new one. If the responder rejects the CREATE_CHILD_SA
4812 request with a NO_ADDITIONAL_SAS notification, the implementation
4813 MUST be capable of instead closing the old SA and creating a new one.
4818 Kaufman Standards Track [Page 86]
4820 RFC 4306 IKEv2 December 2005
4823 Implementations are not required to support requesting temporary IP
4824 addresses or responding to such requests. If an implementation does
4825 support issuing such requests, it MUST include a CP payload in
4826 message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or
4827 INTERNAL_IP6_ADDRESS. All other fields are optional. If an
4828 implementation supports responding to such requests, it MUST parse
4829 the CP payload of type CFG_REQUEST in message 3 and recognize a field
4830 of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports
4831 leasing an address of the appropriate type, it MUST return a CP
4832 payload of type CFG_REPLY containing an address of the requested
4833 type. The responder SHOULD include all of the other related
4834 attributes if it has them.
4836 A minimal IPv4 responder implementation will ignore the contents of
4837 the CP payload except to determine that it includes an
4838 INTERNAL_IP4_ADDRESS attribute and will respond with the address and
4839 other related attributes regardless of whether the initiator
4842 A minimal IPv4 initiator will generate a CP payload containing only
4843 an INTERNAL_IP4_ADDRESS attribute and will parse the response
4844 ignoring attributes it does not know how to use. The only attribute
4845 it MUST be able to process is INTERNAL_ADDRESS_EXPIRY, which it must
4846 use to bound the lifetime of the SA unless it successfully renews the
4847 lease before it expires. Minimal initiators need not be able to
4848 request lease renewals and minimal responders need not respond to
4851 For an implementation to be called conforming to this specification,
4852 it MUST be possible to configure it to accept the following:
4854 PKIX Certificates containing and signed by RSA keys of size 1024 or
4855 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN,
4856 ID_RFC822_ADDR, or ID_DER_ASN1_DN.
4858 Shared key authentication where the ID passes is any of ID_KEY_ID,
4859 ID_FQDN, or ID_RFC822_ADDR.
4861 Authentication where the responder is authenticated using PKIX
4862 Certificates and the initiator is authenticated using shared key
4874 Kaufman Standards Track [Page 87]
4876 RFC 4306 IKEv2 December 2005
4879 5. Security Considerations
4881 While this protocol is designed to minimize disclosure of
4882 configuration information to unauthenticated peers, some such
4883 disclosure is unavoidable. One peer or the other must identify
4884 itself first and prove its identity first. To avoid probing, the
4885 initiator of an exchange is required to identify itself first, and
4886 usually is required to authenticate itself first. The initiator can,
4887 however, learn that the responder supports IKE and what cryptographic
4888 protocols it supports. The responder (or someone impersonating the
4889 responder) can probe the initiator not only for its identity, but
4890 using CERTREQ payloads may be able to determine what certificates the
4891 initiator is willing to use.
4893 Use of EAP authentication changes the probing possibilities somewhat.
4894 When EAP authentication is used, the responder proves its identity
4895 before the initiator does, so an initiator that knew the name of a
4896 valid initiator could probe the responder for both its name and
4899 Repeated rekeying using CREATE_CHILD_SA without additional Diffie-
4900 Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a
4901 single key or overrun of either endpoint. Implementers should take
4902 note of this fact and set a limit on CREATE_CHILD_SA exchanges
4903 between exponentiations. This memo does not prescribe such a limit.
4905 The strength of a key derived from a Diffie-Hellman exchange using
4906 any of the groups defined here depends on the inherent strength of
4907 the group, the size of the exponent used, and the entropy provided by
4908 the random number generator used. Due to these inputs, it is
4909 difficult to determine the strength of a key for any of the defined
4910 groups. Diffie-Hellman group number two, when used with a strong
4911 random number generator and an exponent no less than 200 bits, is
4912 common for use with 3DES. Group five provides greater security than
4913 group two. Group one is for historic purposes only and does not
4914 provide sufficient strength except for use with DES, which is also
4915 for historic use only. Implementations should make note of these
4916 estimates when establishing policy and negotiating security
4919 Note that these limitations are on the Diffie-Hellman groups
4920 themselves. There is nothing in IKE that prohibits using stronger
4921 groups nor is there anything that will dilute the strength obtained
4922 from stronger groups (limited by the strength of the other algorithms
4923 negotiated including the prf function). In fact, the extensible
4924 framework of IKE encourages the definition of more groups; use of
4925 elliptical curve groups may greatly increase strength using much
4930 Kaufman Standards Track [Page 88]
4932 RFC 4306 IKEv2 December 2005
4935 It is assumed that all Diffie-Hellman exponents are erased from
4936 memory after use. In particular, these exponents MUST NOT be derived
4937 from long-lived secrets like the seed to a pseudo-random generator
4938 that is not erased after use.
4940 The strength of all keys is limited by the size of the output of the
4941 negotiated prf function. For this reason, a prf function whose
4942 output is less than 128 bits (e.g., 3DES-CBC) MUST NOT be used with
4945 The security of this protocol is critically dependent on the
4946 randomness of the randomly chosen parameters. These should be
4947 generated by a strong random or properly seeded pseudo-random source
4948 (see [RFC4086]). Implementers should take care to ensure that use of
4949 random numbers for both keys and nonces is engineered in a fashion
4950 that does not undermine the security of the keys.
4952 For information on the rationale of many of the cryptographic design
4953 choices in this protocol, see [SIGMA] and [SKEME]. Though the
4954 security of negotiated CHILD_SAs does not depend on the strength of
4955 the encryption and integrity protection negotiated in the IKE_SA,
4956 implementations MUST NOT negotiate NONE as the IKE integrity
4957 protection algorithm or ENCR_NULL as the IKE encryption algorithm.
4959 When using pre-shared keys, a critical consideration is how to assure
4960 the randomness of these secrets. The strongest practice is to ensure
4961 that any pre-shared key contain as much randomness as the strongest
4962 key being negotiated. Deriving a shared secret from a password,
4963 name, or other low-entropy source is not secure. These sources are
4964 subject to dictionary and social engineering attacks, among others.
4966 The NAT_DETECTION_*_IP notifications contain a hash of the addresses
4967 and ports in an attempt to hide internal IP addresses behind a NAT.
4968 Since the IPv4 address space is only 32 bits, and it is usually very
4969 sparse, it would be possible for an attacker to find out the internal
4970 address used behind the NAT box by trying all possible IP addresses
4971 and trying to find the matching hash. The port numbers are normally
4972 fixed to 500, and the SPIs can be extracted from the packet. This
4973 reduces the number of hash calculations to 2^32. With an educated
4974 guess of the use of private address space, the number of hash
4975 calculations is much smaller. Designers should therefore not assume
4976 that use of IKE will not leak internal address information.
4978 When using an EAP authentication method that does not generate a
4979 shared key for protecting a subsequent AUTH payload, certain man-in-
4980 the-middle and server impersonation attacks are possible [EAPMITM].
4981 These vulnerabilities occur when EAP is also used in protocols that
4982 are not protected with a secure tunnel. Since EAP is a general-
4986 Kaufman Standards Track [Page 89]
4988 RFC 4306 IKEv2 December 2005
4991 purpose authentication protocol, which is often used to provide
4992 single-signon facilities, a deployed IPsec solution that relies on an
4993 EAP authentication method that does not generate a shared key (also
4994 known as a non-key-generating EAP method) can become compromised due
4995 to the deployment of an entirely unrelated application that also
4996 happens to use the same non-key-generating EAP method, but in an
4997 unprotected fashion. Note that this vulnerability is not limited to
4998 just EAP, but can occur in other scenarios where an authentication
4999 infrastructure is reused. For example, if the EAP mechanism used by
5000 IKEv2 utilizes a token authenticator, a man-in-the-middle attacker
5001 could impersonate the web server, intercept the token authentication
5002 exchange, and use it to initiate an IKEv2 connection. For this
5003 reason, use of non-key-generating EAP methods SHOULD be avoided where
5004 possible. Where they are used, it is extremely important that all
5005 usages of these EAP methods SHOULD utilize a protected tunnel, where
5006 the initiator validates the responder's certificate before initiating
5007 the EAP exchange. Implementers SHOULD describe the vulnerabilities
5008 of using non-key-generating EAP methods in the documentation of their
5009 implementations so that the administrators deploying IPsec solutions
5010 are aware of these dangers.
5012 An implementation using EAP MUST also use a public-key-based
5013 authentication of the server to the client before the EAP exchange
5014 begins, even if the EAP method offers mutual authentication. This
5015 avoids having additional IKEv2 protocol variations and protects the
5016 EAP data from active attackers.
5018 If the messages of IKEv2 are long enough that IP-level fragmentation
5019 is necessary, it is possible that attackers could prevent the
5020 exchange from completing by exhausting the reassembly buffers. The
5021 chances of this can be minimized by using the Hash and URL encodings
5022 instead of sending certificates (see section 3.6). Additional
5023 mitigations are discussed in [KPS03].
5025 6. IANA Considerations
5027 This document defines a number of new field types and values where
5028 future assignments will be managed by the IANA.
5030 The following registries have been created by the IANA:
5032 IKEv2 Exchange Types (section 3.1)
5033 IKEv2 Payload Types (section 3.2)
5034 IKEv2 Transform Types (section 3.3.2)
5035 IKEv2 Transform Attribute Types (section 3.3.2)
5036 IKEv2 Encryption Transform IDs (section 3.3.2)
5037 IKEv2 Pseudo-random Function Transform IDs (section 3.3.2)
5038 IKEv2 Integrity Algorithm Transform IDs (section 3.3.2)
5042 Kaufman Standards Track [Page 90]
5044 RFC 4306 IKEv2 December 2005
5047 IKEv2 Diffie-Hellman Transform IDs (section 3.3.2)
5048 IKEv2 Identification Payload ID Types (section 3.5)
5049 IKEv2 Certificate Encodings (section 3.6)
5050 IKEv2 Authentication Method (section 3.8)
5051 IKEv2 Notify Message Types (section 3.10.1)
5052 IKEv2 Notification IPCOMP Transform IDs (section 3.10.1)
5053 IKEv2 Security Protocol Identifiers (section 3.3.1)
5054 IKEv2 Traffic Selector Types (section 3.13.1)
5055 IKEv2 Configuration Payload CFG Types (section 3.15)
5056 IKEv2 Configuration Payload Attribute Types (section 3.15.1)
5058 Note: When creating a new Transform Type, a new registry for it must
5061 Changes and additions to any of those registries are by expert
5066 This document is a collaborative effort of the entire IPsec WG. If
5067 there were no limit to the number of authors that could appear on an
5068 RFC, the following, in alphabetical order, would have been listed:
5069 Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt
5070 Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John
5071 Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero
5072 Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer
5073 Reingold, and Michael Richardson. Many other people contributed to
5074 the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI,
5075 each of which has its own list of authors. Hugh Daniel suggested the
5076 feature of having the initiator, in message 3, specify a name for the
5077 responder, and gave the feature the cute name "You Tarzan, Me Jane".
5078 David Faucher and Valery Smyzlov helped refine the design of the
5079 traffic selector negotiation.
5083 8.1. Normative References
5085 [ADDGROUP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
5086 Diffie-Hellman groups for Internet Key Exchange (IKE)",
5089 [ADDRIPV6] Hinden, R. and S. Deering, "Internet Protocol Version 6
5090 (IPv6) Addressing Architecture", RFC 3513, April 2003.
5092 [Bra97] Bradner, S., "Key Words for use in RFCs to indicate
5093 Requirement Levels", BCP 14, RFC 2119, March 1997.
5098 Kaufman Standards Track [Page 91]
5100 RFC 4306 IKEv2 December 2005
5103 [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
5104 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
5107 [ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
5108 Algorithms", RFC 2451, November 1998.
5110 [Hutt05] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
5111 Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC
5114 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
5115 IANA Considerations Section in RFCs", BCP 26, RFC 2434,
5118 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
5119 of Explicit Congestion Notification (ECN) to IP", RFC
5120 3168, September 2001.
5122 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
5123 X.509 Public Key Infrastructure Certificate and
5124 Certificate Revocation List (CRL) Profile", RFC 3280,
5127 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
5128 Internet Protocol", RFC 4301, December 2005.
5130 8.2. Informative References
5132 [DES] ANSI X3.106, "American National Standard for Information
5133 Systems-Data Link Encryption", American National Standards
5136 [DH] Diffie, W., and Hellman M., "New Directions in
5137 Cryptography", IEEE Transactions on Information Theory, V.
5138 IT-22, n. 6, June 1977.
5140 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC
5143 [DSS] NIST, "Digital Signature Standard", FIPS 186, National
5144 Institute of Standards and Technology, U.S. Department of
5145 Commerce, May, 1994.
5147 [EAPMITM] Asokan, N., Nierni, V., and Nyberg, K., "Man-in-the-Middle
5148 in Tunneled Authentication Protocols",
5149 http://eprint.iacr.org/2002/163, November 2002.
5154 Kaufman Standards Track [Page 92]
5156 RFC 4306 IKEv2 December 2005
5159 [HC98] Harkins, D. and D. Carrel, "The Internet Key Exchange
5160 (IKE)", RFC 2409, November 1998.
5162 [IDEA] Lai, X., "On the Design and Security of Block Ciphers,"
5163 ETH Series in Information Processing, v. 1, Konstanz:
5164 Hartung-Gorre Verlag, 1992.
5166 [IPCOMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP
5167 Payload Compression Protocol (IPComp)", RFC 3173,
5170 [KPS03] Kaufman, C., Perlman, R., and Sommerfeld, B., "DoS
5171 protection for UDP-based protocols", ACM Conference on
5172 Computer and Communications Security, October 2003.
5174 [KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
5175 Hashing for Message Authentication", RFC 2104, February
5178 [LDAP] Wahl, M., Howes, T., and S Kille, "Lightweight Directory
5179 Access Protocol (v3)", RFC 2251, December 1997.
5181 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
5184 [MSST98] Maughan, D., Schertler, M., Schneider, M., and J. Turner,
5185 "Internet Security Association and Key Management Protocol
5186 (ISAKMP)", RFC 2408, November 1998.
5188 [Orm96] Orman, H., "The OAKLEY Key Determination Protocol", RFC
5189 2412, November 1998.
5191 [PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
5192 Management API, Version 2", RFC 2367, July 1998.
5194 [PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
5195 Standards (PKCS) #1: RSA Cryptography Specifications
5196 Version 2.1", RFC 3447, February 2003.
5198 [PK01] Perlman, R., and Kaufman, C., "Analysis of the IPsec key
5199 exchange Standard", WET-ICE Security Conference, MIT,2001,
5200 http://sec.femto.org/wetice-2001/papers/radia-paper.pdf.
5202 [Pip98] Piper, D., "The Internet IP Security Domain Of
5203 Interpretation for ISAKMP", RFC 2407, November 1998.
5210 Kaufman Standards Track [Page 93]
5212 RFC 4306 IKEv2 December 2005
5215 [RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
5216 "Remote Authentication Dial In User Service (RADIUS)", RFC
5219 [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
5220 "Randomness Requirements for Security", BCP 106, RFC 4086,
5223 [RFC1958] Carpenter, B., "Architectural Principles of the Internet",
5224 RFC 1958, June 1996.
5226 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
5227 Internet Protocol", RFC 2401, November 1998.
5229 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
5230 "Definition of the Differentiated Services Field (DS
5231 Field) in the IPv4 and IPv6 Headers", RFC 2474, December
5234 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
5235 and W. Weiss, "An Architecture for Differentiated
5236 Service", RFC 2475, December 1998.
5238 [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management
5239 Protocol", RFC 2522, March 1999.
5241 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February
5244 [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC
5247 [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural
5248 Guidelines and Philosophy", RFC 3439, December 2002.
5250 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
5251 (NAT) Compatibility Requirements", RFC 3715, March 2004.
5253 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
5256 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
5257 4303, December 2005.
5259 [RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for
5260 Obtaining Digital Signatures and Public-Key
5261 Cryptosystems", Communications of the ACM, v. 21, n. 2,
5266 Kaufman Standards Track [Page 94]
5268 RFC 4306 IKEv2 December 2005
5271 [SHA] NIST, "Secure Hash Standard", FIPS 180-1, National
5272 Institute of Standards and Technology, U.S. Department of
5275 [SIGMA] Krawczyk, H., "SIGMA: the `SIGn-and-MAc' Approach to
5276 Authenticated Diffie-Hellman and its Use in the IKE
5277 Protocols", in Advances in Cryptography - CRYPTO 2003
5278 Proceedings, LNCS 2729, Springer, 2003. Available at:
5279 http://www.informatik.uni-trier.de/~ley/db/conf/
5280 crypto/crypto2003.html.
5282 [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange
5283 Mechanism for Internet", from IEEE Proceedings of the 1996
5284 Symposium on Network and Distributed Systems Security.
5286 [X.501] ITU-T Recommendation X.501: Information Technology - Open
5287 Systems Interconnection - The Directory: Models, 1993.
5289 [X.509] ITU-T Recommendation X.509 (1997 E): Information
5290 Technology - Open Systems Interconnection - The Directory:
5291 Authentication Framework, June 1997.
5322 Kaufman Standards Track [Page 95]
5324 RFC 4306 IKEv2 December 2005
5327 Appendix A: Summary of changes from IKEv1
5329 The goals of this revision to IKE are:
5331 1) To define the entire IKE protocol in a single document, replacing
5332 RFCs 2407, 2408, and 2409 and incorporating subsequent changes to
5333 support NAT Traversal, Extensible Authentication, and Remote Address
5336 2) To simplify IKE by replacing the eight different initial exchanges
5337 with a single four-message exchange (with changes in authentication
5338 mechanisms affecting only a single AUTH payload rather than
5339 restructuring the entire exchange) see [PK01];
5341 3) To remove the Domain of Interpretation (DOI), Situation (SIT), and
5342 Labeled Domain Identifier fields, and the Commit and Authentication
5345 4) To decrease IKE's latency in the common case by making the initial
5346 exchange be 2 round trips (4 messages), and allowing the ability to
5347 piggyback setup of a CHILD_SA on that exchange;
5349 5) To replace the cryptographic syntax for protecting the IKE
5350 messages themselves with one based closely on ESP to simplify
5351 implementation and security analysis;
5353 6) To reduce the number of possible error states by making the
5354 protocol reliable (all messages are acknowledged) and sequenced.
5355 This allows shortening CREATE_CHILD_SA exchanges from 3 messages to
5358 7) To increase robustness by allowing the responder to not do
5359 significant processing until it receives a message proving that the
5360 initiator can receive messages at its claimed IP address, and not
5361 commit any state to an exchange until the initiator can be
5362 cryptographically authenticated;
5364 8) To fix cryptographic weaknesses such as the problem with
5365 symmetries in hashes used for authentication documented by Tero
5368 9) To specify Traffic Selectors in their own payloads type rather
5369 than overloading ID payloads, and making more flexible the Traffic
5370 Selectors that may be specified;
5372 10) To specify required behavior under certain error conditions or
5373 when data that is not understood is received, to make it easier to
5374 make future revisions that do not break backward compatibility;
5378 Kaufman Standards Track [Page 96]
5380 RFC 4306 IKEv2 December 2005
5383 11) To simplify and clarify how shared state is maintained in the
5384 presence of network failures and Denial of Service attacks; and
5386 12) To maintain existing syntax and magic numbers to the extent
5387 possible to make it likely that implementations of IKEv1 can be
5388 enhanced to support IKEv2 with minimum effort.
5390 Appendix B: Diffie-Hellman Groups
5392 There are two Diffie-Hellman groups defined here for use in IKE.
5393 These groups were generated by Richard Schroeppel at the University
5394 of Arizona. Properties of these primes are described in [Orm96].
5396 The strength supplied by group one may not be sufficient for the
5397 mandatory-to-implement encryption algorithm and is here for historic
5400 Additional Diffie-Hellman groups have been defined in [ADDGROUP].
5402 B.1. Group 1 - 768 Bit MODP
5404 This group is assigned id 1 (one).
5406 The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } Its
5407 hexadecimal value is:
5409 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
5410 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
5411 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
5412 A63A3620 FFFFFFFF FFFFFFFF
5416 B.2. Group 2 - 1024 Bit MODP
5418 This group is assigned id 2 (two).
5420 The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
5421 Its hexadecimal value is:
5423 FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08
5424 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B
5425 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9
5426 A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6
5427 49286651 ECE65381 FFFFFFFF FFFFFFFF
5434 Kaufman Standards Track [Page 97]
5436 RFC 4306 IKEv2 December 2005
5442 Microsoft Corporation
5446 Phone: 1-425-707-3335
5447 EMail: charliek@microsoft.com
5490 Kaufman Standards Track [Page 98]
5492 RFC 4306 IKEv2 December 2005
5495 Full Copyright Statement
5497 Copyright (C) The Internet Society (2005).
5499 This document is subject to the rights, licenses and restrictions
5500 contained in BCP 78, and except as set forth therein, the authors
5501 retain all their rights.
5503 This document and the information contained herein are provided on an
5504 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
5505 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
5506 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
5507 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
5508 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
5509 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
5511 Intellectual Property
5513 The IETF takes no position regarding the validity or scope of any
5514 Intellectual Property Rights or other rights that might be claimed to
5515 pertain to the implementation or use of the technology described in
5516 this document or the extent to which any license under such rights
5517 might or might not be available; nor does it represent that it has
5518 made any independent effort to identify any such rights. Information
5519 on the procedures with respect to rights in RFC documents can be
5520 found in BCP 78 and BCP 79.
5522 Copies of IPR disclosures made to the IETF Secretariat and any
5523 assurances of licenses to be made available, or the result of an
5524 attempt made to obtain a general license or permission for the use of
5525 such proprietary rights by implementers or users of this
5526 specification can be obtained from the IETF on-line IPR repository at
5527 http://www.ietf.org/ipr.
5529 The IETF invites any interested party to bring to its attention any
5530 copyrights, patents or patent applications, or other proprietary
5531 rights that may cover technology that may be required to implement
5532 this standard. Please address the information to the IETF at ietf-
5537 Funding for the RFC Editor function is currently provided by the
5546 Kaufman Standards Track [Page 99]