]>
Commit | Line | Data |
---|---|---|
a6d7a610 MW |
1 | |
2 | ||
3 | ||
a6d7a610 | 4 | |
a6d7a610 | 5 | |
82f0707f | 6 | |
824a0402 AS |
7 | Internet Engineering Task Force (IETF) C. Kaufman |
8 | Request for Comments: 5996 Microsoft | |
9 | Obsoletes: 4306, 4718 P. Hoffman | |
10 | Category: Standards Track VPN Consortium | |
11 | ISSN: 2070-1721 Y. Nir | |
12 | Check Point | |
13 | P. Eronen | |
14 | Independent | |
15 | September 2010 | |
82f0707f | 16 | |
82f0707f | 17 | |
824a0402 | 18 | Internet Key Exchange Protocol Version 2 (IKEv2) |
a6d7a610 MW |
19 | |
20 | Abstract | |
21 | ||
22 | This document describes version 2 of the Internet Key Exchange (IKE) | |
23 | protocol. IKE is a component of IPsec used for performing mutual | |
824a0402 AS |
24 | authentication and establishing and maintaining Security Associations |
25 | (SAs). This document replaces and updates RFC 4306, and includes all | |
26 | of the clarifications from RFC 4718. | |
82f0707f | 27 | |
824a0402 | 28 | Status of This Memo |
82f0707f | 29 | |
824a0402 | 30 | This is an Internet Standards Track document. |
82f0707f | 31 | |
824a0402 AS |
32 | This document is a product of the Internet Engineering Task Force |
33 | (IETF). It represents the consensus of the IETF community. It has | |
34 | received public review and has been approved for publication by the | |
35 | Internet Engineering Steering Group (IESG). Further information on | |
36 | Internet Standards is available in Section 2 of RFC 5741. | |
82f0707f | 37 | |
824a0402 AS |
38 | Information about the current status of this document, any errata, |
39 | and how to provide feedback on it may be obtained at | |
40 | http://www.rfc-editor.org/info/rfc5996. | |
82f0707f MW |
41 | |
42 | ||
43 | ||
44 | ||
a6d7a610 MW |
45 | |
46 | ||
47 | ||
a6d7a610 MW |
48 | |
49 | ||
82f0707f MW |
50 | |
51 | ||
52 | ||
53 | ||
54 | ||
55 | ||
56 | ||
57 | ||
824a0402 | 58 | Kaufman, et al. Standards Track [Page 1] |
2eac2578 | 59 | \f |
824a0402 | 60 | RFC 5996 IKEv2bis September 2010 |
a6d7a610 MW |
61 | |
62 | ||
824a0402 | 63 | Copyright Notice |
a6d7a610 | 64 | |
824a0402 AS |
65 | Copyright (c) 2010 IETF Trust and the persons identified as the |
66 | document authors. All rights reserved. | |
a6d7a610 | 67 | |
824a0402 AS |
68 | This document is subject to BCP 78 and the IETF Trust's Legal |
69 | Provisions Relating to IETF Documents | |
70 | (http://trustee.ietf.org/license-info) in effect on the date of | |
71 | publication of this document. Please review these documents | |
72 | carefully, as they describe your rights and restrictions with respect | |
73 | to this document. Code Components extracted from this document must | |
74 | include Simplified BSD License text as described in Section 4.e of | |
75 | the Trust Legal Provisions and are provided without warranty as | |
76 | described in the Simplified BSD License. | |
77 | ||
78 | This document may contain material from IETF Documents or IETF | |
79 | Contributions published or made publicly available before November | |
80 | 10, 2008. The person(s) controlling the copyright in some of this | |
81 | material may not have granted the IETF Trust the right to allow | |
82 | modifications of such material outside the IETF Standards Process. | |
83 | Without obtaining an adequate license from the person(s) controlling | |
84 | the copyright in such materials, this document may not be modified | |
85 | outside the IETF Standards Process, and derivative works of it may | |
86 | not be created outside the IETF Standards Process, except to format | |
87 | it for publication as an RFC or to translate it into languages other | |
88 | than English. | |
a6d7a610 | 89 | |
824a0402 | 90 | Table of Contents |
a6d7a610 | 91 | |
824a0402 AS |
92 | 1. Introduction ....................................................5 |
93 | 1.1. Usage Scenarios ............................................6 | |
94 | 1.1.1. Security Gateway to Security Gateway in | |
95 | Tunnel Mode .........................................7 | |
96 | 1.1.2. Endpoint-to-Endpoint Transport Mode .................7 | |
97 | 1.1.3. Endpoint to Security Gateway in Tunnel Mode .........8 | |
98 | 1.1.4. Other Scenarios .....................................9 | |
99 | 1.2. The Initial Exchanges ......................................9 | |
100 | 1.3. The CREATE_CHILD_SA Exchange ..............................13 | |
101 | 1.3.1. Creating New Child SAs with the | |
102 | CREATE_CHILD_SA Exchange ...........................14 | |
103 | 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA | |
104 | Exchange ...........................................15 | |
105 | 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA | |
106 | Exchange ...........................................16 | |
107 | 1.4. The INFORMATIONAL Exchange ................................17 | |
108 | 1.4.1. Deleting an SA with INFORMATIONAL Exchanges ........17 | |
109 | 1.5. Informational Messages outside of an IKE SA ...............18 | |
110 | 1.6. Requirements Terminology ..................................19 | |
111 | ||
112 | ||
113 | ||
114 | Kaufman, et al. Standards Track [Page 2] | |
115 | \f | |
116 | RFC 5996 IKEv2bis September 2010 | |
117 | ||
118 | ||
119 | 1.7. Significant Differences between RFC 4306 and This | |
120 | Document ..................................................20 | |
121 | 2. IKE Protocol Details and Variations ............................22 | |
122 | 2.1. Use of Retransmission Timers ..............................23 | |
123 | 2.2. Use of Sequence Numbers for Message ID ....................24 | |
124 | 2.3. Window Size for Overlapping Requests ......................25 | |
125 | 2.4. State Synchronization and Connection Timeouts .............26 | |
126 | 2.5. Version Numbers and Forward Compatibility .................28 | |
127 | 2.6. IKE SA SPIs and Cookies ...................................30 | |
128 | 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD .......33 | |
129 | 2.7. Cryptographic Algorithm Negotiation .......................34 | |
130 | 2.8. Rekeying ..................................................34 | |
131 | 2.8.1. Simultaneous Child SA Rekeying .....................36 | |
132 | 2.8.2. Simultaneous IKE SA Rekeying .......................39 | |
133 | 2.8.3. Rekeying the IKE SA versus Reauthentication ........40 | |
134 | 2.9. Traffic Selector Negotiation ..............................40 | |
135 | 2.9.1. Traffic Selectors Violating Own Policy .............43 | |
136 | 2.10. Nonces ...................................................44 | |
137 | 2.11. Address and Port Agility .................................44 | |
138 | 2.12. Reuse of Diffie-Hellman Exponentials .....................44 | |
139 | 2.13. Generating Keying Material ...............................45 | |
140 | 2.14. Generating Keying Material for the IKE SA ................46 | |
141 | 2.15. Authentication of the IKE SA .............................47 | |
142 | 2.16. Extensible Authentication Protocol Methods ...............50 | |
143 | 2.17. Generating Keying Material for Child SAs .................52 | |
144 | 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange ........53 | |
145 | 2.19. Requesting an Internal Address on a Remote Network .......53 | |
146 | 2.20. Requesting the Peer's Version ............................55 | |
147 | 2.21. Error Handling ...........................................56 | |
148 | 2.21.1. Error Handling in IKE_SA_INIT .....................56 | |
149 | 2.21.2. Error Handling in IKE_AUTH ........................57 | |
150 | 2.21.3. Error Handling after IKE SA is Authenticated ......58 | |
151 | 2.21.4. Error Handling Outside IKE SA .....................58 | |
152 | 2.22. IPComp ...................................................59 | |
153 | 2.23. NAT Traversal ............................................60 | |
154 | 2.23.1. Transport Mode NAT Traversal ......................64 | |
155 | 2.24. Explicit Congestion Notification (ECN) ...................68 | |
156 | 2.25. Exchange Collisions ......................................68 | |
157 | 2.25.1. Collisions while Rekeying or Closing Child SAs ....69 | |
158 | 2.25.2. Collisions while Rekeying or Closing IKE SAs ......69 | |
159 | 3. Header and Payload Formats .....................................69 | |
160 | 3.1. The IKE Header ............................................70 | |
161 | 3.2. Generic Payload Header ....................................73 | |
162 | 3.3. Security Association Payload ..............................75 | |
163 | 3.3.1. Proposal Substructure ..............................78 | |
164 | 3.3.2. Transform Substructure .............................79 | |
165 | 3.3.3. Valid Transform Types by Protocol ..................82 | |
166 | 3.3.4. Mandatory Transform IDs ............................83 | |
167 | ||
168 | ||
169 | ||
170 | Kaufman, et al. Standards Track [Page 3] | |
171 | \f | |
172 | RFC 5996 IKEv2bis September 2010 | |
173 | ||
174 | ||
175 | 3.3.5. Transform Attributes ...............................84 | |
176 | 3.3.6. Attribute Negotiation ..............................86 | |
177 | 3.4. Key Exchange Payload ......................................87 | |
178 | 3.5. Identification Payloads ...................................87 | |
179 | 3.6. Certificate Payload .......................................90 | |
180 | 3.7. Certificate Request Payload ...............................93 | |
181 | 3.8. Authentication Payload ....................................95 | |
182 | 3.9. Nonce Payload .............................................96 | |
183 | 3.10. Notify Payload ...........................................97 | |
184 | 3.10.1. Notify Message Types ..............................98 | |
185 | 3.11. Delete Payload ..........................................101 | |
186 | 3.12. Vendor ID Payload .......................................102 | |
187 | 3.13. Traffic Selector Payload ................................103 | |
188 | 3.13.1. Traffic Selector .................................105 | |
189 | 3.14. Encrypted Payload .......................................107 | |
190 | 3.15. Configuration Payload ...................................109 | |
191 | 3.15.1. Configuration Attributes .........................110 | |
192 | 3.15.2. Meaning of INTERNAL_IP4_SUBNET and | |
193 | INTERNAL_IP6_SUBNET ..............................113 | |
194 | 3.15.3. Configuration Payloads for IPv6 ..................115 | |
195 | 3.15.4. Address Assignment Failures ......................116 | |
196 | 3.16. Extensible Authentication Protocol (EAP) Payload ........117 | |
197 | 4. Conformance Requirements ......................................118 | |
198 | 5. Security Considerations .......................................120 | |
199 | 5.1. Traffic Selector Authorization ...........................123 | |
200 | 6. IANA Considerations ...........................................124 | |
201 | 7. Acknowledgements ..............................................125 | |
202 | 8. References ....................................................126 | |
203 | 8.1. Normative References .....................................126 | |
204 | 8.2. Informative References ...................................127 | |
205 | Appendix A. Summary of Changes from IKEv1 ........................132 | |
206 | Appendix B. Diffie-Hellman Groups ................................133 | |
207 | B.1. Group 1 - 768-bit MODP ....................................133 | |
208 | B.2. Group 2 - 1024-bit MODP ...................................133 | |
209 | Appendix C. Exchanges and Payloads ..............................134 | |
210 | C.1. IKE_SA_INIT Exchange .....................................134 | |
211 | C.2. IKE_AUTH Exchange without EAP .............................135 | |
212 | C.3. IKE_AUTH Exchange with EAP ...............................136 | |
213 | C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying | |
214 | Child SAs .................................................137 | |
215 | C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA ..........137 | |
216 | C.6. INFORMATIONAL Exchange ....................................137 | |
217 | ||
218 | ||
219 | ||
220 | ||
221 | ||
222 | ||
223 | ||
224 | ||
225 | ||
226 | Kaufman, et al. Standards Track [Page 4] | |
227 | \f | |
228 | RFC 5996 IKEv2bis September 2010 | |
a6d7a610 MW |
229 | |
230 | ||
231 | 1. Introduction | |
232 | ||
a6d7a610 MW |
233 | IP Security (IPsec) provides confidentiality, data integrity, access |
234 | control, and data source authentication to IP datagrams. These | |
235 | services are provided by maintaining shared state between the source | |
236 | and the sink of an IP datagram. This state defines, among other | |
237 | things, the specific services provided to the datagram, which | |
238 | cryptographic algorithms will be used to provide the services, and | |
239 | the keys used as input to the cryptographic algorithms. | |
240 | ||
241 | Establishing this shared state in a manual fashion does not scale | |
242 | well. Therefore, a protocol to establish this state dynamically is | |
824a0402 | 243 | needed. This document describes such a protocol -- the Internet Key |
a6d7a610 MW |
244 | Exchange (IKE). Version 1 of IKE was defined in RFCs 2407 [DOI], |
245 | 2408 [ISAKMP], and 2409 [IKEV1]. IKEv2 replaced all of those RFCs. | |
246 | IKEv2 was defined in [IKEV2] (RFC 4306) and was clarified in [Clarif] | |
247 | (RFC 4718). This document replaces and updates RFC 4306 and RFC | |
2eac2578 MW |
248 | 4718. IKEv2 was a change to the IKE protocol that was not backward |
249 | compatible. In contrast, the current document not only provides a | |
250 | clarification of IKEv2, but makes minimum changes to the IKE | |
824a0402 AS |
251 | protocol. A list of the significant differences between RFC 4306 and |
252 | this document is given in Section 1.7. | |
a6d7a610 MW |
253 | |
254 | IKE performs mutual authentication between two parties and | |
255 | establishes an IKE security association (SA) that includes shared | |
256 | secret information that can be used to efficiently establish SAs for | |
257 | Encapsulating Security Payload (ESP) [ESP] or Authentication Header | |
258 | (AH) [AH] and a set of cryptographic algorithms to be used by the SAs | |
259 | to protect the traffic that they carry. In this document, the term | |
260 | "suite" or "cryptographic suite" refers to a complete set of | |
261 | algorithms used to protect an SA. An initiator proposes one or more | |
262 | suites by listing supported algorithms that can be combined into | |
263 | suites in a mix-and-match fashion. IKE can also negotiate use of IP | |
264 | Compression (IPComp) [IP-COMP] in connection with an ESP or AH SA. | |
265 | The SAs for ESP or AH that get set up through that IKE SA we call | |
266 | "Child SAs". | |
267 | ||
268 | All IKE communications consist of pairs of messages: a request and a | |
824a0402 AS |
269 | response. The pair is called an "exchange", and is sometimes called |
270 | a "request/response pair". The first exchange of messages | |
271 | establishing an IKE SA are called the IKE_SA_INIT and IKE_AUTH | |
272 | exchanges; subsequent IKE exchanges are called the CREATE_CHILD_SA or | |
273 | INFORMATIONAL exchanges. In the common case, there is a single | |
274 | IKE_SA_INIT exchange and a single IKE_AUTH exchange (a total of four | |
275 | messages) to establish the IKE SA and the first Child SA. In | |
276 | exceptional cases, there may be more than one of each of these | |
277 | exchanges. In all cases, all IKE_SA_INIT exchanges MUST complete | |
278 | before any other exchange type, then all IKE_AUTH exchanges MUST | |
a6d7a610 MW |
279 | |
280 | ||
281 | ||
824a0402 | 282 | Kaufman, et al. Standards Track [Page 5] |
a6d7a610 | 283 | \f |
824a0402 | 284 | RFC 5996 IKEv2bis September 2010 |
a6d7a610 MW |
285 | |
286 | ||
824a0402 AS |
287 | complete, and following that, any number of CREATE_CHILD_SA and |
288 | INFORMATIONAL exchanges may occur in any order. In some scenarios, | |
289 | only a single Child SA is needed between the IPsec endpoints, and | |
290 | therefore there would be no additional exchanges. Subsequent | |
291 | exchanges MAY be used to establish additional Child SAs between the | |
292 | same authenticated pair of endpoints and to perform housekeeping | |
293 | functions. | |
a6d7a610 | 294 | |
824a0402 AS |
295 | An IKE message flow always consists of a request followed by a |
296 | response. It is the responsibility of the requester to ensure | |
297 | reliability. If the response is not received within a timeout | |
298 | interval, the requester needs to retransmit the request (or abandon | |
299 | the connection). | |
a6d7a610 | 300 | |
824a0402 | 301 | The first exchange of an IKE session, IKE_SA_INIT, negotiates |
a6d7a610 MW |
302 | security parameters for the IKE SA, sends nonces, and sends Diffie- |
303 | Hellman values. | |
304 | ||
824a0402 AS |
305 | The second exchange, IKE_AUTH, transmits identities, proves knowledge |
306 | of the secrets corresponding to the two identities, and sets up an SA | |
307 | for the first (and often only) AH or ESP Child SA (unless there is | |
308 | failure setting up the AH or ESP Child SA, in which case the IKE SA | |
309 | is still established without the Child SA). | |
a6d7a610 MW |
310 | |
311 | The types of subsequent exchanges are CREATE_CHILD_SA (which creates | |
312 | a Child SA) and INFORMATIONAL (which deletes an SA, reports error | |
313 | conditions, or does other housekeeping). Every request requires a | |
314 | response. An INFORMATIONAL request with no payloads (other than the | |
315 | empty Encrypted payload required by the syntax) is commonly used as a | |
316 | check for liveness. These subsequent exchanges cannot be used until | |
317 | the initial exchanges have completed. | |
318 | ||
319 | In the description that follows, we assume that no errors occur. | |
824a0402 | 320 | Modifications to the flow when errors occur are described in |
a6d7a610 MW |
321 | Section 2.21. |
322 | ||
323 | 1.1. Usage Scenarios | |
324 | ||
824a0402 AS |
325 | IKE is used to negotiate ESP or AH SAs in a number of different |
326 | scenarios, each with its own special requirements. | |
a6d7a610 | 327 | |
2eac2578 MW |
328 | |
329 | ||
330 | ||
331 | ||
332 | ||
333 | ||
334 | ||
335 | ||
336 | ||
337 | ||
824a0402 | 338 | Kaufman, et al. Standards Track [Page 6] |
2eac2578 | 339 | \f |
824a0402 | 340 | RFC 5996 IKEv2bis September 2010 |
2eac2578 MW |
341 | |
342 | ||
824a0402 | 343 | 1.1.1. Security Gateway to Security Gateway in Tunnel Mode |
a6d7a610 MW |
344 | |
345 | +-+-+-+-+-+ +-+-+-+-+-+ | |
346 | | | IPsec | | | |
347 | Protected |Tunnel | tunnel |Tunnel | Protected | |
348 | Subnet <-->|Endpoint |<---------->|Endpoint |<--> Subnet | |
349 | | | | | | |
350 | +-+-+-+-+-+ +-+-+-+-+-+ | |
351 | ||
352 | Figure 1: Security Gateway to Security Gateway Tunnel | |
353 | ||
a6d7a610 MW |
354 | In this scenario, neither endpoint of the IP connection implements |
355 | IPsec, but network nodes between them protect traffic for part of the | |
356 | way. Protection is transparent to the endpoints, and depends on | |
357 | ordinary routing to send packets through the tunnel endpoints for | |
358 | processing. Each endpoint would announce the set of addresses | |
359 | "behind" it, and packets would be sent in tunnel mode where the inner | |
360 | IP header would contain the IP addresses of the actual endpoints. | |
361 | ||
362 | 1.1.2. Endpoint-to-Endpoint Transport Mode | |
363 | ||
364 | +-+-+-+-+-+ +-+-+-+-+-+ | |
365 | | | IPsec transport | | | |
366 | |Protected| or tunnel mode SA |Protected| | |
367 | |Endpoint |<---------------------------------------->|Endpoint | | |
368 | | | | | | |
369 | +-+-+-+-+-+ +-+-+-+-+-+ | |
370 | ||
371 | Figure 2: Endpoint to Endpoint | |
372 | ||
373 | In this scenario, both endpoints of the IP connection implement | |
374 | IPsec, as required of hosts in [IPSECARCH]. Transport mode will | |
375 | commonly be used with no inner IP header. A single pair of addresses | |
376 | will be negotiated for packets to be protected by this SA. These | |
824a0402 | 377 | endpoints MAY implement application-layer access controls based on |
a6d7a610 MW |
378 | the IPsec authenticated identities of the participants. This |
379 | scenario enables the end-to-end security that has been a guiding | |
380 | principle for the Internet since [ARCHPRINC], [TRANSPARENCY], and a | |
381 | method of limiting the inherent problems with complexity in networks | |
382 | noted by [ARCHGUIDEPHIL]. Although this scenario may not be fully | |
383 | applicable to the IPv4 Internet, it has been deployed successfully in | |
384 | specific scenarios within intranets using IKEv1. It should be more | |
385 | broadly enabled during the transition to IPv6 and with the adoption | |
386 | of IKEv2. | |
387 | ||
a6d7a610 MW |
388 | |
389 | ||
390 | ||
824a0402 AS |
391 | |
392 | ||
393 | ||
394 | Kaufman, et al. Standards Track [Page 7] | |
a6d7a610 | 395 | \f |
824a0402 | 396 | RFC 5996 IKEv2bis September 2010 |
a6d7a610 MW |
397 | |
398 | ||
824a0402 AS |
399 | It is possible in this scenario that one or both of the protected |
400 | endpoints will be behind a network address translation (NAT) node, in | |
401 | which case the tunneled packets will have to be UDP encapsulated so | |
2eac2578 MW |
402 | that port numbers in the UDP headers can be used to identify |
403 | individual endpoints "behind" the NAT (see Section 2.23). | |
404 | ||
824a0402 | 405 | 1.1.3. Endpoint to Security Gateway in Tunnel Mode |
a6d7a610 MW |
406 | |
407 | +-+-+-+-+-+ +-+-+-+-+-+ | |
408 | | | IPsec | | Protected | |
409 | |Protected| tunnel |Tunnel | Subnet | |
410 | |Endpoint |<------------------------>|Endpoint |<--- and/or | |
411 | | | | | Internet | |
412 | +-+-+-+-+-+ +-+-+-+-+-+ | |
413 | ||
414 | Figure 3: Endpoint to Security Gateway Tunnel | |
415 | ||
416 | In this scenario, a protected endpoint (typically a portable roaming | |
417 | computer) connects back to its corporate network through an IPsec- | |
418 | protected tunnel. It might use this tunnel only to access | |
419 | information on the corporate network, or it might tunnel all of its | |
420 | traffic back through the corporate network in order to take advantage | |
421 | of protection provided by a corporate firewall against Internet-based | |
422 | attacks. In either case, the protected endpoint will want an IP | |
423 | address associated with the security gateway so that packets returned | |
424 | to it will go to the security gateway and be tunneled back. This IP | |
425 | address may be static or may be dynamically allocated by the security | |
2eac2578 MW |
426 | gateway. In support of the latter case, IKEv2 includes a mechanism |
427 | (namely, configuration payloads) for the initiator to request an IP | |
428 | address owned by the security gateway for use for the duration of its | |
429 | SA. | |
a6d7a610 MW |
430 | |
431 | In this scenario, packets will use tunnel mode. On each packet from | |
432 | the protected endpoint, the outer IP header will contain the source | |
433 | IP address associated with its current location (i.e., the address | |
434 | that will get traffic routed to the endpoint directly), while the | |
435 | inner IP header will contain the source IP address assigned by the | |
436 | security gateway (i.e., the address that will get traffic routed to | |
437 | the security gateway for forwarding to the endpoint). The outer | |
438 | destination address will always be that of the security gateway, | |
439 | while the inner destination address will be the ultimate destination | |
440 | for the packet. | |
441 | ||
442 | In this scenario, it is possible that the protected endpoint will be | |
443 | behind a NAT. In that case, the IP address as seen by the security | |
444 | gateway will not be the same as the IP address sent by the protected | |
a6d7a610 | 445 | |
a6d7a610 | 446 | |
a6d7a610 MW |
447 | |
448 | ||
449 | ||
824a0402 | 450 | Kaufman, et al. Standards Track [Page 8] |
a6d7a610 | 451 | \f |
824a0402 AS |
452 | RFC 5996 IKEv2bis September 2010 |
453 | ||
a6d7a610 | 454 | |
824a0402 AS |
455 | endpoint, and packets will have to be UDP encapsulated in order to be |
456 | routed properly. Interaction with NATs is covered in detail in | |
457 | Section 2.23. | |
a6d7a610 | 458 | |
2eac2578 MW |
459 | 1.1.4. Other Scenarios |
460 | ||
461 | Other scenarios are possible, as are nested combinations of the | |
824a0402 AS |
462 | above. One notable example combines aspects of Sections 1.1.1 and |
463 | 1.1.3. A subnet may make all external accesses through a remote | |
464 | security gateway using an IPsec tunnel, where the addresses on the | |
465 | subnet are routed to the security gateway by the rest of the | |
466 | Internet. An example would be someone's home network being virtually | |
467 | on the Internet with static IP addresses even though connectivity is | |
a6d7a610 MW |
468 | provided by an ISP that assigns a single dynamically assigned IP |
469 | address to the user's security gateway (where the static IP addresses | |
470 | and an IPsec relay are provided by a third party located elsewhere). | |
471 | ||
472 | 1.2. The Initial Exchanges | |
473 | ||
474 | Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH | |
475 | exchanges (known in IKEv1 as Phase 1). These initial exchanges | |
476 | normally consist of four messages, though in some scenarios that | |
477 | number can grow. All communications using IKE consist of request/ | |
478 | response pairs. We'll describe the base exchange first, followed by | |
479 | variations. The first pair of messages (IKE_SA_INIT) negotiate | |
480 | cryptographic algorithms, exchange nonces, and do a Diffie-Hellman | |
481 | exchange [DH]. | |
482 | ||
483 | The second pair of messages (IKE_AUTH) authenticate the previous | |
484 | messages, exchange identities and certificates, and establish the | |
485 | first Child SA. Parts of these messages are encrypted and integrity | |
486 | protected with keys established through the IKE_SA_INIT exchange, so | |
487 | the identities are hidden from eavesdroppers and all fields in all | |
824a0402 AS |
488 | the messages are authenticated. See Section 2.14 for information on |
489 | how the encryption keys are generated. (A man-in-the-middle attacker | |
490 | who cannot complete the IKE_AUTH exchange can nonetheless see the | |
491 | identity of the initiator.) | |
a6d7a610 MW |
492 | |
493 | All messages following the initial exchange are cryptographically | |
494 | protected using the cryptographic algorithms and keys negotiated in | |
824a0402 AS |
495 | the IKE_SA_INIT exchange. These subsequent messages use the syntax |
496 | of the Encrypted payload described in Section 3.14, encrypted with | |
497 | keys that are derived as described in Section 2.14. All subsequent | |
498 | messages include an Encrypted payload, even if they are referred to | |
499 | in the text as "empty". For the CREATE_CHILD_SA, IKE_AUTH, or | |
500 | INFORMATIONAL exchanges, the message following the header is | |
501 | encrypted and the message including the header is integrity protected | |
502 | using the cryptographic algorithms negotiated for the IKE SA. | |
a6d7a610 MW |
503 | |
504 | ||
505 | ||
824a0402 AS |
506 | Kaufman, et al. Standards Track [Page 9] |
507 | \f | |
508 | RFC 5996 IKEv2bis September 2010 | |
a6d7a610 MW |
509 | |
510 | ||
824a0402 AS |
511 | Every IKE message contains a Message ID as part of its fixed header. |
512 | This Message ID is used to match up requests and responses, and to | |
513 | identify retransmissions of messages. | |
a6d7a610 | 514 | |
824a0402 AS |
515 | In the following descriptions, the payloads contained in the message |
516 | are indicated by names as listed below. | |
a6d7a610 MW |
517 | |
518 | Notation Payload | |
519 | ----------------------------------------- | |
520 | AUTH Authentication | |
521 | CERT Certificate | |
522 | CERTREQ Certificate Request | |
523 | CP Configuration | |
524 | D Delete | |
a6d7a610 | 525 | EAP Extensible Authentication |
824a0402 | 526 | HDR IKE header (not a payload) |
a6d7a610 MW |
527 | IDi Identification - Initiator |
528 | IDr Identification - Responder | |
529 | KE Key Exchange | |
530 | Ni, Nr Nonce | |
531 | N Notify | |
532 | SA Security Association | |
824a0402 | 533 | SK Encrypted and Authenticated |
a6d7a610 MW |
534 | TSi Traffic Selector - Initiator |
535 | TSr Traffic Selector - Responder | |
536 | V Vendor ID | |
537 | ||
538 | The details of the contents of each payload are described in section | |
539 | 3. Payloads that may optionally appear will be shown in brackets, | |
824a0402 AS |
540 | such as [CERTREQ]; this indicates that a Certificate Request payload |
541 | can optionally be included. | |
a6d7a610 MW |
542 | |
543 | The initial exchanges are as follows: | |
544 | ||
545 | Initiator Responder | |
546 | ------------------------------------------------------------------- | |
547 | HDR, SAi1, KEi, Ni --> | |
548 | ||
549 | HDR contains the Security Parameter Indexes (SPIs), version numbers, | |
550 | and flags of various sorts. The SAi1 payload states the | |
551 | cryptographic algorithms the initiator supports for the IKE SA. The | |
552 | KE payload sends the initiator's Diffie-Hellman value. Ni is the | |
553 | initiator's nonce. | |
554 | ||
555 | <-- HDR, SAr1, KEr, Nr, [CERTREQ] | |
556 | ||
824a0402 AS |
557 | |
558 | ||
559 | ||
560 | ||
561 | ||
562 | Kaufman, et al. Standards Track [Page 10] | |
563 | \f | |
564 | RFC 5996 IKEv2bis September 2010 | |
565 | ||
566 | ||
a6d7a610 MW |
567 | The responder chooses a cryptographic suite from the initiator's |
568 | offered choices and expresses that choice in the SAr1 payload, | |
569 | completes the Diffie-Hellman exchange with the KEr payload, and sends | |
570 | its nonce in the Nr payload. | |
571 | ||
572 | At this point in the negotiation, each party can generate SKEYSEED, | |
573 | from which all keys are derived for that IKE SA. The messages that | |
574 | follow are encrypted and integrity protected in their entirety, with | |
575 | the exception of the message headers. The keys used for the | |
a6d7a610 MW |
576 | encryption and integrity protection are derived from SKEYSEED and are |
577 | known as SK_e (encryption) and SK_a (authentication, a.k.a. integrity | |
824a0402 AS |
578 | protection); see Sections 2.13 and 2.14 for details on the key |
579 | derivation. A separate SK_e and SK_a is computed for each direction. | |
580 | In addition to the keys SK_e and SK_a derived from the Diffie-Hellman | |
a6d7a610 MW |
581 | value for protection of the IKE SA, another quantity SK_d is derived |
582 | and used for derivation of further keying material for Child SAs. | |
583 | The notation SK { ... } indicates that these payloads are encrypted | |
584 | and integrity protected using that direction's SK_e and SK_a. | |
585 | ||
586 | HDR, SK {IDi, [CERT,] [CERTREQ,] | |
587 | [IDr,] AUTH, SAi2, | |
588 | TSi, TSr} --> | |
589 | ||
590 | The initiator asserts its identity with the IDi payload, proves | |
591 | knowledge of the secret corresponding to IDi and integrity protects | |
592 | the contents of the first message using the AUTH payload (see | |
593 | Section 2.15). It might also send its certificate(s) in CERT | |
594 | payload(s) and a list of its trust anchors in CERTREQ payload(s). If | |
595 | any CERT payloads are included, the first certificate provided MUST | |
596 | contain the public key used to verify the AUTH field. | |
597 | ||
824a0402 AS |
598 | The optional payload IDr enables the initiator to specify to which of |
599 | the responder's identities it wants to talk. This is useful when the | |
600 | machine on which the responder is running is hosting multiple | |
a6d7a610 MW |
601 | identities at the same IP address. If the IDr proposed by the |
602 | initiator is not acceptable to the responder, the responder might use | |
603 | some other IDr to finish the exchange. If the initiator then does | |
824a0402 | 604 | not accept the fact that responder used an IDr different than the one |
a6d7a610 MW |
605 | that was requested, the initiator can close the SA after noticing the |
606 | fact. | |
607 | ||
824a0402 AS |
608 | The Traffic Selectors (TSi and TSr) are discussed in Section 2.9. |
609 | ||
a6d7a610 MW |
610 | The initiator begins negotiation of a Child SA using the SAi2 |
611 | payload. The final fields (starting with SAi2) are described in the | |
612 | description of the CREATE_CHILD_SA exchange. | |
613 | ||
824a0402 AS |
614 | |
615 | ||
616 | ||
617 | ||
618 | Kaufman, et al. Standards Track [Page 11] | |
619 | \f | |
620 | RFC 5996 IKEv2bis September 2010 | |
621 | ||
622 | ||
a6d7a610 MW |
623 | <-- HDR, SK {IDr, [CERT,] AUTH, |
624 | SAr2, TSi, TSr} | |
625 | ||
626 | The responder asserts its identity with the IDr payload, optionally | |
627 | sends one or more certificates (again with the certificate containing | |
628 | the public key used to verify AUTH listed first), authenticates its | |
629 | identity and protects the integrity of the second message with the | |
630 | AUTH payload, and completes negotiation of a Child SA with the | |
631 | additional fields described below in the CREATE_CHILD_SA exchange. | |
632 | ||
824a0402 AS |
633 | Both parties in the IKE_AUTH exchange MUST verify that all signatures |
634 | and Message Authentication Codes (MACs) are computed correctly. If | |
635 | either side uses a shared secret for authentication, the names in the | |
636 | ID payload MUST correspond to the key used to generate the AUTH | |
637 | payload. | |
a6d7a610 | 638 | |
824a0402 AS |
639 | Because the initiator sends its Diffie-Hellman value in the |
640 | IKE_SA_INIT, it must guess the Diffie-Hellman group that the | |
641 | responder will select from its list of supported groups. If the | |
642 | initiator guesses wrong, the responder will respond with a Notify | |
643 | payload of type INVALID_KE_PAYLOAD indicating the selected group. In | |
644 | this case, the initiator MUST retry the IKE_SA_INIT with the | |
645 | corrected Diffie-Hellman group. The initiator MUST again propose its | |
646 | full set of acceptable cryptographic suites because the rejection | |
647 | message was unauthenticated and otherwise an active attacker could | |
648 | trick the endpoints into negotiating a weaker suite than a stronger | |
649 | one that they both prefer. | |
a6d7a610 | 650 | |
2eac2578 | 651 | If creating the Child SA during the IKE_AUTH exchange fails for some |
824a0402 AS |
652 | reason, the IKE SA is still created as usual. The list of Notify |
653 | message types in the IKE_AUTH exchange that do not prevent an IKE SA | |
654 | from being set up include at least the following: NO_PROPOSAL_CHOSEN, | |
2eac2578 MW |
655 | TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, and |
656 | FAILED_CP_REQUIRED. | |
a6d7a610 | 657 | |
824a0402 AS |
658 | If the failure is related to creating the IKE SA (for example, an |
659 | AUTHENTICATION_FAILED Notify error message is returned), the IKE SA | |
660 | is not created. Note that although the IKE_AUTH messages are | |
661 | encrypted and integrity protected, if the peer receiving this Notify | |
662 | error message has not yet authenticated the other end (or if the peer | |
663 | fails to authenticate the other end for some reason), the information | |
664 | needs to be treated with caution. More precisely, assuming that the | |
665 | MAC verifies correctly, the sender of the error Notify message is | |
666 | known to be the responder of the IKE_SA_INIT exchange, but the | |
667 | sender's identity cannot be assured. | |
668 | ||
669 | ||
670 | ||
671 | ||
672 | ||
673 | ||
674 | Kaufman, et al. Standards Track [Page 12] | |
675 | \f | |
676 | RFC 5996 IKEv2bis September 2010 | |
677 | ||
678 | ||
2eac2578 MW |
679 | Note that IKE_AUTH messages do not contain KEi/KEr or Ni/Nr payloads. |
680 | Thus, the SA payloads in the IKE_AUTH exchange cannot contain | |
824a0402 | 681 | Transform Type 4 (Diffie-Hellman group) with any value other than |
2eac2578 MW |
682 | NONE. Implementations SHOULD omit the whole transform substructure |
683 | instead of sending value NONE. | |
a6d7a610 MW |
684 | |
685 | 1.3. The CREATE_CHILD_SA Exchange | |
686 | ||
a6d7a610 MW |
687 | The CREATE_CHILD_SA exchange is used to create new Child SAs and to |
688 | rekey both IKE SAs and Child SAs. This exchange consists of a single | |
689 | request/response pair, and some of its function was referred to as a | |
824a0402 | 690 | Phase 2 exchange in IKEv1. It MAY be initiated by either end of the |
a6d7a610 MW |
691 | IKE SA after the initial exchanges are completed. |
692 | ||
a6d7a610 MW |
693 | An SA is rekeyed by creating a new SA and then deleting the old one. |
694 | This section describes the first part of rekeying, the creation of | |
695 | new SAs; Section 2.8 covers the mechanics of rekeying, including | |
696 | moving traffic from old to new SAs and the deletion of the old SAs. | |
697 | The two sections must be read together to understand the entire | |
698 | process of rekeying. | |
699 | ||
700 | Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this | |
701 | section the term initiator refers to the endpoint initiating this | |
702 | exchange. An implementation MAY refuse all CREATE_CHILD_SA requests | |
703 | within an IKE SA. | |
704 | ||
2eac2578 MW |
705 | The CREATE_CHILD_SA request MAY optionally contain a KE payload for |
706 | an additional Diffie-Hellman exchange to enable stronger guarantees | |
707 | of forward secrecy for the Child SA. The keying material for the | |
a6d7a610 MW |
708 | Child SA is a function of SK_d established during the establishment |
709 | of the IKE SA, the nonces exchanged during the CREATE_CHILD_SA | |
710 | exchange, and the Diffie-Hellman value (if KE payloads are included | |
711 | in the CREATE_CHILD_SA exchange). | |
712 | ||
713 | If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of | |
714 | the SA offers MUST include the Diffie-Hellman group of the KEi. The | |
715 | Diffie-Hellman group of the KEi MUST be an element of the group the | |
716 | initiator expects the responder to accept (additional Diffie-Hellman | |
717 | groups can be proposed). If the responder selects a proposal using a | |
718 | different Diffie-Hellman group (other than NONE), the responder MUST | |
719 | reject the request and indicate its preferred Diffie-Hellman group in | |
824a0402 AS |
720 | the INVALID_KE_PAYLOAD Notify payload. There are two octets of data |
721 | associated with this notification: the accepted Diffie-Hellman group | |
722 | number in big endian order. In the case of such a rejection, the | |
2eac2578 MW |
723 | CREATE_CHILD_SA exchange fails, and the initiator will probably retry |
724 | the exchange with a Diffie-Hellman proposal and KEi in the group that | |
824a0402 AS |
725 | the responder gave in the INVALID_KE_PAYLOAD Notify payload. |
726 | ||
727 | ||
728 | ||
729 | ||
730 | Kaufman, et al. Standards Track [Page 13] | |
731 | \f | |
732 | RFC 5996 IKEv2bis September 2010 | |
733 | ||
2eac2578 MW |
734 | |
735 | The responder sends a NO_ADDITIONAL_SAS notification to indicate that | |
736 | a CREATE_CHILD_SA request is unacceptable because the responder is | |
824a0402 AS |
737 | unwilling to accept any more Child SAs on this IKE SA. This |
738 | notification can also be used to reject IKE SA rekey. Some minimal | |
2eac2578 MW |
739 | implementations may only accept a single Child SA setup in the |
740 | context of an initial IKE exchange and reject any subsequent attempts | |
741 | to add more. | |
a6d7a610 MW |
742 | |
743 | 1.3.1. Creating New Child SAs with the CREATE_CHILD_SA Exchange | |
744 | ||
745 | A Child SA may be created by sending a CREATE_CHILD_SA request. The | |
746 | CREATE_CHILD_SA request for creating a new Child SA is: | |
747 | ||
748 | Initiator Responder | |
749 | ------------------------------------------------------------------- | |
750 | HDR, SK {SA, Ni, [KEi], | |
751 | TSi, TSr} --> | |
752 | ||
753 | The initiator sends SA offer(s) in the SA payload, a nonce in the Ni | |
754 | payload, optionally a Diffie-Hellman value in the KEi payload, and | |
824a0402 | 755 | the proposed Traffic Selectors for the proposed Child SA in the TSi |
a6d7a610 MW |
756 | and TSr payloads. |
757 | ||
758 | The CREATE_CHILD_SA response for creating a new Child SA is: | |
759 | ||
760 | <-- HDR, SK {SA, Nr, [KEr], | |
761 | TSi, TSr} | |
762 | ||
2eac2578 MW |
763 | The responder replies (using the same Message ID to respond) with the |
764 | accepted offer in an SA payload, and a Diffie-Hellman value in the | |
a6d7a610 MW |
765 | KEr payload if KEi was included in the request and the selected |
766 | cryptographic suite includes that group. | |
767 | ||
824a0402 | 768 | The Traffic Selectors for traffic to be sent on that SA are specified |
a6d7a610 MW |
769 | in the TS payloads in the response, which may be a subset of what the |
770 | initiator of the Child SA proposed. | |
771 | ||
2eac2578 MW |
772 | The USE_TRANSPORT_MODE notification MAY be included in a request |
773 | message that also includes an SA payload requesting a Child SA. It | |
774 | requests that the Child SA use transport mode rather than tunnel mode | |
775 | for the SA created. If the request is accepted, the response MUST | |
776 | also include a notification of type USE_TRANSPORT_MODE. If the | |
777 | responder declines the request, the Child SA will be established in | |
778 | tunnel mode. If this is unacceptable to the initiator, the initiator | |
779 | MUST delete the SA. Note: Except when using this option to negotiate | |
780 | transport mode, all Child SAs will use tunnel mode. | |
781 | ||
824a0402 AS |
782 | |
783 | ||
784 | ||
785 | ||
786 | Kaufman, et al. Standards Track [Page 14] | |
787 | \f | |
788 | RFC 5996 IKEv2bis September 2010 | |
789 | ||
790 | ||
2eac2578 | 791 | The ESP_TFC_PADDING_NOT_SUPPORTED notification asserts that the |
824a0402 | 792 | sending endpoint will not accept packets that contain Traffic Flow |
2eac2578 MW |
793 | Confidentiality (TFC) padding over the Child SA being negotiated. If |
794 | neither endpoint accepts TFC padding, this notification is included | |
795 | in both the request and the response. If this notification is | |
796 | included in only one of the messages, TFC padding can still be sent | |
797 | in the other direction. | |
798 | ||
799 | The NON_FIRST_FRAGMENTS_ALSO notification is used for fragmentation | |
800 | control. See [IPSECARCH] for a fuller explanation. Both parties | |
801 | need to agree to sending non-first fragments before either party does | |
802 | so. It is enabled only if NON_FIRST_FRAGMENTS_ALSO notification is | |
803 | included in both the request proposing an SA and the response | |
804 | accepting it. If the responder does not want to send or receive non- | |
805 | first fragments, it only omits NON_FIRST_FRAGMENTS_ALSO notification | |
806 | from its response, but does not reject the whole Child SA creation. | |
a6d7a610 | 807 | |
824a0402 AS |
808 | An IPCOMP_SUPPORTED notification, covered in Section 2.22, can also |
809 | be included in the exchange. | |
810 | ||
811 | A failed attempt to create a Child SA SHOULD NOT tear down the IKE | |
812 | SA: there is no reason to lose the work done to set up the IKE SA. | |
813 | See Section 2.21 for a list of error messages that might occur if | |
814 | creating a Child SA fails. | |
82f0707f | 815 | |
82f0707f MW |
816 | 1.3.2. Rekeying IKE SAs with the CREATE_CHILD_SA Exchange |
817 | ||
818 | The CREATE_CHILD_SA request for rekeying an IKE SA is: | |
a6d7a610 | 819 | |
82f0707f MW |
820 | Initiator Responder |
821 | ------------------------------------------------------------------- | |
822 | HDR, SK {SA, Ni, KEi} --> | |
a6d7a610 | 823 | |
82f0707f MW |
824 | The initiator sends SA offer(s) in the SA payload, a nonce in the Ni |
825 | payload, and a Diffie-Hellman value in the KEi payload. The KEi | |
824a0402 AS |
826 | payload MUST be included. A new initiator SPI is supplied in the SPI |
827 | field of the SA payload. Once a peer receives a request to rekey an | |
828 | IKE SA or sends a request to rekey an IKE SA, it SHOULD NOT start any | |
829 | new CREATE_CHILD_SA exchanges on the IKE SA that is being rekeyed. | |
a6d7a610 MW |
830 | |
831 | The CREATE_CHILD_SA response for rekeying an IKE SA is: | |
832 | ||
824a0402 | 833 | <-- HDR, SK {SA, Nr, KEr} |
a6d7a610 MW |
834 | |
835 | The responder replies (using the same Message ID to respond) with the | |
836 | accepted offer in an SA payload, and a Diffie-Hellman value in the | |
837 | KEr payload if the selected cryptographic suite includes that group. | |
824a0402 AS |
838 | A new responder SPI is supplied in the SPI field of the SA payload. |
839 | ||
840 | ||
841 | ||
842 | Kaufman, et al. Standards Track [Page 15] | |
843 | \f | |
844 | RFC 5996 IKEv2bis September 2010 | |
845 | ||
a6d7a610 MW |
846 | |
847 | The new IKE SA has its message counters set to 0, regardless of what | |
82f0707f | 848 | they were in the earlier IKE SA. The first IKE requests from both |
824a0402 | 849 | sides on the new IKE SA will have Message ID 0. The old IKE SA |
82f0707f MW |
850 | retains its numbering, so any further requests (for example, to |
851 | delete the IKE SA) will have consecutive numbering. The new IKE SA | |
852 | also has its window size reset to 1, and the initiator in this rekey | |
853 | exchange is the new "original initiator" of the new IKE SA. | |
a6d7a610 | 854 | |
824a0402 AS |
855 | Section 2.18 also covers IKE SA rekeying in detail. |
856 | ||
a6d7a610 MW |
857 | 1.3.3. Rekeying Child SAs with the CREATE_CHILD_SA Exchange |
858 | ||
859 | The CREATE_CHILD_SA request for rekeying a Child SA is: | |
860 | ||
861 | Initiator Responder | |
862 | ------------------------------------------------------------------- | |
824a0402 | 863 | HDR, SK {N(REKEY_SA), SA, Ni, [KEi], |
a6d7a610 MW |
864 | TSi, TSr} --> |
865 | ||
866 | The initiator sends SA offer(s) in the SA payload, a nonce in the Ni | |
867 | payload, optionally a Diffie-Hellman value in the KEi payload, and | |
824a0402 | 868 | the proposed Traffic Selectors for the proposed Child SA in the TSi |
a6d7a610 MW |
869 | and TSr payloads. |
870 | ||
824a0402 AS |
871 | The notifications described in Section 1.3.1 may also be sent in a |
872 | rekeying exchange. Usually, these will be the same notifications | |
873 | that were used in the original exchange; for example, when rekeying a | |
874 | transport mode SA, the USE_TRANSPORT_MODE notification will be used. | |
875 | ||
2eac2578 MW |
876 | The REKEY_SA notification MUST be included in a CREATE_CHILD_SA |
877 | exchange if the purpose of the exchange is to replace an existing ESP | |
878 | or AH SA. The SA being rekeyed is identified by the SPI field in the | |
879 | Notify payload; this is the SPI the exchange initiator would expect | |
880 | in inbound ESP or AH packets. There is no data associated with this | |
824a0402 AS |
881 | Notify message type. The Protocol ID field of the REKEY_SA |
882 | notification is set to match the protocol of the SA we are rekeying, | |
883 | for example, 3 for ESP and 2 for AH. | |
82f0707f | 884 | |
2eac2578 | 885 | The CREATE_CHILD_SA response for rekeying a Child SA is: |
82f0707f | 886 | |
2eac2578 MW |
887 | <-- HDR, SK {SA, Nr, [KEr], |
888 | TSi, TSr} | |
82f0707f | 889 | |
a6d7a610 MW |
890 | The responder replies (using the same Message ID to respond) with the |
891 | accepted offer in an SA payload, and a Diffie-Hellman value in the | |
892 | KEr payload if KEi was included in the request and the selected | |
893 | cryptographic suite includes that group. | |
894 | ||
824a0402 AS |
895 | |
896 | ||
897 | ||
898 | Kaufman, et al. Standards Track [Page 16] | |
899 | \f | |
900 | RFC 5996 IKEv2bis September 2010 | |
901 | ||
902 | ||
903 | The Traffic Selectors for traffic to be sent on that SA are specified | |
a6d7a610 MW |
904 | in the TS payloads in the response, which may be a subset of what the |
905 | initiator of the Child SA proposed. | |
906 | ||
907 | 1.4. The INFORMATIONAL Exchange | |
908 | ||
909 | At various points during the operation of an IKE SA, peers may desire | |
910 | to convey control messages to each other regarding errors or | |
911 | notifications of certain events. To accomplish this, IKE defines an | |
912 | INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur | |
913 | after the initial exchanges and are cryptographically protected with | |
824a0402 AS |
914 | the negotiated keys. Note that some informational messages, not |
915 | exchanges, can be sent outside the context of an IKE SA. Section | |
916 | 2.21 also covers error messages in great detail. | |
a6d7a610 MW |
917 | |
918 | Control messages that pertain to an IKE SA MUST be sent under that | |
919 | IKE SA. Control messages that pertain to Child SAs MUST be sent | |
824a0402 | 920 | under the protection of the IKE SA that generated them (or its |
a6d7a610 MW |
921 | successor if the IKE SA was rekeyed). |
922 | ||
923 | Messages in an INFORMATIONAL exchange contain zero or more | |
824a0402 AS |
924 | Notification, Delete, and Configuration payloads. The recipient of |
925 | an INFORMATIONAL exchange request MUST send some response; otherwise, | |
926 | the sender will assume the message was lost in the network and will | |
927 | retransmit it. That response MAY be an empty message. The request | |
928 | message in an INFORMATIONAL exchange MAY also contain no payloads. | |
929 | This is the expected way an endpoint can ask the other endpoint to | |
930 | verify that it is alive. | |
a6d7a610 MW |
931 | |
932 | The INFORMATIONAL exchange is defined as: | |
933 | ||
934 | Initiator Responder | |
935 | ------------------------------------------------------------------- | |
936 | HDR, SK {[N,] [D,] | |
937 | [CP,] ...} --> | |
938 | <-- HDR, SK {[N,] [D,] | |
2eac2578 | 939 | [CP], ...} |
82f0707f | 940 | |
2eac2578 MW |
941 | The processing of an INFORMATIONAL exchange is determined by its |
942 | component payloads. | |
82f0707f | 943 | |
2eac2578 | 944 | 1.4.1. Deleting an SA with INFORMATIONAL Exchanges |
82f0707f | 945 | |
2eac2578 MW |
946 | ESP and AH SAs always exist in pairs, with one SA in each direction. |
947 | When an SA is closed, both members of the pair MUST be closed (that | |
824a0402 AS |
948 | is, deleted). Each endpoint MUST close its incoming SAs and allow |
949 | the other endpoint to close the other SA in each pair. To delete an | |
950 | SA, an INFORMATIONAL exchange with one or more Delete payloads is | |
82f0707f MW |
951 | |
952 | ||
a6d7a610 | 953 | |
824a0402 | 954 | Kaufman, et al. Standards Track [Page 17] |
2eac2578 | 955 | \f |
824a0402 | 956 | RFC 5996 IKEv2bis September 2010 |
a6d7a610 | 957 | |
a6d7a610 | 958 | |
2eac2578 MW |
959 | sent listing the SPIs (as they would be expected in the headers of |
960 | inbound packets) of the SAs to be deleted. The recipient MUST close | |
824a0402 | 961 | the designated SAs. Note that one never sends Delete payloads for |
2eac2578 | 962 | the two sides of an SA in a single message. If there are many SAs to |
824a0402 AS |
963 | delete at the same time, one includes Delete payloads for the inbound |
964 | half of each SA pair in the INFORMATIONAL exchange. | |
965 | ||
966 | Normally, the response in the INFORMATIONAL exchange will contain | |
967 | Delete payloads for the paired SAs going in the other direction. | |
968 | There is one exception. If, by chance, both ends of a set of SAs | |
969 | independently decide to close them, each may send a Delete payload | |
970 | and the two requests may cross in the network. If a node receives a | |
971 | delete request for SAs for which it has already issued a delete | |
972 | request, it MUST delete the outgoing SAs while processing the request | |
973 | and the incoming SAs while processing the response. In that case, | |
974 | the responses MUST NOT include Delete payloads for the deleted SAs, | |
975 | since that would result in duplicate deletion and could in theory | |
976 | delete the wrong SA. | |
977 | ||
978 | Similar to ESP and AH SAs, IKE SAs are also deleted by sending an | |
979 | Informational exchange. Deleting an IKE SA implicitly closes any | |
980 | remaining Child SAs negotiated under it. The response to a request | |
981 | that deletes the IKE SA is an empty INFORMATIONAL response. | |
a6d7a610 | 982 | |
2eac2578 MW |
983 | Half-closed ESP or AH connections are anomalous, and a node with |
984 | auditing capability should probably audit their existence if they | |
824a0402 AS |
985 | persist. Note that this specification does not specify time periods, |
986 | so it is up to individual endpoints to decide how long to wait. A | |
987 | node MAY refuse to accept incoming data on half-closed connections | |
988 | but MUST NOT unilaterally close them and reuse the SPIs. If | |
989 | connection state becomes sufficiently messed up, a node MAY close the | |
990 | IKE SA, as described above. It can then rebuild the SAs it needs on | |
991 | a clean base under a new IKE SA. | |
a6d7a610 MW |
992 | |
993 | 1.5. Informational Messages outside of an IKE SA | |
994 | ||
824a0402 AS |
995 | There are some cases in which a node receives a packet that it cannot |
996 | process, but it may want to notify the sender about this situation. | |
a6d7a610 | 997 | |
824a0402 AS |
998 | o If an ESP or AH packet arrives with an unrecognized SPI. This |
999 | might be due to the receiving node having recently crashed and | |
1000 | lost state, or because of some other system malfunction or attack. | |
2eac2578 | 1001 | |
824a0402 AS |
1002 | o If an encrypted IKE request packet arrives on port 500 or 4500 |
1003 | with an unrecognized IKE SPI. This might be due to the receiving | |
1004 | node having recently crashed and lost state, or because of some | |
1005 | other system malfunction or attack. | |
2eac2578 MW |
1006 | |
1007 | ||
2eac2578 MW |
1008 | |
1009 | ||
824a0402 AS |
1010 | Kaufman, et al. Standards Track [Page 18] |
1011 | \f | |
1012 | RFC 5996 IKEv2bis September 2010 | |
2eac2578 | 1013 | |
a6d7a610 | 1014 | |
824a0402 AS |
1015 | o If an IKE request packet arrives with a higher major version |
1016 | number than the implementation supports. | |
a6d7a610 | 1017 | |
824a0402 AS |
1018 | In the first case, if the receiving node has an active IKE SA to the |
1019 | IP address from whence the packet came, it MAY send an INVALID_SPI | |
1020 | notification of the wayward packet over that IKE SA in an | |
1021 | INFORMATIONAL exchange. The Notification Data contains the SPI of | |
1022 | the invalid packet. The recipient of this notification cannot tell | |
1023 | whether the SPI is for AH or ESP, but this is not important because | |
1024 | the SPIs are supposed to be different for the two. If no suitable | |
1025 | IKE SA exists, the node MAY send an informational message without | |
1026 | cryptographic protection to the source IP address, using the source | |
1027 | UDP port as the destination port if the packet was UDP (UDP- | |
1028 | encapsulated ESP or AH). In this case, it should only be used by the | |
1029 | recipient as a hint that something might be wrong (because it could | |
1030 | easily be forged). This message is not part of an INFORMATIONAL | |
1031 | exchange, and the receiving node MUST NOT respond to it because doing | |
1032 | so could cause a message loop. The message is constructed as | |
1033 | follows: there are no IKE SPI values that would be meaningful to the | |
1034 | recipient of such a notification; using zero values or random values | |
1035 | are both acceptable, this being the exception to the rule in | |
1036 | Section 3.1 that prohibits zero IKE Initiator SPIs. The Initiator | |
1037 | flag is set to 1, the Response flag is set to 0, and the version | |
1038 | flags are set in the normal fashion; these flags are described in | |
1039 | Section 3.1. | |
1040 | ||
1041 | In the second and third cases, the message is always sent without | |
1042 | cryptographic protection (outside of an IKE SA), and includes either | |
1043 | an INVALID_IKE_SPI or an INVALID_MAJOR_VERSION notification (with no | |
1044 | notification data). The message is a response message, and thus it | |
1045 | is sent to the IP address and port from whence it came with the same | |
1046 | IKE SPIs and the Message ID and Exchange Type are copied from the | |
1047 | request. The Response flag is set to 1, and the version flags are | |
1048 | set in the normal fashion. | |
a6d7a610 MW |
1049 | |
1050 | 1.6. Requirements Terminology | |
1051 | ||
1052 | Definitions of the primitive terms in this document (such as Security | |
2eac2578 MW |
1053 | Association or SA) can be found in [IPSECARCH]. It should be noted |
1054 | that parts of IKEv2 rely on some of the processing rules in | |
1055 | [IPSECARCH], as described in various sections of this document. | |
a6d7a610 | 1056 | |
824a0402 AS |
1057 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
1058 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |
1059 | document are to be interpreted as described in [MUSTSHOULD]. | |
82f0707f MW |
1060 | |
1061 | ||
1062 | ||
82f0707f MW |
1063 | |
1064 | ||
a6d7a610 | 1065 | |
824a0402 | 1066 | Kaufman, et al. Standards Track [Page 19] |
2eac2578 | 1067 | \f |
824a0402 AS |
1068 | RFC 5996 IKEv2bis September 2010 |
1069 | ||
a6d7a610 | 1070 | |
824a0402 | 1071 | 1.7. Significant Differences between RFC 4306 and This Document |
a6d7a610 | 1072 | |
824a0402 AS |
1073 | This document contains clarifications and amplifications to IKEv2 |
1074 | [IKEV2]. Many of the clarifications are based on [Clarif]. The | |
a6d7a610 MW |
1075 | changes listed in that document were discussed in the IPsec Working |
1076 | Group and, after the Working Group was disbanded, on the IPsec | |
1077 | mailing list. That document contains detailed explanations of areas | |
1078 | that were unclear in IKEv2, and is thus useful to implementers of | |
1079 | IKEv2. | |
1080 | ||
1081 | The protocol described in this document retains the same major | |
1082 | version number (2) and minor version number (0) as was used in RFC | |
a6d7a610 | 1083 | 4306. That is, the version number is *not* changed from RFC 4306. |
824a0402 AS |
1084 | The small number of technical changes listed here are not expected to |
1085 | affect RFC 4306 implementations that have already been deployed at | |
1086 | the time of publication of this document. | |
a6d7a610 | 1087 | |
824a0402 AS |
1088 | This document makes the figures and references a bit more consistent |
1089 | than they were in [IKEV2]. | |
a6d7a610 | 1090 | |
824a0402 AS |
1091 | IKEv2 developers have noted that the SHOULD-level requirements in RFC |
1092 | 4306 are often unclear in that they don't say when it is OK to not | |
1093 | obey the requirements. They also have noted that there are MUST- | |
1094 | level requirements that are not related to interoperability. This | |
1095 | document has more explanation of some of these requirements. All | |
1096 | non-capitalized uses of the words SHOULD and MUST now mean their | |
1097 | normal English sense, not the interoperability sense of [MUSTSHOULD]. | |
a6d7a610 MW |
1098 | |
1099 | IKEv2 (and IKEv1) developers have noted that there is a great deal of | |
824a0402 AS |
1100 | material in the tables of codes in Section 3.10.1 in RFC 4306. This |
1101 | leads to implementers not having all the needed information in the | |
1102 | main body of the document. Much of the material from those tables | |
1103 | has been moved into the associated parts of the main body of the | |
1104 | document. | |
a6d7a610 | 1105 | |
a6d7a610 MW |
1106 | This document removes discussion of nesting AH and ESP. This was a |
1107 | mistake in RFC 4306 caused by the lag between finishing RFC 4306 and | |
1108 | RFC 4301. Basically, IKEv2 is based on RFC 4301, which does not | |
1109 | include "SA bundles" that were part of RFC 2401. While a single | |
1110 | packet can go through IPsec processing multiple times, each of these | |
1111 | passes uses a separate SA, and the passes are coordinated by the | |
1112 | forwarding tables. In IKEv2, each of these SAs has to be created | |
1113 | using a separate CREATE_CHILD_SA exchange. | |
1114 | ||
1115 | This document removes discussion of the INTERNAL_ADDRESS_EXPIRY | |
1116 | configuration attribute because its implementation was very | |
1117 | problematic. Implementations that conform to this document MUST | |
824a0402 AS |
1118 | |
1119 | ||
1120 | ||
1121 | ||
1122 | Kaufman, et al. Standards Track [Page 20] | |
1123 | \f | |
1124 | RFC 5996 IKEv2bis September 2010 | |
1125 | ||
1126 | ||
a6d7a610 | 1127 | ignore proposals that have configuration attribute type 5, the old |
824a0402 AS |
1128 | value for INTERNAL_ADDRESS_EXPIRY. This document also removed |
1129 | INTERNAL_IP6_NBNS as a configuration attribute. | |
1130 | ||
1131 | This document removes the allowance for rejecting messages in which | |
1132 | the payloads were not in the "right" order; now implementations MUST | |
1133 | NOT reject them. This is due to the lack of clarity where the orders | |
1134 | for the payloads are described. | |
1135 | ||
1136 | The lists of items from RFC 4306 that ended up in the IANA registry | |
1137 | were trimmed to only include items that were actually defined in RFC | |
1138 | 4306. Also, many of those lists are now preceded with the very | |
1139 | important instruction to developers that they really should look at | |
1140 | the IANA registry at the time of development because new items have | |
1141 | been added since RFC 4306. | |
1142 | ||
1143 | This document adds clarification on when notifications are and are | |
1144 | not sent encrypted, depending on the state of the negotiation at the | |
1145 | time. | |
1146 | ||
1147 | This document discusses more about how to negotiate combined-mode | |
1148 | ciphers. | |
1149 | ||
1150 | In Section 1.3.2, "The KEi payload SHOULD be included" was changed to | |
1151 | be "The KEi payload MUST be included". This also led to changes in | |
1152 | Section 2.18. | |
1153 | ||
1154 | In Section 2.1, there is new material covering how the initiator's | |
1155 | SPI and/or IP is used to differentiate if this is a "half-open" IKE | |
1156 | SA or a new request. | |
1157 | ||
1158 | This document clarifies the use of the critical flag in Section 2.5. | |
1159 | ||
1160 | In Section 2.8, "Note that, when rekeying, the new Child SA MAY have | |
1161 | different Traffic Selectors and algorithms than the old one" was | |
1162 | changed to "Note that, when rekeying, the new Child SA SHOULD NOT | |
1163 | have different Traffic Selectors and algorithms than the old one". | |
1164 | ||
1165 | The new Section 2.8.2 covers simultaneous IKE SA rekeying. | |
a6d7a610 | 1166 | |
824a0402 | 1167 | The new Section 2.9.2 covers Traffic Selectors in rekeying. |
a6d7a610 | 1168 | |
824a0402 AS |
1169 | This document adds the restriction in Section 2.13 that all |
1170 | pseudorandom functions (PRFs) used with IKEv2 MUST take variable- | |
1171 | sized keys. This should not affect any implementations because there | |
1172 | were no standardized PRFs that have fixed-size keys. | |
2eac2578 MW |
1173 | |
1174 | ||
1175 | ||
824a0402 AS |
1176 | |
1177 | ||
1178 | Kaufman, et al. Standards Track [Page 21] | |
2eac2578 | 1179 | \f |
824a0402 AS |
1180 | RFC 5996 IKEv2bis September 2010 |
1181 | ||
1182 | ||
1183 | Section 2.18 requires doing a Diffie-Hellman exchange when rekeying | |
1184 | the IKE_SA. In theory, RFC 4306 allowed a policy where the Diffie- | |
1185 | Hellman exchange was optional, but this was not useful (or | |
1186 | appropriate) when rekeying the IKE_SA. | |
1187 | ||
1188 | Section 2.21 has been greatly expanded to cover the different cases | |
1189 | where error responses are needed and the appropriate responses to | |
1190 | them. | |
1191 | ||
1192 | Section 2.23 clarified that, in NAT traversal, now both UDP- | |
1193 | encapsulated IPsec packets and non-UDP-encapsulated IPsec packets | |
1194 | need to be understood when receiving. | |
1195 | ||
1196 | Added Section 2.23.1 to describe NAT traversal when transport mode is | |
1197 | requested. | |
1198 | ||
1199 | Added Section 2.25 to explain how to act when there are timing | |
1200 | collisions when deleting and/or rekeying SAs, and two new error | |
1201 | notifications (TEMPORARY_FAILURE and CHILD_SA_NOT_FOUND) were | |
1202 | defined. | |
a6d7a610 | 1203 | |
824a0402 AS |
1204 | In Section 3.6, "Implementations MUST support the HTTP method for |
1205 | hash-and-URL lookup. The behavior of other URL methods is not | |
1206 | currently specified, and such methods SHOULD NOT be used in the | |
1207 | absence of a document specifying them" was added. | |
1208 | ||
1209 | In Section 3.15.3, a pointer to a new document that is related to | |
1210 | configuration of IPv6 addresses was added. | |
1211 | ||
1212 | Appendix C was expanded and clarified. | |
a6d7a610 MW |
1213 | |
1214 | 2. IKE Protocol Details and Variations | |
1215 | ||
1216 | IKE normally listens and sends on UDP port 500, though IKE messages | |
1217 | may also be received on UDP port 4500 with a slightly different | |
1218 | format (see Section 2.23). Since UDP is a datagram (unreliable) | |
1219 | protocol, IKE includes in its definition recovery from transmission | |
1220 | errors, including packet loss, packet replay, and packet forgery. | |
1221 | IKE is designed to function so long as (1) at least one of a series | |
1222 | of retransmitted packets reaches its destination before timing out; | |
1223 | and (2) the channel is not so full of forged and replayed packets so | |
1224 | as to exhaust the network or CPU capacities of either endpoint. Even | |
1225 | in the absence of those minimum performance requirements, IKE is | |
1226 | designed to fail cleanly (as though the network were broken). | |
1227 | ||
1228 | Although IKEv2 messages are intended to be short, they contain | |
824a0402 | 1229 | structures with no hard upper bound on size (in particular, digital |
a6d7a610 | 1230 | certificates), and IKEv2 itself does not have a mechanism for |
824a0402 AS |
1231 | |
1232 | ||
1233 | ||
1234 | Kaufman, et al. Standards Track [Page 22] | |
1235 | \f | |
1236 | RFC 5996 IKEv2bis September 2010 | |
1237 | ||
1238 | ||
a6d7a610 | 1239 | fragmenting large messages. IP defines a mechanism for fragmentation |
824a0402 | 1240 | of oversized UDP messages, but implementations vary in the maximum |
a6d7a610 | 1241 | message size supported. Furthermore, use of IP fragmentation opens |
824a0402 | 1242 | an implementation to denial-of-service (DoS) attacks [DOSUDPPROT]. |
a6d7a610 MW |
1243 | Finally, some NAT and/or firewall implementations may block IP |
1244 | fragments. | |
1245 | ||
1246 | All IKEv2 implementations MUST be able to send, receive, and process | |
1247 | IKE messages that are up to 1280 octets long, and they SHOULD be able | |
1248 | to send, receive, and process messages that are up to 3000 octets | |
2eac2578 MW |
1249 | long. IKEv2 implementations need to be aware of the maximum UDP |
1250 | message size supported and MAY shorten messages by leaving out some | |
1251 | certificates or cryptographic suite proposals if that will keep | |
1252 | messages below the maximum. Use of the "Hash and URL" formats rather | |
1253 | than including certificates in exchanges where possible can avoid | |
1254 | most problems. Implementations and configuration need to keep in | |
1255 | mind, however, that if the URL lookups are possible only after the | |
824a0402 | 1256 | Child SA is established, recursion issues could prevent this |
2eac2578 MW |
1257 | technique from working. |
1258 | ||
1259 | The UDP payload of all packets containing IKE messages sent on port | |
1260 | 4500 MUST begin with the prefix of four zeros; otherwise, the | |
1261 | receiver won't know how to handle them. | |
a6d7a610 | 1262 | |
a6d7a610 MW |
1263 | 2.1. Use of Retransmission Timers |
1264 | ||
1265 | All messages in IKE exist in pairs: a request and a response. The | |
824a0402 AS |
1266 | setup of an IKE SA normally consists of two exchanges. Once the IKE |
1267 | SA is set up, either end of the Security Association may initiate | |
1268 | requests at any time, and there can be many requests and responses | |
1269 | "in flight" at any given moment. But each message is labeled as | |
1270 | either a request or a response, and for each exchange, one end of the | |
1271 | Security Association is the initiator and the other is the responder. | |
a6d7a610 MW |
1272 | |
1273 | For every pair of IKE messages, the initiator is responsible for | |
1274 | retransmission in the event of a timeout. The responder MUST never | |
1275 | retransmit a response unless it receives a retransmission of the | |
1276 | request. In that event, the responder MUST ignore the retransmitted | |
824a0402 AS |
1277 | request except insofar as it causes a retransmission of the response. |
1278 | The initiator MUST remember each request until it receives the | |
1279 | corresponding response. The responder MUST remember each response | |
1280 | until it receives a request whose sequence number is larger than or | |
1281 | equal to the sequence number in the response plus its window size | |
1282 | (see Section 2.3). In order to allow saving memory, responders are | |
1283 | allowed to forget the response after a timeout of several minutes. | |
82f0707f MW |
1284 | If the responder receives a retransmitted request for which it has |
1285 | already forgotten the response, it MUST ignore the request (and not, | |
1286 | for example, attempt constructing a new response). | |
a6d7a610 | 1287 | |
824a0402 AS |
1288 | |
1289 | ||
1290 | Kaufman, et al. Standards Track [Page 23] | |
1291 | \f | |
1292 | RFC 5996 IKEv2bis September 2010 | |
1293 | ||
1294 | ||
1295 | IKE is a reliable protocol: the initiator MUST retransmit a request | |
1296 | until it either receives a corresponding response or deems the IKE SA | |
1297 | to have failed. In the latter case, the initiator discards all state | |
1298 | associated with the IKE SA and any Child SAs that were negotiated | |
1299 | using that IKE SA. A retransmission from the initiator MUST be | |
1300 | bitwise identical to the original request. That is, everything | |
1301 | starting from the IKE header (the IKE SA initiator's SPI onwards) | |
1302 | must be bitwise identical; items before it (such as the IP and UDP | |
1303 | headers) do not have to be identical. | |
a6d7a610 | 1304 | |
2eac2578 MW |
1305 | Retransmissions of the IKE_SA_INIT request require some special |
1306 | handling. When a responder receives an IKE_SA_INIT request, it has | |
1307 | to determine whether the packet is a retransmission belonging to an | |
1308 | existing "half-open" IKE SA (in which case the responder retransmits | |
1309 | the same response), or a new request (in which case the responder | |
1310 | creates a new IKE SA and sends a fresh response), or it belongs to an | |
1311 | existing IKE SA where the IKE_AUTH request has been already received | |
1312 | (in which case the responder ignores it). | |
a6d7a610 MW |
1313 | |
1314 | It is not sufficient to use the initiator's SPI and/or IP address to | |
1315 | differentiate between these three cases because two different peers | |
1316 | behind a single NAT could choose the same initiator SPI. Instead, a | |
1317 | robust responder will do the IKE SA lookup using the whole packet, | |
1318 | its hash, or the Ni payload. | |
1319 | ||
824a0402 AS |
1320 | The retransmission policy for one-way messages is somewhat different |
1321 | from that for regular messages. Because no acknowledgement is ever | |
1322 | sent, there is no reason to gratuitously retransmit one-way messages. | |
1323 | Given that all these messages are errors, it makes sense to send them | |
1324 | only once per "offending" packet, and only retransmit if further | |
1325 | offending packets are received. Still, it also makes sense to limit | |
1326 | retransmissions of such error messages. | |
2eac2578 | 1327 | |
824a0402 | 1328 | 2.2. Use of Sequence Numbers for Message ID |
2eac2578 | 1329 | |
824a0402 AS |
1330 | Every IKE message contains a Message ID as part of its fixed header. |
1331 | This Message ID is used to match up requests and responses and to | |
1332 | identify retransmissions of messages. Retransmission of a message | |
1333 | MUST use the same Message ID as the original message. | |
2eac2578 | 1334 | |
824a0402 AS |
1335 | The Message ID is a 32-bit quantity, which is zero for the |
1336 | IKE_SA_INIT messages (including retries of the message due to | |
1337 | responses such as COOKIE and INVALID_KE_PAYLOAD), and incremented for | |
1338 | each subsequent exchange. Thus, the first pair of IKE_AUTH messages | |
1339 | will have an ID of 1, the second (when EAP is used) will be 2, and so | |
1340 | on. The Message ID is reset to zero in the new IKE SA after the IKE | |
1341 | SA is rekeyed. | |
2eac2578 MW |
1342 | |
1343 | ||
1344 | ||
a6d7a610 | 1345 | |
824a0402 AS |
1346 | Kaufman, et al. Standards Track [Page 24] |
1347 | \f | |
1348 | RFC 5996 IKEv2bis September 2010 | |
a6d7a610 | 1349 | |
a6d7a610 MW |
1350 | |
1351 | Each endpoint in the IKE Security Association maintains two "current" | |
1352 | Message IDs: the next one to be used for a request it initiates and | |
1353 | the next one it expects to see in a request from the other end. | |
1354 | These counters increment as requests are generated and received. | |
824a0402 | 1355 | Responses always contain the same Message ID as the corresponding |
a6d7a610 | 1356 | request. That means that after the initial exchange, each integer n |
824a0402 | 1357 | may appear as the Message ID in four distinct messages: the nth |
a6d7a610 MW |
1358 | request from the original IKE initiator, the corresponding response, |
1359 | the nth request from the original IKE responder, and the | |
824a0402 | 1360 | corresponding response. If the two ends make a very different number |
a6d7a610 MW |
1361 | of requests, the Message IDs in the two directions can be very |
1362 | different. There is no ambiguity in the messages, however, because | |
824a0402 AS |
1363 | the Initiator and Response flags in the message header specify which |
1364 | of the four messages a particular one is. | |
a6d7a610 | 1365 | |
2eac2578 | 1366 | Throughout this document, "initiator" refers to the party who |
824a0402 AS |
1367 | initiated the exchange being described. The "original initiator" |
1368 | always refers to the party who initiated the exchange that resulted | |
1369 | in the current IKE SA. In other words, if the "original responder" | |
1370 | starts rekeying the IKE SA, that party becomes the "original | |
1371 | initiator" of the new IKE SA. | |
a6d7a610 MW |
1372 | |
1373 | Note that Message IDs are cryptographically protected and provide | |
1374 | protection against message replays. In the unlikely event that | |
1375 | Message IDs grow too large to fit in 32 bits, the IKE SA MUST be | |
1376 | closed or rekeyed. | |
1377 | ||
1378 | 2.3. Window Size for Overlapping Requests | |
1379 | ||
2eac2578 MW |
1380 | The SET_WINDOW_SIZE notification asserts that the sending endpoint is |
1381 | capable of keeping state for multiple outstanding exchanges, | |
1382 | permitting the recipient to send multiple requests before getting a | |
1383 | response to the first. The data associated with a SET_WINDOW_SIZE | |
2eac2578 MW |
1384 | notification MUST be 4 octets long and contain the big endian |
1385 | representation of the number of messages the sender promises to keep. | |
1386 | The window size is always one until the initial exchanges complete. | |
a6d7a610 MW |
1387 | |
1388 | An IKE endpoint MUST wait for a response to each of its messages | |
1389 | before sending a subsequent message unless it has received a | |
1390 | SET_WINDOW_SIZE Notify message from its peer informing it that the | |
1391 | peer is prepared to maintain state for multiple outstanding messages | |
1392 | in order to allow greater throughput. | |
1393 | ||
82f0707f MW |
1394 | After an IKE SA is set up, in order to maximize IKE throughput, an |
1395 | IKE endpoint MAY issue multiple requests before getting a response to | |
1396 | any of them, up to the limit set by its peer's SET_WINDOW_SIZE. | |
1397 | These requests may pass one another over the network. An IKE | |
1398 | endpoint MUST be prepared to accept and process a request while it | |
824a0402 AS |
1399 | |
1400 | ||
1401 | ||
1402 | Kaufman, et al. Standards Track [Page 25] | |
1403 | \f | |
1404 | RFC 5996 IKEv2bis September 2010 | |
1405 | ||
1406 | ||
82f0707f | 1407 | has a request outstanding in order to avoid a deadlock in this |
2eac2578 MW |
1408 | situation. An IKE endpoint may also accept and process multiple |
1409 | requests while it has a request outstanding. | |
82f0707f | 1410 | |
a6d7a610 MW |
1411 | An IKE endpoint MUST NOT exceed the peer's stated window size for |
1412 | transmitted IKE requests. In other words, if the responder stated | |
1413 | its window size is N, then when the initiator needs to make a request | |
1414 | X, it MUST wait until it has received responses to all requests up | |
1415 | through request X-N. An IKE endpoint MUST keep a copy of (or be able | |
1416 | to regenerate exactly) each request it has sent until it receives the | |
1417 | corresponding response. An IKE endpoint MUST keep a copy of (or be | |
1418 | able to regenerate exactly) the number of previous responses equal to | |
1419 | its declared window size in case its response was lost and the | |
2eac2578 | 1420 | initiator requests its retransmission by retransmitting the request. |
82f0707f | 1421 | |
2eac2578 MW |
1422 | An IKE endpoint supporting a window size greater than one ought to be |
1423 | capable of processing incoming requests out of order to maximize | |
1424 | performance in the event of network failures or packet reordering. | |
82f0707f | 1425 | |
2eac2578 MW |
1426 | The window size is normally a (possibly configurable) property of a |
1427 | particular implementation, and is not related to congestion control | |
824a0402 AS |
1428 | (unlike the window size in TCP, for example). In particular, what |
1429 | the responder should do when it receives a SET_WINDOW_SIZE | |
1430 | notification containing a smaller value than is currently in effect | |
1431 | is not defined. Thus, there is currently no way to reduce the window | |
1432 | size of an existing IKE SA; you can only increase it. When rekeying | |
1433 | an IKE SA, the new IKE SA starts with window size 1 until it is | |
1434 | explicitly increased by sending a new SET_WINDOW_SIZE notification. | |
1435 | ||
1436 | The INVALID_MESSAGE_ID notification is sent when an IKE Message ID | |
1437 | outside the supported window is received. This Notify message MUST | |
1438 | NOT be sent in a response; the invalid request MUST NOT be | |
1439 | acknowledged. Instead, inform the other side by initiating an | |
1440 | INFORMATIONAL exchange with Notification data containing the four- | |
1441 | octet invalid Message ID. Sending this notification is OPTIONAL, and | |
1442 | notifications of this type MUST be rate limited. | |
a6d7a610 MW |
1443 | |
1444 | 2.4. State Synchronization and Connection Timeouts | |
1445 | ||
1446 | An IKE endpoint is allowed to forget all of its state associated with | |
1447 | an IKE SA and the collection of corresponding Child SAs at any time. | |
1448 | This is the anticipated behavior in the event of an endpoint crash | |
1449 | and restart. It is important when an endpoint either fails or | |
1450 | reinitializes its state that the other endpoint detect those | |
1451 | conditions and not continue to waste network bandwidth by sending | |
1452 | packets over discarded SAs and having them fall into a black hole. | |
1453 | ||
824a0402 AS |
1454 | |
1455 | ||
1456 | ||
1457 | ||
1458 | Kaufman, et al. Standards Track [Page 26] | |
1459 | \f | |
1460 | RFC 5996 IKEv2bis September 2010 | |
1461 | ||
1462 | ||
2eac2578 MW |
1463 | The INITIAL_CONTACT notification asserts that this IKE SA is the only |
1464 | IKE SA currently active between the authenticated identities. It MAY | |
1465 | be sent when an IKE SA is established after a crash, and the | |
1466 | recipient MAY use this information to delete any other IKE SAs it has | |
1467 | to the same authenticated identity without waiting for a timeout. | |
1468 | This notification MUST NOT be sent by an entity that may be | |
1469 | replicated (e.g., a roaming user's credentials where the user is | |
a6d7a610 | 1470 | allowed to connect to the corporate firewall from two remote systems |
2eac2578 MW |
1471 | at the same time). The INITIAL_CONTACT notification, if sent, MUST |
1472 | be in the first IKE_AUTH request or response, not as a separate | |
824a0402 | 1473 | exchange afterwards; receiving parties MAY ignore it in other |
2eac2578 | 1474 | messages. |
a6d7a610 | 1475 | |
824a0402 AS |
1476 | Since IKE is designed to operate in spite of DoS attacks from the |
1477 | network, an endpoint MUST NOT conclude that the other endpoint has | |
1478 | failed based on any routing information (e.g., ICMP messages) or IKE | |
1479 | messages that arrive without cryptographic protection (e.g., Notify | |
1480 | messages complaining about unknown SPIs). An endpoint MUST conclude | |
1481 | that the other endpoint has failed only when repeated attempts to | |
1482 | contact it have gone unanswered for a timeout period or when a | |
1483 | cryptographically protected INITIAL_CONTACT notification is received | |
1484 | on a different IKE SA to the same authenticated identity. An | |
1485 | endpoint should suspect that the other endpoint has failed based on | |
1486 | routing information and initiate a request to see whether the other | |
1487 | endpoint is alive. To check whether the other side is alive, IKE | |
1488 | specifies an empty INFORMATIONAL message that (like all IKE requests) | |
1489 | requires an acknowledgement (note that within the context of an IKE | |
1490 | SA, an "empty" message consists of an IKE header followed by an | |
1491 | Encrypted payload that contains no payloads). If a cryptographically | |
1492 | protected (fresh, i.e., not retransmitted) message has been received | |
1493 | from the other side recently, unprotected Notify messages MAY be | |
1494 | ignored. Implementations MUST limit the rate at which they take | |
1495 | actions based on unprotected messages. | |
1496 | ||
1497 | The number of retries and length of timeouts are not covered in this | |
a6d7a610 MW |
1498 | specification because they do not affect interoperability. It is |
1499 | suggested that messages be retransmitted at least a dozen times over | |
1500 | a period of at least several minutes before giving up on an SA, but | |
1501 | different environments may require different rules. To be a good | |
824a0402 | 1502 | network citizen, retransmission times MUST increase exponentially to |
a6d7a610 MW |
1503 | avoid flooding the network and making an existing congestion |
1504 | situation worse. If there has only been outgoing traffic on all of | |
1505 | the SAs associated with an IKE SA, it is essential to confirm | |
1506 | liveness of the other endpoint to avoid black holes. If no | |
1507 | cryptographically protected messages have been received on an IKE SA | |
1508 | or any of its Child SAs recently, the system needs to perform a | |
1509 | liveness check in order to prevent sending messages to a dead peer. | |
1510 | (This is sometimes called "dead peer detection" or "DPD", although it | |
824a0402 AS |
1511 | |
1512 | ||
1513 | ||
1514 | Kaufman, et al. Standards Track [Page 27] | |
1515 | \f | |
1516 | RFC 5996 IKEv2bis September 2010 | |
1517 | ||
1518 | ||
a6d7a610 MW |
1519 | is really detecting live peers, not dead ones.) Receipt of a fresh |
1520 | cryptographically protected message on an IKE SA or any of its Child | |
1521 | SAs ensures liveness of the IKE SA and all of its Child SAs. Note | |
1522 | that this places requirements on the failure modes of an IKE | |
824a0402 | 1523 | endpoint. An implementation needs to stop sending over any SA if |
a6d7a610 | 1524 | some failure prevents it from receiving on all of the associated SAs. |
824a0402 AS |
1525 | If a system creates Child SAs that can fail independently from one |
1526 | another without the associated IKE SA being able to send a delete | |
1527 | message, then the system MUST negotiate such Child SAs using separate | |
1528 | IKE SAs. | |
1529 | ||
1530 | There is a DoS attack on the initiator of an IKE SA that can be | |
1531 | avoided if the initiator takes the proper care. Since the first two | |
1532 | messages of an SA setup are not cryptographically protected, an | |
1533 | attacker could respond to the initiator's message before the genuine | |
1534 | responder and poison the connection setup attempt. To prevent this, | |
1535 | the initiator MAY be willing to accept multiple responses to its | |
1536 | first message, treat each as potentially legitimate, respond to it, | |
1537 | and then discard all the invalid half-open connections when it | |
1538 | receives a valid cryptographically protected response to any one of | |
1539 | its requests. Once a cryptographically valid response is received, | |
1540 | all subsequent responses should be ignored whether or not they are | |
1541 | cryptographically valid. | |
a6d7a610 MW |
1542 | |
1543 | Note that with these rules, there is no reason to negotiate and agree | |
a6d7a610 MW |
1544 | upon an SA lifetime. If IKE presumes the partner is dead, based on |
1545 | repeated lack of acknowledgement to an IKE message, then the IKE SA | |
1546 | and all Child SAs set up through that IKE SA are deleted. | |
1547 | ||
1548 | An IKE endpoint may at any time delete inactive Child SAs to recover | |
1549 | resources used to hold their state. If an IKE endpoint chooses to | |
1550 | delete Child SAs, it MUST send Delete payloads to the other end | |
1551 | notifying it of the deletion. It MAY similarly time out the IKE SA. | |
2eac2578 MW |
1552 | Closing the IKE SA implicitly closes all associated Child SAs. In |
1553 | this case, an IKE endpoint SHOULD send a Delete payload indicating | |
1554 | that it has closed the IKE SA unless the other endpoint is no longer | |
1555 | responding. | |
a6d7a610 MW |
1556 | |
1557 | 2.5. Version Numbers and Forward Compatibility | |
1558 | ||
1559 | This document describes version 2.0 of IKE, meaning the major version | |
2eac2578 MW |
1560 | number is 2 and the minor version number is 0. This document is a |
1561 | replacement for [IKEV2]. It is likely that some implementations will | |
1562 | want to support version 1.0 and version 2.0, and in the future, other | |
1563 | versions. | |
a6d7a610 | 1564 | |
824a0402 AS |
1565 | |
1566 | ||
1567 | ||
1568 | ||
1569 | ||
1570 | Kaufman, et al. Standards Track [Page 28] | |
1571 | \f | |
1572 | RFC 5996 IKEv2bis September 2010 | |
1573 | ||
1574 | ||
a6d7a610 MW |
1575 | The major version number should be incremented only if the packet |
1576 | formats or required actions have changed so dramatically that an | |
1577 | older version node would not be able to interoperate with a newer | |
1578 | version node if it simply ignored the fields it did not understand | |
1579 | and took the actions specified in the older specification. The minor | |
1580 | version number indicates new capabilities, and MUST be ignored by a | |
1581 | node with a smaller minor version number, but used for informational | |
1582 | purposes by the node with the larger minor version number. For | |
1583 | example, it might indicate the ability to process a newly defined | |
824a0402 | 1584 | Notify message type. The node with the larger minor version number |
a6d7a610 MW |
1585 | would simply note that its correspondent would not be able to |
1586 | understand that message and therefore would not send it. | |
1587 | ||
2eac2578 | 1588 | If an endpoint receives a message with a higher major version number, |
824a0402 AS |
1589 | it MUST drop the message and SHOULD send an unauthenticated Notify |
1590 | message of type INVALID_MAJOR_VERSION containing the highest | |
1591 | (closest) version number it supports. If an endpoint supports major | |
1592 | version n, and major version m, it MUST support all versions between | |
1593 | n and m. If it receives a message with a major version that it | |
1594 | supports, it MUST respond with that version number. In order to | |
1595 | prevent two nodes from being tricked into corresponding with a lower | |
1596 | major version number than the maximum that they both support, IKE has | |
1597 | a flag that indicates that the node is capable of speaking a higher | |
1598 | major version number. | |
a6d7a610 MW |
1599 | |
1600 | Thus, the major version number in the IKE header indicates the | |
1601 | version number of the message, not the highest version number that | |
a6d7a610 MW |
1602 | the transmitter supports. If the initiator is capable of speaking |
1603 | versions n, n+1, and n+2, and the responder is capable of speaking | |
1604 | versions n and n+1, then they will negotiate speaking n+1, where the | |
1605 | initiator will set a flag indicating its ability to speak a higher | |
1606 | version. If they mistakenly (perhaps through an active attacker | |
1607 | sending error messages) negotiate to version n, then both will notice | |
1608 | that the other side can support a higher version number, and they | |
1609 | MUST break the connection and reconnect using version n+1. | |
1610 | ||
1611 | Note that IKEv1 does not follow these rules, because there is no way | |
1612 | in v1 of noting that you are capable of speaking a higher version | |
1613 | number. So an active attacker can trick two v2-capable nodes into | |
2eac2578 MW |
1614 | speaking v1. When a v2-capable node negotiates down to v1, it should |
1615 | note that fact in its logs. | |
a6d7a610 | 1616 | |
824a0402 | 1617 | Also, for forward compatibility, all fields marked RESERVED MUST be |
a6d7a610 MW |
1618 | set to zero by an implementation running version 2.0, and their |
1619 | content MUST be ignored by an implementation running version 2.0 ("Be | |
824a0402 AS |
1620 | conservative in what you send and liberal in what you receive" [IP]). |
1621 | In this way, future versions of the protocol can use those fields in | |
1622 | a way that is guaranteed to be ignored by implementations that do not | |
1623 | ||
1624 | ||
1625 | ||
1626 | Kaufman, et al. Standards Track [Page 29] | |
1627 | \f | |
1628 | RFC 5996 IKEv2bis September 2010 | |
1629 | ||
1630 | ||
a6d7a610 MW |
1631 | understand them. Similarly, payload types that are not defined are |
1632 | reserved for future use; implementations of a version where they are | |
1633 | undefined MUST skip over those payloads and ignore their contents. | |
1634 | ||
1635 | IKEv2 adds a "critical" flag to each payload header for further | |
1636 | flexibility for forward compatibility. If the critical flag is set | |
1637 | and the payload type is unrecognized, the message MUST be rejected | |
1638 | and the response to the IKE request containing that payload MUST | |
1639 | include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an | |
2eac2578 MW |
1640 | unsupported critical payload was included. In that Notify payload, |
1641 | the notification data contains the one-octet payload type. If the | |
1642 | critical flag is not set and the payload type is unsupported, that | |
1643 | payload MUST be ignored. Payloads sent in IKE response messages MUST | |
1644 | NOT have the critical flag set. Note that the critical flag applies | |
1645 | only to the payload type, not the contents. If the payload type is | |
824a0402 | 1646 | recognized, but the payload contains something that is not (such as |
2eac2578 MW |
1647 | an unknown transform inside an SA payload, or an unknown Notify |
1648 | Message Type inside a Notify payload), the critical flag is ignored. | |
a6d7a610 | 1649 | |
2eac2578 MW |
1650 | Although new payload types may be added in the future and may appear |
1651 | interleaved with the fields defined in this specification, | |
1652 | implementations SHOULD send the payloads defined in this | |
824a0402 | 1653 | specification in the order shown in the figures in Sections 1 and 2; |
2eac2578 MW |
1654 | implementations MUST NOT reject as invalid a message with those |
1655 | payloads in any other order. | |
a6d7a610 | 1656 | |
a6d7a610 MW |
1657 | 2.6. IKE SA SPIs and Cookies |
1658 | ||
824a0402 AS |
1659 | The initial two eight-octet fields in the header, called the "IKE |
1660 | SPIs", are used as a connection identifier at the beginning of IKE | |
1661 | packets. Each endpoint chooses one of the two SPIs and MUST choose | |
1662 | them so as to be unique identifiers of an IKE SA. An SPI value of | |
1663 | zero is special: it indicates that the remote SPI value is not yet | |
1664 | known by the sender. | |
a6d7a610 MW |
1665 | |
1666 | Incoming IKE packets are mapped to an IKE SA only using the packet's | |
1667 | SPI, not using (for example) the source IP address of the packet. | |
1668 | ||
1669 | Unlike ESP and AH where only the recipient's SPI appears in the | |
1670 | header of a message, in IKE the sender's SPI is also sent in every | |
1671 | message. Since the SPI chosen by the original initiator of the IKE | |
1672 | SA is always sent first, an endpoint with multiple IKE SAs open that | |
1673 | wants to find the appropriate IKE SA using the SPI it assigned must | |
824a0402 AS |
1674 | look at the Initiator flag in the header to determine whether it |
1675 | assigned the first or the second eight octets. | |
1676 | ||
1677 | ||
1678 | ||
1679 | ||
1680 | ||
1681 | ||
1682 | Kaufman, et al. Standards Track [Page 30] | |
1683 | \f | |
1684 | RFC 5996 IKEv2bis September 2010 | |
1685 | ||
a6d7a610 MW |
1686 | |
1687 | In the first message of an initial IKE exchange, the initiator will | |
1688 | not know the responder's SPI value and will therefore set that field | |
824a0402 AS |
1689 | to zero. When the IKE_SA_INIT exchange does not result in the |
1690 | creation of an IKE SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, | |
1691 | or COOKIE (see Section 2.6), the responder's SPI will be zero also in | |
1692 | the response message. However, if the responder sends a non-zero | |
1693 | responder SPI, the initiator should not reject the response for only | |
1694 | that reason. | |
1695 | ||
1696 | Two expected attacks against IKE are state and CPU exhaustion, where | |
1697 | the target is flooded with session initiation requests from forged IP | |
1698 | addresses. These attacks can be made less effective if a responder | |
1699 | uses minimal CPU and commits no state to an SA until it knows the | |
1700 | initiator can receive packets at the address from which it claims to | |
1701 | be sending them. | |
a6d7a610 | 1702 | |
2eac2578 MW |
1703 | When a responder detects a large number of half-open IKE SAs, it |
1704 | SHOULD reply to IKE_SA_INIT requests with a response containing the | |
1705 | COOKIE notification. The data associated with this notification MUST | |
1706 | be between 1 and 64 octets in length (inclusive), and its generation | |
1707 | is described later in this section. If the IKE_SA_INIT response | |
1708 | includes the COOKIE notification, the initiator MUST then retry the | |
1709 | IKE_SA_INIT request, and include the COOKIE notification containing | |
1710 | the received data as the first payload, and all other payloads | |
1711 | unchanged. The initial exchange will then be as follows: | |
1712 | ||
a6d7a610 MW |
1713 | Initiator Responder |
1714 | ------------------------------------------------------------------- | |
1715 | HDR(A,0), SAi1, KEi, Ni --> | |
1716 | <-- HDR(A,0), N(COOKIE) | |
1717 | HDR(A,0), N(COOKIE), SAi1, | |
1718 | KEi, Ni --> | |
1719 | <-- HDR(A,B), SAr1, KEr, | |
1720 | Nr, [CERTREQ] | |
1721 | HDR(A,B), SK {IDi, [CERT,] | |
1722 | [CERTREQ,] [IDr,] AUTH, | |
1723 | SAi2, TSi, TSr} --> | |
1724 | <-- HDR(A,B), SK {IDr, [CERT,] | |
1725 | AUTH, SAr2, TSi, TSr} | |
1726 | ||
1727 | The first two messages do not affect any initiator or responder state | |
1728 | except for communicating the cookie. In particular, the message | |
1729 | sequence numbers in the first four messages will all be zero and the | |
1730 | message sequence numbers in the last two messages will be one. 'A' | |
1731 | is the SPI assigned by the initiator, while 'B' is the SPI assigned | |
1732 | by the responder. | |
1733 | ||
824a0402 AS |
1734 | |
1735 | ||
1736 | ||
1737 | ||
1738 | Kaufman, et al. Standards Track [Page 31] | |
1739 | \f | |
1740 | RFC 5996 IKEv2bis September 2010 | |
1741 | ||
1742 | ||
2eac2578 MW |
1743 | An IKE implementation can implement its responder cookie generation |
1744 | in such a way as to not require any saved state to recognize its | |
1745 | valid cookie when the second IKE_SA_INIT message arrives. The exact | |
824a0402 | 1746 | algorithms and syntax used to generate cookies do not affect |
2eac2578 MW |
1747 | interoperability and hence are not specified here. The following is |
1748 | an example of how an endpoint could use cookies to implement limited | |
824a0402 | 1749 | DoS protection. |
a6d7a610 MW |
1750 | |
1751 | A good way to do this is to set the responder cookie to be: | |
1752 | ||
1753 | Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>) | |
1754 | ||
1755 | where <secret> is a randomly generated secret known only to the | |
1756 | responder and periodically changed and | indicates concatenation. | |
1757 | <VersionIDofSecret> should be changed whenever <secret> is | |
1758 | regenerated. The cookie can be recomputed when the IKE_SA_INIT | |
1759 | arrives the second time and compared to the cookie in the received | |
1760 | message. If it matches, the responder knows that the cookie was | |
1761 | generated since the last change to <secret> and that IPi must be the | |
1762 | same as the source address it saw the first time. Incorporating SPIi | |
1763 | into the calculation ensures that if multiple IKE SAs are being set | |
1764 | up in parallel they will all get different cookies (assuming the | |
82f0707f | 1765 | initiator chooses unique SPIi's). Incorporating Ni in the hash |
a6d7a610 | 1766 | ensures that an attacker who sees only message 2 can't successfully |
824a0402 AS |
1767 | forge a message 3. Also, incorporating SPIi in the hash prevents an |
1768 | attacker from fetching one cookie from the other end, and then | |
82f0707f MW |
1769 | initiating many IKE_SA_INIT exchanges all with different initiator |
1770 | SPIs (and perhaps port numbers) so that the responder thinks that | |
824a0402 | 1771 | there are a lot of machines behind one NAT box that are all trying to |
82f0707f | 1772 | connect. |
a6d7a610 MW |
1773 | |
1774 | If a new value for <secret> is chosen while there are connections in | |
a6d7a610 MW |
1775 | the process of being initialized, an IKE_SA_INIT might be returned |
1776 | with other than the current <VersionIDofSecret>. The responder in | |
1777 | that case MAY reject the message by sending another response with a | |
1778 | new cookie or it MAY keep the old value of <secret> around for a | |
2eac2578 MW |
1779 | short time and accept cookies computed from either one. The |
1780 | responder should not accept cookies indefinitely after <secret> is | |
824a0402 AS |
1781 | changed, since that would defeat part of the DoS protection. The |
1782 | responder should change the value of <secret> frequently, especially | |
1783 | if under attack. | |
2eac2578 MW |
1784 | |
1785 | When one party receives an IKE_SA_INIT request containing a cookie | |
1786 | whose contents do not match the value expected, that party MUST | |
1787 | ignore the cookie and process the message as if no cookie had been | |
1788 | included; usually this means sending a response containing a new | |
1789 | cookie. The initiator should limit the number of cookie exchanges it | |
824a0402 AS |
1790 | tries before giving up, possibly using exponential back-off. An |
1791 | ||
1792 | ||
1793 | ||
1794 | Kaufman, et al. Standards Track [Page 32] | |
1795 | \f | |
1796 | RFC 5996 IKEv2bis September 2010 | |
1797 | ||
1798 | ||
1799 | attacker can forge multiple cookie responses to the initiator's | |
1800 | IKE_SA_INIT message, and each of those forged cookie replies will | |
1801 | cause two packets to be sent: one packet from the initiator to the | |
1802 | responder (which will reject those cookies), and one response from | |
1803 | responder to initiator that includes the correct cookie. | |
1804 | ||
1805 | A note on terminology: the term "cookies" originates with Karn and | |
1806 | Simpson [PHOTURIS] in Photuris, an early proposal for key management | |
1807 | with IPsec, and it has persisted. The Internet Security Association | |
1808 | and Key Management Protocol (ISAKMP) [ISAKMP] fixed message header | |
1809 | includes two eight-octet fields called "cookies", and that syntax is | |
1810 | used by both IKEv1 and IKEv2, although in IKEv2 they are referred to | |
1811 | as the "IKE SPI" and there is a new separate field in a Notify | |
1812 | payload holding the cookie. | |
82f0707f MW |
1813 | |
1814 | 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD | |
1815 | ||
82f0707f MW |
1816 | There are two common reasons why the initiator may have to retry the |
1817 | IKE_SA_INIT exchange: the responder requests a cookie or wants a | |
1818 | different Diffie-Hellman group than was included in the KEi payload. | |
a6d7a610 MW |
1819 | If the initiator receives a cookie from the responder, the initiator |
1820 | needs to decide whether or not to include the cookie in only the next | |
1821 | retry of the IKE_SA_INIT request, or in all subsequent retries as | |
1822 | well. | |
1823 | ||
1824 | If the initiator includes the cookie only in the next retry, one | |
824a0402 AS |
1825 | additional round trip may be needed in some cases. An additional |
1826 | round trip is needed also if the initiator includes the cookie in all | |
a6d7a610 | 1827 | retries, but the responder does not support this. For instance, if |
824a0402 AS |
1828 | the responder includes the KEi payloads in cookie calculation, it |
1829 | will reject the request by sending a new cookie. | |
a6d7a610 | 1830 | |
a6d7a610 MW |
1831 | If both peers support including the cookie in all retries, a slightly |
1832 | shorter exchange can happen. | |
1833 | ||
1834 | Initiator Responder | |
1835 | ----------------------------------------------------------- | |
1836 | HDR(A,0), SAi1, KEi, Ni --> | |
1837 | <-- HDR(A,0), N(COOKIE) | |
1838 | HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> | |
1839 | <-- HDR(A,0), N(INVALID_KE_PAYLOAD) | |
1840 | HDR(A,0), N(COOKIE), SAi1, KEi', Ni --> | |
1841 | <-- HDR(A,B), SAr1, KEr, Nr | |
1842 | ||
1843 | Implementations SHOULD support this shorter exchange, but MUST NOT | |
1844 | fail if other implementations do not support this shorter exchange. | |
1845 | ||
824a0402 AS |
1846 | |
1847 | ||
1848 | ||
1849 | ||
1850 | Kaufman, et al. Standards Track [Page 33] | |
1851 | \f | |
1852 | RFC 5996 IKEv2bis September 2010 | |
1853 | ||
1854 | ||
a6d7a610 MW |
1855 | 2.7. Cryptographic Algorithm Negotiation |
1856 | ||
1857 | The payload type known as "SA" indicates a proposal for a set of | |
1858 | choices of IPsec protocols (IKE, ESP, or AH) for the SA as well as | |
1859 | cryptographic algorithms associated with each protocol. | |
1860 | ||
2eac2578 MW |
1861 | An SA payload consists of one or more proposals. Each proposal |
1862 | includes one protocol. Each protocol contains one or more transforms | |
1863 | -- each specifying a cryptographic algorithm. Each transform | |
1864 | contains zero or more attributes (attributes are needed only if the | |
824a0402 | 1865 | Transform ID does not completely specify the cryptographic |
2eac2578 | 1866 | algorithm). |
a6d7a610 MW |
1867 | |
1868 | This hierarchical structure was designed to efficiently encode | |
1869 | proposals for cryptographic suites when the number of supported | |
1870 | suites is large because multiple values are acceptable for multiple | |
1871 | transforms. The responder MUST choose a single suite, which may be | |
824a0402 | 1872 | any subset of the SA proposal following the rules below. |
a6d7a610 | 1873 | |
2eac2578 MW |
1874 | Each proposal contains one protocol. If a proposal is accepted, the |
1875 | SA response MUST contain the same protocol. The responder MUST | |
1876 | accept a single proposal or reject them all and return an error. The | |
1877 | error is given in a notification of type NO_PROPOSAL_CHOSEN. | |
a6d7a610 MW |
1878 | |
1879 | Each IPsec protocol proposal contains one or more transforms. Each | |
824a0402 | 1880 | transform contains a Transform Type. The accepted cryptographic |
a6d7a610 MW |
1881 | suite MUST contain exactly one transform of each type included in the |
1882 | proposal. For example: if an ESP proposal includes transforms | |
1883 | ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256, | |
1884 | AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one | |
1885 | of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six | |
1886 | combinations are acceptable. | |
1887 | ||
a6d7a610 MW |
1888 | If an initiator proposes both normal ciphers with integrity |
1889 | protection as well as combined-mode ciphers, then two proposals are | |
1890 | needed. One of the proposals includes the normal ciphers with the | |
824a0402 AS |
1891 | integrity algorithms for them, and the other proposal includes all |
1892 | the combined-mode ciphers without the integrity algorithms (because | |
1893 | combined-mode ciphers are not allowed to have any integrity algorithm | |
a6d7a610 MW |
1894 | other than "none"). |
1895 | ||
a6d7a610 MW |
1896 | 2.8. Rekeying |
1897 | ||
824a0402 | 1898 | IKE, ESP, and AH Security Associations use secret keys that should be |
2eac2578 | 1899 | used only for a limited amount of time and to protect a limited |
824a0402 AS |
1900 | amount of data. This limits the lifetime of the entire Security |
1901 | Association. When the lifetime of a Security Association expires, | |
1902 | the Security Association MUST NOT be used. If there is demand, new | |
1903 | ||
1904 | ||
1905 | ||
1906 | Kaufman, et al. Standards Track [Page 34] | |
1907 | \f | |
1908 | RFC 5996 IKEv2bis September 2010 | |
1909 | ||
1910 | ||
1911 | Security Associations MAY be established. Reestablishment of | |
1912 | Security Associations to take the place of ones that expire is | |
2eac2578 | 1913 | referred to as "rekeying". |
a6d7a610 MW |
1914 | |
1915 | To allow for minimal IPsec implementations, the ability to rekey SAs | |
1916 | without restarting the entire IKE SA is optional. An implementation | |
1917 | MAY refuse all CREATE_CHILD_SA requests within an IKE SA. If an SA | |
1918 | has expired or is about to expire and rekeying attempts using the | |
1919 | mechanisms described here fail, an implementation MUST close the IKE | |
2eac2578 MW |
1920 | SA and any associated Child SAs and then MAY start new ones. |
1921 | Implementations may wish to support in-place rekeying of SAs, since | |
1922 | doing so offers better performance and is likely to reduce the number | |
1923 | of packets lost during the transition. | |
1924 | ||
a6d7a610 | 1925 | To rekey a Child SA within an existing IKE SA, create a new, |
a6d7a610 | 1926 | equivalent SA (see Section 2.17 below), and when the new one is |
824a0402 AS |
1927 | established, delete the old one. Note that, when rekeying, the new |
1928 | Child SA SHOULD NOT have different Traffic Selectors and algorithms | |
1929 | than the old one. | |
1930 | ||
1931 | To rekey an IKE SA, establish a new equivalent IKE SA (see | |
1932 | Section 2.18 below) with the peer to whom the old IKE SA is shared | |
1933 | using a CREATE_CHILD_SA within the existing IKE SA. An IKE SA so | |
1934 | created inherits all of the original IKE SA's Child SAs, and the new | |
1935 | IKE SA is used for all control messages needed to maintain those | |
1936 | Child SAs. After the new equivalent IKE SA is created, the initiator | |
1937 | deletes the old IKE SA, and the Delete payload to delete itself MUST | |
1938 | be the last request sent over the old IKE SA. | |
a6d7a610 | 1939 | |
2eac2578 MW |
1940 | SAs should be rekeyed proactively, i.e., the new SA should be |
1941 | established before the old one expires and becomes unusable. Enough | |
1942 | time should elapse between the time the new SA is established and the | |
1943 | old one becomes unusable so that traffic can be switched over to the | |
1944 | new SA. | |
a6d7a610 MW |
1945 | |
1946 | A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes | |
1947 | were negotiated. In IKEv2, each end of the SA is responsible for | |
1948 | enforcing its own lifetime policy on the SA and rekeying the SA when | |
1949 | necessary. If the two ends have different lifetime policies, the end | |
1950 | with the shorter lifetime will end up always being the one to request | |
1951 | the rekeying. If an SA has been inactive for a long time and if an | |
1952 | endpoint would not initiate the SA in the absence of traffic, the | |
1953 | endpoint MAY choose to close the SA instead of rekeying it when its | |
824a0402 AS |
1954 | lifetime expires. It can also do so if there has been no traffic |
1955 | since the last time the SA was rekeyed. | |
1956 | ||
1957 | ||
1958 | ||
1959 | ||
1960 | ||
1961 | ||
1962 | Kaufman, et al. Standards Track [Page 35] | |
1963 | \f | |
1964 | RFC 5996 IKEv2bis September 2010 | |
1965 | ||
a6d7a610 MW |
1966 | |
1967 | Note that IKEv2 deliberately allows parallel SAs with the same | |
824a0402 | 1968 | Traffic Selectors between common endpoints. One of the purposes of |
a6d7a610 | 1969 | this is to support traffic quality of service (QoS) differences among |
824a0402 | 1970 | the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and Section 4.1 of |
a6d7a610 | 1971 | [DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints |
824a0402 | 1972 | and the Traffic Selectors may not uniquely identify an SA between |
a6d7a610 | 1973 | those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on |
824a0402 | 1974 | the basis of duplicate Traffic Selectors SHOULD NOT be used. |
a6d7a610 MW |
1975 | |
1976 | There are timing windows -- particularly in the presence of lost | |
1977 | packets -- where endpoints may not agree on the state of an SA. The | |
1978 | responder to a CREATE_CHILD_SA MUST be prepared to accept messages on | |
1979 | an SA before sending its response to the creation request, so there | |
1980 | is no ambiguity for the initiator. The initiator MAY begin sending | |
1981 | on an SA as soon as it processes the response. The initiator, | |
1982 | however, cannot receive on a newly created SA until it receives and | |
a6d7a610 MW |
1983 | processes the response to its CREATE_CHILD_SA request. How, then, is |
1984 | the responder to know when it is OK to send on the newly created SA? | |
1985 | ||
1986 | From a technical correctness and interoperability perspective, the | |
1987 | responder MAY begin sending on an SA as soon as it sends its response | |
1988 | to the CREATE_CHILD_SA request. In some situations, however, this | |
1989 | could result in packets unnecessarily being dropped, so an | |
1990 | implementation MAY defer such sending. | |
1991 | ||
1992 | The responder can be assured that the initiator is prepared to | |
1993 | receive messages on an SA if either (1) it has received a | |
824a0402 AS |
1994 | cryptographically valid message on the other half of the SA pair, or |
1995 | (2) the new SA rekeys an existing SA and it receives an IKE request | |
1996 | to close the replaced SA. When rekeying an SA, the responder | |
1997 | continues to send traffic on the old SA until one of those events | |
1998 | occurs. When establishing a new SA, the responder MAY defer sending | |
1999 | messages on a new SA until either it receives one or a timeout has | |
2000 | occurred. If an initiator receives a message on an SA for which it | |
2001 | has not received a response to its CREATE_CHILD_SA request, it | |
2002 | interprets that as a likely packet loss and retransmits the | |
2003 | CREATE_CHILD_SA request. An initiator MAY send a dummy ESP message | |
2004 | on a newly created ESP SA if it has no messages queued in order to | |
2005 | assure the responder that the initiator is ready to receive messages. | |
2006 | ||
2007 | 2.8.1. Simultaneous Child SA Rekeying | |
a6d7a610 | 2008 | |
a6d7a610 MW |
2009 | If the two ends have the same lifetime policies, it is possible that |
2010 | both will initiate a rekeying at the same time (which will result in | |
2011 | redundant SAs). To reduce the probability of this happening, the | |
2012 | timing of rekeying requests SHOULD be jittered (delayed by a random | |
2013 | amount of time after the need for rekeying is noticed). | |
2014 | ||
824a0402 AS |
2015 | |
2016 | ||
2017 | ||
2018 | Kaufman, et al. Standards Track [Page 36] | |
2019 | \f | |
2020 | RFC 5996 IKEv2bis September 2010 | |
2021 | ||
2022 | ||
a6d7a610 MW |
2023 | This form of rekeying may temporarily result in multiple similar SAs |
2024 | between the same pairs of nodes. When there are two SAs eligible to | |
2025 | receive packets, a node MUST accept incoming packets through either | |
2026 | SA. If redundant SAs are created though such a collision, the SA | |
2027 | created with the lowest of the four nonces used in the two exchanges | |
2eac2578 | 2028 | SHOULD be closed by the endpoint that created it. "Lowest" means an |
824a0402 AS |
2029 | octet-by-octet comparison (instead of, for instance, comparing the |
2030 | nonces as large integers). In other words, start by comparing the | |
2031 | first octet; if they're equal, move to the next octet, and so on. If | |
2032 | you reach the end of one nonce, that nonce is the lower one. The | |
2033 | node that initiated the surviving rekeyed SA should delete the | |
2034 | replaced SA after the new one is established. | |
a6d7a610 MW |
2035 | |
2036 | The following is an explanation on the impact this has on | |
824a0402 | 2037 | implementations. Assume that hosts A and B have an existing Child SA |
a6d7a610 MW |
2038 | pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same |
2039 | time: | |
2040 | ||
2041 | Host A Host B | |
2042 | ------------------------------------------------------------------- | |
2043 | send req1: N(REKEY_SA,SPIa1), | |
2044 | SA(..,SPIa2,..),Ni1,.. --> | |
2045 | <-- send req2: N(REKEY_SA,SPIb1), | |
2046 | SA(..,SPIb2,..),Ni2 | |
2047 | recv req2 <-- | |
2048 | ||
824a0402 | 2049 | At this point, A knows there is a simultaneous rekeying happening. |
a6d7a610 MW |
2050 | However, it cannot yet know which of the exchanges will have the |
2051 | lowest nonce, so it will just note the situation and respond as | |
2052 | usual. | |
2053 | ||
2054 | send resp2: SA(..,SPIa3,..), | |
2055 | Nr1,.. --> | |
2056 | --> recv req1 | |
2057 | ||
2058 | Now B also knows that simultaneous rekeying is going on. It responds | |
2059 | as usual. | |
2060 | ||
2061 | <-- send resp1: SA(..,SPIb3,..), | |
2062 | Nr2,.. | |
2063 | recv resp1 <-- | |
2064 | --> recv resp2 | |
2065 | ||
2066 | At this point, there are three Child SA pairs between A and B (the | |
2067 | old one and two new ones). A and B can now compare the nonces. | |
2068 | Suppose that the lowest nonce was Nr1 in message resp2; in this case, | |
2069 | B (the sender of req2) deletes the redundant new SA, and A (the node | |
2070 | that initiated the surviving rekeyed SA), deletes the old one. | |
2071 | ||
824a0402 AS |
2072 | |
2073 | ||
2074 | Kaufman, et al. Standards Track [Page 37] | |
2075 | \f | |
2076 | RFC 5996 IKEv2bis September 2010 | |
2077 | ||
2078 | ||
a6d7a610 MW |
2079 | send req3: D(SPIa1) --> |
2080 | <-- send req4: D(SPIb2) | |
2081 | --> recv req3 | |
2082 | <-- send resp3: D(SPIb1) | |
2083 | recv req4 <-- | |
2084 | send resp4: D(SPIa3) --> | |
2085 | ||
2086 | The rekeying is now finished. | |
2087 | ||
2088 | However, there is a second possible sequence of events that can | |
2089 | happen if some packets are lost in the network, resulting in | |
2090 | retransmissions. The rekeying begins as usual, but A's first packet | |
2091 | (req1) is lost. | |
2092 | ||
a6d7a610 MW |
2093 | Host A Host B |
2094 | ------------------------------------------------------------------- | |
2095 | send req1: N(REKEY_SA,SPIa1), | |
2096 | SA(..,SPIa2,..), | |
2097 | Ni1,.. --> (lost) | |
2098 | <-- send req2: N(REKEY_SA,SPIb1), | |
2099 | SA(..,SPIb2,..),Ni2 | |
2100 | recv req2 <-- | |
2101 | send resp2: SA(..,SPIa3,..), | |
2102 | Nr1,.. --> | |
2103 | --> recv resp2 | |
2104 | <-- send req3: D(SPIb1) | |
2105 | recv req3 <-- | |
2106 | send resp3: D(SPIa1) --> | |
2107 | --> recv resp3 | |
2108 | ||
2109 | From B's point of view, the rekeying is now completed, and since it | |
2110 | has not yet received A's req1, it does not even know that there was | |
2111 | simultaneous rekeying. However, A will continue retransmitting the | |
2112 | message, and eventually it will reach B. | |
2113 | ||
2114 | resend req1 --> | |
2115 | --> recv req1 | |
2116 | ||
2117 | To B, it looks like A is trying to rekey an SA that no longer exists; | |
2118 | thus, B responds to the request with something non-fatal such as | |
824a0402 | 2119 | CHILD_SA_NOT_FOUND. |
a6d7a610 | 2120 | |
824a0402 | 2121 | <-- send resp1: N(CHILD_SA_NOT_FOUND) |
a6d7a610 MW |
2122 | recv resp1 <-- |
2123 | ||
2124 | When A receives this error, it already knows there was simultaneous | |
2125 | rekeying, so it can ignore the error message. | |
2126 | ||
82f0707f | 2127 | |
82f0707f | 2128 | |
82f0707f | 2129 | |
824a0402 AS |
2130 | Kaufman, et al. Standards Track [Page 38] |
2131 | \f | |
2132 | RFC 5996 IKEv2bis September 2010 | |
82f0707f | 2133 | |
2eac2578 | 2134 | |
824a0402 | 2135 | 2.8.2. Simultaneous IKE SA Rekeying |
2eac2578 | 2136 | |
824a0402 AS |
2137 | Probably the most complex case occurs when both peers try to rekey |
2138 | the IKE_SA at the same time. Basically, the text in Section 2.8 | |
2139 | applies to this case as well; however, it is important to ensure that | |
2140 | the Child SAs are inherited by the correct IKE_SA. | |
2eac2578 | 2141 | |
824a0402 AS |
2142 | The case where both endpoints notice the simultaneous rekeying works |
2143 | the same way as with Child SAs. After the CREATE_CHILD_SA exchanges, | |
2144 | three IKE SAs exist between A and B: the old IKE SA and two new IKE | |
2145 | SAs. The new IKE SA containing the lowest nonce SHOULD be deleted by | |
2146 | the node that created it, and the other surviving new IKE SA MUST | |
2147 | inherit all the Child SAs. | |
2148 | ||
2149 | In addition to normal simultaneous rekeying cases, there is a special | |
2150 | case where one peer finishes its rekey before it even notices that | |
2151 | other peer is doing a rekey. If only one peer detects a simultaneous | |
2152 | rekey, redundant SAs are not created. In this case, when the peer | |
2153 | that did not notice the simultaneous rekey gets the request to rekey | |
2154 | the IKE SA that it has already successfully rekeyed, it SHOULD return | |
2155 | TEMPORARY_FAILURE because it is an IKE SA that it is currently trying | |
2156 | to close (whether or not it has already sent the delete notification | |
2157 | for the SA). If the peer that did notice the simultaneous rekey gets | |
2158 | the delete request from the other peer for the old IKE SA, it knows | |
2159 | that the other peer did not detect the simultaneous rekey, and the | |
2160 | first peer can forget its own rekey attempt. | |
2eac2578 | 2161 | |
82f0707f MW |
2162 | Host A Host B |
2163 | ------------------------------------------------------------------- | |
2164 | send req1: | |
2165 | SA(..,SPIa1,..),Ni1,.. --> | |
2166 | <-- send req2: SA(..,SPIb1,..),Ni2,.. | |
2167 | --> recv req1 | |
2168 | <-- send resp1: SA(..,SPIb2,..),Nr2,.. | |
2169 | recv resp1 <-- | |
2170 | send req3: D() --> | |
2171 | --> recv req3 | |
2172 | ||
2173 | At this point, host B sees a request to close the IKE_SA. There's | |
2174 | not much more to do than to reply as usual. However, at this point | |
2175 | host B should stop retransmitting req2, since once host A receives | |
2176 | resp3, it will delete all the state associated with the old IKE_SA | |
2177 | and will not be able to reply to it. | |
2178 | ||
2179 | <-- send resp3: () | |
2180 | ||
824a0402 AS |
2181 | The TEMPORARY_FAILURE notification was not included in RFC 4306, and |
2182 | support of the TEMPORARY_FAILURE notification is not negotiated. | |
2183 | ||
2184 | ||
2185 | ||
2186 | Kaufman, et al. Standards Track [Page 39] | |
2187 | \f | |
2188 | RFC 5996 IKEv2bis September 2010 | |
2189 | ||
2190 | ||
2191 | Thus, older peers that implement RFC 4306 but not this document may | |
2192 | receive these notifications. In that case, they will treat it the | |
2193 | same as any other unknown error notification, and will stop the | |
2194 | exchange. Because the other peer has already rekeyed the exchange, | |
2195 | doing so does not have any ill effects. | |
2196 | ||
2197 | 2.8.3. Rekeying the IKE SA versus Reauthentication | |
a6d7a610 | 2198 | |
a6d7a610 MW |
2199 | Rekeying the IKE SA and reauthentication are different concepts in |
2200 | IKEv2. Rekeying the IKE SA establishes new keys for the IKE SA and | |
2201 | resets the Message ID counters, but it does not authenticate the | |
2202 | parties again (no AUTH or EAP payloads are involved). | |
2203 | ||
2204 | Although rekeying the IKE SA may be important in some environments, | |
2205 | reauthentication (the verification that the parties still have access | |
2206 | to the long-term credentials) is often more important. | |
2207 | ||
2208 | IKEv2 does not have any special support for reauthentication. | |
a6d7a610 | 2209 | Reauthentication is done by creating a new IKE SA from scratch (using |
824a0402 | 2210 | IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA Notify |
a6d7a610 | 2211 | payloads), creating new Child SAs within the new IKE SA (without |
824a0402 | 2212 | REKEY_SA Notify payloads), and finally deleting the old IKE SA (which |
a6d7a610 MW |
2213 | deletes the old Child SAs as well). |
2214 | ||
2215 | This means that reauthentication also establishes new keys for the | |
2216 | IKE SA and Child SAs. Therefore, while rekeying can be performed | |
2217 | more often than reauthentication, the situation where "authentication | |
2218 | lifetime" is shorter than "key lifetime" does not make sense. | |
2219 | ||
2220 | While creation of a new IKE SA can be initiated by either party | |
2221 | (initiator or responder in the original IKE SA), the use of EAP | |
824a0402 AS |
2222 | and/or Configuration payloads means in practice that reauthentication |
2223 | has to be initiated by the same party as the original IKE SA. IKEv2 | |
2224 | does not currently allow the responder to request reauthentication in | |
2225 | this case; however, there are extensions that add this functionality | |
2226 | such as [REAUTH]. | |
a6d7a610 MW |
2227 | |
2228 | 2.9. Traffic Selector Negotiation | |
2229 | ||
2eac2578 MW |
2230 | When an RFC4301-compliant IPsec subsystem receives an IP packet that |
2231 | matches a "protect" selector in its Security Policy Database (SPD), | |
2232 | the subsystem protects that packet with IPsec. When no SA exists | |
2233 | yet, it is the task of IKE to create it. Maintenance of a system's | |
824a0402 AS |
2234 | SPD is outside the scope of IKE, although some implementations might |
2235 | update their SPD in connection with the running of IKE (for an | |
2236 | example scenario, see Section 1.1.3). | |
2237 | ||
2238 | ||
2239 | ||
2240 | ||
2241 | ||
2242 | Kaufman, et al. Standards Track [Page 40] | |
2243 | \f | |
2244 | RFC 5996 IKEv2bis September 2010 | |
2245 | ||
a6d7a610 MW |
2246 | |
2247 | Traffic Selector (TS) payloads allow endpoints to communicate some of | |
824a0402 AS |
2248 | the information from their SPD to their peers. These must be |
2249 | communicated to IKE from the SPD (for example, the PF_KEY API [PFKEY] | |
2250 | uses the SADB_ACQUIRE message). TS payloads specify the selection | |
2251 | criteria for packets that will be forwarded over the newly set up SA. | |
2252 | This can serve as a consistency check in some scenarios to assure | |
2253 | that the SPDs are consistent. In others, it guides the dynamic | |
2254 | update of the SPD. | |
a6d7a610 MW |
2255 | |
2256 | Two TS payloads appear in each of the messages in the exchange that | |
2257 | creates a Child SA pair. Each TS payload contains one or more | |
2258 | Traffic Selectors. Each Traffic Selector consists of an address | |
2259 | range (IPv4 or IPv6), a port range, and an IP protocol ID. | |
2260 | ||
2261 | The first of the two TS payloads is known as TSi (Traffic Selector- | |
2262 | initiator). The second is known as TSr (Traffic Selector-responder). | |
2263 | TSi specifies the source address of traffic forwarded from (or the | |
2264 | destination address of traffic forwarded to) the initiator of the | |
2265 | Child SA pair. TSr specifies the destination address of the traffic | |
2266 | forwarded to (or the source address of the traffic forwarded from) | |
a6d7a610 MW |
2267 | the responder of the Child SA pair. For example, if the original |
2268 | initiator requests the creation of a Child SA pair, and wishes to | |
824a0402 AS |
2269 | tunnel all traffic from subnet 198.51.100.* on the initiator's side |
2270 | to subnet 192.0.2.* on the responder's side, the initiator would | |
2271 | include a single Traffic Selector in each TS payload. TSi would | |
2272 | specify the address range (198.51.100.0 - 198.51.100.255) and TSr | |
2273 | would specify the address range (192.0.2.0 - 192.0.2.255). Assuming | |
2274 | that proposal was acceptable to the responder, it would send | |
2275 | identical TS payloads back. | |
a6d7a610 MW |
2276 | |
2277 | IKEv2 allows the responder to choose a subset of the traffic proposed | |
2278 | by the initiator. This could happen when the configurations of the | |
2279 | two endpoints are being updated but only one end has received the new | |
2280 | information. Since the two endpoints may be configured by different | |
2281 | people, the incompatibility may persist for an extended period even | |
2282 | in the absence of errors. It also allows for intentionally different | |
2283 | configurations, as when one end is configured to tunnel all addresses | |
2284 | and depends on the other end to have the up-to-date list. | |
2285 | ||
2286 | When the responder chooses a subset of the traffic proposed by the | |
824a0402 | 2287 | initiator, it narrows the Traffic Selectors to some subset of the |
a6d7a610 | 2288 | initiator's proposal (provided the set does not become the null set). |
824a0402 AS |
2289 | If the type of Traffic Selector proposed is unknown, the responder |
2290 | ignores that Traffic Selector, so that the unknown type is not | |
a6d7a610 MW |
2291 | returned in the narrowed set. |
2292 | ||
824a0402 AS |
2293 | |
2294 | ||
2295 | ||
2296 | ||
2297 | ||
2298 | Kaufman, et al. Standards Track [Page 41] | |
2299 | \f | |
2300 | RFC 5996 IKEv2bis September 2010 | |
2301 | ||
2302 | ||
2303 | To enable the responder to choose the appropriate range in this case, | |
2304 | if the initiator has requested the SA due to a data packet, the | |
2305 | initiator SHOULD include as the first Traffic Selector in each of TSi | |
2306 | and TSr a very specific Traffic Selector including the addresses in | |
2307 | the packet triggering the request. In the example, the initiator | |
2308 | would include in TSi two Traffic Selectors: the first containing the | |
2309 | address range (198.51.100.43 - 198.51.100.43) and the source port and | |
2310 | IP protocol from the packet and the second containing (198.51.100.0 - | |
2311 | 198.51.100.255) with all ports and IP protocols. The initiator would | |
2312 | similarly include two Traffic Selectors in TSr. If the initiator | |
2313 | creates the Child SA pair not in response to an arriving packet, but | |
2314 | rather, say, upon startup, then there may be no specific addresses | |
2315 | the initiator prefers for the initial tunnel over any other. In that | |
a6d7a610 MW |
2316 | case, the first values in TSi and TSr can be ranges rather than |
2317 | specific values. | |
2318 | ||
2eac2578 | 2319 | The responder performs the narrowing as follows: |
a6d7a610 | 2320 | |
a6d7a610 | 2321 | o If the responder's policy does not allow it to accept any part of |
824a0402 AS |
2322 | the proposed Traffic Selectors, it responds with a TS_UNACCEPTABLE |
2323 | Notify message. | |
a6d7a610 MW |
2324 | |
2325 | o If the responder's policy allows the entire set of traffic covered | |
2326 | by TSi and TSr, no narrowing is necessary, and the responder can | |
2327 | return the same TSi and TSr values. | |
2328 | ||
2329 | o If the responder's policy allows it to accept the first selector | |
824a0402 AS |
2330 | of TSi and TSr, then the responder MUST narrow the Traffic |
2331 | Selectors to a subset that includes the initiator's first choices. | |
a6d7a610 | 2332 | In this example above, the responder might respond with TSi being |
824a0402 | 2333 | (198.51.100.43 - 198.51.100.43) with all ports and IP protocols. |
a6d7a610 MW |
2334 | |
2335 | o If the responder's policy does not allow it to accept the first | |
2336 | selector of TSi and TSr, the responder narrows to an acceptable | |
2337 | subset of TSi and TSr. | |
2338 | ||
2339 | When narrowing is done, there may be several subsets that are | |
2340 | acceptable but their union is not. In this case, the responder | |
2341 | arbitrarily chooses one of them, and MAY include an | |
2eac2578 MW |
2342 | ADDITIONAL_TS_POSSIBLE notification in the response. The |
2343 | ADDITIONAL_TS_POSSIBLE notification asserts that the responder | |
824a0402 AS |
2344 | narrowed the proposed Traffic Selectors but that other Traffic |
2345 | Selectors would also have been acceptable, though only in a separate | |
a6d7a610 MW |
2346 | SA. There is no data associated with this Notify type. This case |
2347 | will occur only when the initiator and responder are configured | |
2348 | differently from one another. If the initiator and responder agree | |
2349 | on the granularity of tunnels, the initiator will never request a | |
824a0402 AS |
2350 | tunnel wider than the responder will accept. |
2351 | ||
2352 | ||
2353 | ||
2354 | Kaufman, et al. Standards Track [Page 42] | |
2355 | \f | |
2356 | RFC 5996 IKEv2bis September 2010 | |
2357 | ||
a6d7a610 MW |
2358 | |
2359 | It is possible for the responder's policy to contain multiple smaller | |
824a0402 | 2360 | ranges, all encompassed by the initiator's Traffic Selector, and with |
a6d7a610 MW |
2361 | the responder's policy being that each of those ranges should be sent |
2362 | over a different SA. Continuing the example above, the responder | |
2363 | might have a policy of being willing to tunnel those addresses to and | |
2364 | from the initiator, but might require that each address pair be on a | |
824a0402 AS |
2365 | separately negotiated Child SA. If the initiator didn't generate its |
2366 | request based on the packet, but (for example) upon startup, there | |
2367 | would not be the very specific first Traffic Selectors helping the | |
2368 | responder to select the correct range. There would be no way for the | |
2369 | responder to determine which pair of addresses should be included in | |
2370 | this tunnel, and it would have to make a guess or reject the request | |
2371 | with a SINGLE_PAIR_REQUIRED Notify message. | |
a6d7a610 | 2372 | |
2eac2578 MW |
2373 | The SINGLE_PAIR_REQUIRED error indicates that a CREATE_CHILD_SA |
2374 | request is unacceptable because its sender is only willing to accept | |
824a0402 | 2375 | Traffic Selectors specifying a single pair of addresses. The |
2eac2578 MW |
2376 | requestor is expected to respond by requesting an SA for only the |
2377 | specific traffic it is trying to forward. | |
a6d7a610 | 2378 | |
2eac2578 MW |
2379 | Few implementations will have policies that require separate SAs for |
2380 | each address pair. Because of this, if only some parts of the TSi | |
2381 | and TSr proposed by the initiator are acceptable to the responder, | |
2382 | responders SHOULD narrow the selectors to an acceptable subset rather | |
2383 | than use SINGLE_PAIR_REQUIRED. | |
a6d7a610 MW |
2384 | |
2385 | 2.9.1. Traffic Selectors Violating Own Policy | |
2386 | ||
a6d7a610 | 2387 | When creating a new SA, the initiator needs to avoid proposing |
824a0402 | 2388 | Traffic Selectors that violate its own policy. If this rule is not |
a6d7a610 MW |
2389 | followed, valid traffic may be dropped. If you use decorrelated |
2390 | policies from [IPSECARCH], this kind of policy violations cannot | |
2391 | happen. | |
2392 | ||
2393 | This is best illustrated by an example. Suppose that host A has a | |
824a0402 AS |
2394 | policy whose effect is that traffic to 198.51.100.66 is sent via host |
2395 | B encrypted using AES, and traffic to all other hosts in | |
2396 | 198.51.100.0/24 is also sent via B, but must use 3DES. Suppose also | |
2397 | that host B accepts any combination of AES and 3DES. | |
2398 | ||
2399 | If host A now proposes an SA that uses 3DES, and includes TSr | |
2400 | containing (198.51.100.0-198.51.100.255), this will be accepted by | |
2401 | host B. Now, host B can also use this SA to send traffic from | |
2402 | 198.51.100.66, but those packets will be dropped by A since it | |
2403 | requires the use of AES for this traffic. Even if host A creates a | |
2404 | new SA only for 198.51.100.66 that uses AES, host B may freely | |
2405 | continue to use the first SA for the traffic. In this situation, | |
2eac2578 MW |
2406 | |
2407 | ||
2408 | ||
2eac2578 | 2409 | |
824a0402 AS |
2410 | Kaufman, et al. Standards Track [Page 43] |
2411 | \f | |
2412 | RFC 5996 IKEv2bis September 2010 | |
2eac2578 | 2413 | |
a6d7a610 | 2414 | |
824a0402 AS |
2415 | when proposing the SA, host A should have followed its own policy, |
2416 | and included a TSr containing ((198.51.100.0- | |
2417 | 198.51.100.65),(198.51.100.67-198.51.100.255)) instead. | |
a6d7a610 MW |
2418 | |
2419 | In general, if (1) the initiator makes a proposal "for traffic X | |
2420 | (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator | |
2421 | does not actually accept traffic X' with SA, and (3) the initiator | |
2422 | would be willing to accept traffic X' with some SA' (!=SA), valid | |
2423 | traffic can be unnecessarily dropped since the responder can apply | |
2424 | either SA or SA' to traffic X'. | |
2425 | ||
2426 | 2.10. Nonces | |
2427 | ||
2428 | The IKE_SA_INIT messages each contain a nonce. These nonces are used | |
2429 | as inputs to cryptographic functions. The CREATE_CHILD_SA request | |
2430 | and the CREATE_CHILD_SA response also contain nonces. These nonces | |
2431 | are used to add freshness to the key derivation technique used to | |
824a0402 AS |
2432 | obtain keys for Child SA, and to ensure creation of strong |
2433 | pseudorandom bits from the Diffie-Hellman key. Nonces used in IKEv2 | |
2434 | MUST be randomly chosen, MUST be at least 128 bits in size, and MUST | |
2435 | be at least half the key size of the negotiated pseudorandom function | |
2436 | (PRF). However, the initiator chooses the nonce before the outcome | |
2437 | of the negotiation is known. Because of that, the nonce has to be | |
2438 | long enough for all the PRFs being proposed. If the same random | |
2439 | number source is used for both keys and nonces, care must be taken to | |
2440 | ensure that the latter use does not compromise the former. | |
a6d7a610 MW |
2441 | |
2442 | 2.11. Address and Port Agility | |
2443 | ||
2444 | IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and | |
824a0402 | 2445 | AH associations for the same IP addresses over which it runs. The IP |
a6d7a610 MW |
2446 | addresses and ports in the outer header are, however, not themselves |
2447 | cryptographically protected, and IKE is designed to work even through | |
2448 | Network Address Translation (NAT) boxes. An implementation MUST | |
2449 | accept incoming requests even if the source port is not 500 or 4500, | |
2450 | and MUST respond to the address and port from which the request was | |
2451 | received. It MUST specify the address and port at which the request | |
2452 | was received as the source address and port in the response. IKE | |
2453 | functions identically over IPv4 or IPv6. | |
2454 | ||
2455 | 2.12. Reuse of Diffie-Hellman Exponentials | |
2456 | ||
2457 | IKE generates keying material using an ephemeral Diffie-Hellman | |
2458 | exchange in order to gain the property of "perfect forward secrecy". | |
2459 | This means that once a connection is closed and its corresponding | |
2460 | keys are forgotten, even someone who has recorded all of the data | |
2461 | from the connection and gets access to all of the long-term keys of | |
824a0402 AS |
2462 | |
2463 | ||
2464 | ||
2465 | ||
2466 | Kaufman, et al. Standards Track [Page 44] | |
2467 | \f | |
2468 | RFC 5996 IKEv2bis September 2010 | |
2469 | ||
2470 | ||
a6d7a610 MW |
2471 | the two endpoints cannot reconstruct the keys used to protect the |
2472 | conversation without doing a brute force search of the session key | |
2473 | space. | |
2474 | ||
2475 | Achieving perfect forward secrecy requires that when a connection is | |
2476 | closed, each endpoint MUST forget not only the keys used by the | |
2477 | connection but also any information that could be used to recompute | |
2478 | those keys. | |
2479 | ||
824a0402 | 2480 | Because computing Diffie-Hellman exponentials is computationally |
a6d7a610 MW |
2481 | expensive, an endpoint may find it advantageous to reuse those |
2482 | exponentials for multiple connection setups. There are several | |
2483 | reasonable strategies for doing this. An endpoint could choose a new | |
2484 | exponential only periodically though this could result in less-than- | |
2485 | perfect forward secrecy if some connection lasts for less than the | |
2486 | lifetime of the exponential. Or it could keep track of which | |
2487 | exponential was used for each connection and delete the information | |
a6d7a610 MW |
2488 | associated with the exponential only when some corresponding |
2489 | connection was closed. This would allow the exponential to be reused | |
2490 | without losing perfect forward secrecy at the cost of maintaining | |
2491 | more state. | |
2492 | ||
824a0402 AS |
2493 | Whether and when to reuse Diffie-Hellman exponentials are private |
2494 | decisions in the sense that they will not affect interoperability. | |
2495 | An implementation that reuses exponentials MAY choose to remember the | |
2496 | exponential used by the other endpoint on past exchanges and if one | |
2497 | is reused to avoid the second half of the calculation. See [REUSE] | |
2498 | for a security analysis of this practice and for additional security | |
2499 | considerations when reusing ephemeral Diffie-Hellman keys. | |
a6d7a610 MW |
2500 | |
2501 | 2.13. Generating Keying Material | |
2502 | ||
2503 | In the context of the IKE SA, four cryptographic algorithms are | |
2504 | negotiated: an encryption algorithm, an integrity protection | |
824a0402 AS |
2505 | algorithm, a Diffie-Hellman group, and a pseudorandom function (PRF). |
2506 | The PRF is used for the construction of keying material for all of | |
2507 | the cryptographic algorithms used in both the IKE SA and the Child | |
2508 | SAs. | |
2509 | ||
2510 | We assume that each encryption algorithm and integrity protection | |
2511 | algorithm uses a fixed-size key and that any randomly chosen value of | |
2512 | that fixed size can serve as an appropriate key. For algorithms that | |
2513 | accept a variable-length key, a fixed key size MUST be specified as | |
2514 | part of the cryptographic transform negotiated (see Section 3.3.5 for | |
2515 | the definition of the Key Length transform attribute). For | |
2516 | algorithms for which not all values are valid keys (such as DES or | |
2517 | 3DES with key parity), the algorithm by which keys are derived from | |
2518 | arbitrary values MUST be specified by the cryptographic transform. | |
2eac2578 MW |
2519 | |
2520 | ||
2521 | ||
824a0402 | 2522 | Kaufman, et al. Standards Track [Page 45] |
2eac2578 | 2523 | \f |
824a0402 | 2524 | RFC 5996 IKEv2bis September 2010 |
2eac2578 MW |
2525 | |
2526 | ||
824a0402 AS |
2527 | For integrity protection functions based on Hashed Message |
2528 | Authentication Code (HMAC), the fixed key size is the size of the | |
2529 | output of the underlying hash function. | |
a6d7a610 | 2530 | |
824a0402 AS |
2531 | It is assumed that PRFs accept keys of any length, but have a |
2532 | preferred key size. The preferred key size MUST be used as the | |
2533 | length of SK_d, SK_pi, and SK_pr (see Section 2.14). For PRFs based | |
2534 | on the HMAC construction, the preferred key size is equal to the | |
2535 | length of the output of the underlying hash function. Other types of | |
2536 | PRFs MUST specify their preferred key size. | |
a6d7a610 MW |
2537 | |
2538 | Keying material will always be derived as the output of the | |
824a0402 AS |
2539 | negotiated PRF algorithm. Since the amount of keying material needed |
2540 | may be greater than the size of the output of the PRF, the PRF is | |
2541 | used iteratively. The term "prf+" describes a function that outputs | |
2542 | a pseudorandom stream based on the inputs to a pseudorandom function | |
2543 | called "prf". | |
2544 | ||
2545 | In the following, | indicates concatenation. prf+ is defined as: | |
a6d7a610 | 2546 | |
a6d7a610 MW |
2547 | prf+ (K,S) = T1 | T2 | T3 | T4 | ... |
2548 | ||
2549 | where: | |
2550 | T1 = prf (K, S | 0x01) | |
2551 | T2 = prf (K, T1 | S | 0x02) | |
2552 | T3 = prf (K, T2 | S | 0x03) | |
2553 | T4 = prf (K, T3 | S | 0x04) | |
824a0402 | 2554 | ... |
a6d7a610 | 2555 | |
824a0402 AS |
2556 | This continues until all the material needed to compute all required |
2557 | keys has been output from prf+. The keys are taken from the output | |
2558 | string without regard to boundaries (e.g., if the required keys are a | |
2559 | 256-bit Advanced Encryption Standard (AES) key and a 160-bit HMAC | |
2560 | key, and the prf function generates 160 bits, the AES key will come | |
2561 | from T1 and the beginning of T2, while the HMAC key will come from | |
2562 | the rest of T2 and the beginning of T3). | |
2eac2578 | 2563 | |
824a0402 AS |
2564 | The constant concatenated to the end of each prf function is a single |
2565 | octet. The prf+ function is not defined beyond 255 times the size of | |
2566 | the prf function output. | |
2eac2578 | 2567 | |
a6d7a610 MW |
2568 | 2.14. Generating Keying Material for the IKE SA |
2569 | ||
2570 | The shared keys are computed as follows. A quantity called SKEYSEED | |
2571 | is calculated from the nonces exchanged during the IKE_SA_INIT | |
2572 | exchange and the Diffie-Hellman shared secret established during that | |
2573 | exchange. SKEYSEED is used to calculate seven other secrets: SK_d | |
2574 | used for deriving new keys for the Child SAs established with this | |
824a0402 AS |
2575 | |
2576 | ||
2577 | ||
2578 | Kaufman, et al. Standards Track [Page 46] | |
2579 | \f | |
2580 | RFC 5996 IKEv2bis September 2010 | |
2581 | ||
2582 | ||
a6d7a610 MW |
2583 | IKE SA; SK_ai and SK_ar used as a key to the integrity protection |
2584 | algorithm for authenticating the component messages of subsequent | |
2585 | exchanges; SK_ei and SK_er used for encrypting (and of course | |
2586 | decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are | |
2587 | used when generating an AUTH payload. The lengths of SK_d, SK_pi, | |
824a0402 | 2588 | and SK_pr MUST be the preferred key length of the PRF agreed upon. |
a6d7a610 MW |
2589 | |
2590 | SKEYSEED and its derivatives are computed as follows: | |
2591 | ||
2592 | SKEYSEED = prf(Ni | Nr, g^ir) | |
2593 | ||
2594 | {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } | |
2595 | = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) | |
2596 | ||
2597 | (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, | |
2598 | SK_pi, and SK_pr are taken in order from the generated bits of the | |
2599 | prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman | |
2600 | exchange. g^ir is represented as a string of octets in big endian | |
2601 | order padded with zeros if necessary to make it the length of the | |
2602 | modulus. Ni and Nr are the nonces, stripped of any headers. For | |
824a0402 | 2603 | historical backward-compatibility reasons, there are two PRFs that |
a6d7a610 | 2604 | are treated specially in this calculation. If the negotiated PRF is |
824a0402 AS |
2605 | AES-XCBC-PRF-128 [AESXCBCPRF128] or AES-CMAC-PRF-128 [AESCMACPRF128], |
2606 | only the first 64 bits of Ni and the first 64 bits of Nr are used in | |
2607 | calculating SKEYSEED, but all the bits are used for input to the prf+ | |
2608 | function. | |
a6d7a610 MW |
2609 | |
2610 | The two directions of traffic flow use different keys. The keys used | |
2611 | to protect messages from the original initiator are SK_ai and SK_ei. | |
2612 | The keys used to protect messages in the other direction are SK_ar | |
2613 | and SK_er. | |
2614 | ||
2615 | 2.15. Authentication of the IKE SA | |
2616 | ||
2617 | When not using extensible authentication (see Section 2.16), the | |
824a0402 AS |
2618 | peers are authenticated by having each sign (or MAC using a padded |
2619 | shared secret as the key, as described later in this section) a block | |
2620 | of data. In these calculations, IDi' and IDr' are the entire ID | |
2621 | payloads excluding the fixed header. For the responder, the octets | |
2622 | to be signed start with the first octet of the first SPI in the | |
2623 | header of the second message (IKE_SA_INIT response) and end with the | |
2624 | last octet of the last payload in the second message. Appended to | |
2625 | this (for the purposes of computing the signature) are the | |
2626 | initiator's nonce Ni (just the value, not the payload containing it), | |
2627 | and the value prf(SK_pr, IDr'). Note that neither the nonce Ni nor | |
2628 | the value prf(SK_pr, IDr') are transmitted. Similarly, the initiator | |
2629 | signs the first message (IKE_SA_INIT request), starting with the | |
2630 | first octet of the first SPI in the header and ending with the last | |
2eac2578 MW |
2631 | |
2632 | ||
2633 | ||
824a0402 | 2634 | Kaufman, et al. Standards Track [Page 47] |
2eac2578 | 2635 | \f |
824a0402 | 2636 | RFC 5996 IKEv2bis September 2010 |
2eac2578 MW |
2637 | |
2638 | ||
824a0402 AS |
2639 | octet of the last payload. Appended to this (for purposes of |
2640 | computing the signature) are the responder's nonce Nr, and the value | |
2641 | prf(SK_pi, IDi'). It is critical to the security of the exchange | |
2642 | that each side sign the other side's nonce. | |
a6d7a610 | 2643 | |
a6d7a610 MW |
2644 | The initiator's signed octets can be described as: |
2645 | ||
2646 | InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI | |
2647 | GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR | |
2648 | RealIKEHDR = SPIi | SPIr | . . . | Length | |
2649 | RealMessage1 = RealIKEHDR | RestOfMessage1 | |
2650 | NonceRPayload = PayloadHeader | NonceRData | |
824a0402 | 2651 | InitiatorIDPayload = PayloadHeader | RestOfInitIDPayload |
a6d7a610 MW |
2652 | RestOfInitIDPayload = IDType | RESERVED | InitIDData |
2653 | MACedIDForI = prf(SK_pi, RestOfInitIDPayload) | |
2654 | ||
2655 | The responder's signed octets can be described as: | |
2656 | ||
a6d7a610 MW |
2657 | ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR |
2658 | GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR | |
2659 | RealIKEHDR = SPIi | SPIr | . . . | Length | |
2660 | RealMessage2 = RealIKEHDR | RestOfMessage2 | |
2661 | NonceIPayload = PayloadHeader | NonceIData | |
824a0402 | 2662 | ResponderIDPayload = PayloadHeader | RestOfRespIDPayload |
a6d7a610 MW |
2663 | RestOfRespIDPayload = IDType | RESERVED | RespIDData |
2664 | MACedIDForR = prf(SK_pr, RestOfRespIDPayload) | |
2665 | ||
2666 | Note that all of the payloads are included under the signature, | |
2667 | including any payload types not defined in this document. If the | |
2668 | first message of the exchange is sent multiple times (such as with a | |
2669 | responder cookie and/or a different Diffie-Hellman group), it is the | |
2670 | latest version of the message that is signed. | |
2671 | ||
2672 | Optionally, messages 3 and 4 MAY include a certificate, or | |
2673 | certificate chain providing evidence that the key used to compute a | |
2674 | digital signature belongs to the name in the ID payload. The | |
2675 | signature or MAC will be computed using algorithms dictated by the | |
2676 | type of key used by the signer, and specified by the Auth Method | |
2677 | field in the Authentication payload. There is no requirement that | |
2678 | the initiator and responder sign with the same cryptographic | |
2679 | algorithms. The choice of cryptographic algorithms depends on the | |
2680 | type of key each has. In particular, the initiator may be using a | |
824a0402 AS |
2681 | shared key while the responder may have a public signature key and |
2682 | certificate. It will commonly be the case (but it is not required) | |
2683 | that, if a shared secret is used for authentication, the same key is | |
2684 | used in both directions. | |
2eac2578 MW |
2685 | |
2686 | ||
2687 | ||
2eac2578 MW |
2688 | |
2689 | ||
824a0402 AS |
2690 | Kaufman, et al. Standards Track [Page 48] |
2691 | \f | |
2692 | RFC 5996 IKEv2bis September 2010 | |
2693 | ||
a6d7a610 MW |
2694 | |
2695 | Note that it is a common but typically insecure practice to have a | |
2696 | shared key derived solely from a user-chosen password without | |
2697 | incorporating another source of randomness. This is typically | |
2698 | insecure because user-chosen passwords are unlikely to have | |
2699 | sufficient unpredictability to resist dictionary attacks and these | |
2700 | attacks are not prevented in this authentication method. | |
2701 | (Applications using password-based authentication for bootstrapping | |
2702 | and IKE SA should use the authentication method in Section 2.16, | |
2eac2578 MW |
2703 | which is designed to prevent off-line dictionary attacks.) The pre- |
2704 | shared key needs to contain as much unpredictability as the strongest | |
2705 | key being negotiated. In the case of a pre-shared key, the AUTH | |
2706 | value is computed as: | |
a6d7a610 | 2707 | |
82f0707f | 2708 | For the initiator: |
824a0402 | 2709 | AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), |
82f0707f MW |
2710 | <InitiatorSignedOctets>) |
2711 | For the responder: | |
824a0402 | 2712 | AUTH = prf( prf(Shared Secret, "Key Pad for IKEv2"), |
82f0707f | 2713 | <ResponderSignedOctets>) |
a6d7a610 MW |
2714 | |
2715 | where the string "Key Pad for IKEv2" is 17 ASCII characters without | |
2716 | null termination. The shared secret can be variable length. The pad | |
2717 | string is added so that if the shared secret is derived from a | |
2718 | password, the IKE implementation need not store the password in | |
a6d7a610 MW |
2719 | cleartext, but rather can store the value prf(Shared Secret,"Key Pad |
2720 | for IKEv2"), which could not be used as a password equivalent for | |
2721 | protocols other than IKEv2. As noted above, deriving the shared | |
2722 | secret from a password is not secure. This construction is used | |
2723 | because it is anticipated that people will do it anyway. The | |
824a0402 | 2724 | management interface by which the shared secret is provided MUST |
a6d7a610 MW |
2725 | accept ASCII strings of at least 64 octets and MUST NOT add a null |
2726 | terminator before using them as shared secrets. It MUST also accept | |
824a0402 | 2727 | a hex encoding of the shared secret. The management interface MAY |
a6d7a610 MW |
2728 | accept other encodings if the algorithm for translating the encoding |
2729 | to a binary string is specified. | |
2730 | ||
824a0402 AS |
2731 | There are two types of EAP authentication (described in |
2732 | Section 2.16), and each type uses different values in the AUTH | |
2733 | computations shown above. If the EAP method is key-generating, | |
2734 | substitute master session key (MSK) for the shared secret in the | |
2735 | computation. For non-key-generating methods, substitute SK_pi and | |
2736 | SK_pr, respectively, for the shared secret in the two AUTH | |
2737 | computations. | |
2738 | ||
2739 | ||
2740 | ||
a6d7a610 | 2741 | |
2eac2578 MW |
2742 | |
2743 | ||
2744 | ||
824a0402 AS |
2745 | |
2746 | Kaufman, et al. Standards Track [Page 49] | |
2eac2578 | 2747 | \f |
824a0402 AS |
2748 | RFC 5996 IKEv2bis September 2010 |
2749 | ||
2eac2578 | 2750 | |
824a0402 | 2751 | 2.16. Extensible Authentication Protocol Methods |
2eac2578 | 2752 | |
824a0402 AS |
2753 | In addition to authentication using public key signatures and shared |
2754 | secrets, IKE supports authentication using methods defined in RFC | |
2755 | 3748 [EAP]. Typically, these methods are asymmetric (designed for a | |
2756 | user authenticating to a server), and they may not be mutual. For | |
2757 | this reason, these protocols are typically used to authenticate the | |
a6d7a610 | 2758 | initiator to the responder and MUST be used in conjunction with a |
824a0402 | 2759 | public-key-signature-based authentication of the responder to the |
a6d7a610 MW |
2760 | initiator. These methods are often associated with mechanisms |
2761 | referred to as "Legacy Authentication" mechanisms. | |
2762 | ||
824a0402 AS |
2763 | While this document references [EAP] with the intent that new methods |
2764 | can be added in the future without updating this specification, some | |
2765 | simpler variations are documented here. [EAP] defines an | |
2766 | authentication protocol requiring a variable number of messages. | |
2767 | Extensible Authentication is implemented in IKE as additional | |
2768 | IKE_AUTH exchanges that MUST be completed in order to initialize the | |
2769 | IKE SA. | |
2770 | ||
2771 | An initiator indicates a desire to use EAP by leaving out the AUTH | |
2772 | payload from the first message in the IKE_AUTH exchange. (Note that | |
2773 | the AUTH payload is required for non-EAP authentication, and is thus | |
2774 | not marked as optional in the rest of this document.) By including | |
2775 | an IDi payload but not an AUTH payload, the initiator has declared an | |
a6d7a610 | 2776 | identity but has not proven it. If the responder is willing to use |
824a0402 AS |
2777 | an EAP method, it will place an Extensible Authentication Protocol |
2778 | (EAP) payload in the response of the IKE_AUTH exchange and defer | |
2779 | sending SAr2, TSi, and TSr until initiator authentication is complete | |
2780 | in a subsequent IKE_AUTH exchange. In the case of a minimal EAP | |
2781 | method, the initial SA establishment will appear as follows: | |
a6d7a610 | 2782 | |
a6d7a610 MW |
2783 | Initiator Responder |
2784 | ------------------------------------------------------------------- | |
2785 | HDR, SAi1, KEi, Ni --> | |
2786 | <-- HDR, SAr1, KEr, Nr, [CERTREQ] | |
2787 | HDR, SK {IDi, [CERTREQ,] | |
2788 | [IDr,] SAi2, | |
2789 | TSi, TSr} --> | |
2790 | <-- HDR, SK {IDr, [CERT,] AUTH, | |
2791 | EAP } | |
2792 | HDR, SK {EAP} --> | |
2793 | <-- HDR, SK {EAP (success)} | |
2794 | HDR, SK {AUTH} --> | |
2795 | <-- HDR, SK {AUTH, SAr2, TSi, TSr } | |
2796 | ||
824a0402 AS |
2797 | |
2798 | ||
2799 | ||
2800 | ||
2801 | ||
2802 | Kaufman, et al. Standards Track [Page 50] | |
2803 | \f | |
2804 | RFC 5996 IKEv2bis September 2010 | |
2805 | ||
2806 | ||
2eac2578 MW |
2807 | As described in Section 2.2, when EAP is used, each pair of IKE SA |
2808 | initial setup messages will have their message numbers incremented; | |
2809 | the first pair of AUTH messages will have an ID of 1, the second will | |
2810 | be 2, and so on. | |
a6d7a610 MW |
2811 | |
2812 | For EAP methods that create a shared key as a side effect of | |
2813 | authentication, that shared key MUST be used by both the initiator | |
2814 | and responder to generate AUTH payloads in messages 7 and 8 using the | |
2815 | syntax for shared secrets specified in Section 2.15. The shared key | |
2816 | from EAP is the field from the EAP specification named MSK. This | |
2817 | shared key generated during an IKE exchange MUST NOT be used for any | |
2818 | other purpose. | |
2819 | ||
2820 | EAP methods that do not establish a shared key SHOULD NOT be used, as | |
2821 | they are subject to a number of man-in-the-middle attacks [EAPMITM] | |
2822 | if these EAP methods are used in other protocols that do not use a | |
2823 | server-authenticated tunnel. Please see the Security Considerations | |
2824 | section for more details. If EAP methods that do not generate a | |
2825 | shared key are used, the AUTH payloads in messages 7 and 8 MUST be | |
2826 | generated using SK_pi and SK_pr, respectively. | |
2827 | ||
2eac2578 MW |
2828 | The initiator of an IKE SA using EAP needs to be capable of extending |
2829 | the initial protocol exchange to at least ten IKE_AUTH exchanges in | |
2830 | the event the responder sends notification messages and/or retries | |
2831 | the authentication prompt. Once the protocol exchange defined by the | |
2832 | chosen EAP authentication method has successfully terminated, the | |
2833 | responder MUST send an EAP payload containing the Success message. | |
2834 | Similarly, if the authentication method has failed, the responder | |
2835 | MUST send an EAP payload containing the Failure message. The | |
2836 | responder MAY at any time terminate the IKE exchange by sending an | |
2837 | EAP payload containing the Failure message. | |
a6d7a610 MW |
2838 | |
2839 | Following such an extended exchange, the EAP AUTH payloads MUST be | |
2840 | included in the two messages following the one containing the EAP | |
a6d7a610 MW |
2841 | Success message. |
2842 | ||
2eac2578 | 2843 | When the initiator authentication uses EAP, it is possible that the |
824a0402 AS |
2844 | contents of the IDi payload is used only for Authentication, |
2845 | Authorization, and Accounting (AAA) routing purposes and selecting | |
2846 | which EAP method to use. This value may be different from the | |
2847 | identity authenticated by the EAP method. It is important that | |
2eac2578 MW |
2848 | policy lookups and access control decisions use the actual |
2849 | authenticated identity. Often the EAP server is implemented in a | |
2850 | separate AAA server that communicates with the IKEv2 responder. In | |
824a0402 AS |
2851 | this case, the authenticated identity, if different from that in the |
2852 | IDi payload, has to be sent from the AAA server to the IKEv2 | |
2853 | responder. | |
2854 | ||
2855 | ||
2856 | ||
2857 | ||
2858 | Kaufman, et al. Standards Track [Page 51] | |
2859 | \f | |
2860 | RFC 5996 IKEv2bis September 2010 | |
2861 | ||
a6d7a610 MW |
2862 | |
2863 | 2.17. Generating Keying Material for Child SAs | |
2864 | ||
2865 | A single Child SA is created by the IKE_AUTH exchange, and additional | |
2866 | Child SAs can optionally be created in CREATE_CHILD_SA exchanges. | |
2867 | Keying material for them is generated as follows: | |
2868 | ||
2869 | KEYMAT = prf+(SK_d, Ni | Nr) | |
2870 | ||
2871 | Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this | |
2872 | request is the first Child SA created or the fresh Ni and Nr from the | |
2873 | CREATE_CHILD_SA exchange if this is a subsequent creation. | |
2874 | ||
2875 | For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman | |
2876 | exchange, the keying material is defined as: | |
2877 | ||
2878 | KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) | |
2879 | ||
2880 | where g^ir (new) is the shared secret from the ephemeral Diffie- | |
2881 | Hellman exchange of this CREATE_CHILD_SA exchange (represented as an | |
2882 | octet string in big endian order padded with zeros in the high-order | |
2883 | bits if necessary to make it the length of the modulus). | |
2884 | ||
824a0402 AS |
2885 | A single CHILD_SA negotiation may result in multiple Security |
2886 | Associations. ESP and AH SAs exist in pairs (one in each direction), | |
2887 | so two SAs are created in a single Child SA negotiation for them. | |
2888 | Furthermore, Child SA negotiation may include some future IPsec | |
2889 | protocol(s) in addition to, or instead of, ESP or AH (for example, | |
2890 | ROHC_INTEG as described in [ROHCV2]). In any case, keying material | |
2891 | for each Child SA MUST be taken from the expanded KEYMAT using the | |
2892 | following rules: | |
2893 | ||
2894 | o All keys for SAs carrying data from the initiator to the responder | |
2895 | are taken before SAs going from the responder to the initiator. | |
2896 | ||
2897 | o If multiple IPsec protocols are negotiated, keying material for | |
2898 | each Child SA is taken in the order in which the protocol headers | |
2899 | will appear in the encapsulated packet. | |
2900 | ||
2901 | o If an IPsec protocol requires multiple keys, the order in which | |
2902 | they are taken from the SA's keying material needs to be described | |
2903 | in the protocol's specification. For ESP and AH, [IPSECARCH] | |
2904 | defines the order, namely: the encryption key (if any) MUST be | |
2905 | taken from the first bits and the integrity key (if any) MUST be | |
2906 | taken from the remaining bits. | |
2907 | ||
2908 | ||
2909 | ||
a6d7a610 | 2910 | |
a6d7a610 | 2911 | |
a6d7a610 | 2912 | |
a6d7a610 | 2913 | |
824a0402 AS |
2914 | Kaufman, et al. Standards Track [Page 52] |
2915 | \f | |
2916 | RFC 5996 IKEv2bis September 2010 | |
2917 | ||
a6d7a610 MW |
2918 | |
2919 | Each cryptographic algorithm takes a fixed number of bits of keying | |
2920 | material specified as part of the algorithm, or negotiated in SA | |
2921 | payloads (see Section 2.13 for description of key lengths, and | |
2922 | Section 3.3.5 for the definition of the Key Length transform | |
2923 | attribute). | |
2924 | ||
2925 | 2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange | |
2926 | ||
2927 | The CREATE_CHILD_SA exchange can be used to rekey an existing IKE SA | |
824a0402 AS |
2928 | (see Sections 1.3.2 and 2.8). New initiator and responder SPIs are |
2929 | supplied in the SPI fields in the Proposal structures inside the | |
2930 | Security Association (SA) payloads (not the SPI fields in the IKE | |
2931 | header). The TS payloads are omitted when rekeying an IKE SA. | |
2932 | SKEYSEED for the new IKE SA is computed using SK_d from the existing | |
2933 | IKE SA as follows: | |
a6d7a610 | 2934 | |
82f0707f | 2935 | SKEYSEED = prf(SK_d (old), g^ir (new) | Ni | Nr) |
a6d7a610 MW |
2936 | |
2937 | where g^ir (new) is the shared secret from the ephemeral Diffie- | |
2938 | Hellman exchange of this CREATE_CHILD_SA exchange (represented as an | |
2939 | octet string in big endian order padded with zeros if necessary to | |
2940 | make it the length of the modulus) and Ni and Nr are the two nonces | |
2941 | stripped of any headers. | |
2942 | ||
2eac2578 MW |
2943 | The old and new IKE SA may have selected a different PRF. Because |
2944 | the rekeying exchange belongs to the old IKE SA, it is the old IKE | |
824a0402 | 2945 | SA's PRF that is used to generate SKEYSEED. |
a6d7a610 | 2946 | |
2eac2578 MW |
2947 | The main reason for rekeying the IKE SA is to ensure that the |
2948 | compromise of old keying material does not provide information about | |
2949 | the current keys, or vice versa. Therefore, implementations MUST | |
2950 | perform a new Diffie-Hellman exchange when rekeying the IKE SA. In | |
2951 | other words, an initiator MUST NOT propose the value "NONE" for the | |
824a0402 AS |
2952 | Diffie-Hellman transform, and a responder MUST NOT accept such a |
2953 | proposal. This means that a successful exchange rekeying the IKE SA | |
2954 | always includes the KEi/KEr payloads. | |
a6d7a610 | 2955 | |
82f0707f | 2956 | The new IKE SA MUST reset its message counters to 0. |
a6d7a610 | 2957 | |
82f0707f | 2958 | SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as |
2eac2578 | 2959 | specified in Section 2.14, using SPIi, SPIr, Ni, and Nr from the new |
824a0402 | 2960 | exchange, and using the new IKE SA's PRF. |
a6d7a610 MW |
2961 | |
2962 | 2.19. Requesting an Internal Address on a Remote Network | |
2963 | ||
2964 | Most commonly occurring in the endpoint-to-security-gateway scenario, | |
2965 | an endpoint may need an IP address in the network protected by the | |
2966 | security gateway and may need to have that address dynamically | |
824a0402 AS |
2967 | |
2968 | ||
2969 | ||
2970 | Kaufman, et al. Standards Track [Page 53] | |
2971 | \f | |
2972 | RFC 5996 IKEv2bis September 2010 | |
2973 | ||
2974 | ||
a6d7a610 MW |
2975 | assigned. A request for such a temporary address can be included in |
2976 | any request to create a Child SA (including the implicit request in | |
82f0707f MW |
2977 | message 3) by including a CP payload. Note, however, it is usual to |
2978 | only assign one IP address during the IKE_AUTH exchange. That | |
2979 | address persists at least until the deletion of the IKE SA. | |
a6d7a610 MW |
2980 | |
2981 | This function provides address allocation to an IPsec Remote Access | |
2982 | Client (IRAC) trying to tunnel into a network protected by an IPsec | |
2983 | Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an | |
2984 | IKE SA and a Child SA, the IRAC MUST request the IRAS-controlled | |
2985 | address (and optionally other information concerning the protected | |
2986 | network) in the IKE_AUTH exchange. The IRAS may procure an address | |
824a0402 AS |
2987 | for the IRAC from any number of sources such as a DHCP/BOOTP |
2988 | (Bootstrap Protocol) server or its own address pool. | |
a6d7a610 MW |
2989 | |
2990 | Initiator Responder | |
2991 | ------------------------------------------------------------------- | |
2992 | HDR, SK {IDi, [CERT,] | |
2993 | [CERTREQ,] [IDr,] AUTH, | |
2994 | CP(CFG_REQUEST), SAi2, | |
2995 | TSi, TSr} --> | |
2996 | <-- HDR, SK {IDr, [CERT,] AUTH, | |
2997 | CP(CFG_REPLY), SAr2, | |
2998 | TSi, TSr} | |
2999 | ||
3000 | In all cases, the CP payload MUST be inserted before the SA payload. | |
3001 | In variations of the protocol where there are multiple IKE_AUTH | |
3002 | exchanges, the CP payloads MUST be inserted in the messages | |
3003 | containing the SA payloads. | |
3004 | ||
3005 | CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute | |
3006 | (either IPv4 or IPv6) but MAY contain any number of additional | |
3007 | attributes the initiator wants returned in the response. | |
3008 | ||
824a0402 AS |
3009 | |
3010 | ||
3011 | ||
3012 | ||
3013 | ||
3014 | ||
3015 | ||
3016 | ||
3017 | ||
3018 | ||
3019 | ||
3020 | ||
3021 | ||
3022 | ||
3023 | ||
3024 | ||
3025 | ||
3026 | Kaufman, et al. Standards Track [Page 54] | |
3027 | \f | |
3028 | RFC 5996 IKEv2bis September 2010 | |
3029 | ||
3030 | ||
a6d7a610 MW |
3031 | For example, message from initiator to responder: |
3032 | ||
3033 | CP(CFG_REQUEST)= | |
3034 | INTERNAL_ADDRESS() | |
3035 | TSi = (0, 0-65535,0.0.0.0-255.255.255.255) | |
3036 | TSr = (0, 0-65535,0.0.0.0-255.255.255.255) | |
3037 | ||
3038 | NOTE: Traffic Selectors contain (protocol, port range, address | |
3039 | range). | |
3040 | ||
3041 | Message from responder to initiator: | |
3042 | ||
a6d7a610 MW |
3043 | CP(CFG_REPLY)= |
3044 | INTERNAL_ADDRESS(192.0.2.202) | |
3045 | INTERNAL_NETMASK(255.255.255.0) | |
3046 | INTERNAL_SUBNET(192.0.2.0/255.255.255.0) | |
3047 | TSi = (0, 0-65535,192.0.2.202-192.0.2.202) | |
3048 | TSr = (0, 0-65535,192.0.2.0-192.0.2.255) | |
3049 | ||
3050 | All returned values will be implementation dependent. As can be seen | |
3051 | in the above example, the IRAS MAY also send other attributes that | |
3052 | were not included in CP(CFG_REQUEST) and MAY ignore the non- | |
3053 | mandatory attributes that it does not support. | |
3054 | ||
a6d7a610 MW |
3055 | The responder MUST NOT send a CFG_REPLY without having first received |
3056 | a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS | |
3057 | to perform an unnecessary configuration lookup if the IRAC cannot | |
824a0402 AS |
3058 | process the REPLY. |
3059 | ||
3060 | In the case where the IRAS's configuration requires that CP be used | |
3061 | for a given identity IDi, but IRAC has failed to send a | |
3062 | CP(CFG_REQUEST), IRAS MUST fail the request, and terminate the Child | |
3063 | SA creation with a FAILED_CP_REQUIRED error. The FAILED_CP_REQUIRED | |
3064 | is not fatal to the IKE SA; it simply causes the Child SA creation to | |
3065 | fail. The initiator can fix this by later starting a new | |
3066 | Configuration payload request. There is no associated data in the | |
3067 | FAILED_CP_REQUIRED error. | |
a6d7a610 MW |
3068 | |
3069 | 2.20. Requesting the Peer's Version | |
3070 | ||
3071 | An IKE peer wishing to inquire about the other peer's IKE software | |
3072 | version information MAY use the method below. This is an example of | |
3073 | a configuration request within an INFORMATIONAL exchange, after the | |
3074 | IKE SA and first Child SA have been created. | |
3075 | ||
824a0402 AS |
3076 | |
3077 | ||
3078 | ||
3079 | ||
3080 | ||
3081 | ||
3082 | Kaufman, et al. Standards Track [Page 55] | |
3083 | \f | |
3084 | RFC 5996 IKEv2bis September 2010 | |
3085 | ||
3086 | ||
a6d7a610 | 3087 | An IKE implementation MAY decline to give out version information |
824a0402 AS |
3088 | prior to authentication or even after authentication in case some |
3089 | implementation is known to have some security weakness. In that | |
3090 | case, it MUST either return an empty string or no CP payload if CP is | |
3091 | not supported. | |
a6d7a610 MW |
3092 | |
3093 | Initiator Responder | |
3094 | ------------------------------------------------------------------- | |
3095 | HDR, SK{CP(CFG_REQUEST)} --> | |
3096 | <-- HDR, SK{CP(CFG_REPLY)} | |
3097 | ||
3098 | CP(CFG_REQUEST)= | |
3099 | APPLICATION_VERSION("") | |
3100 | ||
3101 | CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar | |
3102 | Inc.") | |
3103 | ||
824a0402 | 3104 | 2.21. Error Handling |
2eac2578 | 3105 | |
824a0402 AS |
3106 | There are many kinds of errors that can occur during IKE processing. |
3107 | The general rule is that if a request is received that is badly | |
3108 | formatted, or unacceptable for reasons of policy (such as no matching | |
3109 | cryptographic algorithms), the response contains a Notify payload | |
3110 | indicating the error. The decision whether or not to send such a | |
3111 | response depends whether or not there is an authenticated IKE SA. | |
3112 | ||
3113 | If there is an error parsing or processing a response packet, the | |
3114 | general rule is to not send back any error message because responses | |
3115 | should not generate new requests (and a new request would be the only | |
3116 | way to send back an error message). Such errors in parsing or | |
3117 | processing response packets should still cause the recipient to clean | |
3118 | up the IKE state (for example, by sending a Delete for a bad SA). | |
3119 | ||
3120 | Only authentication failures (AUTHENTICATION_FAILED and EAP failure) | |
3121 | and malformed messages (INVALID_SYNTAX) lead to a deletion of the IKE | |
3122 | SA without requiring an explicit INFORMATIONAL exchange carrying a | |
3123 | Delete payload. Other error conditions MAY require such an exchange | |
3124 | if policy dictates that this is needed. If the exchange is | |
3125 | terminated with EAP Failure, an AUTHENTICATION_FAILED notification is | |
3126 | not sent. | |
3127 | ||
3128 | 2.21.1. Error Handling in IKE_SA_INIT | |
2eac2578 | 3129 | |
824a0402 AS |
3130 | Errors that occur before a cryptographically protected IKE SA is |
3131 | established need to be handled very carefully. There is a trade-off | |
3132 | between wanting to help the peer to diagnose a problem and thus | |
3133 | responding to the error and wanting to avoid being part of a DoS | |
3134 | attack based on forged messages. | |
2eac2578 MW |
3135 | |
3136 | ||
3137 | ||
824a0402 | 3138 | Kaufman, et al. Standards Track [Page 56] |
2eac2578 | 3139 | \f |
824a0402 | 3140 | RFC 5996 IKEv2bis September 2010 |
2eac2578 MW |
3141 | |
3142 | ||
824a0402 AS |
3143 | In an IKE_SA_INIT exchange, any error notification causes the |
3144 | exchange to fail. Note that some error notifications such as COOKIE, | |
3145 | INVALID_KE_PAYLOAD or INVALID_MAJOR_VERSION may lead to a subsequent | |
3146 | successful exchange. Because all error notifications are completely | |
3147 | unauthenticated, the recipient should continue trying for some time | |
3148 | before giving up. The recipient should not immediately act based on | |
3149 | the error notification unless corrective actions are defined in this | |
3150 | specification, such as for COOKIE, INVALID_KE_PAYLOAD, and | |
3151 | INVALID_MAJOR_VERSION. | |
a6d7a610 | 3152 | |
824a0402 | 3153 | 2.21.2. Error Handling in IKE_AUTH |
a6d7a610 | 3154 | |
824a0402 AS |
3155 | All errors that occur in an IKE_AUTH exchange, causing the |
3156 | authentication to fail for whatever reason (invalid shared secret, | |
3157 | invalid ID, untrusted certificate issuer, revoked or expired | |
3158 | certificate, etc.) SHOULD result in an AUTHENTICATION_FAILED | |
3159 | notification. If the error occurred on the responder, the | |
3160 | notification is returned in the protected response, and is usually | |
3161 | the only payload in that response. Although the IKE_AUTH messages | |
3162 | are encrypted and integrity protected, if the peer receiving this | |
3163 | notification has not authenticated the other end yet, that peer needs | |
3164 | to treat the information with caution. | |
3165 | ||
3166 | If the error occurs on the initiator, the notification MAY be | |
3167 | returned in a separate INFORMATIONAL exchange, usually with no other | |
3168 | payloads. This is an exception for the general rule of not starting | |
3169 | new exchanges based on errors in responses. | |
3170 | ||
3171 | Note, however, that request messages that contain an unsupported | |
3172 | critical payload, or where the whole message is malformed (rather | |
3173 | than just bad payload contents), MUST be rejected in their entirety, | |
3174 | and MUST only lead to an UNSUPPORTED_CRITICAL_PAYLOAD or | |
3175 | INVALID_SYNTAX Notification sent as a response. The receiver should | |
3176 | not verify the payloads related to authentication in this case. | |
3177 | ||
3178 | If authentication has succeeded in the IKE_AUTH exchange, the IKE SA | |
3179 | is established; however, establishing the Child SA or requesting | |
3180 | configuration information may still fail. This failure does not | |
3181 | automatically cause the IKE SA to be deleted. Specifically, a | |
3182 | responder may include all the payloads associated with authentication | |
3183 | (IDr, CERT, and AUTH) while sending error notifications for the | |
3184 | piggybacked exchanges (FAILED_CP_REQUIRED, NO_PROPOSAL_CHOSEN, and so | |
3185 | on), and the initiator MUST NOT fail the authentication because of | |
3186 | this. The initiator MAY, of course, for reasons of policy later | |
3187 | delete such an IKE SA. | |
3188 | ||
3189 | ||
3190 | ||
3191 | ||
3192 | ||
3193 | ||
3194 | Kaufman, et al. Standards Track [Page 57] | |
3195 | \f | |
3196 | RFC 5996 IKEv2bis September 2010 | |
3197 | ||
3198 | ||
3199 | In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately | |
3200 | following it (in case an error happened when processing a response to | |
3201 | IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and | |
3202 | AUTHENTICATION_FAILED notifications are the only ones to cause the | |
3203 | IKE SA to be deleted or not created, without a Delete payload. | |
3204 | Extension documents may define new error notifications with these | |
3205 | semantics, but MUST NOT use them unless the peer has been shown to | |
3206 | understand them, such as by using the Vendor ID payload. | |
3207 | ||
3208 | 2.21.3. Error Handling after IKE SA is Authenticated | |
3209 | ||
3210 | After the IKE SA is authenticated, all requests having errors MUST | |
3211 | result in a response notifying about the error. | |
3212 | ||
3213 | In normal situations, there should not be cases where a valid | |
3214 | response from one peer results in an error situation in the other | |
3215 | peer, so there should not be any reason for a peer to send error | |
3216 | messages to the other end except as a response. Because sending such | |
3217 | error messages as an INFORMATIONAL exchange might lead to further | |
3218 | errors that could cause loops, such errors SHOULD NOT be sent. If | |
3219 | errors are seen that indicate that the peers do not have the same | |
3220 | state, it might be good to delete the IKE SA to clean up state and | |
3221 | start over. | |
3222 | ||
3223 | If a peer parsing a request notices that it is badly formatted (after | |
3224 | it has passed the message authentication code checks and window | |
3225 | checks) and it returns an INVALID_SYNTAX notification, then this | |
3226 | error notification is considered fatal in both peers, meaning that | |
3227 | the IKE SA is deleted without needing an explicit Delete payload. | |
3228 | ||
3229 | 2.21.4. Error Handling Outside IKE SA | |
3230 | ||
3231 | A node needs to limit the rate at which it will send messages in | |
3232 | response to unprotected messages. | |
a6d7a610 MW |
3233 | |
3234 | If a node receives a message on UDP port 500 or 4500 outside the | |
824a0402 AS |
3235 | context of an IKE SA known to it (and the message is not a request to |
3236 | start an IKE SA), this may be the result of a recent crash of the | |
3237 | node. If the message is marked as a response, the node can audit the | |
3238 | suspicious event but MUST NOT respond. If the message is marked as a | |
3239 | request, the node can audit the suspicious event and MAY send a | |
3240 | response. If a response is sent, the response MUST be sent to the IP | |
3241 | address and port from where it came with the same IKE SPIs and the | |
3242 | Message ID copied. The response MUST NOT be cryptographically | |
3243 | protected and MUST contain an INVALID_IKE_SPI Notify payload. The | |
2eac2578 MW |
3244 | INVALID_IKE_SPI notification indicates an IKE message was received |
3245 | with an unrecognized destination SPI; this usually indicates that the | |
3246 | recipient has rebooted and forgotten the existence of an IKE SA. | |
a6d7a610 | 3247 | |
824a0402 AS |
3248 | |
3249 | ||
3250 | Kaufman, et al. Standards Track [Page 58] | |
3251 | \f | |
3252 | RFC 5996 IKEv2bis September 2010 | |
3253 | ||
3254 | ||
3255 | A peer receiving such an unprotected Notify payload MUST NOT respond | |
a6d7a610 | 3256 | and MUST NOT change the state of any existing SAs. The message might |
824a0402 | 3257 | be a forgery or might be a response that a genuine correspondent was |
2eac2578 MW |
3258 | tricked into sending. A node should treat such a message (and also a |
3259 | network message like ICMP destination unreachable) as a hint that | |
3260 | there might be problems with SAs to that IP address and should | |
824a0402 | 3261 | initiate a liveness check for any such IKE SA. An implementation |
2eac2578 | 3262 | SHOULD limit the frequency of such tests to avoid being tricked into |
824a0402 | 3263 | participating in a DoS attack. |
2eac2578 | 3264 | |
824a0402 AS |
3265 | If an error occurs outside the context of an IKE request (e.g., the |
3266 | node is getting ESP messages on a nonexistent SPI), the node SHOULD | |
3267 | initiate an INFORMATIONAL exchange with a Notify payload describing | |
3268 | the problem. | |
2eac2578 | 3269 | |
824a0402 AS |
3270 | A node receiving a suspicious message from an IP address (and port, |
3271 | if NAT traversal is used) with which it has an IKE SA SHOULD send an | |
3272 | IKE Notify payload in an IKE INFORMATIONAL exchange over that SA. | |
3273 | The recipient MUST NOT change the state of any SAs as a result, but | |
3274 | may wish to audit the event to aid in diagnosing malfunctions. | |
a6d7a610 MW |
3275 | |
3276 | 2.22. IPComp | |
3277 | ||
824a0402 AS |
3278 | Use of IP Compression [IP-COMP] can be negotiated as part of the |
3279 | setup of a Child SA. While IP Compression involves an extra header | |
a6d7a610 MW |
3280 | in each packet and a compression parameter index (CPI), the virtual |
3281 | "compression association" has no life outside the ESP or AH SA that | |
3282 | contains it. Compression associations disappear when the | |
3283 | corresponding ESP or AH SA goes away. It is not explicitly mentioned | |
824a0402 | 3284 | in any Delete payload. |
a6d7a610 | 3285 | |
824a0402 | 3286 | Negotiation of IP Compression is separate from the negotiation of |
a6d7a610 MW |
3287 | cryptographic parameters associated with a Child SA. A node |
3288 | requesting a Child SA MAY advertise its support for one or more | |
3289 | compression algorithms through one or more Notify payloads of type | |
824a0402 | 3290 | IPCOMP_SUPPORTED. This Notify message may be included only in a |
a6d7a610 MW |
3291 | message containing an SA payload negotiating a Child SA and indicates |
3292 | a willingness by its sender to use IPComp on this SA. The response | |
3293 | MAY indicate acceptance of a single compression algorithm with a | |
3294 | Notify payload of type IPCOMP_SUPPORTED. These payloads MUST NOT | |
3295 | occur in messages that do not contain SA payloads. | |
3296 | ||
824a0402 AS |
3297 | The data associated with this Notify message includes a two-octet |
3298 | IPComp CPI followed by a one-octet Transform ID optionally followed | |
3299 | by attributes whose length and format are defined by that Transform | |
2eac2578 MW |
3300 | ID. A message proposing an SA may contain multiple IPCOMP_SUPPORTED |
3301 | notifications to indicate multiple supported algorithms. A message | |
3302 | accepting an SA may contain at most one. | |
a6d7a610 | 3303 | |
824a0402 AS |
3304 | |
3305 | ||
3306 | Kaufman, et al. Standards Track [Page 59] | |
3307 | \f | |
3308 | RFC 5996 IKEv2bis September 2010 | |
3309 | ||
3310 | ||
3311 | The Transform IDs are listed here. The values in the following table | |
3312 | are only current as of the publication date of RFC 4306. Other | |
3313 | values may have been added since then or will be added after the | |
3314 | publication of this document. Readers should refer to [IKEV2IANA] | |
3315 | for the latest values. | |
a6d7a610 MW |
3316 | |
3317 | Name Number Defined In | |
3318 | ------------------------------------- | |
a6d7a610 MW |
3319 | IPCOMP_OUI 1 |
3320 | IPCOMP_DEFLATE 2 RFC 2394 | |
3321 | IPCOMP_LZS 3 RFC 2395 | |
3322 | IPCOMP_LZJH 4 RFC 3051 | |
a6d7a610 MW |
3323 | |
3324 | Although there has been discussion of allowing multiple compression | |
3325 | algorithms to be accepted and to have different compression | |
3326 | algorithms available for the two directions of a Child SA, | |
3327 | implementations of this specification MUST NOT accept an IPComp | |
3328 | algorithm that was not proposed, MUST NOT accept more than one, and | |
3329 | MUST NOT compress using an algorithm other than one proposed and | |
3330 | accepted in the setup of the Child SA. | |
3331 | ||
3332 | A side effect of separating the negotiation of IPComp from | |
3333 | cryptographic parameters is that it is not possible to propose | |
824a0402 | 3334 | multiple cryptographic suites and propose IP Compression with some of |
a6d7a610 MW |
3335 | them but not others. |
3336 | ||
3337 | In some cases, Robust Header Compression (ROHC) may be more | |
3338 | appropriate than IP Compression. [ROHCV2] defines the use of ROHC | |
3339 | with IKEv2 and IPsec. | |
3340 | ||
3341 | 2.23. NAT Traversal | |
3342 | ||
3343 | Network Address Translation (NAT) gateways are a controversial | |
3344 | subject. This section briefly describes what they are and how they | |
3345 | are likely to act on IKE traffic. Many people believe that NATs are | |
3346 | evil and that we should not design our protocols so as to make them | |
3347 | work better. IKEv2 does specify some unintuitive processing rules in | |
3348 | order that NATs are more likely to work. | |
3349 | ||
3350 | NATs exist primarily because of the shortage of IPv4 addresses, | |
3351 | though there are other rationales. IP nodes that are "behind" a NAT | |
3352 | have IP addresses that are not globally unique, but rather are | |
a6d7a610 MW |
3353 | assigned from some space that is unique within the network behind the |
3354 | NAT but that are likely to be reused by nodes behind other NATs. | |
3355 | Generally, nodes behind NATs can communicate with other nodes behind | |
3356 | the same NAT and with nodes with globally unique addresses, but not | |
3357 | with nodes behind other NATs. There are exceptions to that rule. | |
3358 | When those nodes make connections to nodes on the real Internet, the | |
824a0402 AS |
3359 | |
3360 | ||
3361 | ||
3362 | Kaufman, et al. Standards Track [Page 60] | |
3363 | \f | |
3364 | RFC 5996 IKEv2bis September 2010 | |
3365 | ||
3366 | ||
a6d7a610 MW |
3367 | NAT gateway "translates" the IP source address to an address that |
3368 | will be routed back to the gateway. Messages to the gateway from the | |
3369 | Internet have their destination addresses "translated" to the | |
3370 | internal address that will route the packet to the correct endnode. | |
3371 | ||
3372 | NATs are designed to be "transparent" to endnodes. Neither software | |
3373 | on the node behind the NAT nor the node on the Internet requires | |
3374 | modification to communicate through the NAT. Achieving this | |
3375 | transparency is more difficult with some protocols than with others. | |
3376 | Protocols that include IP addresses of the endpoints within the | |
3377 | payloads of the packet will fail unless the NAT gateway understands | |
3378 | the protocol and modifies the internal references as well as those in | |
3379 | the headers. Such knowledge is inherently unreliable, is a network | |
3380 | layer violation, and often results in subtle problems. | |
3381 | ||
3382 | Opening an IPsec connection through a NAT introduces special | |
3383 | problems. If the connection runs in transport mode, changing the IP | |
3384 | addresses on packets will cause the checksums to fail and the NAT | |
3385 | cannot correct the checksums because they are cryptographically | |
3386 | protected. Even in tunnel mode, there are routing problems because | |
3387 | transparently translating the addresses of AH and ESP packets | |
3388 | requires special logic in the NAT and that logic is heuristic and | |
3389 | unreliable in nature. For that reason, IKEv2 will use UDP | |
3390 | encapsulation of IKE and ESP packets. This encoding is slightly less | |
3391 | efficient but is easier for NATs to process. In addition, firewalls | |
824a0402 AS |
3392 | may be configured to pass UDP-encapsulated IPsec traffic but not |
3393 | plain, unencapsulated ESP/AH or vice versa. | |
a6d7a610 MW |
3394 | |
3395 | It is a common practice of NATs to translate TCP and UDP port numbers | |
3396 | as well as addresses and use the port numbers of inbound packets to | |
3397 | decide which internal node should get a given packet. For this | |
824a0402 | 3398 | reason, even though IKE packets MUST be sent to and from UDP port 500 |
a6d7a610 MW |
3399 | or 4500, they MUST be accepted coming from any port and responses |
3400 | MUST be sent to the port from whence they came. This is because the | |
3401 | ports may be modified as the packets pass through NATs. Similarly, | |
3402 | IP addresses of the IKE endpoints are generally not included in the | |
3403 | IKE payloads because the payloads are cryptographically protected and | |
3404 | could not be transparently modified by NATs. | |
3405 | ||
2eac2578 | 3406 | Port 4500 is reserved for UDP-encapsulated ESP and IKE. An IPsec |
824a0402 AS |
3407 | endpoint that discovers a NAT between it and its correspondent (as |
3408 | described below) MUST send all subsequent traffic from port 4500, | |
3409 | which NATs should not treat specially (as they might with port 500). | |
82f0707f | 3410 | |
824a0402 AS |
3411 | An initiator can use port 4500 for both IKE and ESP, regardless of |
3412 | whether or not there is a NAT, even at the beginning of IKE. When | |
3413 | either side is using port 4500, sending ESP with UDP encapsulation is | |
3414 | not required, but understanding received UDP-encapsulated ESP packets | |
a6d7a610 | 3415 | |
a6d7a610 | 3416 | |
a6d7a610 | 3417 | |
824a0402 AS |
3418 | Kaufman, et al. Standards Track [Page 61] |
3419 | \f | |
3420 | RFC 5996 IKEv2bis September 2010 | |
82f0707f MW |
3421 | |
3422 | ||
824a0402 AS |
3423 | is required. UDP encapsulation MUST NOT be done on port 500. If |
3424 | Network Address Translation Traversal (NAT-T) is supported (that is, | |
3425 | if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT), | |
3426 | all devices MUST be able to receive and process both UDP-encapsulated | |
3427 | ESP and non-UDP-encapsulated ESP packets at any time. Either side | |
3428 | can decide whether or not to use UDP encapsulation for ESP | |
3429 | irrespective of the choice made by the other side. However, if a NAT | |
3430 | is detected, both devices MUST use UDP encapsulation for ESP. | |
82f0707f | 3431 | |
824a0402 AS |
3432 | The specific requirements for supporting NAT traversal [NATREQ] are |
3433 | listed below. Support for NAT traversal is optional. In this | |
3434 | section only, requirements listed as MUST apply only to | |
3435 | implementations supporting NAT traversal. | |
a6d7a610 | 3436 | |
824a0402 AS |
3437 | o Both the IKE initiator and responder MUST include in their |
3438 | IKE_SA_INIT packets Notify payloads of type | |
3439 | NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP. Those | |
3440 | payloads can be used to detect if there is NAT between the hosts, | |
3441 | and which end is behind the NAT. The location of the payloads in | |
3442 | the IKE_SA_INIT packets is just after the Ni and Nr payloads | |
3443 | (before the optional CERTREQ payload). | |
a6d7a610 | 3444 | |
2eac2578 MW |
3445 | o The data associated with the NAT_DETECTION_SOURCE_IP notification |
3446 | is a SHA-1 digest of the SPIs (in the order they appear in the | |
824a0402 | 3447 | header), IP address, and port from which this packet was sent. |
2eac2578 MW |
3448 | There MAY be multiple NAT_DETECTION_SOURCE_IP payloads in a |
3449 | message if the sender does not know which of several network | |
3450 | attachments will be used to send the packet. | |
3451 | ||
3452 | o The data associated with the NAT_DETECTION_DESTINATION_IP | |
3453 | notification is a SHA-1 digest of the SPIs (in the order they | |
3454 | appear in the header), IP address, and port to which this packet | |
3455 | was sent. | |
3456 | ||
3457 | o The recipient of either the NAT_DETECTION_SOURCE_IP or | |
3458 | NAT_DETECTION_DESTINATION_IP notification MAY compare the supplied | |
824a0402 AS |
3459 | value to a SHA-1 hash of the SPIs, source or recipient IP address |
3460 | (respectively), address, and port, and if they don't match, it | |
3461 | SHOULD enable NAT traversal. In the case there is a mismatch of | |
3462 | the NAT_DETECTION_SOURCE_IP hash with all of the | |
3463 | NAT_DETECTION_SOURCE_IP payloads received, the recipient MAY | |
3464 | reject the connection attempt if NAT traversal is not supported. | |
3465 | In the case of a mismatching NAT_DETECTION_DESTINATION_IP hash, it | |
3466 | means that the system receiving the NAT_DETECTION_DESTINATION_IP | |
3467 | payload is behind a NAT and that system SHOULD start sending | |
3468 | keepalive packets as defined in [UDPENCAPS]; alternately, it MAY | |
3469 | reject the connection attempt if NAT traversal is not supported. | |
3470 | ||
3471 | ||
3472 | ||
3473 | ||
3474 | Kaufman, et al. Standards Track [Page 62] | |
3475 | \f | |
3476 | RFC 5996 IKEv2bis September 2010 | |
3477 | ||
a6d7a610 MW |
3478 | |
3479 | o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches | |
3480 | the expected value of the source IP and port found from the IP | |
82f0707f | 3481 | header of the packet containing the payload, it means that the |
824a0402 | 3482 | system sending those payloads is behind a NAT (i.e., someone along |
a6d7a610 MW |
3483 | the route changed the source address of the original packet to |
3484 | match the address of the NAT box). In this case, the system | |
824a0402 | 3485 | receiving the payloads should allow dynamic updates of the other |
a6d7a610 MW |
3486 | systems' IP address, as described later. |
3487 | ||
824a0402 AS |
3488 | o The IKE initiator MUST check the NAT_DETECTION_SOURCE_IP or |
3489 | NAT_DETECTION_DESTINATION_IP payloads if present, and if they do | |
3490 | not match the addresses in the outer packet, MUST tunnel all | |
a6d7a610 MW |
3491 | future IKE and ESP packets associated with this IKE SA over UDP |
3492 | port 4500. | |
3493 | ||
3494 | o To tunnel IKE packets over UDP port 4500, the IKE header has four | |
3495 | octets of zero prepended and the result immediately follows the | |
3496 | UDP header. To tunnel ESP packets over UDP port 4500, the ESP | |
3497 | header immediately follows the UDP header. Since the first four | |
3498 | octets of the ESP header contain the SPI, and the SPI cannot | |
3499 | validly be zero, it is always possible to distinguish ESP and IKE | |
3500 | messages. | |
3501 | ||
3502 | o Implementations MUST process received UDP-encapsulated ESP packets | |
3503 | even when no NAT was detected. | |
3504 | ||
3505 | o The original source and destination IP address required for the | |
3506 | transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) | |
3507 | are obtained from the Traffic Selectors associated with the | |
824a0402 AS |
3508 | exchange. In the case of transport mode NAT traversal, the |
3509 | Traffic Selectors MUST contain exactly one IP address, which is | |
3510 | then used as the original IP address. This is covered in greater | |
3511 | detail in Section 2.23.1. | |
a6d7a610 | 3512 | |
82f0707f MW |
3513 | o There are cases where a NAT box decides to remove mappings that |
3514 | are still alive (for example, the keepalive interval is too long, | |
824a0402 AS |
3515 | or the NAT box is rebooted). This will be apparent to a host if |
3516 | it receives a packet whose integrity protection validates, but has | |
3517 | a different port, address, or both from the one that was | |
3518 | associated with the SA in the validated packet. When such a | |
3519 | validated packet is found, a host that does not support other | |
3520 | methods of recovery such as IKEv2 Mobility and Multihoming | |
3521 | (MOBIKE) [MOBIKE], and that is not behind a NAT, SHOULD send all | |
3522 | packets (including retransmission packets) to the IP address and | |
3523 | port in the validated packet, and SHOULD store this as the new | |
3524 | address and port combination for the SA (that is, they SHOULD | |
3525 | dynamically update the address). A host behind a NAT SHOULD NOT | |
3526 | do this type of dynamic address update if a validated packet has | |
3527 | ||
3528 | ||
3529 | ||
3530 | Kaufman, et al. Standards Track [Page 63] | |
3531 | \f | |
3532 | RFC 5996 IKEv2bis September 2010 | |
3533 | ||
3534 | ||
3535 | different port and/or address values because it opens a possible | |
3536 | DoS attack (such as allowing an attacker to break the connection | |
3537 | with a single packet). Also, dynamic address update should only | |
3538 | be done in response to a new packet; otherwise, an attacker can | |
3539 | revert the addresses with old replayed packets. Because of this, | |
3540 | dynamic updates can only be done safely if replay protection is | |
3541 | enabled. When IKEv2 is used with MOBIKE, dynamically updating the | |
3542 | addresses described above interferes with MOBIKE's way of | |
3543 | recovering from the same situation. See Section 3.8 of [MOBIKE] | |
82f0707f | 3544 | for more information. |
a6d7a610 | 3545 | |
824a0402 AS |
3546 | 2.23.1. Transport Mode NAT Traversal |
3547 | ||
3548 | Transport mode used with NAT Traversal requires special handling of | |
3549 | the Traffic Selectors used in the IKEv2. The complete scenario looks | |
3550 | like: | |
3551 | ||
3552 | +------+ +------+ +------+ +------+ | |
3553 | |Client| IP1 | NAT | IPN1 IPN2 | NAT | IP2 |Server| | |
3554 | |node |<------>| A |<---------->| B |<------->| | | |
3555 | +------+ +------+ +------+ +------+ | |
3556 | ||
3557 | (Other scenarios are simplifications of this complex case, so this | |
3558 | discussion uses the complete scenario.) | |
3559 | ||
3560 | In this scenario, there are two address translating NATs: NAT A and | |
3561 | NAT B. NAT A is a dynamic NAT that maps the client's source address | |
3562 | IP1 to IPN1. NAT B is a static NAT configured so that connections | |
3563 | coming to IPN2 address are mapped to the gateway's address IP2, that | |
3564 | is, IPN2 destination address is mapped to IP2. This allows the | |
3565 | client to connect to a server by connecting to the IPN2. NAT B does | |
3566 | not necessarily need to be a static NAT, but the client needs to know | |
3567 | how to connect to the server, and it can only do that if it somehow | |
3568 | knows the outer address of the NAT B, that is, the IPN2 address. If | |
3569 | NAT B is a static NAT, then its address can be configured to the | |
3570 | client's configuration. Another option would be to find it using | |
3571 | some other protocol (like DNS), but that is outside of scope of | |
3572 | IKEv2. | |
2eac2578 | 3573 | |
824a0402 AS |
3574 | In this scenario, both the client and server are configured to use |
3575 | transport mode for the traffic originating from the client node and | |
3576 | destined to the server. | |
3577 | ||
3578 | When the client starts creating the IKEv2 SA and Child SA for sending | |
3579 | traffic to the server, it may have a triggering packet with source IP | |
3580 | address of IP1, and a destination IP address of IPN2. Its Peer | |
3581 | Authorization Database (PAD) and SPD needs to have a configuration | |
3582 | matching those addresses (or wildcard entries covering them). | |
3583 | ||
3584 | ||
3585 | ||
3586 | Kaufman, et al. Standards Track [Page 64] | |
3587 | \f | |
3588 | RFC 5996 IKEv2bis September 2010 | |
3589 | ||
3590 | ||
3591 | Because this is transport mode, it uses exactly same addresses as the | |
3592 | Traffic Selectors and outer IP address of the IKE packets. For | |
3593 | transport mode, it MUST use exactly one IP address in the TSi and TSr | |
3594 | payloads. It can have multiple Traffic Selectors if it has, for | |
3595 | example, multiple port ranges that it wants to negotiate, but all TSi | |
3596 | entries must use the IP1-IP1 range as the IP addresses, and all TSr | |
3597 | entries must have the IPN2-IPN2 range as IP addresses. The first | |
3598 | Traffic Selector of TSi and TSr SHOULD have very specific Traffic | |
3599 | Selectors including protocol and port numbers, such as from the | |
3600 | packet triggering the request. | |
2eac2578 | 3601 | |
824a0402 AS |
3602 | NAT A will then replace the source address of the IKE packet from IP1 |
3603 | to IPN1, and NAT B will replace the destination address of the IKE | |
3604 | packet from IPN2 to IP2, so when the packet arrives to the server it | |
3605 | will still have the exactly same Traffic Selectors that were sent by | |
3606 | the client, but the IP address of the IKE packet has been replaced by | |
3607 | IPN1 and IP2. | |
2eac2578 | 3608 | |
824a0402 AS |
3609 | When the server receives this packet, it normally looks in the Peer |
3610 | Authorization Database (PAD) described in RFC 4301 [IPSECARCH] based | |
3611 | on the ID and then searches the SPD based on the Traffic Selectors. | |
3612 | Because IP1 does not really mean anything to the server (it is the | |
3613 | address client has behind the NAT), it is useless to do a lookup | |
3614 | based on that if transport mode is used. On the other hand, the | |
3615 | server cannot know whether transport mode is allowed by its policy | |
3616 | before it finds the matching SPD entry. | |
2eac2578 | 3617 | |
824a0402 AS |
3618 | In this case, the server should first check that the initiator |
3619 | requested transport mode, and then do address substitution on the | |
3620 | Traffic Selectors. It needs to first store the old Traffic Selector | |
3621 | IP addresses to be used later for the incremental checksum fixup (the | |
3622 | IP address in the TSi can be stored as the original source address | |
3623 | and the IP address in the TSr can be stored as the original | |
3624 | destination address). After that, if the other end was detected as | |
3625 | being behind a NAT, the server replaces the IP address in TSi | |
3626 | payloads with the IP address obtained from the source address of the | |
3627 | IKE packet received (that is, it replaces IP1 in TSi with IPN1). If | |
3628 | the server's end was detected to be behind NAT, it replaces the IP | |
3629 | address in the TSr payloads with the IP address obtained from the | |
3630 | destination address of the IKE packet received (that is, it replaces | |
3631 | IPN2 in TSr with IP2). | |
2eac2578 | 3632 | |
824a0402 AS |
3633 | After this address substitution, both the Traffic Selectors and the |
3634 | IKE UDP source/destination addresses look the same, and the server | |
3635 | does SPD lookup based on those new Traffic Selectors. If an entry is | |
3636 | found and it allows transport mode, then that entry is used. If an | |
3637 | entry is found but it does not allow transport mode, then the server | |
3638 | MAY undo the address substitution and redo the SPD lookup using the | |
3639 | ||
3640 | ||
3641 | ||
3642 | Kaufman, et al. Standards Track [Page 65] | |
3643 | \f | |
3644 | RFC 5996 IKEv2bis September 2010 | |
3645 | ||
3646 | ||
3647 | original Traffic Selectors. If the second lookup succeeds, the | |
3648 | server will create an SA in tunnel mode using real Traffic Selectors | |
3649 | sent by the other end. | |
3650 | ||
3651 | This address substitution in transport mode is needed because the SPD | |
3652 | is looked up using the addresses that will be seen by the local host. | |
3653 | This also will make sure the Security Association Database (SAD) | |
3654 | entries for the tunnel exit checks and return packets is added using | |
3655 | the addresses as seen by the local operating system stack. | |
3656 | ||
3657 | The most common case is that the server's SPD will contain wildcard | |
3658 | entries matching any addresses, but this also allows making different | |
3659 | SPD entries, for example, for different known NATs' outer addresses. | |
3660 | ||
3661 | After the SPD lookup, the server will do Traffic Selector narrowing | |
3662 | based on the SPD entry it found. It will again use the already | |
3663 | substituted Traffic Selectors, and it will thus send back Traffic | |
3664 | Selectors having IPN1 and IP2 as their IP addresses; it can still | |
3665 | narrow down the protocol number or port ranges used by the Traffic | |
3666 | Selectors. The SAD entry created for the Child SA will have the | |
3667 | addresses as seen by the server, namely IPN1 and IP2. | |
3668 | ||
3669 | When the client receives the server's response to the Child SA, it | |
3670 | will do similar processing. If the transport mode SA was created, | |
3671 | the client can store the original returned Traffic Selectors as | |
3672 | original source and destination addresses. It will replace the IP | |
3673 | addresses in the Traffic Selectors with the ones from the IP header | |
3674 | of the IKE packet: it will replace IPN1 with IP1 and IP2 with IPN2. | |
3675 | Then, it will use those Traffic Selectors when verifying the SA | |
3676 | against sent Traffic Selectors, and when installing the SAD entry. | |
3677 | ||
3678 | A summary of the rules for NAT traversal in transport mode is: | |
3679 | ||
3680 | For the client proposing transport mode: | |
3681 | ||
3682 | - The TSi entries MUST have exactly one IP address, and that MUST | |
3683 | match the source address of the IKE SA. | |
3684 | ||
3685 | - The TSr entries MUST have exactly one IP address, and that MUST | |
3686 | match the destination address of the IKE SA. | |
3687 | ||
3688 | - The first TSi and TSr Traffic Selectors SHOULD have very specific | |
3689 | Traffic Selectors including protocol and port numbers, such as | |
3690 | from the packet triggering the request. | |
3691 | ||
3692 | - There MAY be multiple TSi and TSr entries. | |
3693 | ||
3694 | ||
3695 | ||
3696 | ||
3697 | ||
3698 | Kaufman, et al. Standards Track [Page 66] | |
3699 | \f | |
3700 | RFC 5996 IKEv2bis September 2010 | |
3701 | ||
3702 | ||
3703 | - If transport mode for the SA was selected (that is, if the server | |
3704 | included USE_TRANSPORT_MODE notification in its response): | |
3705 | ||
3706 | - Store the original Traffic Selectors as the received source and | |
3707 | destination address. | |
3708 | ||
3709 | - If the server is behind a NAT, substitute the IP address in the | |
3710 | TSr entries with the remote address of the IKE SA. | |
3711 | ||
3712 | - If the client is behind a NAT, substitute the IP address in the | |
3713 | TSi entries with the local address of the IKE SA. | |
3714 | ||
3715 | - Do address substitution before using those Traffic Selectors | |
3716 | for anything other than storing original content of them. | |
3717 | This includes verification that Traffic Selectors were narrowed | |
3718 | correctly by the other end, creation of the SAD entry, and so on. | |
3719 | ||
3720 | For the responder, when transport mode is proposed by client: | |
3721 | ||
3722 | - Store the original Traffic Selector IP addresses as received source | |
3723 | and destination address, in case undo address | |
3724 | substitution is needed, to use as the "real source and destination | |
3725 | address" specified by [UDPENCAPS], and for TCP/UDP checksum fixup. | |
3726 | ||
3727 | - If the client is behind a NAT, substitute the IP address in the | |
3728 | TSi entries with the remote address of the IKE SA. | |
3729 | ||
3730 | - If the server is behind a NAT, substitute the IP address in the | |
3731 | TSr entries with the local address of the IKE SA. | |
3732 | ||
3733 | - Do PAD and SPD lookup using the ID and substituted Traffic | |
3734 | Selectors. | |
3735 | ||
3736 | - If no SPD entry was found, or if found SPD entry does not | |
3737 | allow transport mode, undo the Traffic Selector substitutions. | |
3738 | Do PAD and SPD lookup again using the ID and original Traffic | |
3739 | Selectors, but also searching for tunnel mode SPD entry (that | |
3740 | is, fall back to tunnel mode). | |
3741 | ||
3742 | - However, if a transport mode SPD entry was found, do normal | |
3743 | traffic selection narrowing based on the substituted Traffic | |
3744 | Selectors and SPD entry. Use the resulting Traffic Selectors when | |
3745 | creating SAD entries, and when sending Traffic Selectors back to | |
3746 | the client. | |
3747 | ||
3748 | ||
3749 | ||
3750 | ||
3751 | ||
3752 | ||
3753 | ||
3754 | Kaufman, et al. Standards Track [Page 67] | |
3755 | \f | |
3756 | RFC 5996 IKEv2bis September 2010 | |
2eac2578 MW |
3757 | |
3758 | ||
a6d7a610 MW |
3759 | 2.24. Explicit Congestion Notification (ECN) |
3760 | ||
3761 | When IPsec tunnels behave as originally specified in [IPSECARCH-OLD], | |
3762 | ECN usage is not appropriate for the outer IP headers because tunnel | |
3763 | decapsulation processing discards ECN congestion indications to the | |
3764 | detriment of the network. ECN support for IPsec tunnels for IKEv1- | |
3765 | based IPsec requires multiple operating modes and negotiation (see | |
3766 | [ECN]). IKEv2 simplifies this situation by requiring that ECN be | |
824a0402 | 3767 | usable in the outer IP headers of all tunnel mode Child SAs created |
a6d7a610 | 3768 | by IKEv2. Specifically, tunnel encapsulators and decapsulators for |
824a0402 | 3769 | all tunnel mode SAs created by IKEv2 MUST support the ECN full- |
a6d7a610 MW |
3770 | functionality option for tunnels specified in [ECN] and MUST |
3771 | implement the tunnel encapsulation and decapsulation processing | |
3772 | specified in [IPSECARCH] to prevent discarding of ECN congestion | |
3773 | indications. | |
3774 | ||
824a0402 AS |
3775 | 2.25. Exchange Collisions |
3776 | ||
3777 | Because IKEv2 exchanges can be initiated by either peer, it is | |
3778 | possible that two exchanges affecting the same SA partly overlap. | |
3779 | This can lead to a situation where the SA state information is | |
3780 | temporarily not synchronized, and a peer can receive a request that | |
3781 | it cannot process in a normal fashion. | |
3782 | ||
3783 | Obviously, using a window size greater than 1 leads to more complex | |
3784 | situations, especially if requests are processed out of order. This | |
3785 | section concentrates on problems that can arise even with a window | |
3786 | size of 1, and recommends solutions. | |
3787 | ||
3788 | A TEMPORARY_FAILURE notification SHOULD be sent when a peer receives | |
3789 | a request that cannot be completed due to a temporary condition such | |
3790 | as a rekeying operation. When a peer receives a TEMPORARY_FAILURE | |
3791 | notification, it MUST NOT immediately retry the operation; it MUST | |
3792 | wait so that the sender may complete whatever operation caused the | |
3793 | temporary condition. The recipient MAY retry the request one or more | |
3794 | times over a period of several minutes. If a peer continues to | |
3795 | receive TEMPORARY_FAILURE on the same IKE SA after several minutes, | |
3796 | it SHOULD conclude that the state information is out of sync and | |
3797 | close the IKE SA. | |
3798 | ||
3799 | A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives | |
3800 | a request to rekey a Child SA that does not exist. The SA that the | |
3801 | initiator attempted to rekey is indicated by the SPI field in the | |
3802 | Notify payload, which is copied from the SPI field in the REKEY_SA | |
3803 | notification. A peer that receives a CHILD_SA_NOT_FOUND notification | |
3804 | SHOULD silently delete the Child SA (if it still exists) and send a | |
3805 | request to create a new Child SA from scratch (if the Child SA does | |
3806 | not yet exist). | |
3807 | ||
3808 | ||
3809 | ||
3810 | Kaufman, et al. Standards Track [Page 68] | |
3811 | \f | |
3812 | RFC 5996 IKEv2bis September 2010 | |
3813 | ||
3814 | ||
3815 | 2.25.1. Collisions while Rekeying or Closing Child SAs | |
3816 | ||
3817 | If a peer receives a request to rekey a Child SA that it is currently | |
3818 | trying to close, it SHOULD reply with TEMPORARY_FAILURE. If a peer | |
3819 | receives a request to rekey a Child SA that it is currently rekeying, | |
3820 | it SHOULD reply as usual, and SHOULD prepare to close redundant SAs | |
3821 | later based on the nonces (see Section 2.8.1). If a peer receives a | |
3822 | request to rekey a Child SA that does not exist, it SHOULD reply with | |
3823 | CHILD_SA_NOT_FOUND. | |
3824 | ||
3825 | If a peer receives a request to close a Child SA that it is currently | |
3826 | trying to close, it SHOULD reply without a Delete payload (see | |
3827 | Section 1.4.1). If a peer receives a request to close a Child SA | |
3828 | that it is currently rekeying, it SHOULD reply as usual, with a | |
3829 | Delete payload. If a peer receives a request to close a Child SA | |
3830 | that does not exist, it SHOULD reply without a Delete payload. | |
3831 | ||
3832 | If a peer receives a request to rekey the IKE SA, and it is currently | |
3833 | creating, rekeying, or closing a Child SA of that IKE SA, it SHOULD | |
3834 | reply with TEMPORARY_FAILURE. | |
3835 | ||
3836 | 2.25.2. Collisions while Rekeying or Closing IKE SAs | |
3837 | ||
3838 | If a peer receives a request to rekey an IKE SA that it is currently | |
3839 | rekeying, it SHOULD reply as usual, and SHOULD prepare to close | |
3840 | redundant SAs and move inherited Child SAs later based on the nonces | |
3841 | (see Section 2.8.2). If a peer receives a request to rekey an IKE SA | |
3842 | that it is currently trying to close, it SHOULD reply with | |
3843 | TEMPORARY_FAILURE. | |
3844 | ||
3845 | If a peer receives a request to close an IKE SA that it is currently | |
3846 | rekeying, it SHOULD reply as usual, and forget about its own rekeying | |
3847 | request. If a peer receives a request to close an IKE SA that it is | |
3848 | currently trying to close, it SHOULD reply as usual, and forget about | |
3849 | its own close request. | |
3850 | ||
3851 | If a peer receives a request to create or rekey a Child SA when it is | |
3852 | currently rekeying the IKE SA, it SHOULD reply with | |
3853 | TEMPORARY_FAILURE. If a peer receives a request to delete a Child SA | |
3854 | when it is currently rekeying the IKE SA, it SHOULD reply as usual, | |
3855 | with a Delete payload. | |
a6d7a610 MW |
3856 | |
3857 | 3. Header and Payload Formats | |
3858 | ||
3859 | In the tables in this section, some cryptographic primitives and | |
824a0402 AS |
3860 | configuration attributes are marked as "UNSPECIFIED". These are |
3861 | items for which there are no known specifications and therefore | |
a6d7a610 | 3862 | interoperability is currently impossible. A future specification may |
824a0402 AS |
3863 | |
3864 | ||
3865 | ||
3866 | Kaufman, et al. Standards Track [Page 69] | |
3867 | \f | |
3868 | RFC 5996 IKEv2bis September 2010 | |
3869 | ||
3870 | ||
a6d7a610 MW |
3871 | describe their use, but until such specification is made, |
3872 | implementations SHOULD NOT attempt to use items marked as | |
3873 | "UNSPECIFIED" in implementations that are meant to be interoperable. | |
3874 | ||
3875 | 3.1. The IKE Header | |
3876 | ||
3877 | IKE messages use UDP ports 500 and/or 4500, with one IKE message per | |
3878 | UDP datagram. Information from the beginning of the packet through | |
3879 | the UDP header is largely ignored except that the IP addresses and | |
3880 | UDP ports from the headers are reversed and used for return packets. | |
3881 | When sent on UDP port 500, IKE messages begin immediately following | |
3882 | the UDP header. When sent on UDP port 4500, IKE messages have | |
824a0402 | 3883 | prepended four octets of zero. These four octets of zeros are not |
a6d7a610 MW |
3884 | part of the IKE message and are not included in any of the length |
3885 | fields or checksums defined by IKE. Each IKE message begins with the | |
824a0402 AS |
3886 | IKE header, denoted HDR in this document. Following the header are |
3887 | one or more IKE payloads each identified by a "Next Payload" field in | |
3888 | the preceding payload. Payloads are identified in the order in which | |
3889 | they appear in an IKE message by looking in the "Next Payload" field | |
3890 | in the IKE header, and subsequently according to the "Next Payload" | |
3891 | field in the IKE payload itself until a "Next Payload" field of zero | |
3892 | indicates that no payloads follow. If a payload of type "Encrypted" | |
3893 | is found, that payload is decrypted and its contents parsed as | |
3894 | additional payloads. An Encrypted payload MUST be the last payload | |
3895 | in a packet and an Encrypted payload MUST NOT contain another | |
3896 | Encrypted payload. | |
3897 | ||
3898 | The responder's SPI in the header identifies an instance of an IKE | |
3899 | Security Association. It is therefore possible for a single instance | |
3900 | of IKE to multiplex distinct sessions with multiple peers, including | |
3901 | multiple sessions per peer. | |
3902 | ||
3903 | All multi-octet fields representing integers are laid out in big | |
3904 | endian order (also known as "most significant byte first", or | |
3905 | "network byte order"). | |
3906 | ||
3907 | ||
3908 | ||
3909 | ||
3910 | ||
3911 | ||
3912 | ||
2eac2578 MW |
3913 | |
3914 | ||
3915 | ||
2eac2578 MW |
3916 | |
3917 | ||
a6d7a610 | 3918 | |
a6d7a610 | 3919 | |
824a0402 AS |
3920 | |
3921 | ||
3922 | Kaufman, et al. Standards Track [Page 70] | |
3923 | \f | |
3924 | RFC 5996 IKEv2bis September 2010 | |
3925 | ||
a6d7a610 MW |
3926 | |
3927 | The format of the IKE header is shown in Figure 4. | |
3928 | ||
3929 | 1 2 3 | |
3930 | 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 | |
3931 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3932 | | IKE SA Initiator's SPI | | |
3933 | | | | |
3934 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3935 | | IKE SA Responder's SPI | | |
3936 | | | | |
3937 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3938 | | Next Payload | MjVer | MnVer | Exchange Type | Flags | | |
3939 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3940 | | Message ID | | |
3941 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3942 | | Length | | |
3943 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3944 | ||
3945 | Figure 4: IKE Header Format | |
3946 | ||
3947 | o Initiator's SPI (8 octets) - A value chosen by the initiator to | |
824a0402 | 3948 | identify a unique IKE Security Association. This value MUST NOT |
a6d7a610 MW |
3949 | be zero. |
3950 | ||
3951 | o Responder's SPI (8 octets) - A value chosen by the responder to | |
824a0402 AS |
3952 | identify a unique IKE Security Association. This value MUST be |
3953 | zero in the first message of an IKE initial exchange (including | |
2eac2578 | 3954 | repeats of that message including a cookie). |
a6d7a610 MW |
3955 | |
3956 | o Next Payload (1 octet) - Indicates the type of payload that | |
3957 | immediately follows the header. The format and value of each | |
3958 | payload are defined below. | |
3959 | ||
3960 | o Major Version (4 bits) - Indicates the major version of the IKE | |
3961 | protocol in use. Implementations based on this version of IKE | |
824a0402 AS |
3962 | MUST set the major version to 2. Implementations based on |
3963 | previous versions of IKE and ISAKMP MUST set the major version to | |
a6d7a610 MW |
3964 | 1. Implementations based on this version of IKE MUST reject or |
3965 | ignore messages containing a version number greater than 2 with an | |
3966 | INVALID_MAJOR_VERSION notification message as described in Section | |
3967 | 2.5. | |
3968 | ||
3969 | o Minor Version (4 bits) - Indicates the minor version of the IKE | |
3970 | protocol in use. Implementations based on this version of IKE | |
824a0402 | 3971 | MUST set the minor version to 0. They MUST ignore the minor |
a6d7a610 MW |
3972 | version number of received messages. |
3973 | ||
824a0402 AS |
3974 | |
3975 | ||
3976 | ||
3977 | ||
3978 | Kaufman, et al. Standards Track [Page 71] | |
3979 | \f | |
3980 | RFC 5996 IKEv2bis September 2010 | |
3981 | ||
3982 | ||
a6d7a610 MW |
3983 | o Exchange Type (1 octet) - Indicates the type of exchange being |
3984 | used. This constrains the payloads sent in each message in an | |
824a0402 AS |
3985 | exchange. The values in the following table are only current as |
3986 | of the publication date of RFC 4306. Other values may have been | |
3987 | added since then or will be added after the publication of this | |
3988 | document. Readers should refer to [IKEV2IANA] for the latest | |
3989 | values. | |
a6d7a610 MW |
3990 | |
3991 | Exchange Type Value | |
3992 | ---------------------------------- | |
a6d7a610 MW |
3993 | IKE_SA_INIT 34 |
3994 | IKE_AUTH 35 | |
3995 | CREATE_CHILD_SA 36 | |
3996 | INFORMATIONAL 37 | |
a6d7a610 MW |
3997 | |
3998 | o Flags (1 octet) - Indicates specific options that are set for the | |
3999 | message. Presence of options is indicated by the appropriate bit | |
824a0402 | 4000 | in the flags field being set. The bits are as follows: |
a6d7a610 | 4001 | |
824a0402 AS |
4002 | +-+-+-+-+-+-+-+-+ |
4003 | |X|X|R|V|I|X|X|X| | |
4004 | +-+-+-+-+-+-+-+-+ | |
a6d7a610 | 4005 | |
824a0402 AS |
4006 | In the description below, a bit being 'set' means its value is '1', |
4007 | while 'cleared' means its value is '0'. 'X' bits MUST be cleared | |
4008 | when sending and MUST be ignored on receipt. | |
a6d7a610 | 4009 | |
824a0402 AS |
4010 | * R (Response) - This bit indicates that this message is a |
4011 | response to a message containing the same Message ID. This bit | |
4012 | MUST be cleared in all request messages and MUST be set in all | |
4013 | responses. An IKE endpoint MUST NOT generate a response to a | |
4014 | message that is marked as being a response (with one exception; | |
4015 | see Section 2.21.2). | |
a6d7a610 | 4016 | |
824a0402 AS |
4017 | * V (Version) - This bit indicates that the transmitter is |
4018 | capable of speaking a higher major version number of the | |
4019 | protocol than the one indicated in the major version number | |
4020 | field. Implementations of IKEv2 MUST clear this bit when | |
4021 | sending and MUST ignore it in incoming messages. | |
82f0707f | 4022 | |
824a0402 AS |
4023 | * I (Initiator) - This bit MUST be set in messages sent by the |
4024 | original initiator of the IKE SA and MUST be cleared in | |
4025 | messages sent by the original responder. It is used by the | |
4026 | recipient to determine which eight octets of the SPI were | |
4027 | generated by the recipient. This bit changes to reflect who | |
4028 | initiated the last rekey of the IKE SA. | |
82f0707f MW |
4029 | |
4030 | ||
4031 | ||
4032 | ||
82f0707f | 4033 | |
824a0402 AS |
4034 | Kaufman, et al. Standards Track [Page 72] |
4035 | \f | |
4036 | RFC 5996 IKEv2bis September 2010 | |
4037 | ||
82f0707f | 4038 | |
824a0402 AS |
4039 | o Message ID (4 octets, unsigned integer) - Message identifier used |
4040 | to control retransmission of lost packets and matching of requests | |
4041 | and responses. It is essential to the security of the protocol | |
a6d7a610 | 4042 | because it is used to prevent message replay attacks. See |
824a0402 | 4043 | Sections 2.1 and 2.2. |
a6d7a610 | 4044 | |
824a0402 AS |
4045 | o Length (4 octets, unsigned integer) - Length of the total message |
4046 | (header + payloads) in octets. | |
a6d7a610 MW |
4047 | |
4048 | 3.2. Generic Payload Header | |
4049 | ||
824a0402 AS |
4050 | Each IKE payload defined in Sections 3.3 through 3.16 begins with a |
4051 | generic payload header, shown in Figure 5. Figures for each payload | |
4052 | below will include the generic payload header, but for brevity, the | |
4053 | description of each field will be omitted. | |
a6d7a610 MW |
4054 | |
4055 | 1 2 3 | |
4056 | 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 | |
4057 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4058 | | Next Payload |C| RESERVED | Payload Length | | |
4059 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4060 | ||
4061 | Figure 5: Generic Payload Header | |
4062 | ||
4063 | The Generic Payload Header fields are defined as follows: | |
4064 | ||
4065 | o Next Payload (1 octet) - Identifier for the payload type of the | |
4066 | next payload in the message. If the current payload is the last | |
4067 | in the message, then this field will be 0. This field provides a | |
4068 | "chaining" capability whereby additional payloads can be added to | |
824a0402 AS |
4069 | a message by appending each one to the end of the message and |
4070 | setting the "Next Payload" field of the preceding payload to | |
4071 | indicate the new payload's type. An Encrypted payload, which must | |
4072 | always be the last payload of a message, is an exception. It | |
4073 | contains data structures in the format of additional payloads. In | |
4074 | the header of an Encrypted payload, the Next Payload field is set | |
4075 | to the payload type of the first contained payload (instead of 0); | |
4076 | conversely, the Next Payload field of the last contained payload | |
4077 | is set to zero). The payload type values are listed here. The | |
4078 | values in the following table are only current as of the | |
4079 | publication date of RFC 4306. Other values may have been added | |
4080 | since then or will be added after the publication of this | |
4081 | document. Readers should refer to [IKEV2IANA] for the latest | |
4082 | values. | |
a6d7a610 MW |
4083 | |
4084 | ||
4085 | ||
4086 | ||
82f0707f MW |
4087 | |
4088 | ||
824a0402 AS |
4089 | |
4090 | Kaufman, et al. Standards Track [Page 73] | |
a6d7a610 | 4091 | \f |
824a0402 | 4092 | RFC 5996 IKEv2bis September 2010 |
a6d7a610 MW |
4093 | |
4094 | ||
4095 | Next Payload Type Notation Value | |
4096 | -------------------------------------------------- | |
4097 | No Next Payload 0 | |
a6d7a610 MW |
4098 | Security Association SA 33 |
4099 | Key Exchange KE 34 | |
4100 | Identification - Initiator IDi 35 | |
4101 | Identification - Responder IDr 36 | |
4102 | Certificate CERT 37 | |
4103 | Certificate Request CERTREQ 38 | |
4104 | Authentication AUTH 39 | |
4105 | Nonce Ni, Nr 40 | |
4106 | Notify N 41 | |
4107 | Delete D 42 | |
4108 | Vendor ID V 43 | |
4109 | Traffic Selector - Initiator TSi 44 | |
4110 | Traffic Selector - Responder TSr 45 | |
824a0402 | 4111 | Encrypted and Authenticated SK 46 |
a6d7a610 MW |
4112 | Configuration CP 47 |
4113 | Extensible Authentication EAP 48 | |
a6d7a610 MW |
4114 | |
4115 | (Payload type values 1-32 should not be assigned in the | |
4116 | future so that there is no overlap with the code assignments | |
4117 | for IKEv1.) | |
4118 | ||
4119 | o Critical (1 bit) - MUST be set to zero if the sender wants the | |
4120 | recipient to skip this payload if it does not understand the | |
4121 | payload type code in the Next Payload field of the previous | |
4122 | payload. MUST be set to one if the sender wants the recipient to | |
4123 | reject this entire message if it does not understand the payload | |
4124 | type. MUST be ignored by the recipient if the recipient | |
4125 | understands the payload type code. MUST be set to zero for | |
4126 | payload types defined in this document. Note that the critical | |
4127 | bit applies to the current payload rather than the "next" payload | |
4128 | whose type code appears in the first octet. The reasoning behind | |
4129 | not setting the critical bit for payloads defined in this document | |
4130 | is that all implementations MUST understand all payload types | |
824a0402 | 4131 | defined in this document and therefore must ignore the critical |
a6d7a610 | 4132 | bit's value. Skipped payloads are expected to have valid Next |
824a0402 AS |
4133 | Payload and Payload Length fields. See Section 2.5 for more |
4134 | information on this bit. | |
a6d7a610 MW |
4135 | |
4136 | o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on | |
4137 | receipt. | |
4138 | ||
824a0402 AS |
4139 | o Payload Length (2 octets, unsigned integer) - Length in octets of |
4140 | the current payload, including the generic payload header. | |
4141 | ||
a6d7a610 MW |
4142 | |
4143 | ||
4144 | ||
824a0402 AS |
4145 | |
4146 | Kaufman, et al. Standards Track [Page 74] | |
a6d7a610 | 4147 | \f |
824a0402 | 4148 | RFC 5996 IKEv2bis September 2010 |
a6d7a610 MW |
4149 | |
4150 | ||
2eac2578 MW |
4151 | Many payloads contain fields marked as "RESERVED". Some payloads in |
4152 | IKEv2 (and historically in IKEv1) are not aligned to 4-octet | |
4153 | boundaries. | |
a6d7a610 MW |
4154 | |
4155 | 3.3. Security Association Payload | |
4156 | ||
824a0402 AS |
4157 | The Security Association payload, denoted SA in this document, is |
4158 | used to negotiate attributes of a Security Association. Assembly of | |
4159 | Security Association payloads requires great peace of mind. An SA | |
4160 | payload MAY contain multiple proposals. If there is more than one, | |
4161 | they MUST be ordered from most preferred to least preferred. Each | |
4162 | proposal contains a single IPsec protocol (where a protocol is IKE, | |
4163 | ESP, or AH), each protocol MAY contain multiple transforms, and each | |
a6d7a610 MW |
4164 | transform MAY contain multiple attributes. When parsing an SA, an |
4165 | implementation MUST check that the total Payload Length is consistent | |
4166 | with the payload's internal lengths and counts. Proposals, | |
824a0402 | 4167 | Transforms, and Attributes each have their own variable-length |
a6d7a610 MW |
4168 | encodings. They are nested such that the Payload Length of an SA |
4169 | includes the combined contents of the SA, Proposal, Transform, and | |
4170 | Attribute information. The length of a Proposal includes the lengths | |
4171 | of all Transforms and Attributes it contains. The length of a | |
4172 | Transform includes the lengths of all Attributes it contains. | |
4173 | ||
4174 | The syntax of Security Associations, Proposals, Transforms, and | |
824a0402 | 4175 | Attributes is based on ISAKMP; however, the semantics are somewhat |
a6d7a610 MW |
4176 | different. The reason for the complexity and the hierarchy is to |
4177 | allow for multiple possible combinations of algorithms to be encoded | |
4178 | in a single SA. Sometimes there is a choice of multiple algorithms, | |
4179 | whereas other times there is a combination of algorithms. For | |
4180 | example, an initiator might want to propose using ESP with either | |
4181 | (3DES and HMAC_MD5) or (AES and HMAC_SHA1). | |
4182 | ||
824a0402 | 4183 | One of the reasons the semantics of the SA payload have changed from |
a6d7a610 MW |
4184 | ISAKMP and IKEv1 is to make the encodings more compact in common |
4185 | cases. | |
4186 | ||
824a0402 | 4187 | The Proposal structure contains within it a Proposal Num and an IPsec |
a6d7a610 MW |
4188 | protocol ID. Each structure MUST have a proposal number one (1) |
4189 | greater than the previous structure. The first Proposal in the | |
824a0402 AS |
4190 | initiator's SA payload MUST have a Proposal Num of one (1). One |
4191 | reason to use multiple proposals is to propose both standard crypto | |
4192 | ciphers and combined-mode ciphers. Combined-mode ciphers include | |
4193 | both integrity and encryption in a single encryption algorithm, and | |
4194 | MUST either offer no integrity algorithm or a single integrity | |
4195 | algorithm of "none", with no integrity algorithm being the | |
4196 | RECOMMENDED method. If an initiator wants to propose both combined- | |
4197 | mode ciphers and normal ciphers, it must include two proposals: one | |
4198 | will have all the combined-mode ciphers, and the other will have all | |
4199 | ||
4200 | ||
4201 | ||
4202 | Kaufman, et al. Standards Track [Page 75] | |
4203 | \f | |
4204 | RFC 5996 IKEv2bis September 2010 | |
4205 | ||
4206 | ||
4207 | the normal ciphers with the integrity algorithms. For example, one | |
4208 | such proposal would have two proposal structures. Proposal 1 is ESP | |
4209 | with AES-128, AES-192, and AES-256 bits in Cipher Block Chaining | |
4210 | (CBC) mode, with either HMAC-SHA1-96 or XCBC-96 as the integrity | |
4211 | algorithm; Proposal 2 is AES-128 or AES-256 in GCM mode with an | |
4212 | 8-octet Integrity Check Value (ICV). Both proposals allow but do not | |
4213 | require the use of ESNs (Extended Sequence Numbers). This can be | |
4214 | illustrated as: | |
4215 | ||
4216 | SA Payload | |
4217 | | | |
4218 | +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4, | |
4219 | | | 7 transforms, SPI = 0x052357bb ) | |
4220 | | | | |
4221 | | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | |
4222 | | | +-- Attribute ( Key Length = 128 ) | |
4223 | | | | |
4224 | | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | |
4225 | | | +-- Attribute ( Key Length = 192 ) | |
4226 | | | | |
4227 | | +-- Transform ENCR ( Name = ENCR_AES_CBC ) | |
4228 | | | +-- Attribute ( Key Length = 256 ) | |
4229 | | | | |
4230 | | +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 ) | |
4231 | | +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 ) | |
4232 | | +-- Transform ESN ( Name = ESNs ) | |
4233 | | +-- Transform ESN ( Name = No ESNs ) | |
4234 | | | |
4235 | +--- Proposal #2 ( Proto ID = ESP(3), SPI size = 4, | |
4236 | | 4 transforms, SPI = 0x35a1d6f2 ) | |
4237 | | | |
4238 | +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV ) | |
4239 | | +-- Attribute ( Key Length = 128 ) | |
4240 | | | |
4241 | +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV ) | |
4242 | | +-- Attribute ( Key Length = 256 ) | |
4243 | | | |
4244 | +-- Transform ESN ( Name = ESNs ) | |
4245 | +-- Transform ESN ( Name = No ESNs ) | |
a6d7a610 | 4246 | |
824a0402 AS |
4247 | Each Proposal/Protocol structure is followed by one or more transform |
4248 | structures. The number of different transforms is generally | |
4249 | determined by the Protocol. AH generally has two transforms: | |
4250 | Extended Sequence Numbers (ESNs) and an integrity check algorithm. | |
4251 | ESP generally has three: ESN, an encryption algorithm, and an | |
4252 | integrity check algorithm. IKE generally has four transforms: a | |
4253 | Diffie-Hellman group, an integrity check algorithm, a PRF algorithm, | |
a6d7a610 MW |
4254 | |
4255 | ||
a6d7a610 MW |
4256 | |
4257 | ||
824a0402 AS |
4258 | Kaufman, et al. Standards Track [Page 76] |
4259 | \f | |
4260 | RFC 5996 IKEv2bis September 2010 | |
a6d7a610 | 4261 | |
824a0402 AS |
4262 | |
4263 | and an encryption algorithm. For each Protocol, the set of | |
4264 | permissible transforms is assigned Transform ID numbers, which appear | |
4265 | in the header of each transform. | |
a6d7a610 MW |
4266 | |
4267 | If there are multiple transforms with the same Transform Type, the | |
4268 | proposal is an OR of those transforms. If there are multiple | |
824a0402 | 4269 | transforms with different Transform Types, the proposal is an AND of |
a6d7a610 MW |
4270 | the different groups. For example, to propose ESP with (3DES or AES- |
4271 | CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two | |
4272 | Transform Type 1 candidates (one for 3DES and one for AEC-CBC) and | |
4273 | two Transform Type 3 candidates (one for HMAC_MD5 and one for | |
4274 | HMAC_SHA). This effectively proposes four combinations of | |
4275 | algorithms. If the initiator wanted to propose only a subset of | |
4276 | those, for example (3DES and HMAC_MD5) or (IDEA and HMAC_SHA), there | |
4277 | is no way to encode that as multiple transforms within a single | |
4278 | Proposal. Instead, the initiator would have to construct two | |
4279 | different Proposals, each with two transforms. | |
4280 | ||
4281 | A given transform MAY have one or more Attributes. Attributes are | |
4282 | necessary when the transform can be used in more than one way, as | |
4283 | when an encryption algorithm has a variable key size. The transform | |
4284 | would specify the algorithm and the attribute would specify the key | |
4285 | size. Most transforms do not have attributes. A transform MUST NOT | |
4286 | have multiple attributes of the same type. To propose alternate | |
4287 | values for an attribute (for example, multiple key sizes for the AES | |
824a0402 AS |
4288 | encryption algorithm), an implementation MUST include multiple |
4289 | transforms with the same Transform Type each with a single Attribute. | |
a6d7a610 MW |
4290 | |
4291 | Note that the semantics of Transforms and Attributes are quite | |
4292 | different from those in IKEv1. In IKEv1, a single Transform carried | |
4293 | multiple algorithms for a protocol with one carried in the Transform | |
4294 | and the others carried in the Attributes. | |
4295 | ||
a6d7a610 MW |
4296 | 1 2 3 |
4297 | 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 | |
4298 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4299 | | Next Payload |C| RESERVED | Payload Length | | |
4300 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4301 | | | | |
4302 | ~ <Proposals> ~ | |
4303 | | | | |
4304 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4305 | ||
4306 | Figure 6: Security Association Payload | |
4307 | ||
4308 | o Proposals (variable) - One or more proposal substructures. | |
4309 | ||
824a0402 AS |
4310 | |
4311 | ||
4312 | ||
4313 | ||
4314 | Kaufman, et al. Standards Track [Page 77] | |
4315 | \f | |
4316 | RFC 5996 IKEv2bis September 2010 | |
4317 | ||
4318 | ||
4319 | The payload type for the Security Association payload is thirty-three | |
a6d7a610 MW |
4320 | (33). |
4321 | ||
4322 | 3.3.1. Proposal Substructure | |
4323 | ||
4324 | 1 2 3 | |
4325 | 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 | |
4326 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4327 | | 0 (last) or 2 | RESERVED | Proposal Length | | |
4328 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
824a0402 | 4329 | | Proposal Num | Protocol ID | SPI Size |Num Transforms| |
a6d7a610 MW |
4330 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
4331 | ~ SPI (variable) ~ | |
4332 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4333 | | | | |
4334 | ~ <Transforms> ~ | |
4335 | | | | |
4336 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4337 | ||
4338 | Figure 7: Proposal Substructure | |
4339 | ||
4340 | o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the | |
4341 | last Proposal Substructure in the SA. This syntax is inherited | |
4342 | from ISAKMP, but is unnecessary because the last Proposal could be | |
4343 | identified from the length of the SA. The value (2) corresponds | |
824a0402 | 4344 | to a payload type of Proposal in IKEv1, and the first four octets |
a6d7a610 | 4345 | of the Proposal structure are designed to look somewhat like the |
824a0402 | 4346 | header of a payload. |
a6d7a610 MW |
4347 | |
4348 | o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on | |
4349 | receipt. | |
4350 | ||
824a0402 AS |
4351 | o Proposal Length (2 octets, unsigned integer) - Length of this |
4352 | proposal, including all transforms and attributes that follow. | |
a6d7a610 | 4353 | |
824a0402 AS |
4354 | o Proposal Num (1 octet) - When a proposal is made, the first |
4355 | proposal in an SA payload MUST be 1, and subsequent proposals MUST | |
4356 | be one more than the previous proposal (indicating an OR of the | |
4357 | two proposals). When a proposal is accepted, the proposal number | |
4358 | in the SA payload MUST match the number on the proposal sent that | |
4359 | was accepted. | |
a6d7a610 | 4360 | |
824a0402 AS |
4361 | o Protocol ID (1 octet) - Specifies the IPsec protocol identifier |
4362 | for the current negotiation. The values in the following table | |
4363 | are only current as of the publication date of RFC 4306. Other | |
4364 | values may have been added since then or will be added after the | |
4365 | publication of this document. Readers should refer to [IKEV2IANA] | |
4366 | for the latest values. | |
a6d7a610 | 4367 | |
a6d7a610 MW |
4368 | |
4369 | ||
824a0402 AS |
4370 | Kaufman, et al. Standards Track [Page 78] |
4371 | \f | |
4372 | RFC 5996 IKEv2bis September 2010 | |
a6d7a610 | 4373 | |
a6d7a610 MW |
4374 | |
4375 | Protocol Protocol ID | |
4376 | ----------------------------------- | |
a6d7a610 MW |
4377 | IKE 1 |
4378 | AH 2 | |
4379 | ESP 3 | |
a6d7a610 MW |
4380 | |
4381 | o SPI Size (1 octet) - For an initial IKE SA negotiation, this field | |
4382 | MUST be zero; the SPI is obtained from the outer header. During | |
4383 | subsequent negotiations, it is equal to the size, in octets, of | |
4384 | the SPI of the corresponding protocol (8 for IKE, 4 for ESP and | |
4385 | AH). | |
4386 | ||
824a0402 | 4387 | o Num Transforms (1 octet) - Specifies the number of transforms in |
a6d7a610 MW |
4388 | this proposal. |
4389 | ||
4390 | o SPI (variable) - The sending entity's SPI. Even if the SPI Size | |
4391 | is not a multiple of 4 octets, there is no padding applied to the | |
4392 | payload. When the SPI Size field is zero, this field is not | |
4393 | present in the Security Association payload. | |
4394 | ||
4395 | o Transforms (variable) - One or more transform substructures. | |
4396 | ||
a6d7a610 MW |
4397 | 3.3.2. Transform Substructure |
4398 | ||
4399 | 1 2 3 | |
4400 | 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 | |
4401 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4402 | | 0 (last) or 3 | RESERVED | Transform Length | | |
4403 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4404 | |Transform Type | RESERVED | Transform ID | | |
4405 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4406 | | | | |
4407 | ~ Transform Attributes ~ | |
4408 | | | | |
4409 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4410 | ||
4411 | Figure 8: Transform Substructure | |
4412 | ||
4413 | o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the | |
4414 | last Transform Substructure in the Proposal. This syntax is | |
4415 | inherited from ISAKMP, but is unnecessary because the last | |
4416 | transform could be identified from the length of the proposal. | |
824a0402 | 4417 | The value (3) corresponds to a payload type of Transform in IKEv1, |
a6d7a610 | 4418 | and the first four octets of the Transform structure are designed |
824a0402 | 4419 | to look somewhat like the header of a payload. |
a6d7a610 MW |
4420 | |
4421 | o RESERVED - MUST be sent as zero; MUST be ignored on receipt. | |
4422 | ||
824a0402 AS |
4423 | |
4424 | ||
4425 | ||
4426 | Kaufman, et al. Standards Track [Page 79] | |
4427 | \f | |
4428 | RFC 5996 IKEv2bis September 2010 | |
4429 | ||
4430 | ||
a6d7a610 MW |
4431 | o Transform Length - The length (in octets) of the Transform |
4432 | Substructure including Header and Attributes. | |
4433 | ||
4434 | o Transform Type (1 octet) - The type of transform being specified | |
4435 | in this transform. Different protocols support different | |
824a0402 | 4436 | Transform Types. For some protocols, some of the transforms may |
a6d7a610 MW |
4437 | be optional. If a transform is optional and the initiator wishes |
4438 | to propose that the transform be omitted, no transform of the | |
4439 | given type is included in the proposal. If the initiator wishes | |
4440 | to make use of the transform optional to the responder, it | |
824a0402 | 4441 | includes a transform substructure with Transform ID = 0 as one of |
a6d7a610 MW |
4442 | the options. |
4443 | ||
824a0402 AS |
4444 | o Transform ID (2 octets) - The specific instance of the Transform |
4445 | Type being proposed. | |
a6d7a610 | 4446 | |
824a0402 AS |
4447 | The Transform Type values are listed below. The values in the |
4448 | following table are only current as of the publication date of RFC | |
4449 | 4306. Other values may have been added since then or will be added | |
4450 | after the publication of this document. Readers should refer to | |
4451 | [IKEV2IANA] for the latest values. | |
a6d7a610 MW |
4452 | |
4453 | Description Trans. Used In | |
4454 | Type | |
4455 | ------------------------------------------------------------------ | |
a6d7a610 | 4456 | Encryption Algorithm (ENCR) 1 IKE and ESP |
824a0402 | 4457 | Pseudorandom Function (PRF) 2 IKE |
a6d7a610 | 4458 | Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP |
824a0402 | 4459 | Diffie-Hellman group (D-H) 4 IKE, optional in AH & ESP |
a6d7a610 | 4460 | Extended Sequence Numbers (ESN) 5 AH and ESP |
a6d7a610 MW |
4461 | |
4462 | (*) Negotiating an integrity algorithm is mandatory for the | |
824a0402 | 4463 | Encrypted payload format specified in this document. For example, |
a6d7a610 MW |
4464 | [AEAD] specifies additional formats based on authenticated |
4465 | encryption, in which a separate integrity algorithm is not | |
4466 | negotiated. | |
4467 | ||
824a0402 AS |
4468 | For Transform Type 1 (Encryption Algorithm), the Transform IDs are |
4469 | listed below. The values in the following table are only current as | |
4470 | of the publication date of RFC 4306. Other values may have been | |
4471 | added since then or will be added after the publication of this | |
4472 | document. Readers should refer to [IKEV2IANA] for the latest values. | |
4473 | ||
4474 | ||
4475 | ||
4476 | ||
4477 | ||
4478 | ||
4479 | ||
4480 | ||
4481 | ||
4482 | Kaufman, et al. Standards Track [Page 80] | |
4483 | \f | |
4484 | RFC 5996 IKEv2bis September 2010 | |
4485 | ||
a6d7a610 MW |
4486 | |
4487 | Name Number Defined In | |
4488 | --------------------------------------------------- | |
a6d7a610 MW |
4489 | ENCR_DES_IV64 1 (UNSPECIFIED) |
4490 | ENCR_DES 2 (RFC2405), [DES] | |
4491 | ENCR_3DES 3 (RFC2451) | |
4492 | ENCR_RC5 4 (RFC2451) | |
4493 | ENCR_IDEA 5 (RFC2451), [IDEA] | |
4494 | ENCR_CAST 6 (RFC2451) | |
4495 | ENCR_BLOWFISH 7 (RFC2451) | |
4496 | ENCR_3IDEA 8 (UNSPECIFIED) | |
4497 | ENCR_DES_IV32 9 (UNSPECIFIED) | |
a6d7a610 MW |
4498 | ENCR_NULL 11 (RFC2410) |
4499 | ENCR_AES_CBC 12 (RFC3602) | |
4500 | ENCR_AES_CTR 13 (RFC3686) | |
a6d7a610 | 4501 | |
824a0402 AS |
4502 | For Transform Type 2 (Pseudorandom Function), the Transform IDs are |
4503 | listed below. The values in the following table are only current as | |
4504 | of the publication date of RFC 4306. Other values may have been | |
4505 | added since then or will be added after the publication of this | |
4506 | document. Readers should refer to [IKEV2IANA] for the latest values. | |
a6d7a610 MW |
4507 | |
4508 | Name Number Defined In | |
4509 | ------------------------------------------------------ | |
a6d7a610 MW |
4510 | PRF_HMAC_MD5 1 (RFC2104), [MD5] |
4511 | PRF_HMAC_SHA1 2 (RFC2104), [SHA] | |
824a0402 | 4512 | PRF_HMAC_TIGER 3 (UNSPECIFIED) |
a6d7a610 | 4513 | |
824a0402 AS |
4514 | For Transform Type 3 (Integrity Algorithm), defined Transform IDs are |
4515 | listed below. The values in the following table are only current as | |
4516 | of the publication date of RFC 4306. Other values may have been | |
4517 | added since then or will be added after the publication of this | |
4518 | document. Readers should refer to [IKEV2IANA] for the latest values. | |
a6d7a610 MW |
4519 | |
4520 | Name Number Defined In | |
4521 | ---------------------------------------- | |
4522 | NONE 0 | |
4523 | AUTH_HMAC_MD5_96 1 (RFC2403) | |
4524 | AUTH_HMAC_SHA1_96 2 (RFC2404) | |
4525 | AUTH_DES_MAC 3 (UNSPECIFIED) | |
4526 | AUTH_KPDK_MD5 4 (UNSPECIFIED) | |
4527 | AUTH_AES_XCBC_96 5 (RFC3566) | |
a6d7a610 | 4528 | |
824a0402 AS |
4529 | For Transform Type 4 (Diffie-Hellman group), defined Transform IDs |
4530 | are listed below. The values in the following table are only current | |
4531 | as of the publication date of RFC 4306. Other values may have been | |
4532 | added since then or will be added after the publication of this | |
4533 | document. Readers should refer to [IKEV2IANA] for the latest values. | |
4534 | ||
4535 | ||
4536 | ||
4537 | ||
4538 | Kaufman, et al. Standards Track [Page 81] | |
4539 | \f | |
4540 | RFC 5996 IKEv2bis September 2010 | |
4541 | ||
a6d7a610 | 4542 | |
824a0402 | 4543 | Name Number Defined In |
a6d7a610 MW |
4544 | ---------------------------------------- |
4545 | NONE 0 | |
824a0402 AS |
4546 | 768-bit MODP 1 Appendix B |
4547 | 1024-bit MODP 2 Appendix B | |
a6d7a610 | 4548 | 1536-bit MODP 5 [ADDGROUP] |
a6d7a610 MW |
4549 | 2048-bit MODP 14 [ADDGROUP] |
4550 | 3072-bit MODP 15 [ADDGROUP] | |
4551 | 4096-bit MODP 16 [ADDGROUP] | |
4552 | 6144-bit MODP 17 [ADDGROUP] | |
4553 | 8192-bit MODP 18 [ADDGROUP] | |
a6d7a610 | 4554 | |
824a0402 AS |
4555 | Although ESP and AH do not directly include a Diffie-Hellman |
4556 | exchange, a Diffie-Hellman group MAY be negotiated for the Child SA. | |
4557 | This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA | |
4558 | exchange, providing perfect forward secrecy for the generated Child | |
4559 | SA keys. | |
a6d7a610 | 4560 | |
824a0402 AS |
4561 | For Transform Type 5 (Extended Sequence Numbers), defined Transform |
4562 | IDs are listed below. The values in the following table are only | |
4563 | current as of the publication date of RFC 4306. Other values may | |
4564 | have been added since then or will be added after the publication of | |
4565 | this document. Readers should refer to [IKEV2IANA] for the latest | |
4566 | values. | |
a6d7a610 MW |
4567 | |
4568 | Name Number | |
4569 | -------------------------------------------- | |
4570 | No Extended Sequence Numbers 0 | |
4571 | Extended Sequence Numbers 1 | |
a6d7a610 | 4572 | |
2eac2578 MW |
4573 | Note that an initiator who supports ESNs will usually include two ESN |
4574 | transforms, with values "0" and "1", in its proposals. A proposal | |
4575 | containing a single ESN transform with value "1" means that using | |
4576 | normal (non-extended) sequence numbers is not acceptable. | |
a6d7a610 | 4577 | |
824a0402 | 4578 | Numerous additional Transform Types have been defined since the |
a6d7a610 MW |
4579 | publication of RFC 4306. Please refer to the IANA IKEv2 registry for |
4580 | details. | |
4581 | ||
4582 | 3.3.3. Valid Transform Types by Protocol | |
4583 | ||
4584 | The number and type of transforms that accompany an SA payload are | |
4585 | dependent on the protocol in the SA itself. An SA payload proposing | |
4586 | the establishment of an SA has the following mandatory and optional | |
824a0402 | 4587 | Transform Types. A compliant implementation MUST understand all |
a6d7a610 | 4588 | mandatory and optional types for each protocol it supports (though it |
824a0402 AS |
4589 | |
4590 | ||
4591 | ||
4592 | ||
4593 | ||
4594 | Kaufman, et al. Standards Track [Page 82] | |
4595 | \f | |
4596 | RFC 5996 IKEv2bis September 2010 | |
4597 | ||
4598 | ||
a6d7a610 MW |
4599 | need not accept proposals with unacceptable suites). A proposal MAY |
4600 | omit the optional types if the only value for them it will accept is | |
4601 | NONE. | |
4602 | ||
4603 | Protocol Mandatory Types Optional Types | |
4604 | --------------------------------------------------- | |
4605 | IKE ENCR, PRF, INTEG*, D-H | |
4606 | ESP ENCR, ESN INTEG, D-H | |
4607 | AH INTEG, ESN D-H | |
4608 | ||
4609 | (*) Negotiating an integrity algorithm is mandatory for the | |
824a0402 | 4610 | Encrypted payload format specified in this document. For example, |
a6d7a610 MW |
4611 | [AEAD] specifies additional formats based on authenticated |
4612 | encryption, in which a separate integrity algorithm is not | |
4613 | negotiated. | |
4614 | ||
4615 | 3.3.4. Mandatory Transform IDs | |
4616 | ||
4617 | The specification of suites that MUST and SHOULD be supported for | |
4618 | interoperability has been removed from this document because they are | |
824a0402 AS |
4619 | likely to change more rapidly than this document evolves. At the |
4620 | time of publication of this document, [RFC4307] specifies these | |
4621 | suites, but note that it might be updated in the future, and other | |
4622 | RFCs might specify different sets of suites. | |
a6d7a610 MW |
4623 | |
4624 | An important lesson learned from IKEv1 is that no system should only | |
4625 | implement the mandatory algorithms and expect them to be the best | |
4626 | choice for all customers. | |
4627 | ||
a6d7a610 MW |
4628 | It is likely that IANA will add additional transforms in the future, |
4629 | and some users may want to use private suites, especially for IKE | |
4630 | where implementations should be capable of supporting different | |
4631 | parameters, up to certain size limits. In support of this goal, all | |
4632 | implementations of IKEv2 SHOULD include a management facility that | |
4633 | allows specification (by a user or system administrator) of Diffie- | |
824a0402 AS |
4634 | Hellman parameters (the generator, modulus, and exponent lengths and |
4635 | values) for new Diffie-Hellman groups. Implementations SHOULD | |
4636 | provide a management interface through which these parameters and the | |
4637 | associated Transform IDs may be entered (by a user or system | |
a6d7a610 MW |
4638 | administrator), to enable negotiating such groups. |
4639 | ||
4640 | All implementations of IKEv2 MUST include a management facility that | |
4641 | enables a user or system administrator to specify the suites that are | |
4642 | acceptable for use with IKE. Upon receipt of a payload with a set of | |
824a0402 AS |
4643 | Transform IDs, the implementation MUST compare the transmitted |
4644 | Transform IDs against those locally configured via the management | |
a6d7a610 MW |
4645 | controls, to verify that the proposed suite is acceptable based on |
4646 | local policy. The implementation MUST reject SA proposals that are | |
824a0402 AS |
4647 | |
4648 | ||
4649 | ||
4650 | Kaufman, et al. Standards Track [Page 83] | |
4651 | \f | |
4652 | RFC 5996 IKEv2bis September 2010 | |
4653 | ||
4654 | ||
a6d7a610 MW |
4655 | not authorized by these IKE suite controls. Note that cryptographic |
4656 | suites that MUST be implemented need not be configured as acceptable | |
4657 | to local policy. | |
4658 | ||
4659 | 3.3.5. Transform Attributes | |
4660 | ||
4661 | Each transform in a Security Association payload may include | |
4662 | attributes that modify or complete the specification of the | |
4663 | transform. The set of valid attributes depends on the transform. | |
4664 | Currently, only a single attribute type is defined: the Key Length | |
4665 | attribute is used by certain encryption transforms with variable- | |
4666 | length keys (see below for details). | |
4667 | ||
4668 | The attributes are type/value pairs and are defined below. | |
4669 | Attributes can have a value with a fixed two-octet length or a | |
4670 | variable-length value. For the latter, the attribute is encoded as | |
4671 | type/length/value. | |
4672 | ||
4673 | 1 2 3 | |
4674 | 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 | |
4675 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4676 | |A| Attribute Type | AF=0 Attribute Length | | |
4677 | |F| | AF=1 Attribute Value | | |
4678 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4679 | | AF=0 Attribute Value | | |
4680 | | AF=1 Not Transmitted | | |
4681 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4682 | ||
4683 | Figure 9: Data Attributes | |
4684 | ||
a6d7a610 | 4685 | o Attribute Format (AF) (1 bit) - Indicates whether the data |
824a0402 AS |
4686 | attribute follows the Type/Length/Value (TLV) format or a |
4687 | shortened Type/Value (TV) format. If the AF bit is zero (0), then | |
4688 | the attribute uses TLV format; if the AF bit is one (1), the TV | |
4689 | format (with two-byte value) is used. | |
a6d7a610 MW |
4690 | |
4691 | o Attribute Type (15 bits) - Unique identifier for each type of | |
4692 | attribute (see below). | |
4693 | ||
824a0402 AS |
4694 | o Attribute Value (variable length) - Value of the attribute |
4695 | associated with the attribute type. If the AF bit is a zero (0), | |
a6d7a610 MW |
4696 | this field has a variable length defined by the Attribute Length |
4697 | field. If the AF bit is a one (1), the Attribute Value has a | |
4698 | length of 2 octets. | |
4699 | ||
824a0402 AS |
4700 | The only currently defined attribute type (Key Length) is fixed |
4701 | length; the variable-length encoding specification is included only | |
4702 | for future extensions. Attributes described as fixed length MUST NOT | |
4703 | ||
4704 | ||
4705 | ||
4706 | Kaufman, et al. Standards Track [Page 84] | |
4707 | \f | |
4708 | RFC 5996 IKEv2bis September 2010 | |
4709 | ||
4710 | ||
4711 | be encoded using the variable-length encoding unless that length | |
4712 | exceeds two bytes. Variable-length attributes MUST NOT be encoded as | |
4713 | fixed-length even if their value can fit into two octets. Note: This | |
4714 | is a change from IKEv1, where increased flexibility may have | |
4715 | simplified the composer of messages but certainly complicated the | |
4716 | parser. | |
4717 | ||
4718 | The values in the following table are only current as of the | |
4719 | publication date of RFC 4306. Other values may have been added since | |
4720 | then or will be added after the publication of this document. | |
4721 | Readers should refer to [IKEV2IANA] for the latest values. | |
a6d7a610 MW |
4722 | |
4723 | Attribute Type Value Attribute Format | |
4724 | ------------------------------------------------------------ | |
a6d7a610 | 4725 | Key Length (in bits) 14 TV |
a6d7a610 MW |
4726 | |
4727 | Values 0-13 and 15-17 were used in a similar context in IKEv1, and | |
4728 | should not be assigned except to matching values. | |
4729 | ||
4730 | The Key Length attribute specifies the key length in bits (MUST use | |
2eac2578 | 4731 | network byte order) for certain transforms as follows: |
a6d7a610 MW |
4732 | |
4733 | o The Key Length attribute MUST NOT be used with transforms that use | |
824a0402 AS |
4734 | a fixed-length key. For example, this includes ENCR_DES, |
4735 | ENCR_IDEA, and all the Type 2 (Pseudorandom function) and Type 3 | |
4736 | (Integrity Algorithm) transforms specified in this document. It | |
4737 | is recommended that future Type 2 or 3 transforms do not use this | |
a6d7a610 MW |
4738 | attribute. |
4739 | ||
4740 | o Some transforms specify that the Key Length attribute MUST be | |
4741 | always included (omitting the attribute is not allowed, and | |
824a0402 AS |
4742 | proposals not containing it MUST be rejected). For example, this |
4743 | includes ENCR_AES_CBC and ENCR_AES_CTR. | |
a6d7a610 MW |
4744 | |
4745 | o Some transforms allow variable-length keys, but also specify a | |
824a0402 AS |
4746 | default key length if the attribute is not included. For example, |
4747 | these transforms include ENCR_RC5 and ENCR_BLOWFISH. | |
a6d7a610 MW |
4748 | |
4749 | Implementation note: To further interoperability and to support | |
4750 | upgrading endpoints independently, implementers of this protocol | |
4751 | SHOULD accept values that they deem to supply greater security. For | |
4752 | instance, if a peer is configured to accept a variable-length cipher | |
4753 | with a key length of X bits and is offered that cipher with a larger | |
4754 | key length, the implementation SHOULD accept the offer if it supports | |
4755 | use of the longer key. | |
4756 | ||
824a0402 AS |
4757 | |
4758 | ||
4759 | ||
4760 | ||
4761 | ||
4762 | Kaufman, et al. Standards Track [Page 85] | |
4763 | \f | |
4764 | RFC 5996 IKEv2bis September 2010 | |
4765 | ||
4766 | ||
4767 | Support for this capability allows a responder to express a concept | |
4768 | of "at least" a certain level of security -- "a key length of _at | |
4769 | least_ X bits for cipher Y". However, as the attribute is always | |
4770 | returned unchanged (see the next section), an initiator willing to | |
4771 | accept multiple key lengths has to include multiple transforms with | |
4772 | the same Transform Type, each with a different Key Length attribute. | |
a6d7a610 MW |
4773 | |
4774 | 3.3.6. Attribute Negotiation | |
4775 | ||
824a0402 | 4776 | During Security Association negotiation initiators present offers to |
a6d7a610 MW |
4777 | responders. Responders MUST select a single complete set of |
4778 | parameters from the offers (or reject all offers if none are | |
4779 | acceptable). If there are multiple proposals, the responder MUST | |
4780 | choose a single proposal. If the selected proposal has multiple | |
824a0402 | 4781 | transforms with the same type, the responder MUST choose a single |
a6d7a610 MW |
4782 | one. Any attributes of a selected transform MUST be returned |
4783 | unmodified. The initiator of an exchange MUST check that the | |
4784 | accepted offer is consistent with one of its proposals, and if not | |
824a0402 | 4785 | MUST terminate the exchange. |
a6d7a610 MW |
4786 | |
4787 | If the responder receives a proposal that contains a Transform Type | |
4788 | it does not understand, or a proposal that is missing a mandatory | |
4789 | Transform Type, it MUST consider this proposal unacceptable; however, | |
4790 | other proposals in the same SA payload are processed as usual. | |
824a0402 AS |
4791 | Similarly, if the responder receives a transform that it does not |
4792 | understand, or one that contains a Transform Attribute it does not | |
4793 | understand, it MUST consider this transform unacceptable; other | |
4794 | transforms with the same Transform Type are processed as usual. This | |
4795 | allows new Transform Types and Transform Attributes to be defined in | |
4796 | the future. | |
a6d7a610 | 4797 | |
2eac2578 | 4798 | Negotiating Diffie-Hellman groups presents some special challenges. |
82f0707f MW |
4799 | SA offers include proposed attributes and a Diffie-Hellman public |
4800 | number (KE) in the same message. If in the initial exchange the | |
a6d7a610 MW |
4801 | initiator offers to use one of several Diffie-Hellman groups, it |
4802 | SHOULD pick the one the responder is most likely to accept and | |
82f0707f MW |
4803 | include a KE corresponding to that group. If the responder selects a |
4804 | proposal using a different Diffie-Hellman group (other than NONE), | |
4805 | the responder will indicate the correct group in the response and the | |
4806 | initiator SHOULD pick an element of that group for its KE value when | |
4807 | retrying the first message. It SHOULD, however, continue to propose | |
4808 | its full supported set of groups in order to prevent a man-in-the- | |
824a0402 AS |
4809 | middle downgrade attack. If one of the proposals offered is for the |
4810 | Diffie-Hellman group of NONE, and the responder selects that Diffie- | |
4811 | Hellman group, then it MUST ignore the initiator's KE payload and | |
4812 | omit the KE payload from the response. | |
4813 | ||
4814 | ||
4815 | ||
4816 | ||
4817 | ||
4818 | Kaufman, et al. Standards Track [Page 86] | |
4819 | \f | |
4820 | RFC 5996 IKEv2bis September 2010 | |
4821 | ||
a6d7a610 MW |
4822 | |
4823 | 3.4. Key Exchange Payload | |
4824 | ||
824a0402 | 4825 | The Key Exchange payload, denoted KE in this document, is used to |
a6d7a610 | 4826 | exchange Diffie-Hellman public numbers as part of a Diffie-Hellman |
824a0402 | 4827 | key exchange. The Key Exchange payload consists of the IKE generic |
a6d7a610 MW |
4828 | payload header followed by the Diffie-Hellman public value itself. |
4829 | ||
4830 | 1 2 3 | |
4831 | 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 | |
4832 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4833 | | Next Payload |C| RESERVED | Payload Length | | |
4834 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
824a0402 | 4835 | | Diffie-Hellman Group Num | RESERVED | |
a6d7a610 MW |
4836 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
4837 | | | | |
4838 | ~ Key Exchange Data ~ | |
4839 | | | | |
4840 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4841 | ||
4842 | Figure 10: Key Exchange Payload Format | |
4843 | ||
824a0402 | 4844 | A Key Exchange payload is constructed by copying one's Diffie-Hellman |
a6d7a610 | 4845 | public value into the "Key Exchange Data" portion of the payload. |
824a0402 AS |
4846 | The length of the Diffie-Hellman public value for modular |
4847 | exponentiation group (MODP) groups MUST be equal to the length of the | |
4848 | prime modulus over which the exponentiation was performed, prepending | |
4849 | zero bits to the value if necessary. | |
4850 | ||
4851 | The Diffie-Hellman Group Num identifies the Diffie-Hellman group in | |
4852 | which the Key Exchange Data was computed (see Section 3.3.2). This | |
4853 | Diffie-Hellman Group Num MUST match a Diffie-Hellman group specified | |
4854 | in a proposal in the SA payload that is sent in the same message, and | |
4855 | SHOULD match the Diffie-Hellman group in the first group in the first | |
4856 | proposal, if such exists. If none of the proposals in that SA | |
4857 | payload specifies a Diffie-Hellman group, the KE payload MUST NOT be | |
4858 | present. If the selected proposal uses a different Diffie-Hellman | |
4859 | group (other than NONE), the message MUST be rejected with a Notify | |
4860 | payload of type INVALID_KE_PAYLOAD. See also Sections 1.2 and 2.7. | |
4861 | ||
4862 | The payload type for the Key Exchange payload is thirty-four (34). | |
a6d7a610 | 4863 | |
824a0402 | 4864 | 3.5. Identification Payloads |
a6d7a610 | 4865 | |
824a0402 AS |
4866 | The Identification payloads, denoted IDi and IDr in this document, |
4867 | allow peers to assert an identity to one another. This identity may | |
4868 | be used for policy lookup, but does not necessarily have to match | |
4869 | anything in the CERT payload; both fields may be used by an | |
4870 | implementation to perform access control decisions. When using the | |
a6d7a610 | 4871 | |
a6d7a610 MW |
4872 | |
4873 | ||
824a0402 AS |
4874 | Kaufman, et al. Standards Track [Page 87] |
4875 | \f | |
4876 | RFC 5996 IKEv2bis September 2010 | |
a6d7a610 MW |
4877 | |
4878 | ||
2eac2578 MW |
4879 | ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 |
4880 | does not require this address to match the address in the IP header | |
4881 | of IKEv2 packets, or anything in the TSi/TSr payloads. The contents | |
824a0402 AS |
4882 | of IDi/IDr are used purely to fetch the policy and authentication |
4883 | data related to the other party. | |
a6d7a610 MW |
4884 | |
4885 | NOTE: In IKEv1, two ID payloads were used in each direction to hold | |
4886 | Traffic Selector (TS) information for data passing over the SA. In | |
4887 | IKEv2, this information is carried in TS payloads (see Section 3.13). | |
4888 | ||
824a0402 AS |
4889 | The Peer Authorization Database (PAD) as described in RFC 4301 |
4890 | [IPSECARCH] describes the use of the ID payload in IKEv2 and provides | |
4891 | a formal model for the binding of identity to policy in addition to | |
4892 | providing services that deal more specifically with the details of | |
4893 | policy enforcement. The PAD is intended to provide a link between | |
4894 | the SPD and the IKE Security Association management. See Section | |
4895 | 4.4.3 of RFC 4301 for more details. | |
4896 | ||
4897 | The Identification payload consists of the IKE generic payload header | |
a6d7a610 MW |
4898 | followed by identification fields as follows: |
4899 | ||
4900 | 1 2 3 | |
4901 | 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 | |
4902 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4903 | | Next Payload |C| RESERVED | Payload Length | | |
4904 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4905 | | ID Type | RESERVED | | |
4906 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4907 | | | | |
4908 | ~ Identification Data ~ | |
4909 | | | | |
4910 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4911 | ||
4912 | Figure 11: Identification Payload Format | |
4913 | ||
4914 | o ID Type (1 octet) - Specifies the type of Identification being | |
4915 | used. | |
4916 | ||
4917 | o RESERVED - MUST be sent as zero; MUST be ignored on receipt. | |
4918 | ||
4919 | o Identification Data (variable length) - Value, as indicated by the | |
4920 | Identification Type. The length of the Identification Data is | |
4921 | computed from the size in the ID payload header. | |
4922 | ||
824a0402 AS |
4923 | The payload types for the Identification payload are thirty-five (35) |
4924 | for IDi and thirty-six (36) for IDr. | |
a6d7a610 MW |
4925 | |
4926 | ||
4927 | ||
4928 | ||
824a0402 AS |
4929 | |
4930 | Kaufman, et al. Standards Track [Page 88] | |
2eac2578 | 4931 | \f |
824a0402 | 4932 | RFC 5996 IKEv2bis September 2010 |
a6d7a610 | 4933 | |
a6d7a610 | 4934 | |
824a0402 AS |
4935 | The following table lists the assigned semantics for the |
4936 | Identification Type field. The values in the following table are | |
4937 | only current as of the publication date of RFC 4306. Other values | |
4938 | may have been added since then or will be added after the publication | |
4939 | of this document. Readers should refer to [IKEV2IANA] for the latest | |
4940 | values. | |
a6d7a610 MW |
4941 | |
4942 | ID Type Value | |
4943 | ------------------------------------------------------------------- | |
a6d7a610 | 4944 | ID_IPV4_ADDR 1 |
824a0402 | 4945 | A single four (4) octet IPv4 address. |
a6d7a610 MW |
4946 | |
4947 | ID_FQDN 2 | |
824a0402 AS |
4948 | A fully-qualified domain name string. An example of an ID_FQDN |
4949 | is "example.com". The string MUST NOT contain any terminators | |
4950 | (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII; | |
4951 | for an "internationalized domain name", the syntax is as defined | |
4952 | in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net". | |
a6d7a610 MW |
4953 | |
4954 | ID_RFC822_ADDR 3 | |
824a0402 AS |
4955 | A fully-qualified RFC 822 email address string. An example of a |
4956 | ID_RFC822_ADDR is "jsmith@example.com". The string MUST NOT | |
4957 | contain any terminators. Because of [EAI], implementations would | |
4958 | be wise to treat this field as UTF-8 encoded text, not as | |
4959 | pure ASCII. | |
a6d7a610 MW |
4960 | |
4961 | ID_IPV6_ADDR 5 | |
824a0402 | 4962 | A single sixteen (16) octet IPv6 address. |
a6d7a610 MW |
4963 | |
4964 | ID_DER_ASN1_DN 9 | |
824a0402 AS |
4965 | The binary Distinguished Encoding Rules (DER) encoding of an |
4966 | ASN.1 X.500 Distinguished Name [PKIX]. | |
a6d7a610 MW |
4967 | |
4968 | ID_DER_ASN1_GN 10 | |
824a0402 | 4969 | The binary DER encoding of an ASN.1 X.509 GeneralName [PKIX]. |
a6d7a610 MW |
4970 | |
4971 | ID_KEY_ID 11 | |
824a0402 AS |
4972 | An opaque octet stream that may be used to pass vendor- |
4973 | specific information necessary to do certain proprietary | |
4974 | types of identification. | |
a6d7a610 | 4975 | |
2eac2578 | 4976 | Two implementations will interoperate only if each can generate a |
824a0402 AS |
4977 | type of ID acceptable to the other. To assure maximum |
4978 | interoperability, implementations MUST be configurable to send at | |
4979 | least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and | |
4980 | MUST be configurable to accept all of these four types. | |
4981 | Implementations SHOULD be capable of generating and accepting all of | |
4982 | these types. IPv6-capable implementations MUST additionally be | |
2eac2578 | 4983 | |
a6d7a610 MW |
4984 | |
4985 | ||
824a0402 | 4986 | Kaufman, et al. Standards Track [Page 89] |
a6d7a610 | 4987 | \f |
824a0402 | 4988 | RFC 5996 IKEv2bis September 2010 |
a6d7a610 MW |
4989 | |
4990 | ||
824a0402 AS |
4991 | configurable to accept ID_IPV6_ADDR. IPv6-only implementations MAY |
4992 | be configurable to send only ID_IPV6_ADDR instead of ID_IPV4_ADDR for | |
4993 | IP addresses. | |
a6d7a610 | 4994 | |
2eac2578 MW |
4995 | EAP [EAP] does not mandate the use of any particular type of |
4996 | identifier, but often EAP is used with Network Access Identifiers | |
4997 | (NAIs) defined in [NAI]. Although NAIs look a bit like email | |
4998 | addresses (e.g., "joe@example.com"), the syntax is not exactly the | |
4999 | same as the syntax of email address in [MAILFORMAT]. For those NAIs | |
5000 | that include the realm component, the ID_RFC822_ADDR identification | |
5001 | type SHOULD be used. Responder implementations should not attempt to | |
5002 | verify that the contents actually conform to the exact syntax given | |
5003 | in [MAILFORMAT], but instead should accept any reasonable-looking | |
824a0402 | 5004 | NAI. For NAIs that do not include the realm component, the ID_KEY_ID |
2eac2578 | 5005 | identification type SHOULD be used. |
a6d7a610 MW |
5006 | |
5007 | 3.6. Certificate Payload | |
5008 | ||
824a0402 AS |
5009 | The Certificate payload, denoted CERT in this document, provides a |
5010 | means to transport certificates or other authentication-related | |
5011 | information via IKE. Certificate payloads SHOULD be included in an | |
5012 | exchange if certificates are available to the sender. The Hash and | |
5013 | URL formats of the Certificate payloads should be used in case the | |
5014 | peer has indicated an ability to retrieve this information from | |
5015 | elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note | |
5016 | that the term "Certificate payload" is somewhat misleading, because | |
5017 | not all authentication mechanisms use certificates and data other | |
5018 | than certificates may be passed in this payload. | |
a6d7a610 | 5019 | |
824a0402 | 5020 | The Certificate payload is defined as follows: |
a6d7a610 MW |
5021 | |
5022 | 1 2 3 | |
5023 | 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 | |
5024 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5025 | | Next Payload |C| RESERVED | Payload Length | | |
5026 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5027 | | Cert Encoding | | | |
5028 | +-+-+-+-+-+-+-+-+ | | |
5029 | ~ Certificate Data ~ | |
5030 | | | | |
5031 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5032 | ||
5033 | Figure 12: Certificate Payload Format | |
5034 | ||
824a0402 AS |
5035 | o Certificate Encoding (1 octet) - This field indicates the type of |
5036 | certificate or certificate-related information contained in the | |
5037 | Certificate Data field. The values in the following table are | |
5038 | only current as of the publication date of RFC 4306. Other values | |
a6d7a610 MW |
5039 | |
5040 | ||
2eac2578 | 5041 | |
824a0402 | 5042 | Kaufman, et al. Standards Track [Page 90] |
a6d7a610 | 5043 | \f |
824a0402 | 5044 | RFC 5996 IKEv2bis September 2010 |
82f0707f | 5045 | |
a6d7a610 | 5046 | |
824a0402 AS |
5047 | may have been added since then or will be added after the |
5048 | publication of this document. Readers should refer to [IKEV2IANA] | |
5049 | for the latest values. | |
a6d7a610 MW |
5050 | |
5051 | Certificate Encoding Value | |
5052 | ---------------------------------------------------- | |
a6d7a610 MW |
5053 | PKCS #7 wrapped X.509 certificate 1 UNSPECIFIED |
5054 | PGP Certificate 2 UNSPECIFIED | |
5055 | DNS Signed Key 3 UNSPECIFIED | |
5056 | X.509 Certificate - Signature 4 | |
5057 | Kerberos Token 6 UNSPECIFIED | |
5058 | Certificate Revocation List (CRL) 7 | |
5059 | Authority Revocation List (ARL) 8 UNSPECIFIED | |
5060 | SPKI Certificate 9 UNSPECIFIED | |
5061 | X.509 Certificate - Attribute 10 UNSPECIFIED | |
5062 | Raw RSA Key 11 | |
5063 | Hash and URL of X.509 certificate 12 | |
5064 | Hash and URL of X.509 bundle 13 | |
a6d7a610 MW |
5065 | |
5066 | o Certificate Data (variable length) - Actual encoding of | |
5067 | certificate data. The type of certificate is indicated by the | |
5068 | Certificate Encoding field. | |
5069 | ||
824a0402 | 5070 | The payload type for the Certificate payload is thirty-seven (37). |
a6d7a610 MW |
5071 | |
5072 | Specific syntax for some of the certificate type codes above is not | |
5073 | defined in this document. The types whose syntax is defined in this | |
5074 | document are: | |
5075 | ||
824a0402 | 5076 | o "X.509 Certificate - Signature" contains a DER-encoded X.509 |
a6d7a610 | 5077 | certificate whose public key is used to validate the sender's AUTH |
824a0402 AS |
5078 | payload. Note that with this encoding, if a chain of certificates |
5079 | needs to be sent, multiple CERT payloads are used, only the first | |
5080 | of which holds the public key used to validate the sender's AUTH | |
a6d7a610 MW |
5081 | payload. |
5082 | ||
824a0402 | 5083 | o "Certificate Revocation List" contains a DER-encoded X.509 |
a6d7a610 MW |
5084 | certificate revocation list. |
5085 | ||
824a0402 AS |
5086 | o "Raw RSA Key" contains a PKCS #1 encoded RSA key, that is, a DER- |
5087 | encoded RSAPublicKey structure (see [RSA] and [PKCS1]). | |
a6d7a610 | 5088 | |
824a0402 AS |
5089 | o Hash and URL encodings allow IKE messages to remain short by |
5090 | replacing long data structures with a 20-octet SHA-1 hash (see | |
a6d7a610 | 5091 | [SHA]) of the replaced value followed by a variable-length URL |
824a0402 | 5092 | that resolves to the DER-encoded data structure itself. This |
a6d7a610 | 5093 | improves efficiency when the endpoints have certificate data |
a6d7a610 MW |
5094 | |
5095 | ||
5096 | ||
824a0402 AS |
5097 | |
5098 | Kaufman, et al. Standards Track [Page 91] | |
a6d7a610 | 5099 | \f |
824a0402 | 5100 | RFC 5996 IKEv2bis September 2010 |
82f0707f | 5101 | |
a6d7a610 | 5102 | |
824a0402 AS |
5103 | cached and makes IKE less subject to DoS attacks that become |
5104 | easier to mount when IKE messages are large enough to require IP | |
5105 | fragmentation [DOSUDPPROT]. | |
a6d7a610 | 5106 | |
824a0402 AS |
5107 | The "Hash and URL of a bundle" type uses the following ASN.1 |
5108 | definition for the X.509 bundle: | |
a6d7a610 MW |
5109 | |
5110 | CertBundle | |
5111 | { iso(1) identified-organization(3) dod(6) internet(1) | |
5112 | security(5) mechanisms(5) pkix(7) id-mod(0) | |
5113 | id-mod-cert-bundle(34) } | |
5114 | ||
5115 | DEFINITIONS EXPLICIT TAGS ::= | |
5116 | BEGIN | |
5117 | ||
5118 | IMPORTS | |
5119 | Certificate, CertificateList | |
5120 | FROM PKIX1Explicit88 | |
5121 | { iso(1) identified-organization(3) dod(6) | |
5122 | internet(1) security(5) mechanisms(5) pkix(7) | |
5123 | id-mod(0) id-pkix1-explicit(18) } ; | |
5124 | ||
5125 | CertificateOrCRL ::= CHOICE { | |
5126 | cert [0] Certificate, | |
5127 | crl [1] CertificateList } | |
5128 | ||
5129 | CertificateBundle ::= SEQUENCE OF CertificateOrCRL | |
5130 | ||
5131 | END | |
5132 | ||
5133 | Implementations MUST be capable of being configured to send and | |
5134 | accept up to four X.509 certificates in support of authentication, | |
5135 | and also MUST be capable of being configured to send and accept the | |
824a0402 | 5136 | Hash and URL format (with HTTP URLs). Implementations SHOULD be |
a6d7a610 MW |
5137 | capable of being configured to send and accept Raw RSA keys. If |
5138 | multiple certificates are sent, the first certificate MUST contain | |
5139 | the public key used to sign the AUTH payload. The other certificates | |
5140 | may be sent in any order. | |
5141 | ||
824a0402 AS |
5142 | Implementations MUST support the HTTP [HTTP] method for hash-and-URL |
5143 | lookup. The behavior of other URL methods [URLS] is not currently | |
5144 | specified, and such methods SHOULD NOT be used in the absence of a | |
5145 | document specifying them. | |
5146 | ||
5147 | ||
5148 | ||
a6d7a610 | 5149 | |
a6d7a610 | 5150 | |
a6d7a610 MW |
5151 | |
5152 | ||
5153 | ||
824a0402 | 5154 | Kaufman, et al. Standards Track [Page 92] |
a6d7a610 | 5155 | \f |
824a0402 | 5156 | RFC 5996 IKEv2bis September 2010 |
82f0707f | 5157 | |
a6d7a610 | 5158 | |
824a0402 AS |
5159 | 3.7. Certificate Request Payload |
5160 | ||
5161 | The Certificate Request payload, denoted CERTREQ in this document, | |
5162 | provides a means to request preferred certificates via IKE and can | |
5163 | appear in the IKE_INIT_SA response and/or the IKE_AUTH request. | |
5164 | Certificate Request payloads MAY be included in an exchange when the | |
5165 | sender needs to get the certificate of the receiver. | |
5166 | ||
5167 | The Certificate Request payload is defined as follows: | |
a6d7a610 MW |
5168 | 1 2 3 |
5169 | 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 | |
5170 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5171 | | Next Payload |C| RESERVED | Payload Length | | |
5172 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5173 | | Cert Encoding | | | |
5174 | +-+-+-+-+-+-+-+-+ | | |
5175 | ~ Certification Authority ~ | |
5176 | | | | |
5177 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5178 | ||
5179 | Figure 13: Certificate Request Payload Format | |
5180 | ||
5181 | o Certificate Encoding (1 octet) - Contains an encoding of the type | |
5182 | or format of certificate requested. Values are listed in | |
5183 | Section 3.6. | |
5184 | ||
5185 | o Certification Authority (variable length) - Contains an encoding | |
5186 | of an acceptable certification authority for the type of | |
5187 | certificate requested. | |
5188 | ||
824a0402 | 5189 | The payload type for the Certificate Request payload is thirty-eight |
a6d7a610 MW |
5190 | (38). |
5191 | ||
5192 | The Certificate Encoding field has the same values as those defined | |
5193 | in Section 3.6. The Certification Authority field contains an | |
5194 | indicator of trusted authorities for this certificate type. The | |
5195 | Certification Authority value is a concatenated list of SHA-1 hashes | |
5196 | of the public keys of trusted Certification Authorities (CAs). Each | |
5197 | is encoded as the SHA-1 hash of the Subject Public Key Info element | |
5198 | (see section 4.1.2.7 of [PKIX]) from each Trust Anchor certificate. | |
824a0402 | 5199 | The 20-octet hashes are concatenated and included with no other |
a6d7a610 MW |
5200 | formatting. |
5201 | ||
2eac2578 | 5202 | The contents of the "Certification Authority" field are defined only |
824a0402 AS |
5203 | for X.509 certificates, which are types 4, 12, and 13. Other values |
5204 | SHOULD NOT be used until Standards-Track specifications that specify | |
5205 | their use are published. | |
5206 | ||
5207 | ||
5208 | ||
5209 | ||
5210 | Kaufman, et al. Standards Track [Page 93] | |
5211 | \f | |
5212 | RFC 5996 IKEv2bis September 2010 | |
5213 | ||
a6d7a610 MW |
5214 | |
5215 | Note that the term "Certificate Request" is somewhat misleading, in | |
5216 | that values other than certificates are defined in a "Certificate" | |
5217 | payload and requests for those values can be present in a Certificate | |
824a0402 | 5218 | Request payload. The syntax of the Certificate Request payload in |
a6d7a610 MW |
5219 | such cases is not defined in this document. |
5220 | ||
824a0402 | 5221 | The Certificate Request payload is processed by inspecting the "Cert |
2eac2578 MW |
5222 | Encoding" field to determine whether the processor has any |
5223 | certificates of this type. If so, the "Certification Authority" | |
a6d7a610 MW |
5224 | field is inspected to determine if the processor has any certificates |
5225 | that can be validated up to one of the specified certification | |
5226 | authorities. This can be a chain of certificates. | |
5227 | ||
5228 | If an end-entity certificate exists that satisfies the criteria | |
5229 | specified in the CERTREQ, a certificate or certificate chain SHOULD | |
5230 | be sent back to the certificate requestor if the recipient of the | |
5231 | CERTREQ: | |
5232 | ||
5233 | o is configured to use certificate authentication, | |
5234 | ||
5235 | o is allowed to send a CERT payload, | |
5236 | ||
5237 | o has matching CA trust policy governing the current negotiation, | |
5238 | and | |
5239 | ||
824a0402 | 5240 | o has at least one time-wise and usage-appropriate end-entity |
a6d7a610 MW |
5241 | certificate chaining to a CA provided in the CERTREQ. |
5242 | ||
5243 | Certificate revocation checking must be considered during the | |
5244 | chaining process used to select a certificate. Note that even if two | |
5245 | peers are configured to use two different CAs, cross-certification | |
5246 | relationships should be supported by appropriate selection logic. | |
5247 | ||
5248 | The intent is not to prevent communication through the strict | |
5249 | adherence of selection of a certificate based on CERTREQ, when an | |
5250 | alternate certificate could be selected by the sender that would | |
5251 | still enable the recipient to successfully validate and trust it | |
5252 | through trust conveyed by cross-certification, CRLs, or other out-of- | |
5253 | band configured means. Thus, the processing of a CERTREQ should be | |
5254 | seen as a suggestion for a certificate to select, not a mandated one. | |
5255 | If no certificates exist, then the CERTREQ is ignored. This is not | |
5256 | an error condition of the protocol. There may be cases where there | |
5257 | is a preferred CA sent in the CERTREQ, but an alternate might be | |
5258 | acceptable (perhaps after prompting a human operator). | |
5259 | ||
a6d7a610 | 5260 | |
a6d7a610 | 5261 | |
a6d7a610 MW |
5262 | |
5263 | ||
5264 | ||
82f0707f | 5265 | |
824a0402 | 5266 | Kaufman, et al. Standards Track [Page 94] |
2eac2578 | 5267 | \f |
824a0402 | 5268 | RFC 5996 IKEv2bis September 2010 |
a6d7a610 MW |
5269 | |
5270 | ||
824a0402 AS |
5271 | The HTTP_CERT_LOOKUP_SUPPORTED notification MAY be included in any |
5272 | message that can include a CERTREQ payload and indicates that the | |
5273 | sender is capable of looking up certificates based on an HTTP-based | |
5274 | URL (and hence presumably would prefer to receive certificate | |
5275 | specifications in that format). | |
5276 | ||
5277 | 3.8. Authentication Payload | |
5278 | ||
5279 | The Authentication payload, denoted AUTH in this document, contains | |
5280 | data used for authentication purposes. The syntax of the | |
5281 | Authentication data varies according to the Auth Method as specified | |
5282 | below. | |
5283 | ||
5284 | The Authentication payload is defined as follows: | |
a6d7a610 MW |
5285 | |
5286 | 1 2 3 | |
5287 | 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 | |
5288 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5289 | | Next Payload |C| RESERVED | Payload Length | | |
5290 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5291 | | Auth Method | RESERVED | | |
5292 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5293 | | | | |
5294 | ~ Authentication Data ~ | |
5295 | | | | |
5296 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5297 | ||
5298 | Figure 14: Authentication Payload Format | |
5299 | ||
5300 | o Auth Method (1 octet) - Specifies the method of authentication | |
824a0402 AS |
5301 | used. The types of signatures are listed here. The values in the |
5302 | following table are only current as of the publication date of RFC | |
5303 | 4306. Other values may have been added since then or will be | |
5304 | added after the publication of this document. Readers should | |
5305 | refer to [IKEV2IANA] for the latest values. | |
a6d7a610 | 5306 | |
824a0402 AS |
5307 | Mechanism Value |
5308 | ----------------------------------------------------------------- | |
5309 | RSA Digital Signature 1 | |
5310 | Computed as specified in Section 2.15 using an RSA private key | |
5311 | with RSASSA-PKCS1-v1_5 signature scheme specified in [PKCS1] | |
5312 | (implementers should note that IKEv1 used a different method for | |
5313 | RSA signatures). To promote interoperability, implementations | |
5314 | that support this type SHOULD support signatures that use SHA-1 | |
5315 | as the hash function and SHOULD use SHA-1 as the default hash | |
5316 | function when generating signatures. Implementations can use the | |
5317 | certificates received from a given peer as a hint for selecting a | |
5318 | mutually understood hash function for the AUTH payload signature. | |
a6d7a610 | 5319 | |
a6d7a610 | 5320 | |
a6d7a610 | 5321 | |
824a0402 AS |
5322 | Kaufman, et al. Standards Track [Page 95] |
5323 | \f | |
5324 | RFC 5996 IKEv2bis September 2010 | |
a6d7a610 | 5325 | |
a6d7a610 | 5326 | |
824a0402 AS |
5327 | Note, however, that the hash algorithm used in the AUTH payload |
5328 | signature doesn't have to be the same as any hash algorithm(s) | |
5329 | used in the certificate(s). | |
a6d7a610 | 5330 | |
824a0402 AS |
5331 | Shared Key Message Integrity Code 2 |
5332 | Computed as specified in Section 2.15 using the shared key | |
5333 | associated with the identity in the ID payload and the negotiated | |
5334 | PRF. | |
a6d7a610 | 5335 | |
824a0402 AS |
5336 | DSS Digital Signature 3 |
5337 | Computed as specified in Section 2.15 using a DSS private key | |
5338 | (see [DSS]) over a SHA-1 hash. | |
a6d7a610 | 5339 | |
824a0402 | 5340 | o Authentication Data (variable length) - see Section 2.15. |
a6d7a610 | 5341 | |
824a0402 | 5342 | The payload type for the Authentication payload is thirty-nine (39). |
82f0707f | 5343 | |
824a0402 | 5344 | 3.9. Nonce Payload |
a6d7a610 | 5345 | |
824a0402 AS |
5346 | The Nonce payload, denoted as Ni and Nr in this document for the |
5347 | initiator's and responder's nonce, respectively, contains random data | |
5348 | used to guarantee liveness during an exchange and protect against | |
5349 | replay attacks. | |
a6d7a610 | 5350 | |
824a0402 | 5351 | The Nonce payload is defined as follows: |
a6d7a610 MW |
5352 | |
5353 | 1 2 3 | |
5354 | 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 | |
5355 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5356 | | Next Payload |C| RESERVED | Payload Length | | |
5357 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5358 | | | | |
5359 | ~ Nonce Data ~ | |
5360 | | | | |
5361 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5362 | ||
5363 | Figure 15: Nonce Payload Format | |
5364 | ||
5365 | o Nonce Data (variable length) - Contains the random data generated | |
5366 | by the transmitting entity. | |
5367 | ||
824a0402 | 5368 | The payload type for the Nonce payload is forty (40). |
a6d7a610 | 5369 | |
824a0402 AS |
5370 | The size of the Nonce Data MUST be between 16 and 256 octets, |
5371 | inclusive. Nonce values MUST NOT be reused. | |
a6d7a610 MW |
5372 | |
5373 | ||
5374 | ||
5375 | ||
5376 | ||
5377 | ||
824a0402 AS |
5378 | Kaufman, et al. Standards Track [Page 96] |
5379 | \f | |
5380 | RFC 5996 IKEv2bis September 2010 | |
a6d7a610 MW |
5381 | |
5382 | ||
824a0402 | 5383 | 3.10. Notify Payload |
a6d7a610 | 5384 | |
824a0402 AS |
5385 | The Notify payload, denoted N in this document, is used to transmit |
5386 | informational data, such as error conditions and state transitions, | |
5387 | to an IKE peer. A Notify payload may appear in a response message | |
5388 | (usually specifying why a request was rejected), in an INFORMATIONAL | |
5389 | Exchange (to report an error not in an IKE request), or in any other | |
5390 | message to indicate sender capabilities or to modify the meaning of | |
5391 | the request. | |
a6d7a610 | 5392 | |
824a0402 | 5393 | The Notify payload is defined as follows: |
a6d7a610 MW |
5394 | 1 2 3 |
5395 | 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 | |
5396 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5397 | | Next Payload |C| RESERVED | Payload Length | | |
5398 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5399 | | Protocol ID | SPI Size | Notify Message Type | | |
5400 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5401 | | | | |
5402 | ~ Security Parameter Index (SPI) ~ | |
5403 | | | | |
5404 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5405 | | | | |
5406 | ~ Notification Data ~ | |
5407 | | | | |
5408 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5409 | ||
5410 | Figure 16: Notify Payload Format | |
5411 | ||
5412 | o Protocol ID (1 octet) - If this notification concerns an existing | |
824a0402 AS |
5413 | SA whose SPI is given in the SPI field, this field indicates the |
5414 | type of that SA. For notifications concerning Child SAs, this | |
5415 | field MUST contain either (2) to indicate AH or (3) to indicate | |
5416 | ESP. Of the notifications defined in this document, the SPI is | |
5417 | included only with INVALID_SELECTORS and REKEY_SA. If the SPI | |
5418 | field is empty, this field MUST be sent as zero and MUST be | |
5419 | ignored on receipt. | |
a6d7a610 MW |
5420 | |
5421 | o SPI Size (1 octet) - Length in octets of the SPI as defined by the | |
5422 | IPsec protocol ID or zero if no SPI is applicable. For a | |
5423 | notification concerning the IKE SA, the SPI Size MUST be zero and | |
5424 | the field must be empty. | |
5425 | ||
5426 | o Notify Message Type (2 octets) - Specifies the type of | |
5427 | notification message. | |
5428 | ||
5429 | o SPI (variable length) - Security Parameter Index. | |
5430 | ||
a6d7a610 | 5431 | |
a6d7a610 | 5432 | |
a6d7a610 | 5433 | |
824a0402 AS |
5434 | Kaufman, et al. Standards Track [Page 97] |
5435 | \f | |
5436 | RFC 5996 IKEv2bis September 2010 | |
a6d7a610 MW |
5437 | |
5438 | ||
824a0402 AS |
5439 | o Notification Data (variable length) - Status or error data |
5440 | transmitted in addition to the Notify Message Type. Values for | |
5441 | this field are type specific (see below). | |
a6d7a610 | 5442 | |
824a0402 | 5443 | The payload type for the Notify payload is forty-one (41). |
a6d7a610 | 5444 | |
824a0402 | 5445 | 3.10.1. Notify Message Types |
a6d7a610 | 5446 | |
824a0402 AS |
5447 | Notification information can be error messages specifying why an SA |
5448 | could not be established. It can also be status data that a process | |
a6d7a610 | 5449 | managing an SA database wishes to communicate with a peer process. |
824a0402 | 5450 | |
a6d7a610 MW |
5451 | The table below lists the Notification messages and their |
5452 | corresponding values. The number of different error statuses was | |
5453 | greatly reduced from IKEv1 both for simplification and to avoid | |
5454 | giving configuration information to probers. | |
5455 | ||
5456 | Types in the range 0 - 16383 are intended for reporting errors. An | |
5457 | implementation receiving a Notify payload with one of these types | |
5458 | that it does not recognize in a response MUST assume that the | |
2eac2578 MW |
5459 | corresponding request has failed entirely. Unrecognized error types |
5460 | in a request and status types in a request or response MUST be | |
5461 | ignored, and they should be logged. | |
a6d7a610 MW |
5462 | |
5463 | Notify payloads with status types MAY be added to any message and | |
5464 | MUST be ignored if not recognized. They are intended to indicate | |
824a0402 | 5465 | capabilities, and as part of SA negotiation, are used to negotiate |
a6d7a610 MW |
5466 | non-cryptographic parameters. |
5467 | ||
824a0402 | 5468 | More information on error handling can be found in Section 2.21. |
a6d7a610 | 5469 | |
824a0402 AS |
5470 | The values in the following table are only current as of the |
5471 | publication date of RFC 4306, plus two error types added in this | |
5472 | document. Other values may have been added since then or will be | |
5473 | added after the publication of this document. Readers should refer | |
5474 | to [IKEV2IANA] for the latest values. | |
a6d7a610 | 5475 | |
824a0402 AS |
5476 | NOTIFY messages: error types Value |
5477 | ------------------------------------------------------------------- | |
5478 | UNSUPPORTED_CRITICAL_PAYLOAD 1 | |
5479 | See Section 2.5. | |
a6d7a610 | 5480 | |
824a0402 AS |
5481 | INVALID_IKE_SPI 4 |
5482 | See Section 2.21. | |
a6d7a610 | 5483 | |
824a0402 AS |
5484 | INVALID_MAJOR_VERSION 5 |
5485 | See Section 2.5. | |
a6d7a610 | 5486 | |
a6d7a610 MW |
5487 | |
5488 | ||
5489 | ||
824a0402 | 5490 | Kaufman, et al. Standards Track [Page 98] |
a6d7a610 | 5491 | \f |
824a0402 | 5492 | RFC 5996 IKEv2bis September 2010 |
a6d7a610 | 5493 | |
a6d7a610 | 5494 | |
824a0402 AS |
5495 | INVALID_SYNTAX 7 |
5496 | Indicates the IKE message that was received was invalid because | |
5497 | some type, length, or value was out of range or because the | |
5498 | request was rejected for policy reasons. To avoid a DoS | |
5499 | attack using forged messages, this status may only be | |
5500 | returned for and in an encrypted packet if the Message ID and | |
5501 | cryptographic checksum were valid. To avoid leaking information | |
5502 | to someone probing a node, this status MUST be sent in response | |
5503 | to any error not covered by one of the other status types. | |
5504 | To aid debugging, more detailed error information should be | |
5505 | written to a console or log. | |
a6d7a610 | 5506 | |
824a0402 AS |
5507 | INVALID_MESSAGE_ID 9 |
5508 | See Section 2.3. | |
a6d7a610 | 5509 | |
824a0402 AS |
5510 | INVALID_SPI 11 |
5511 | See Section 1.5. | |
a6d7a610 | 5512 | |
824a0402 AS |
5513 | NO_PROPOSAL_CHOSEN 14 |
5514 | None of the proposed crypto suites was acceptable. This can be | |
5515 | sent in any case where the offered proposals (including but not | |
5516 | limited to SA payload values, USE_TRANSPORT_MODE notify, | |
5517 | IPCOMP_SUPPORTED notify) are not acceptable for the responder. | |
5518 | This can also be used as "generic" Child SA error when Child SA | |
5519 | cannot be created for some other reason. See also Section 2.7. | |
a6d7a610 | 5520 | |
824a0402 AS |
5521 | INVALID_KE_PAYLOAD 17 |
5522 | See Sections 1.2 and 1.3. | |
a6d7a610 | 5523 | |
824a0402 AS |
5524 | AUTHENTICATION_FAILED 24 |
5525 | Sent in the response to an IKE_AUTH message when, for some reason, | |
5526 | the authentication failed. There is no associated data. See also | |
5527 | Section 2.21.2. | |
a6d7a610 | 5528 | |
824a0402 AS |
5529 | SINGLE_PAIR_REQUIRED 34 |
5530 | See Section 2.9. | |
a6d7a610 | 5531 | |
824a0402 AS |
5532 | NO_ADDITIONAL_SAS 35 |
5533 | See Section 1.3. | |
a6d7a610 | 5534 | |
824a0402 AS |
5535 | INTERNAL_ADDRESS_FAILURE 36 |
5536 | See Section 3.15.4. | |
a6d7a610 | 5537 | |
824a0402 AS |
5538 | FAILED_CP_REQUIRED 37 |
5539 | See Section 2.19. | |
a6d7a610 | 5540 | |
824a0402 AS |
5541 | TS_UNACCEPTABLE 38 |
5542 | See Section 2.9. | |
a6d7a610 MW |
5543 | |
5544 | ||
5545 | ||
824a0402 AS |
5546 | Kaufman, et al. Standards Track [Page 99] |
5547 | \f | |
5548 | RFC 5996 IKEv2bis September 2010 | |
a6d7a610 MW |
5549 | |
5550 | ||
824a0402 AS |
5551 | INVALID_SELECTORS 39 |
5552 | MAY be sent in an IKE INFORMATIONAL exchange when a node receives | |
5553 | an ESP or AH packet whose selectors do not match those of the SA | |
5554 | on which it was delivered (and that caused the packet to be | |
5555 | dropped). The Notification Data contains the start of the | |
5556 | offending packet (as in ICMP messages) and the SPI field of the | |
5557 | notification is set to match the SPI of the Child SA. | |
a6d7a610 | 5558 | |
824a0402 AS |
5559 | TEMPORARY_FAILURE 43 |
5560 | See section 2.25. | |
a6d7a610 | 5561 | |
824a0402 AS |
5562 | CHILD_SA_NOT_FOUND 44 |
5563 | See section 2.25. | |
a6d7a610 | 5564 | |
a6d7a610 MW |
5565 | |
5566 | ||
5567 | NOTIFY messages: status types Value | |
5568 | ------------------------------------------------------------------- | |
a6d7a610 MW |
5569 | INITIAL_CONTACT 16384 |
5570 | See Section 2.4. | |
5571 | ||
5572 | SET_WINDOW_SIZE 16385 | |
5573 | See Section 2.3. | |
5574 | ||
5575 | ADDITIONAL_TS_POSSIBLE 16386 | |
5576 | See Section 2.9. | |
5577 | ||
5578 | IPCOMP_SUPPORTED 16387 | |
5579 | See Section 2.22. | |
5580 | ||
5581 | NAT_DETECTION_SOURCE_IP 16388 | |
5582 | See Section 2.23. | |
5583 | ||
5584 | NAT_DETECTION_DESTINATION_IP 16389 | |
5585 | See Section 2.23. | |
5586 | ||
5587 | COOKIE 16390 | |
5588 | See Section 2.6. | |
5589 | ||
5590 | USE_TRANSPORT_MODE 16391 | |
5591 | See Section 1.3.1. | |
5592 | ||
5593 | HTTP_CERT_LOOKUP_SUPPORTED 16392 | |
5594 | See Section 3.6. | |
5595 | ||
5596 | REKEY_SA 16393 | |
5597 | See Section 1.3.3. | |
5598 | ||
a6d7a610 | 5599 | |
a6d7a610 | 5600 | |
a6d7a610 | 5601 | |
824a0402 AS |
5602 | Kaufman, et al. Standards Track [Page 100] |
5603 | \f | |
5604 | RFC 5996 IKEv2bis September 2010 | |
a6d7a610 MW |
5605 | |
5606 | ||
824a0402 AS |
5607 | ESP_TFC_PADDING_NOT_SUPPORTED 16394 |
5608 | See Section 1.3.1. | |
a6d7a610 | 5609 | |
824a0402 AS |
5610 | NON_FIRST_FRAGMENTS_ALSO 16395 |
5611 | See Section 1.3.1. | |
a6d7a610 | 5612 | |
824a0402 | 5613 | 3.11. Delete Payload |
a6d7a610 | 5614 | |
824a0402 AS |
5615 | The Delete payload, denoted D in this document, contains a protocol- |
5616 | specific Security Association identifier that the sender has removed | |
5617 | from its Security Association database and is, therefore, no longer | |
5618 | valid. Figure 17 shows the format of the Delete payload. It is | |
a6d7a610 MW |
5619 | possible to send multiple SPIs in a Delete payload; however, each SPI |
5620 | MUST be for the same protocol. Mixing of protocol identifiers MUST | |
5621 | NOT be performed in the Delete payload. It is permitted, however, to | |
5622 | include multiple Delete payloads in a single INFORMATIONAL exchange | |
5623 | where each Delete payload lists SPIs for a different protocol. | |
5624 | ||
5625 | Deletion of the IKE SA is indicated by a protocol ID of 1 (IKE) but | |
5626 | no SPIs. Deletion of a Child SA, such as ESP or AH, will contain the | |
5627 | IPsec protocol ID of that protocol (2 for AH, 3 for ESP), and the SPI | |
5628 | is the SPI the sending endpoint would expect in inbound ESP or AH | |
5629 | packets. | |
5630 | ||
824a0402 | 5631 | The Delete payload is defined as follows: |
a6d7a610 MW |
5632 | |
5633 | 1 2 3 | |
5634 | 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 | |
5635 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5636 | | Next Payload |C| RESERVED | Payload Length | | |
5637 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
824a0402 | 5638 | | Protocol ID | SPI Size | Num of SPIs | |
a6d7a610 MW |
5639 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
5640 | | | | |
5641 | ~ Security Parameter Index(es) (SPI) ~ | |
5642 | | | | |
5643 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5644 | ||
5645 | Figure 17: Delete Payload Format | |
5646 | ||
5647 | o Protocol ID (1 octet) - Must be 1 for an IKE SA, 2 for AH, or 3 | |
5648 | for ESP. | |
5649 | ||
5650 | o SPI Size (1 octet) - Length in octets of the SPI as defined by the | |
5651 | protocol ID. It MUST be zero for IKE (SPI is in message header) | |
5652 | or four for AH and ESP. | |
5653 | ||
a6d7a610 MW |
5654 | |
5655 | ||
5656 | ||
5657 | ||
824a0402 AS |
5658 | Kaufman, et al. Standards Track [Page 101] |
5659 | \f | |
5660 | RFC 5996 IKEv2bis September 2010 | |
a6d7a610 MW |
5661 | |
5662 | ||
824a0402 AS |
5663 | o Num of SPIs (2 octets, unsigned integer) - The number of SPIs |
5664 | contained in the Delete payload. The size of each SPI is defined | |
5665 | by the SPI Size field. | |
a6d7a610 | 5666 | |
824a0402 AS |
5667 | o Security Parameter Index(es) (variable length) - Identifies the |
5668 | specific Security Association(s) to delete. The length of this | |
5669 | field is determined by the SPI Size and Num of SPIs fields. | |
a6d7a610 | 5670 | |
824a0402 | 5671 | The payload type for the Delete payload is forty-two (42). |
a6d7a610 MW |
5672 | |
5673 | 3.12. Vendor ID Payload | |
5674 | ||
824a0402 | 5675 | The Vendor ID payload, denoted V in this document, contains a vendor- |
a6d7a610 MW |
5676 | defined constant. The constant is used by vendors to identify and |
5677 | recognize remote instances of their implementations. This mechanism | |
5678 | allows a vendor to experiment with new features while maintaining | |
5679 | backward compatibility. | |
5680 | ||
5681 | A Vendor ID payload MAY announce that the sender is capable of | |
5682 | accepting certain extensions to the protocol, or it MAY simply | |
5683 | identify the implementation as an aid in debugging. A Vendor ID | |
5684 | payload MUST NOT change the interpretation of any information defined | |
5685 | in this specification (i.e., the critical bit MUST be set to 0). | |
824a0402 AS |
5686 | Multiple Vendor ID payloads MAY be sent. An implementation is not |
5687 | required to send any Vendor ID payload at all. | |
a6d7a610 MW |
5688 | |
5689 | A Vendor ID payload may be sent as part of any message. Reception of | |
5690 | a familiar Vendor ID payload allows an implementation to make use of | |
824a0402 AS |
5691 | private use numbers described throughout this document, such as |
5692 | private payloads, private exchanges, private notifications, etc. | |
5693 | Unfamiliar Vendor IDs MUST be ignored. | |
5694 | ||
5695 | Writers of documents who wish to extend this protocol MUST define a | |
5696 | Vendor ID payload to announce the ability to implement the extension | |
5697 | in the document. It is expected that documents that gain acceptance | |
5698 | and are standardized will be given "magic numbers" out of the Future | |
5699 | Use range by IANA, and the requirement to use a Vendor ID will go | |
5700 | away. | |
5701 | ||
5702 | The Vendor ID payload fields are defined as follows: | |
5703 | ||
5704 | ||
5705 | ||
5706 | ||
5707 | ||
5708 | ||
5709 | ||
5710 | ||
5711 | ||
a6d7a610 | 5712 | |
a6d7a610 | 5713 | |
824a0402 AS |
5714 | Kaufman, et al. Standards Track [Page 102] |
5715 | \f | |
5716 | RFC 5996 IKEv2bis September 2010 | |
5717 | ||
a6d7a610 MW |
5718 | |
5719 | 1 2 3 | |
5720 | 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 | |
5721 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5722 | | Next Payload |C| RESERVED | Payload Length | | |
5723 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5724 | | | | |
5725 | ~ Vendor ID (VID) ~ | |
5726 | | | | |
5727 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5728 | ||
5729 | Figure 18: Vendor ID Payload Format | |
5730 | ||
5731 | o Vendor ID (variable length) - It is the responsibility of the | |
5732 | person choosing the Vendor ID to assure its uniqueness in spite of | |
5733 | the absence of any central registry for IDs. Good practice is to | |
824a0402 AS |
5734 | include a company name, a person name, or some such information. |
5735 | If you want to show off, you might include the latitude and | |
5736 | longitude and time where you were when you chose the ID and some | |
5737 | random input. A message digest of a long unique string is | |
5738 | preferable to the long unique string itself. | |
a6d7a610 | 5739 | |
824a0402 | 5740 | The payload type for the Vendor ID payload is forty-three (43). |
a6d7a610 MW |
5741 | |
5742 | 3.13. Traffic Selector Payload | |
5743 | ||
824a0402 AS |
5744 | The Traffic Selector payload, denoted TS in this document, allows |
5745 | peers to identify packet flows for processing by IPsec security | |
5746 | services. The Traffic Selector payload consists of the IKE generic | |
5747 | payload header followed by individual Traffic Selectors as follows: | |
a6d7a610 MW |
5748 | |
5749 | 1 2 3 | |
5750 | 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 | |
5751 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5752 | | Next Payload |C| RESERVED | Payload Length | | |
5753 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5754 | | Number of TSs | RESERVED | | |
5755 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5756 | | | | |
5757 | ~ <Traffic Selectors> ~ | |
5758 | | | | |
5759 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5760 | ||
5761 | Figure 19: Traffic Selectors Payload Format | |
5762 | ||
824a0402 | 5763 | o Number of TSs (1 octet) - Number of Traffic Selectors being |
a6d7a610 MW |
5764 | provided. |
5765 | ||
824a0402 AS |
5766 | |
5767 | ||
5768 | ||
5769 | ||
5770 | Kaufman, et al. Standards Track [Page 103] | |
5771 | \f | |
5772 | RFC 5996 IKEv2bis September 2010 | |
5773 | ||
5774 | ||
a6d7a610 MW |
5775 | o RESERVED - This field MUST be sent as zero and MUST be ignored on |
5776 | receipt. | |
5777 | ||
5778 | o Traffic Selectors (variable length) - One or more individual | |
824a0402 | 5779 | Traffic Selectors. |
a6d7a610 MW |
5780 | |
5781 | The length of the Traffic Selector payload includes the TS header and | |
824a0402 | 5782 | all the Traffic Selectors. |
a6d7a610 | 5783 | |
824a0402 AS |
5784 | The payload type for the Traffic Selector payload is forty-four (44) |
5785 | for addresses at the initiator's end of the SA and forty-five (45) | |
a6d7a610 MW |
5786 | for addresses at the responder's end. |
5787 | ||
2eac2578 | 5788 | There is no requirement that TSi and TSr contain the same number of |
824a0402 | 5789 | individual Traffic Selectors. Thus, they are interpreted as follows: |
2eac2578 MW |
5790 | a packet matches a given TSi/TSr if it matches at least one of the |
5791 | individual selectors in TSi, and at least one of the individual | |
5792 | selectors in TSr. | |
a6d7a610 | 5793 | |
824a0402 | 5794 | For instance, the following Traffic Selectors: |
a6d7a610 | 5795 | |
824a0402 AS |
5796 | TSi = ((17, 100, 198.51.100.66-198.51.100.66), |
5797 | (17, 200, 198.51.100.66-198.51.100.66)) | |
a6d7a610 MW |
5798 | TSr = ((17, 300, 0.0.0.0-255.255.255.255), |
5799 | (17, 400, 0.0.0.0-255.255.255.255)) | |
5800 | ||
824a0402 AS |
5801 | would match UDP packets from 198.51.100.66 to anywhere, with any of |
5802 | the four combinations of source/destination ports (100,300), | |
5803 | (100,400), (200,300), and (200, 400). | |
a6d7a610 MW |
5804 | |
5805 | Thus, some types of policies may require several Child SA pairs. For | |
5806 | instance, a policy matching only source/destination ports (100,300) | |
5807 | and (200,400), but not the other two combinations, cannot be | |
5808 | negotiated as a single Child SA pair. | |
5809 | ||
824a0402 AS |
5810 | |
5811 | ||
5812 | ||
5813 | ||
5814 | ||
5815 | ||
5816 | ||
5817 | ||
5818 | ||
5819 | ||
5820 | ||
5821 | ||
5822 | ||
5823 | ||
5824 | ||
5825 | ||
5826 | Kaufman, et al. Standards Track [Page 104] | |
5827 | \f | |
5828 | RFC 5996 IKEv2bis September 2010 | |
5829 | ||
5830 | ||
a6d7a610 MW |
5831 | 3.13.1. Traffic Selector |
5832 | ||
5833 | 1 2 3 | |
5834 | 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 | |
5835 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5836 | | TS Type |IP Protocol ID*| Selector Length | | |
5837 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5838 | | Start Port* | End Port* | | |
5839 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5840 | | | | |
5841 | ~ Starting Address* ~ | |
5842 | | | | |
5843 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5844 | | | | |
5845 | ~ Ending Address* ~ | |
5846 | | | | |
5847 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5848 | ||
5849 | Figure 20: Traffic Selector | |
5850 | ||
5851 | *Note: All fields other than TS Type and Selector Length depend on | |
5852 | the TS Type. The fields shown are for TS Types 7 and 8, the only two | |
5853 | values currently defined. | |
5854 | ||
824a0402 | 5855 | o TS Type (one octet) - Specifies the type of Traffic Selector. |
a6d7a610 MW |
5856 | |
5857 | o IP protocol ID (1 octet) - Value specifying an associated IP | |
824a0402 AS |
5858 | protocol ID (such as UDP, TCP, and ICMP). A value of zero means |
5859 | that the protocol ID is not relevant to this Traffic Selector -- | |
5860 | the SA can carry all protocols. | |
5861 | ||
5862 | o Selector Length - Specifies the length of this Traffic Selector | |
5863 | substructure including the header. | |
a6d7a610 | 5864 | |
824a0402 AS |
5865 | o Start Port (2 octets, unsigned integer) - Value specifying the |
5866 | smallest port number allowed by this Traffic Selector. For | |
5867 | protocols for which port is undefined (including protocol 0), or | |
5868 | if all ports are allowed, this field MUST be zero. ICMP and | |
5869 | ICMPv6 Type and Code values, as well as Mobile IP version 6 | |
5870 | (MIPv6) mobility header (MH) Type values, are represented in this | |
5871 | field as specified in Section 4.4.1.1 of [IPSECARCH]. ICMP Type | |
5872 | and Code values are treated as a single 16-bit integer port | |
5873 | number, with Type in the most significant eight bits and Code in | |
5874 | the least significant eight bits. MIPv6 MH Type values are | |
5875 | treated as a single 16-bit integer port number, with Type in the | |
5876 | most significant eight bits and the least significant eight bits | |
5877 | set to zero. | |
a6d7a610 MW |
5878 | |
5879 | ||
5880 | ||
5881 | ||
824a0402 | 5882 | Kaufman, et al. Standards Track [Page 105] |
a6d7a610 | 5883 | \f |
824a0402 | 5884 | RFC 5996 IKEv2bis September 2010 |
a6d7a610 MW |
5885 | |
5886 | ||
824a0402 AS |
5887 | o End Port (2 octets, unsigned integer) - Value specifying the |
5888 | largest port number allowed by this Traffic Selector. For | |
5889 | protocols for which port is undefined (including protocol 0), or | |
5890 | if all ports are allowed, this field MUST be 65535. ICMP and | |
5891 | ICMPv6 Type and Code values, as well as MIPv6 MH Type values, are | |
5892 | represented in this field as specified in Section 4.4.1.1 of | |
5893 | [IPSECARCH]. ICMP Type and Code values are treated as a single | |
5894 | 16-bit integer port number, with Type in the most significant | |
5895 | eight bits and Code in the least significant eight bits. MIPv6 MH | |
5896 | Type values are treated as a single 16-bit integer port number, | |
5897 | with Type in the most significant eight bits and the least | |
5898 | significant eight bits set to zero. | |
a6d7a610 MW |
5899 | |
5900 | o Starting Address - The smallest address included in this Traffic | |
824a0402 | 5901 | Selector (length determined by TS Type). |
a6d7a610 MW |
5902 | |
5903 | o Ending Address - The largest address included in this Traffic | |
824a0402 | 5904 | Selector (length determined by TS Type). |
a6d7a610 MW |
5905 | |
5906 | Systems that are complying with [IPSECARCH] that wish to indicate | |
5907 | "ANY" ports MUST set the start port to 0 and the end port to 65535; | |
5908 | note that according to [IPSECARCH], "ANY" includes "OPAQUE". Systems | |
5909 | working with [IPSECARCH] that wish to indicate "OPAQUE" ports, but | |
5910 | not "ANY" ports, MUST set the start port to 65535 and the end port to | |
5911 | 0. | |
5912 | ||
824a0402 AS |
5913 | The Traffic Selector types 7 and 8 can also refer to ICMP or ICMPv6 |
5914 | type and code fields, as well as MH Type fields for the IPv6 mobility | |
5915 | header [MIPV6]. Note, however, that neither ICMP nor MIPv6 packets | |
5916 | have separate source and destination fields. The method for | |
5917 | specifying the Traffic Selectors for ICMP and MIPv6 is shown by | |
5918 | example in Section 4.4.1.3 of [IPSECARCH]. | |
a6d7a610 | 5919 | |
824a0402 AS |
5920 | The following table lists values for the Traffic Selector Type field |
5921 | and the corresponding Address Selector Data. The values in the | |
5922 | following table are only current as of the publication date of RFC | |
5923 | 4306. Other values may have been added since then or will be added | |
5924 | after the publication of this document. Readers should refer to | |
5925 | [IKEV2IANA] for the latest values. | |
a6d7a610 | 5926 | |
824a0402 AS |
5927 | TS Type Value |
5928 | ------------------------------------------------------------------- | |
5929 | TS_IPV4_ADDR_RANGE 7 | |
a6d7a610 MW |
5930 | |
5931 | ||
a6d7a610 MW |
5932 | |
5933 | ||
a6d7a610 | 5934 | |
a6d7a610 | 5935 | |
824a0402 AS |
5936 | |
5937 | ||
5938 | Kaufman, et al. Standards Track [Page 106] | |
5939 | \f | |
5940 | RFC 5996 IKEv2bis September 2010 | |
5941 | ||
a6d7a610 MW |
5942 | |
5943 | A range of IPv4 addresses, represented by two four-octet | |
824a0402 | 5944 | values. The first value is the beginning IPv4 address |
a6d7a610 | 5945 | (inclusive) and the second value is the ending IPv4 address |
824a0402 | 5946 | (inclusive). All addresses falling between the two specified |
a6d7a610 MW |
5947 | addresses are considered to be within the list. |
5948 | ||
5949 | TS_IPV6_ADDR_RANGE 8 | |
5950 | ||
5951 | A range of IPv6 addresses, represented by two sixteen-octet | |
824a0402 | 5952 | values. The first value is the beginning IPv6 address |
a6d7a610 | 5953 | (inclusive) and the second value is the ending IPv6 address |
824a0402 | 5954 | (inclusive). All addresses falling between the two specified |
a6d7a610 MW |
5955 | addresses are considered to be within the list. |
5956 | ||
a6d7a610 MW |
5957 | 3.14. Encrypted Payload |
5958 | ||
824a0402 AS |
5959 | The Encrypted payload, denoted SK{...} in this document, contains |
5960 | other payloads in encrypted form. The Encrypted payload, if present | |
a6d7a610 | 5961 | in a message, MUST be the last payload in the message. Often, it is |
824a0402 AS |
5962 | the only payload in the message. This payload is also called the |
5963 | "Encrypted and Authenticated" payload. | |
a6d7a610 MW |
5964 | |
5965 | The algorithms for encryption and integrity protection are negotiated | |
5966 | during IKE SA setup, and the keys are computed as specified in | |
824a0402 | 5967 | Sections 2.14 and 2.18. |
a6d7a610 MW |
5968 | |
5969 | This document specifies the cryptographic processing of Encrypted | |
5970 | payloads using a block cipher in CBC mode and an integrity check | |
5971 | algorithm that computes a fixed-length checksum over a variable size | |
5972 | message. The design is modeled after the ESP algorithms described in | |
5973 | RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC]. This document | |
5974 | completely specifies the cryptographic processing of IKE data, but | |
5975 | those documents should be consulted for design rationale. Future | |
5976 | documents may specify the processing of Encrypted payloads for other | |
5977 | types of transforms, such as counter mode encryption and | |
5978 | authenticated encryption algorithms. Peers MUST NOT negotiate | |
5979 | transforms for which no such specification exists. | |
5980 | ||
824a0402 AS |
5981 | When an authenticated encryption algorithm is used to protect the IKE |
5982 | SA, the construction of the Encrypted payload is different than what | |
5983 | is described here. See [AEAD] for more information on authenticated | |
5984 | encryption algorithms and their use in ESP. | |
a6d7a610 | 5985 | |
824a0402 AS |
5986 | The payload type for an Encrypted payload is forty-six (46). The |
5987 | Encrypted payload consists of the IKE generic payload header followed | |
5988 | by individual fields as follows: | |
a6d7a610 | 5989 | |
a6d7a610 MW |
5990 | |
5991 | ||
824a0402 AS |
5992 | |
5993 | ||
5994 | Kaufman, et al. Standards Track [Page 107] | |
5995 | \f | |
5996 | RFC 5996 IKEv2bis September 2010 | |
5997 | ||
a6d7a610 MW |
5998 | |
5999 | 1 2 3 | |
6000 | 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 | |
6001 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
6002 | | Next Payload |C| RESERVED | Payload Length | | |
6003 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
6004 | | Initialization Vector | | |
6005 | | (length is block size for encryption algorithm) | | |
6006 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
6007 | ~ Encrypted IKE Payloads ~ | |
6008 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
6009 | | | Padding (0-255 octets) | | |
6010 | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | |
6011 | | | Pad Length | | |
6012 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
6013 | ~ Integrity Checksum Data ~ | |
6014 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
6015 | ||
6016 | Figure 21: Encrypted Payload Format | |
6017 | ||
6018 | o Next Payload - The payload type of the first embedded payload. | |
6019 | Note that this is an exception in the standard header format, | |
6020 | since the Encrypted payload is the last payload in the message and | |
6021 | therefore the Next Payload field would normally be zero. But | |
6022 | because the content of this payload is embedded payloads and there | |
6023 | was no natural place to put the type of the first one, that type | |
6024 | is placed here. | |
6025 | ||
824a0402 AS |
6026 | o Payload Length - Includes the lengths of the header, |
6027 | initialization vector (IV), Encrypted IKE payloads, Padding, Pad | |
6028 | Length, and Integrity Checksum Data. | |
a6d7a610 MW |
6029 | |
6030 | o Initialization Vector - For CBC mode ciphers, the length of the | |
6031 | initialization vector (IV) is equal to the block length of the | |
6032 | underlying encryption algorithm. Senders MUST select a new | |
6033 | unpredictable IV for every message; recipients MUST accept any | |
82f0707f | 6034 | value. The reader is encouraged to consult [MODES] for advice on |
a6d7a610 | 6035 | IV generation. In particular, using the final ciphertext block of |
82f0707f MW |
6036 | the previous message is not considered unpredictable. For modes |
6037 | other than CBC, the IV format and processing is specified in the | |
6038 | document specifying the encryption algorithm and mode. | |
a6d7a610 | 6039 | |
824a0402 | 6040 | o IKE payloads are as specified earlier in this section. This field |
a6d7a610 MW |
6041 | is encrypted with the negotiated cipher. |
6042 | ||
824a0402 AS |
6043 | o Padding MAY contain any value chosen by the sender, and MUST have |
6044 | a length that makes the combination of the payloads, the Padding, | |
6045 | and the Pad Length to be a multiple of the encryption block size. | |
6046 | This field is encrypted with the negotiated cipher. | |
a6d7a610 MW |
6047 | |
6048 | ||
6049 | ||
824a0402 | 6050 | Kaufman, et al. Standards Track [Page 108] |
a6d7a610 | 6051 | \f |
824a0402 | 6052 | RFC 5996 IKEv2bis September 2010 |
a6d7a610 | 6053 | |
a6d7a610 MW |
6054 | |
6055 | o Pad Length is the length of the Padding field. The sender SHOULD | |
6056 | set the Pad Length to the minimum value that makes the combination | |
824a0402 | 6057 | of the payloads, the Padding, and the Pad Length a multiple of the |
a6d7a610 MW |
6058 | block size, but the recipient MUST accept any length that results |
6059 | in proper alignment. This field is encrypted with the negotiated | |
6060 | cipher. | |
6061 | ||
6062 | o Integrity Checksum Data is the cryptographic checksum of the | |
824a0402 | 6063 | entire message starting with the Fixed IKE header through the Pad |
a6d7a610 MW |
6064 | Length. The checksum MUST be computed over the encrypted message. |
6065 | Its length is determined by the integrity algorithm negotiated. | |
6066 | ||
6067 | 3.15. Configuration Payload | |
6068 | ||
6069 | The Configuration payload, denoted CP in this document, is used to | |
6070 | exchange configuration information between IKE peers. The exchange | |
6071 | is for an IRAC to request an internal IP address from an IRAS and to | |
6072 | exchange other information of the sort that one would acquire with | |
6073 | Dynamic Host Configuration Protocol (DHCP) if the IRAC were directly | |
6074 | connected to a LAN. | |
6075 | ||
824a0402 | 6076 | The Configuration payload is defined as follows: |
a6d7a610 MW |
6077 | |
6078 | 1 2 3 | |
6079 | 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 | |
6080 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
6081 | | Next Payload |C| RESERVED | Payload Length | | |
6082 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
6083 | | CFG Type | RESERVED | | |
6084 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
6085 | | | | |
6086 | ~ Configuration Attributes ~ | |
6087 | | | | |
6088 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
6089 | ||
6090 | Figure 22: Configuration Payload Format | |
6091 | ||
824a0402 | 6092 | The payload type for the Configuration payload is forty-seven (47). |
a6d7a610 MW |
6093 | |
6094 | o CFG Type (1 octet) - The type of exchange represented by the | |
824a0402 AS |
6095 | Configuration Attributes. The values in the following table are |
6096 | only current as of the publication date of RFC 4306. Other values | |
6097 | may have been added since then or will be added after the | |
6098 | publication of this document. Readers should refer to [IKEV2IANA] | |
6099 | for the latest values. | |
6100 | ||
a6d7a610 MW |
6101 | |
6102 | ||
6103 | ||
6104 | ||
6105 | ||
824a0402 | 6106 | Kaufman, et al. Standards Track [Page 109] |
a6d7a610 | 6107 | \f |
824a0402 | 6108 | RFC 5996 IKEv2bis September 2010 |
a6d7a610 MW |
6109 | |
6110 | ||
6111 | CFG Type Value | |
6112 | -------------------------- | |
a6d7a610 MW |
6113 | CFG_REQUEST 1 |
6114 | CFG_REPLY 2 | |
6115 | CFG_SET 3 | |
6116 | CFG_ACK 4 | |
a6d7a610 MW |
6117 | |
6118 | o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on | |
6119 | receipt. | |
6120 | ||
6121 | o Configuration Attributes (variable length) - These are type length | |
824a0402 AS |
6122 | value (TLV) structures specific to the Configuration payload and |
6123 | are defined below. There may be zero or more Configuration | |
6124 | Attributes in this payload. | |
a6d7a610 MW |
6125 | |
6126 | 3.15.1. Configuration Attributes | |
6127 | ||
6128 | 1 2 3 | |
6129 | 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 | |
6130 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
6131 | |R| Attribute Type | Length | | |
6132 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
6133 | | | | |
6134 | ~ Value ~ | |
6135 | | | | |
6136 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
6137 | ||
6138 | Figure 23: Configuration Attribute Format | |
6139 | ||
6140 | o Reserved (1 bit) - This bit MUST be set to zero and MUST be | |
6141 | ignored on receipt. | |
6142 | ||
6143 | o Attribute Type (15 bits) - A unique identifier for each of the | |
6144 | Configuration Attribute Types. | |
6145 | ||
824a0402 | 6146 | o Length (2 octets, unsigned integer) - Length in octets of value. |
a6d7a610 MW |
6147 | |
6148 | o Value (0 or more octets) - The variable-length value of this | |
824a0402 | 6149 | Configuration Attribute. The following lists the attribute types. |
a6d7a610 | 6150 | |
824a0402 AS |
6151 | The values in the following table are only current as of the |
6152 | publication date of RFC 4306 (except INTERNAL_ADDRESS_EXPIRY and | |
6153 | INTERNAL_IP6_NBNS which were removed by this document). Other values | |
6154 | may have been added since then or will be added after the publication | |
6155 | of this document. Readers should refer to [IKEV2IANA] for the latest | |
6156 | values. | |
a6d7a610 MW |
6157 | |
6158 | ||
6159 | ||
6160 | ||
6161 | ||
824a0402 | 6162 | Kaufman, et al. Standards Track [Page 110] |
a6d7a610 | 6163 | \f |
824a0402 | 6164 | RFC 5996 IKEv2bis September 2010 |
a6d7a610 MW |
6165 | |
6166 | ||
824a0402 AS |
6167 | Attribute Type Value Multi-Valued Length |
6168 | ------------------------------------------------------------ | |
6169 | INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets | |
6170 | INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets | |
6171 | INTERNAL_IP4_DNS 3 YES 0 or 4 octets | |
6172 | INTERNAL_IP4_NBNS 4 YES 0 or 4 octets | |
6173 | INTERNAL_IP4_DHCP 6 YES 0 or 4 octets | |
6174 | APPLICATION_VERSION 7 NO 0 or more | |
6175 | INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets | |
6176 | INTERNAL_IP6_DNS 10 YES 0 or 16 octets | |
6177 | INTERNAL_IP6_DHCP 12 YES 0 or 16 octets | |
6178 | INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets | |
6179 | SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 | |
6180 | INTERNAL_IP6_SUBNET 15 YES 17 octets | |
a6d7a610 MW |
6181 | |
6182 | * These attributes may be multi-valued on return only if | |
6183 | multiple values were requested. | |
6184 | ||
6185 | o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the | |
6186 | internal network, sometimes called a red node address or private | |
824a0402 | 6187 | address, and it MAY be a private address on the Internet. In a |
2eac2578 MW |
6188 | request message, the address specified is a requested address (or |
6189 | a zero-length address if no specific address is requested). If a | |
6190 | specific address is requested, it likely indicates that a previous | |
6191 | connection existed with this address and the requestor would like | |
6192 | to reuse that address. With IPv6, a requestor MAY supply the low- | |
6193 | order address octets it wants to use. Multiple internal addresses | |
6194 | MAY be requested by requesting multiple internal address | |
6195 | attributes. The responder MAY only send up to the number of | |
6196 | addresses requested. The INTERNAL_IP6_ADDRESS is made up of two | |
6197 | fields: the first is a 16-octet IPv6 address, and the second is a | |
6198 | one-octet prefix-length as defined in [ADDRIPV6]. The requested | |
6199 | address is valid as long as this IKE SA (or its rekeyed | |
6200 | successors) requesting the address is valid. This is described in | |
6201 | more detail in Section 3.15.3. | |
a6d7a610 MW |
6202 | |
6203 | o INTERNAL_IP4_NETMASK - The internal network's netmask. Only one | |
824a0402 | 6204 | netmask is allowed in the request and response messages (e.g., |
a6d7a610 | 6205 | 255.255.255.0), and it MUST be used only with an |
2eac2578 MW |
6206 | INTERNAL_IP4_ADDRESS attribute. INTERNAL_IP4_NETMASK in a |
6207 | CFG_REPLY means roughly the same thing as INTERNAL_IP4_SUBNET | |
824a0402 AS |
6208 | containing the same information ("send traffic to these addresses |
6209 | through me"), but also implies a link boundary. For instance, the | |
6210 | client could use its own address and the netmask to calculate the | |
6211 | broadcast address of the link. An empty INTERNAL_IP4_NETMASK | |
6212 | attribute can be included in a CFG_REQUEST to request this | |
6213 | ||
6214 | ||
a6d7a610 MW |
6215 | |
6216 | ||
6217 | ||
824a0402 | 6218 | Kaufman, et al. Standards Track [Page 111] |
a6d7a610 | 6219 | \f |
824a0402 | 6220 | RFC 5996 IKEv2bis September 2010 |
a6d7a610 MW |
6221 | |
6222 | ||
2eac2578 MW |
6223 | information (although the gateway can send the information even |
6224 | when not requested). Non-empty values for this attribute in a | |
6225 | CFG_REQUEST do not make sense and thus MUST NOT be included. | |
a6d7a610 MW |
6226 | |
6227 | o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a DNS | |
6228 | server within the network. Multiple DNS servers MAY be requested. | |
6229 | The responder MAY respond with zero or more DNS server attributes. | |
6230 | ||
6231 | o INTERNAL_IP4_NBNS - Specifies an address of a NetBios Name Server | |
6232 | (WINS) within the network. Multiple NBNS servers MAY be | |
6233 | requested. The responder MAY respond with zero or more NBNS | |
6234 | server attributes. | |
6235 | ||
a6d7a610 MW |
6236 | o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send |
6237 | any internal DHCP requests to the address contained within the | |
6238 | attribute. Multiple DHCP servers MAY be requested. The responder | |
6239 | MAY respond with zero or more DHCP server attributes. | |
6240 | ||
6241 | o APPLICATION_VERSION - The version or application information of | |
6242 | the IPsec host. This is a string of printable ASCII characters | |
6243 | that is NOT null terminated. | |
6244 | ||
6245 | o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge- | |
6246 | device protects. This attribute is made up of two fields: the | |
6247 | first being an IP address and the second being a netmask. | |
6248 | Multiple sub-networks MAY be requested. The responder MAY respond | |
6249 | with zero or more sub-network attributes. This is discussed in | |
6250 | more detail in Section 3.15.2. | |
6251 | ||
6252 | o SUPPORTED_ATTRIBUTES - When used within a Request, this attribute | |
6253 | MUST be zero-length and specifies a query to the responder to | |
6254 | reply back with all of the attributes that it supports. The | |
6255 | response contains an attribute that contains a set of attribute | |
6256 | identifiers each in 2 octets. The length divided by 2 (octets) | |
6257 | would state the number of supported attributes contained in the | |
6258 | response. | |
6259 | ||
a6d7a610 MW |
6260 | o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge- |
6261 | device protects. This attribute is made up of two fields: the | |
6262 | first is a 16-octet IPv6 address, and the second is a one-octet | |
6263 | prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY | |
6264 | be requested. The responder MAY respond with zero or more sub- | |
824a0402 AS |
6265 | network attributes. This is discussed in more detail in |
6266 | Section 3.15.2. | |
6267 | ||
6268 | ||
2eac2578 MW |
6269 | |
6270 | ||
6271 | ||
2eac2578 MW |
6272 | |
6273 | ||
824a0402 AS |
6274 | Kaufman, et al. Standards Track [Page 112] |
6275 | \f | |
6276 | RFC 5996 IKEv2bis September 2010 | |
6277 | ||
a6d7a610 MW |
6278 | |
6279 | Note that no recommendations are made in this document as to how an | |
6280 | implementation actually figures out what information to send in a | |
824a0402 AS |
6281 | response. That is, we do not recommend any specific method of an |
6282 | IRAS determining which DNS server should be returned to a requesting | |
6283 | IRAC. | |
6284 | ||
6285 | The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request | |
6286 | information from its peer. If an attribute in the CFG_REQUEST | |
6287 | Configuration payload is not zero-length, it is taken as a suggestion | |
6288 | for that attribute. The CFG_REPLY Configuration payload MAY return | |
6289 | that value, or a new one. It MAY also add new attributes and not | |
6290 | include some requested ones. Unrecognized or unsupported attributes | |
6291 | MUST be ignored in both requests and responses. | |
6292 | ||
6293 | The CFG_SET and CFG_ACK pair allows an IKE endpoint to push | |
6294 | configuration data to its peer. In this case, the CFG_SET | |
6295 | Configuration payload contains attributes the initiator wants its | |
6296 | peer to alter. The responder MUST return a Configuration payload if | |
6297 | it accepted any of the configuration data and it MUST contain the | |
6298 | attributes that the responder accepted with zero-length data. Those | |
6299 | attributes that it did not accept MUST NOT be in the CFG_ACK | |
6300 | Configuration payload. If no attributes were accepted, the responder | |
6301 | MUST return either an empty CFG_ACK payload or a response message | |
6302 | without a CFG_ACK payload. There are currently no defined uses for | |
6303 | the CFG_SET/CFG_ACK exchange, though they may be used in connection | |
6304 | with extensions based on Vendor IDs. An implementation of this | |
6305 | specification MAY ignore CFG_SET payloads. | |
6306 | ||
6307 | 3.15.2. Meaning of INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET | |
a6d7a610 | 6308 | |
a6d7a610 MW |
6309 | INTERNAL_IP4/6_SUBNET attributes can indicate additional subnets, |
6310 | ones that need one or more separate SAs, that can be reached through | |
6311 | the gateway that announces the attributes. INTERNAL_IP4/6_SUBNET | |
6312 | attributes may also express the gateway's policy about what traffic | |
6313 | should be sent through the gateway; the client can choose whether | |
6314 | other traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is | |
6315 | sent through the gateway or directly to the destination. Thus, | |
6316 | traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET | |
6317 | attributes should be sent through the gateway that announces the | |
824a0402 AS |
6318 | attributes. If there are no existing Child SAs whose Traffic |
6319 | Selectors cover the address in question, new SAs need to be created. | |
6320 | ||
6321 | ||
6322 | ||
6323 | ||
6324 | ||
a6d7a610 | 6325 | |
824a0402 AS |
6326 | |
6327 | ||
6328 | ||
6329 | ||
6330 | Kaufman, et al. Standards Track [Page 113] | |
6331 | \f | |
6332 | RFC 5996 IKEv2bis September 2010 | |
6333 | ||
6334 | ||
6335 | For instance, if there are two subnets, 198.51.100.0/26 and | |
a6d7a610 MW |
6336 | 192.0.2.0/24, and the client's request contains the following: |
6337 | ||
6338 | CP(CFG_REQUEST) = | |
6339 | INTERNAL_IP4_ADDRESS() | |
6340 | TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) | |
6341 | TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) | |
6342 | ||
6343 | then a valid response could be the following (in which TSr and | |
6344 | INTERNAL_IP4_SUBNET contain the same information): | |
6345 | ||
6346 | CP(CFG_REPLY) = | |
824a0402 AS |
6347 | INTERNAL_IP4_ADDRESS(198.51.100.234) |
6348 | INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192) | |
a6d7a610 | 6349 | INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) |
824a0402 AS |
6350 | TSi = (0, 0-65535, 198.51.100.234-198.51.100.234) |
6351 | TSr = ((0, 0-65535, 198.51.100.0-198.51.100.63), | |
a6d7a610 MW |
6352 | (0, 0-65535, 192.0.2.0-192.0.2.255)) |
6353 | ||
2eac2578 MW |
6354 | In these cases, the INTERNAL_IP4_SUBNET does not really carry any |
6355 | useful information. | |
a6d7a610 | 6356 | |
824a0402 | 6357 | A different possible response would have been this: |
a6d7a610 MW |
6358 | |
6359 | CP(CFG_REPLY) = | |
824a0402 AS |
6360 | INTERNAL_IP4_ADDRESS(198.51.100.234) |
6361 | INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192) | |
a6d7a610 | 6362 | INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) |
824a0402 | 6363 | TSi = (0, 0-65535, 198.51.100.234-198.51.100.234) |
a6d7a610 MW |
6364 | TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) |
6365 | ||
824a0402 | 6366 | That response would mean that the client can send all its traffic |
a6d7a610 MW |
6367 | through the gateway, but the gateway does not mind if the client |
6368 | sends traffic not included by INTERNAL_IP4_SUBNET directly to the | |
6369 | destination (without going through the gateway). | |
6370 | ||
6371 | A different situation arises if the gateway has a policy that | |
6372 | requires the traffic for the two subnets to be carried in separate | |
6373 | SAs. Then a response like this would indicate to the client that if | |
6374 | it wants access to the second subnet, it needs to create a separate | |
6375 | SA: | |
6376 | ||
6377 | CP(CFG_REPLY) = | |
824a0402 AS |
6378 | INTERNAL_IP4_ADDRESS(198.51.100.234) |
6379 | INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192) | |
a6d7a610 | 6380 | INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) |
824a0402 AS |
6381 | TSi = (0, 0-65535, 198.51.100.234-198.51.100.234) |
6382 | TSr = (0, 0-65535, 198.51.100.0-198.51.100.63) | |
6383 | ||
6384 | ||
6385 | ||
6386 | Kaufman, et al. Standards Track [Page 114] | |
6387 | \f | |
6388 | RFC 5996 IKEv2bis September 2010 | |
6389 | ||
a6d7a610 MW |
6390 | |
6391 | INTERNAL_IP4_SUBNET can also be useful if the client's TSr included | |
6392 | only part of the address space. For instance, if the client requests | |
6393 | the following: | |
6394 | ||
6395 | CP(CFG_REQUEST) = | |
6396 | INTERNAL_IP4_ADDRESS() | |
6397 | TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) | |
6398 | TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) | |
6399 | ||
824a0402 | 6400 | then the gateway's response might be: |
a6d7a610 MW |
6401 | |
6402 | CP(CFG_REPLY) = | |
824a0402 AS |
6403 | INTERNAL_IP4_ADDRESS(198.51.100.234) |
6404 | INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192) | |
a6d7a610 | 6405 | INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) |
824a0402 | 6406 | TSi = (0, 0-65535, 198.51.100.234-198.51.100.234) |
a6d7a610 MW |
6407 | TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) |
6408 | ||
824a0402 | 6409 | Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET in |
2eac2578 MW |
6410 | CFG_REQUESTs is unclear, they cannot be used reliably in |
6411 | CFG_REQUESTs. | |
6412 | ||
824a0402 | 6413 | 3.15.3. Configuration Payloads for IPv6 |
a6d7a610 | 6414 | |
824a0402 | 6415 | The Configuration payloads for IPv6 are based on the corresponding |
a6d7a610 MW |
6416 | IPv4 payloads, and do not fully follow the "normal IPv6 way of doing |
6417 | things". In particular, IPv6 stateless autoconfiguration or router | |
824a0402 AS |
6418 | advertisement messages are not used, neither is neighbor discovery. |
6419 | Note that there is an additional document that discusses IPv6 | |
6420 | configuration in IKEv2, [IPV6CONFIG]. At the present time, it is an | |
6421 | experimental document, but there is a hope that with more | |
6422 | implementation experience, it will gain the same standards treatment | |
6423 | as this document. | |
a6d7a610 MW |
6424 | |
6425 | A client can be assigned an IPv6 address using the | |
824a0402 | 6426 | INTERNAL_IP6_ADDRESS Configuration payload. A minimal exchange might |
a6d7a610 MW |
6427 | look like this: |
6428 | ||
6429 | CP(CFG_REQUEST) = | |
6430 | INTERNAL_IP6_ADDRESS() | |
6431 | INTERNAL_IP6_DNS() | |
6432 | TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) | |
6433 | TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) | |
6434 | ||
824a0402 AS |
6435 | |
6436 | ||
6437 | ||
6438 | ||
6439 | ||
6440 | ||
6441 | ||
6442 | Kaufman, et al. Standards Track [Page 115] | |
6443 | \f | |
6444 | RFC 5996 IKEv2bis September 2010 | |
6445 | ||
6446 | ||
a6d7a610 MW |
6447 | CP(CFG_REPLY) = |
6448 | INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) | |
6449 | INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44) | |
6450 | TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5) | |
6451 | TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) | |
6452 | ||
6453 | The client MAY send a non-empty INTERNAL_IP6_ADDRESS attribute in the | |
6454 | CFG_REQUEST to request a specific address or interface identifier. | |
6455 | The gateway first checks if the specified address is acceptable, and | |
6456 | if it is, returns that one. If the address was not acceptable, the | |
6457 | gateway attempts to use the interface identifier with some other | |
6458 | prefix; if even that fails, the gateway selects another interface | |
6459 | identifier. | |
6460 | ||
6461 | The INTERNAL_IP6_ADDRESS attribute also contains a prefix length | |
6462 | field. When used in a CFG_REPLY, this corresponds to the | |
6463 | INTERNAL_IP4_NETMASK attribute in the IPv4 case. | |
6464 | ||
6465 | Although this approach to configuring IPv6 addresses is reasonably | |
6466 | simple, it has some limitations. IPsec tunnels configured using | |
824a0402 AS |
6467 | IKEv2 are not fully featured "interfaces" in the IPv6 addressing |
6468 | architecture sense [ADDRIPV6]. In particular, they do not | |
a6d7a610 MW |
6469 | necessarily have link-local addresses, and this may complicate the |
6470 | use of protocols that assume them, such as [MLDV2]. | |
6471 | ||
a6d7a610 MW |
6472 | 3.15.4. Address Assignment Failures |
6473 | ||
a6d7a610 MW |
6474 | If the responder encounters an error while attempting to assign an IP |
6475 | address to the initiator during the processing of a Configuration | |
824a0402 | 6476 | payload, it responds with an INTERNAL_ADDRESS_FAILURE notification. |
a6d7a610 | 6477 | The IKE SA is still created even if the initial Child SA cannot be |
2eac2578 MW |
6478 | created because of this failure. If this error is generated within |
6479 | an IKE_AUTH exchange, no Child SA will be created. However, there | |
6480 | are some more complex error cases. | |
a6d7a610 | 6481 | |
824a0402 AS |
6482 | If the responder does not support Configuration payloads at all, it |
6483 | can simply ignore all Configuration payloads. This type of | |
a6d7a610 MW |
6484 | implementation never sends INTERNAL_ADDRESS_FAILURE notifications. |
6485 | If the initiator requires the assignment of an IP address, it will | |
6486 | treat a response without CFG_REPLY as an error. | |
6487 | ||
6488 | The initiator may request a particular type of address (IPv4 or IPv6) | |
6489 | that the responder does not support, even though the responder | |
824a0402 | 6490 | supports Configuration payloads. In this case, the responder simply |
a6d7a610 MW |
6491 | ignores the type of address it does not support and processes the |
6492 | rest of the request as usual. | |
6493 | ||
824a0402 AS |
6494 | |
6495 | ||
6496 | ||
6497 | ||
6498 | Kaufman, et al. Standards Track [Page 116] | |
6499 | \f | |
6500 | RFC 5996 IKEv2bis September 2010 | |
6501 | ||
6502 | ||
a6d7a610 MW |
6503 | If the initiator requests multiple addresses of a type that the |
6504 | responder supports, and some (but not all) of the requests fail, the | |
6505 | responder replies with the successful addresses only. The responder | |
6506 | sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned. | |
6507 | ||
824a0402 AS |
6508 | If the initiator does not receive the IP address(es) required by its |
6509 | policy, it MAY keep the IKE SA up and retry the Configuration payload | |
6510 | as separate INFORMATIONAL exchange after suitable timeout, or it MAY | |
6511 | tear down the IKE SA by sending a Delete payload inside a separate | |
6512 | INFORMATIONAL exchange and later retry IKE SA from the beginning | |
6513 | after some timeout. Such a timeout should not be too short | |
6514 | (especially if the IKE SA is started from the beginning) because | |
6515 | these error situations may not be able to be fixed quickly; the | |
6516 | timeout should likely be several minutes. For example, an address | |
6517 | shortage problem on the responder will probably only be fixed when | |
6518 | more entries are returned to the address pool when other clients | |
6519 | disconnect or when responder is reconfigured with larger address | |
6520 | pool. | |
6521 | ||
a6d7a610 MW |
6522 | 3.16. Extensible Authentication Protocol (EAP) Payload |
6523 | ||
824a0402 AS |
6524 | The Extensible Authentication Protocol payload, denoted EAP in this |
6525 | document, allows IKE SAs to be authenticated using the protocol | |
6526 | defined in RFC 3748 [EAP] and subsequent extensions to that protocol. | |
6527 | When using EAP, an appropriate EAP method needs to be selected. Many | |
6528 | of these methods have been defined, specifying the protocol's use | |
6529 | with various authentication mechanisms. EAP method types are listed | |
6530 | in [EAP-IANA]. A short summary of the EAP format is included here | |
6531 | for clarity. | |
a6d7a610 MW |
6532 | |
6533 | 1 2 3 | |
6534 | 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 | |
6535 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
6536 | | Next Payload |C| RESERVED | Payload Length | | |
6537 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
6538 | | | | |
6539 | ~ EAP Message ~ | |
6540 | | | | |
6541 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
6542 | ||
2eac2578 MW |
6543 | Figure 24: EAP Payload Format |
6544 | ||
824a0402 | 6545 | The payload type for an EAP payload is forty-eight (48). |
2eac2578 | 6546 | |
a6d7a610 MW |
6547 | |
6548 | ||
6549 | ||
a6d7a610 MW |
6550 | |
6551 | ||
a6d7a610 | 6552 | |
2eac2578 | 6553 | |
824a0402 | 6554 | Kaufman, et al. Standards Track [Page 117] |
2eac2578 | 6555 | \f |
824a0402 | 6556 | RFC 5996 IKEv2bis September 2010 |
2eac2578 | 6557 | |
a6d7a610 MW |
6558 | |
6559 | 1 2 3 | |
6560 | 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 | |
6561 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
6562 | | Code | Identifier | Length | | |
6563 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
6564 | | Type | Type_Data... | |
6565 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | |
6566 | ||
6567 | Figure 25: EAP Message Format | |
6568 | ||
6569 | o Code (1 octet) indicates whether this message is a Request (1), | |
6570 | Response (2), Success (3), or Failure (4). | |
6571 | ||
6572 | o Identifier (1 octet) is used in PPP to distinguish replayed | |
6573 | messages from repeated ones. Since in IKE, EAP runs over a | |
6574 | reliable protocol, it serves no function here. In a response | |
6575 | message, this octet MUST be set to match the identifier in the | |
824a0402 | 6576 | corresponding request. |
a6d7a610 | 6577 | |
824a0402 AS |
6578 | o Length (2 octets, unsigned integer) is the length of the EAP |
6579 | message and MUST be four less than the Payload Length of the | |
6580 | encapsulating payload. | |
a6d7a610 MW |
6581 | |
6582 | o Type (1 octet) is present only if the Code field is Request (1) or | |
6583 | Response (2). For other codes, the EAP message length MUST be | |
6584 | four octets and the Type and Type_Data fields MUST NOT be present. | |
6585 | In a Request (1) message, Type indicates the data being requested. | |
6586 | In a Response (2) message, Type MUST either be Nak or match the | |
824a0402 AS |
6587 | type of the data requested. Note that since IKE passes an |
6588 | indication of initiator identity in the first message in the | |
6589 | IKE_AUTH exchange, the responder SHOULD NOT send EAP Identity | |
6590 | requests (type 1). The initiator MAY, however, respond to such | |
6591 | requests if it receives them. | |
a6d7a610 MW |
6592 | |
6593 | o Type_Data (Variable Length) varies with the Type of Request and | |
6594 | the associated Response. For the documentation of the EAP | |
6595 | methods, see [EAP]. | |
6596 | ||
824a0402 AS |
6597 | Note that since IKE passes an indication of initiator identity in the |
6598 | first message in the IKE_AUTH exchange, the responder should not send | |
6599 | EAP Identity requests. The initiator may, however, respond to such | |
6600 | requests if it receives them. | |
a6d7a610 | 6601 | |
824a0402 | 6602 | 4. Conformance Requirements |
a6d7a610 | 6603 | |
824a0402 AS |
6604 | In order to assure that all implementations of IKEv2 can |
6605 | interoperate, there are "MUST support" requirements in addition to | |
6606 | those listed elsewhere. Of course, IKEv2 is a security protocol, and | |
a6d7a610 | 6607 | |
a6d7a610 MW |
6608 | |
6609 | ||
824a0402 | 6610 | Kaufman, et al. Standards Track [Page 118] |
2eac2578 | 6611 | \f |
824a0402 | 6612 | RFC 5996 IKEv2bis September 2010 |
a6d7a610 | 6613 | |
a6d7a610 | 6614 | |
a6d7a610 MW |
6615 | one of its major functions is to allow only authorized parties to |
6616 | successfully complete establishment of SAs. So a particular | |
6617 | implementation may be configured with any of a number of restrictions | |
6618 | concerning algorithms and trusted authorities that will prevent | |
6619 | universal interoperability. | |
6620 | ||
6621 | IKEv2 is designed to permit minimal implementations that can | |
824a0402 AS |
6622 | interoperate with all compliant implementations. The following are |
6623 | features that can be omitted in a minimal implementation: | |
a6d7a610 MW |
6624 | |
6625 | o Ability to negotiate SAs through a NAT and tunnel the resulting | |
6626 | ESP SA over UDP. | |
6627 | ||
6628 | o Ability to request (and respond to a request for) a temporary IP | |
6629 | address on the remote end of a tunnel. | |
6630 | ||
824a0402 | 6631 | o Ability to support EAP-based authentication. |
a6d7a610 MW |
6632 | |
6633 | o Ability to support window sizes greater than one. | |
6634 | ||
6635 | o Ability to establish multiple ESP or AH SAs within a single IKE | |
6636 | SA. | |
6637 | ||
6638 | o Ability to rekey SAs. | |
6639 | ||
6640 | To assure interoperability, all implementations MUST be capable of | |
6641 | parsing all payload types (if only to skip over them) and to ignore | |
6642 | payload types that it does not support unless the critical bit is set | |
6643 | in the payload header. If the critical bit is set in an unsupported | |
6644 | payload header, all implementations MUST reject the messages | |
6645 | containing those payloads. | |
6646 | ||
6647 | Every implementation MUST be capable of doing four-message | |
6648 | IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, | |
6649 | one for ESP or AH). Implementations MAY be initiate-only or respond- | |
6650 | only if appropriate for their platform. Every implementation MUST be | |
6651 | capable of responding to an INFORMATIONAL exchange, but a minimal | |
824a0402 AS |
6652 | implementation MAY respond to any request in the INFORMATIONAL |
6653 | exchange with an empty response (note that within the context of an | |
6654 | IKE SA, an "empty" message consists of an IKE header followed by an | |
6655 | Encrypted payload with no payloads contained in it). A minimal | |
6656 | implementation MAY support the CREATE_CHILD_SA exchange only in so | |
6657 | far as to recognize requests and reject them with a Notify payload of | |
6658 | type NO_ADDITIONAL_SAS. A minimal implementation need not be able to | |
6659 | initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA | |
6660 | expires (based on locally configured values of either lifetime or | |
6661 | octets passed), and implementation MAY either try to renew it with a | |
6662 | CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and | |
a6d7a610 MW |
6663 | |
6664 | ||
6665 | ||
824a0402 | 6666 | Kaufman, et al. Standards Track [Page 119] |
a6d7a610 | 6667 | \f |
824a0402 | 6668 | RFC 5996 IKEv2bis September 2010 |
a6d7a610 MW |
6669 | |
6670 | ||
a6d7a610 MW |
6671 | create a new one. If the responder rejects the CREATE_CHILD_SA |
6672 | request with a NO_ADDITIONAL_SAS notification, the implementation | |
6673 | MUST be capable of instead deleting the old SA and creating a new | |
6674 | one. | |
6675 | ||
6676 | Implementations are not required to support requesting temporary IP | |
6677 | addresses or responding to such requests. If an implementation does | |
824a0402 AS |
6678 | support issuing such requests and its policy requires using temporary |
6679 | IP addresses, it MUST include a CP payload in the first message in | |
6680 | the IKE_AUTH exchange containing at least a field of type | |
6681 | INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. All other fields are | |
6682 | optional. If an implementation supports responding to such requests, | |
6683 | it MUST parse the CP payload of type CFG_REQUEST in the first message | |
6684 | in the IKE_AUTH exchange and recognize a field of type | |
6685 | INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports leasing | |
6686 | an address of the appropriate type, it MUST return a CP payload of | |
6687 | type CFG_REPLY containing an address of the requested type. The | |
6688 | responder may include any other related attributes. | |
a6d7a610 MW |
6689 | |
6690 | For an implementation to be called conforming to this specification, | |
6691 | it MUST be possible to configure it to accept the following: | |
6692 | ||
824a0402 AS |
6693 | o Public Key Infrastructure using X.509 (PKIX) Certificates |
6694 | containing and signed by RSA keys of size 1024 or 2048 bits, where | |
6695 | the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or | |
6696 | ID_DER_ASN1_DN. | |
a6d7a610 MW |
6697 | |
6698 | o Shared key authentication where the ID passed is any of ID_KEY_ID, | |
6699 | ID_FQDN, or ID_RFC822_ADDR. | |
6700 | ||
2eac2578 MW |
6701 | o Authentication where the responder is authenticated using PKIX |
6702 | Certificates and the initiator is authenticated using shared key | |
6703 | authentication. | |
a6d7a610 | 6704 | |
a6d7a610 MW |
6705 | 5. Security Considerations |
6706 | ||
6707 | While this protocol is designed to minimize disclosure of | |
6708 | configuration information to unauthenticated peers, some such | |
6709 | disclosure is unavoidable. One peer or the other must identify | |
6710 | itself first and prove its identity first. To avoid probing, the | |
6711 | initiator of an exchange is required to identify itself first, and | |
6712 | usually is required to authenticate itself first. The initiator can, | |
6713 | however, learn that the responder supports IKE and what cryptographic | |
6714 | protocols it supports. The responder (or someone impersonating the | |
6715 | responder) can probe the initiator not only for its identity, but | |
6716 | using CERTREQ payloads may be able to determine what certificates the | |
6717 | initiator is willing to use. | |
6718 | ||
824a0402 AS |
6719 | |
6720 | ||
6721 | ||
6722 | Kaufman, et al. Standards Track [Page 120] | |
6723 | \f | |
6724 | RFC 5996 IKEv2bis September 2010 | |
6725 | ||
6726 | ||
a6d7a610 MW |
6727 | Use of EAP authentication changes the probing possibilities somewhat. |
6728 | When EAP authentication is used, the responder proves its identity | |
6729 | before the initiator does, so an initiator that knew the name of a | |
6730 | valid initiator could probe the responder for both its name and | |
6731 | certificates. | |
6732 | ||
6733 | Repeated rekeying using CREATE_CHILD_SA without additional Diffie- | |
6734 | Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a | |
824a0402 AS |
6735 | single key. Implementers should take note of this fact and set a |
6736 | limit on CREATE_CHILD_SA exchanges between exponentiations. This | |
6737 | document does not prescribe such a limit. | |
a6d7a610 MW |
6738 | |
6739 | The strength of a key derived from a Diffie-Hellman exchange using | |
6740 | any of the groups defined here depends on the inherent strength of | |
6741 | the group, the size of the exponent used, and the entropy provided by | |
6742 | the random number generator used. Due to these inputs, it is | |
6743 | difficult to determine the strength of a key for any of the defined | |
6744 | groups. Diffie-Hellman group number two, when used with a strong | |
6745 | random number generator and an exponent no less than 200 bits, is | |
6746 | common for use with 3DES. Group five provides greater security than | |
6747 | group two. Group one is for historic purposes only and does not | |
6748 | provide sufficient strength except for use with DES, which is also | |
6749 | for historic use only. Implementations should make note of these | |
6750 | estimates when establishing policy and negotiating security | |
6751 | parameters. | |
6752 | ||
6753 | Note that these limitations are on the Diffie-Hellman groups | |
6754 | themselves. There is nothing in IKE that prohibits using stronger | |
6755 | groups nor is there anything that will dilute the strength obtained | |
a6d7a610 | 6756 | from stronger groups (limited by the strength of the other algorithms |
824a0402 AS |
6757 | negotiated including the PRF). In fact, the extensible framework of |
6758 | IKE encourages the definition of more groups; use of elliptic curve | |
6759 | groups may greatly increase strength using much smaller numbers. | |
2eac2578 | 6760 | |
a6d7a610 MW |
6761 | It is assumed that all Diffie-Hellman exponents are erased from |
6762 | memory after use. | |
6763 | ||
82f0707f MW |
6764 | The IKE_SA_INIT and IKE_AUTH exchanges happen before the initiator |
6765 | has been authenticated. As a result, an implementation of this | |
6766 | protocol needs to be completely robust when deployed on any insecure | |
824a0402 AS |
6767 | network. Implementation vulnerabilities, particularly DoS attacks, |
6768 | can be exploited by unauthenticated peers. This issue is | |
6769 | particularly worrisome because of the unlimited number of messages in | |
6770 | EAP-based authentication. | |
82f0707f | 6771 | |
a6d7a610 | 6772 | The strength of all keys is limited by the size of the output of the |
824a0402 AS |
6773 | negotiated PRF. For this reason, a PRF whose output is less than 128 |
6774 | bits (e.g., 3DES-CBC) MUST NOT be used with this protocol. | |
6775 | ||
6776 | ||
6777 | ||
6778 | Kaufman, et al. Standards Track [Page 121] | |
6779 | \f | |
6780 | RFC 5996 IKEv2bis September 2010 | |
6781 | ||
a6d7a610 MW |
6782 | |
6783 | The security of this protocol is critically dependent on the | |
6784 | randomness of the randomly chosen parameters. These should be | |
824a0402 | 6785 | generated by a strong random or properly seeded pseudorandom source |
a6d7a610 MW |
6786 | (see [RANDOMNESS]). Implementers should take care to ensure that use |
6787 | of random numbers for both keys and nonces is engineered in a fashion | |
6788 | that does not undermine the security of the keys. | |
6789 | ||
6790 | For information on the rationale of many of the cryptographic design | |
6791 | choices in this protocol, see [SIGMA] and [SKEME]. Though the | |
6792 | security of negotiated Child SAs does not depend on the strength of | |
6793 | the encryption and integrity protection negotiated in the IKE SA, | |
6794 | implementations MUST NOT negotiate NONE as the IKE integrity | |
6795 | protection algorithm or ENCR_NULL as the IKE encryption algorithm. | |
6796 | ||
6797 | When using pre-shared keys, a critical consideration is how to assure | |
6798 | the randomness of these secrets. The strongest practice is to ensure | |
6799 | that any pre-shared key contain as much randomness as the strongest | |
6800 | key being negotiated. Deriving a shared secret from a password, | |
6801 | name, or other low-entropy source is not secure. These sources are | |
824a0402 | 6802 | subject to dictionary and social-engineering attacks, among others. |
a6d7a610 MW |
6803 | |
6804 | The NAT_DETECTION_*_IP notifications contain a hash of the addresses | |
6805 | and ports in an attempt to hide internal IP addresses behind a NAT. | |
6806 | Since the IPv4 address space is only 32 bits, and it is usually very | |
6807 | sparse, it would be possible for an attacker to find out the internal | |
6808 | address used behind the NAT box by trying all possible IP addresses | |
6809 | and trying to find the matching hash. The port numbers are normally | |
6810 | fixed to 500, and the SPIs can be extracted from the packet. This | |
6811 | reduces the number of hash calculations to 2^32. With an educated | |
6812 | guess of the use of private address space, the number of hash | |
6813 | calculations is much smaller. Designers should therefore not assume | |
6814 | that use of IKE will not leak internal address information. | |
6815 | ||
6816 | When using an EAP authentication method that does not generate a | |
a6d7a610 | 6817 | shared key for protecting a subsequent AUTH payload, certain man-in- |
824a0402 | 6818 | the-middle and server-impersonation attacks are possible [EAPMITM]. |
a6d7a610 MW |
6819 | These vulnerabilities occur when EAP is also used in protocols that |
6820 | are not protected with a secure tunnel. Since EAP is a general- | |
6821 | purpose authentication protocol, which is often used to provide | |
6822 | single-signon facilities, a deployed IPsec solution that relies on an | |
6823 | EAP authentication method that does not generate a shared key (also | |
6824 | known as a non-key-generating EAP method) can become compromised due | |
6825 | to the deployment of an entirely unrelated application that also | |
6826 | happens to use the same non-key-generating EAP method, but in an | |
6827 | unprotected fashion. Note that this vulnerability is not limited to | |
6828 | just EAP, but can occur in other scenarios where an authentication | |
6829 | infrastructure is reused. For example, if the EAP mechanism used by | |
6830 | IKEv2 utilizes a token authenticator, a man-in-the-middle attacker | |
824a0402 AS |
6831 | |
6832 | ||
6833 | ||
6834 | Kaufman, et al. Standards Track [Page 122] | |
6835 | \f | |
6836 | RFC 5996 IKEv2bis September 2010 | |
6837 | ||
6838 | ||
a6d7a610 MW |
6839 | could impersonate the web server, intercept the token authentication |
6840 | exchange, and use it to initiate an IKEv2 connection. For this | |
6841 | reason, use of non-key-generating EAP methods SHOULD be avoided where | |
6842 | possible. Where they are used, it is extremely important that all | |
6843 | usages of these EAP methods SHOULD utilize a protected tunnel, where | |
6844 | the initiator validates the responder's certificate before initiating | |
2eac2578 MW |
6845 | the EAP authentication. Implementers should describe the |
6846 | vulnerabilities of using non-key-generating EAP methods in the | |
6847 | documentation of their implementations so that the administrators | |
6848 | deploying IPsec solutions are aware of these dangers. | |
a6d7a610 | 6849 | |
824a0402 AS |
6850 | An implementation using EAP MUST also use a public-key-based |
6851 | authentication of the server to the client before the EAP | |
6852 | authentication begins, even if the EAP method offers mutual | |
6853 | authentication. This avoids having additional IKEv2 protocol | |
6854 | variations and protects the EAP data from active attackers. | |
a6d7a610 MW |
6855 | |
6856 | If the messages of IKEv2 are long enough that IP-level fragmentation | |
6857 | is necessary, it is possible that attackers could prevent the | |
6858 | exchange from completing by exhausting the reassembly buffers. The | |
6859 | chances of this can be minimized by using the Hash and URL encodings | |
6860 | instead of sending certificates (see Section 3.6). Additional | |
6861 | mitigations are discussed in [DOSUDPPROT]. | |
6862 | ||
82f0707f MW |
6863 | Admission control is critical to the security of the protocol. For |
6864 | example, trust anchors used for identifying IKE peers should probably | |
82f0707f MW |
6865 | be different than those used for other forms of trust, such as those |
6866 | used to identify public web servers. Moreover, although IKE provides | |
6867 | a great deal of leeway in defining the security policy for a trusted | |
6868 | peer's identity, credentials, and the correlation between them, | |
6869 | having such security policy defined explicitly is essential to a | |
6870 | secure implementation. | |
6871 | ||
824a0402 | 6872 | 5.1. Traffic Selector Authorization |
a6d7a610 | 6873 | |
824a0402 AS |
6874 | IKEv2 relies on information in the Peer Authorization Database (PAD) |
6875 | when determining what kind of Child SAs a peer is allowed to create. | |
6876 | This process is described in Section 4.4.3 of [IPSECARCH]. When a | |
6877 | peer requests the creation of an Child SA with some Traffic | |
6878 | Selectors, the PAD must contain "Child SA Authorization Data" linking | |
6879 | the identity authenticated by IKEv2 and the addresses permitted for | |
6880 | Traffic Selectors. | |
2eac2578 | 6881 | |
824a0402 AS |
6882 | For example, the PAD might be configured so that authenticated |
6883 | identity "sgw23.example.com" is allowed to create Child SAs for | |
6884 | 192.0.2.0/24, meaning this security gateway is a valid | |
6885 | "representative" for these addresses. Host-to-host IPsec requires | |
2eac2578 | 6886 | |
2eac2578 MW |
6887 | |
6888 | ||
a6d7a610 | 6889 | |
824a0402 AS |
6890 | Kaufman, et al. Standards Track [Page 123] |
6891 | \f | |
6892 | RFC 5996 IKEv2bis September 2010 | |
6893 | ||
a6d7a610 | 6894 | |
a6d7a610 | 6895 | similar entries, linking, for example, "fooserver4.example.com" with |
824a0402 | 6896 | 198.51.100.66/32, meaning this identity is a valid "owner" or |
a6d7a610 MW |
6897 | "representative" of the address in question. |
6898 | ||
6899 | As noted in [IPSECARCH], "It is necessary to impose these constraints | |
6900 | on creation of child SAs to prevent an authenticated peer from | |
824a0402 | 6901 | spoofing IDs associated with other, legitimate peers". In the |
a6d7a610 | 6902 | example given above, a correct configuration of the PAD prevents |
824a0402 AS |
6903 | sgw23 from creating Child SAs with address 198.51.100.66, and |
6904 | prevents fooserver4 from creating Child SAs with addresses from | |
6905 | 192.0.2.0/24. | |
a6d7a610 MW |
6906 | |
6907 | It is important to note that simply sending IKEv2 packets using some | |
824a0402 AS |
6908 | particular address does not imply a permission to create Child SAs |
6909 | with that address in the Traffic Selectors. For example, even if | |
6910 | sgw23 would be able to spoof its IP address as 198.51.100.66, it | |
6911 | could not create Child SAs matching fooserver4's traffic. | |
a6d7a610 MW |
6912 | |
6913 | The IKEv2 specification does not specify how exactly IP address | |
824a0402 | 6914 | assignment using Configuration payloads interacts with the PAD. Our |
a6d7a610 | 6915 | interpretation is that when a security gateway assigns an address |
824a0402 | 6916 | using Configuration payloads, it also creates a temporary PAD entry |
a6d7a610 MW |
6917 | linking the authenticated peer identity and the newly allocated inner |
6918 | address. | |
6919 | ||
6920 | It has been recognized that configuring the PAD correctly may be | |
6921 | difficult in some environments. For instance, if IPsec is used | |
6922 | between a pair of hosts whose addresses are allocated dynamically | |
6923 | using DHCP, it is extremely difficult to ensure that the PAD | |
6924 | specifies the correct "owner" for each IP address. This would | |
6925 | require a mechanism to securely convey address assignments from the | |
6926 | DHCP server, and link them to identities authenticated using IKEv2. | |
6927 | ||
6928 | Due to this limitation, some vendors have been known to configure | |
824a0402 AS |
6929 | their PADs to allow an authenticated peer to create Child SAs with |
6930 | Traffic Selectors containing the same address that was used for the | |
6931 | IKEv2 packets. In environments where IP spoofing is possible (i.e., | |
6932 | almost everywhere) this essentially allows any peer to create Child | |
6933 | SAs with any Traffic Selectors. This is not an appropriate or secure | |
6934 | configuration in most circumstances. See [H2HIPSEC] for an extensive | |
6935 | discussion about this issue, and the limitations of host-to-host | |
6936 | IPsec in general. | |
6937 | ||
6938 | 6. IANA Considerations | |
6939 | ||
6940 | [IKEV2] defined many field types and values. IANA has already | |
6941 | registered those types and values in [IKEV2IANA], so they are not | |
6942 | listed here again. | |
2eac2578 MW |
6943 | |
6944 | ||
6945 | ||
824a0402 | 6946 | Kaufman, et al. Standards Track [Page 124] |
2eac2578 | 6947 | \f |
824a0402 | 6948 | RFC 5996 IKEv2bis September 2010 |
2eac2578 MW |
6949 | |
6950 | ||
824a0402 AS |
6951 | Two items have been removed from the IKEv2 Configuration Payload |
6952 | Attribute Types table: INTERNAL_IP6_NBNS and INTERNAL_ADDRESS_EXPIRY. | |
a6d7a610 | 6953 | |
824a0402 AS |
6954 | Two new additions to the IKEv2 parameters "NOTIFY MESSAGES - ERROR |
6955 | TYPES" registry are defined here that were not defined in [IKEV2]: | |
a6d7a610 | 6956 | |
824a0402 AS |
6957 | 43 TEMPORARY_FAILURE |
6958 | 44 CHILD_SA_NOT_FOUND | |
a6d7a610 | 6959 | |
824a0402 AS |
6960 | IANA has changed the existing IKEv2 Payload Types table from: |
6961 | ||
6962 | 46 Encrypted E [IKEV2] | |
6963 | ||
6964 | to | |
6965 | ||
6966 | 46 Encrypted and Authenticated SK [This document] | |
a6d7a610 | 6967 | |
824a0402 AS |
6968 | IANA has updated all references to RFC 4306 to point to this |
6969 | document. | |
a6d7a610 MW |
6970 | |
6971 | 7. Acknowledgements | |
6972 | ||
824a0402 AS |
6973 | Many individuals in the IPsecME Working Group were very helpful in |
6974 | contributing ideas and text for this document, as well as in | |
6975 | reviewing the clarifications suggested by others. | |
a6d7a610 MW |
6976 | |
6977 | The acknowledgements from the IKEv2 document were: | |
6978 | ||
6979 | This document is a collaborative effort of the entire IPsec WG. If | |
6980 | there were no limit to the number of authors that could appear on an | |
6981 | RFC, the following, in alphabetical order, would have been listed: | |
6982 | Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt | |
6983 | Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John | |
6984 | Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero | |
6985 | Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer | |
6986 | Reingold, and Michael Richardson. Many other people contributed to | |
6987 | the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI, | |
6988 | each of which has its own list of authors. Hugh Daniel suggested the | |
6989 | feature of having the initiator, in message 3, specify a name for the | |
6990 | responder, and gave the feature the cute name "You Tarzan, Me Jane". | |
824a0402 AS |
6991 | David Faucher and Valery Smyslov helped refine the design of the |
6992 | Traffic Selector negotiation. | |
6993 | ||
a6d7a610 | 6994 | |
a6d7a610 MW |
6995 | |
6996 | ||
2eac2578 MW |
6997 | |
6998 | ||
6999 | ||
824a0402 AS |
7000 | |
7001 | ||
7002 | Kaufman, et al. Standards Track [Page 125] | |
2eac2578 | 7003 | \f |
824a0402 | 7004 | RFC 5996 IKEv2bis September 2010 |
2eac2578 MW |
7005 | |
7006 | ||
a6d7a610 MW |
7007 | 8. References |
7008 | ||
7009 | 8.1. Normative References | |
7010 | ||
824a0402 | 7011 | [ADDGROUP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) |
a6d7a610 MW |
7012 | Diffie-Hellman groups for Internet Key Exchange (IKE)", |
7013 | RFC 3526, May 2003. | |
7014 | ||
824a0402 AS |
7015 | [ADDRIPV6] Hinden, R. and S. Deering, "IP Version 6 Addressing |
7016 | Architecture", RFC 4291, February 2006. | |
7017 | ||
7018 | [AEAD] Black, D. and D. McGrew, "Using Authenticated Encryption | |
7019 | Algorithms with the Encrypted Payload of the Internet Key | |
7020 | Exchange version 2 (IKEv2) Protocol", RFC 5282, | |
7021 | August 2008. | |
7022 | ||
7023 | [AESCMACPRF128] | |
7024 | Song, J., Poovendran, R., Lee, J., and T. Iwata, "The | |
7025 | Advanced Encryption Standard-Cipher-based Message | |
7026 | Authentication Code-Pseudo-Random Function-128 (AES-CMAC- | |
7027 | PRF-128) Algorithm for the Internet Key Exchange Protocol | |
7028 | (IKE)", RFC 4615, August 2006. | |
7029 | ||
7030 | [AESXCBCPRF128] | |
7031 | Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the | |
7032 | Internet Key Exchange Protocol (IKE)", RFC 4434, | |
7033 | February 2006. | |
a6d7a610 MW |
7034 | |
7035 | [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. | |
7036 | Levkowetz, "Extensible Authentication Protocol (EAP)", | |
7037 | RFC 3748, June 2004. | |
7038 | ||
7039 | [ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition | |
7040 | of Explicit Congestion Notification (ECN) to IP", | |
7041 | RFC 3168, September 2001. | |
7042 | ||
7043 | [ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher | |
7044 | Algorithms", RFC 2451, November 1998. | |
7045 | ||
824a0402 AS |
7046 | [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., |
7047 | Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext | |
7048 | Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. | |
7049 | ||
7050 | [IKEV2IANA] | |
7051 | "Internet Key Exchange Version 2 (IKEv2) Parameters", | |
7052 | <http://www.iana.org>. | |
7053 | ||
7054 | ||
7055 | ||
7056 | ||
7057 | ||
7058 | Kaufman, et al. Standards Track [Page 126] | |
7059 | \f | |
7060 | RFC 5996 IKEv2bis September 2010 | |
7061 | ||
7062 | ||
a6d7a610 MW |
7063 | [IPSECARCH] |
7064 | Kent, S. and K. Seo, "Security Architecture for the | |
7065 | Internet Protocol", RFC 4301, December 2005. | |
7066 | ||
7067 | [MUSTSHOULD] | |
824a0402 | 7068 | Bradner, S., "Key words for use in RFCs to Indicate |
a6d7a610 MW |
7069 | Requirement Levels", BCP 14, RFC 2119, March 1997. |
7070 | ||
7071 | [PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography | |
7072 | Standards (PKCS) #1: RSA Cryptography Specifications | |
7073 | Version 2.1", RFC 3447, February 2003. | |
7074 | ||
824a0402 AS |
7075 | [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., |
7076 | Housley, R., and W. Polk, "Internet X.509 Public Key | |
7077 | Infrastructure Certificate and Certificate Revocation List | |
7078 | (CRL) Profile", RFC 5280, May 2008. | |
2eac2578 | 7079 | |
824a0402 AS |
7080 | [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the |
7081 | Internet Key Exchange Version 2 (IKEv2)", RFC 4307, | |
7082 | December 2005. | |
a6d7a610 MW |
7083 | |
7084 | [UDPENCAPS] | |
7085 | Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. | |
7086 | Stenberg, "UDP Encapsulation of IPsec ESP Packets", | |
a6d7a610 MW |
7087 | RFC 3948, January 2005. |
7088 | ||
824a0402 AS |
7089 | [URLS] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform |
7090 | Resource Identifier (URI): Generic Syntax", STD 66, | |
7091 | RFC 3986, January 2005. | |
a6d7a610 | 7092 | |
824a0402 | 7093 | 8.2. Informative References |
a6d7a610 MW |
7094 | |
7095 | [AH] Kent, S., "IP Authentication Header", RFC 4302, | |
7096 | December 2005. | |
7097 | ||
7098 | [ARCHGUIDEPHIL] | |
7099 | Bush, R. and D. Meyer, "Some Internet Architectural | |
7100 | Guidelines and Philosophy", RFC 3439, December 2002. | |
7101 | ||
7102 | [ARCHPRINC] | |
7103 | Carpenter, B., "Architectural Principles of the Internet", | |
7104 | RFC 1958, June 1996. | |
7105 | ||
7106 | [Clarif] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and | |
7107 | Implementation Guidelines", RFC 4718, October 2006. | |
7108 | ||
824a0402 AS |
7109 | |
7110 | ||
7111 | ||
7112 | ||
7113 | ||
7114 | Kaufman, et al. Standards Track [Page 127] | |
7115 | \f | |
7116 | RFC 5996 IKEv2bis September 2010 | |
7117 | ||
7118 | ||
a6d7a610 MW |
7119 | [DES] American National Standards Institute, "American National |
7120 | Standard for Information Systems-Data Link Encryption", | |
7121 | ANSI X3.106, 1983. | |
7122 | ||
7123 | [DH] Diffie, W. and M. Hellman, "New Directions in | |
7124 | Cryptography", IEEE Transactions on Information Theory, | |
7125 | V.IT-22 n. 6, June 1977. | |
7126 | ||
a6d7a610 MW |
7127 | [DIFFSERVARCH] |
7128 | Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., | |
7129 | and W. Weiss, "An Architecture for Differentiated | |
824a0402 | 7130 | Services", RFC 2475, December 1998. |
a6d7a610 MW |
7131 | |
7132 | [DIFFSERVFIELD] | |
7133 | Nichols, K., Blake, S., Baker, F., and D. Black, | |
7134 | "Definition of the Differentiated Services Field (DS | |
7135 | Field) in the IPv4 and IPv6 Headers", RFC 2474, | |
7136 | December 1998. | |
7137 | ||
7138 | [DIFFTUNNEL] | |
7139 | Black, D., "Differentiated Services and Tunnels", | |
7140 | RFC 2983, October 2000. | |
7141 | ||
7142 | [DOI] Piper, D., "The Internet IP Security Domain of | |
a6d7a610 MW |
7143 | Interpretation for ISAKMP", RFC 2407, November 1998. |
7144 | ||
7145 | [DOSUDPPROT] | |
7146 | C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection | |
7147 | for UDP-based protocols", ACM Conference on Computer and | |
824a0402 | 7148 | Communications Security, October 2003. |
a6d7a610 MW |
7149 | |
7150 | [DSS] National Institute of Standards and Technology, U.S. | |
7151 | Department of Commerce, "Digital Signature Standard", | |
7152 | Draft FIPS 186-3, June 2008. | |
7153 | ||
7154 | [EAI] Abel, Y., "Internationalized Email Headers", RFC 5335, | |
7155 | September 2008. | |
7156 | ||
824a0402 AS |
7157 | [EAP-IANA] "Extensible Authentication Protocol (EAP) Registry: Method |
7158 | Types", <http://www.iana.org>. | |
7159 | ||
a6d7a610 MW |
7160 | [EAPMITM] N. Asokan, V. Nierni, and K. Nyberg, "Man-in-the-Middle in |
7161 | Tunneled Authentication Protocols", November 2002, | |
7162 | <http://eprint.iacr.org/2002/163>. | |
7163 | ||
7164 | [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", | |
7165 | RFC 4303, December 2005. | |
7166 | ||
824a0402 AS |
7167 | |
7168 | ||
7169 | ||
7170 | Kaufman, et al. Standards Track [Page 128] | |
7171 | \f | |
7172 | RFC 5996 IKEv2bis September 2010 | |
7173 | ||
7174 | ||
a6d7a610 MW |
7175 | [EXCHANGEANALYSIS] |
7176 | R. Perlman and C. Kaufman, "Analysis of the IPsec key | |
824a0402 | 7177 | exchange Standard", WET-ICE Security Conference, MIT, |
a6d7a610 MW |
7178 | 2001, |
7179 | <http://sec.femto.org/wetice-2001/papers/radia-paper.pdf>. | |
7180 | ||
824a0402 | 7181 | [H2HIPSEC] Aura, T., Roe, M., and A. Mohammed, "Experiences with |
a6d7a610 MW |
7182 | Host-to-Host IPsec", 13th International Workshop on |
7183 | Security Protocols, Cambridge, UK, April 2005. | |
7184 | ||
7185 | [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | |
7186 | Hashing for Message Authentication", RFC 2104, | |
7187 | February 1997. | |
7188 | ||
7189 | [IDEA] X. Lai, "On the Design and Security of Block Ciphers", ETH | |
7190 | Series in Information Processing, v. 1, Konstanz: Hartung- | |
7191 | Gorre Verlag, 1992. | |
7192 | ||
824a0402 AS |
7193 | [IDNA] Klensin, J., "Internationalized Domain Names for |
7194 | Applications (IDNA): Definitions and Document Framework", | |
7195 | RFC 5890, August 2010. | |
2eac2578 | 7196 | |
a6d7a610 MW |
7197 | [IKEV1] Harkins, D. and D. Carrel, "The Internet Key Exchange |
7198 | (IKE)", RFC 2409, November 1998. | |
7199 | ||
7200 | [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", | |
a6d7a610 MW |
7201 | RFC 4306, December 2005. |
7202 | ||
824a0402 AS |
7203 | [IP] Postel, J., "Internet Protocol", STD 5, RFC 791, |
7204 | September 1981. | |
7205 | ||
a6d7a610 MW |
7206 | [IP-COMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP |
7207 | Payload Compression Protocol (IPComp)", RFC 3173, | |
7208 | September 2001. | |
7209 | ||
7210 | [IPSECARCH-OLD] | |
7211 | Kent, S. and R. Atkinson, "Security Architecture for the | |
7212 | Internet Protocol", RFC 2401, November 1998. | |
7213 | ||
824a0402 AS |
7214 | [IPV6CONFIG] |
7215 | Eronen, P., Laganier, J., and C. Madson, "IPv6 | |
7216 | Configuration in Internet Key Exchange Protocol Version 2 | |
7217 | (IKEv2)", RFC 5739, February 2010. | |
a6d7a610 MW |
7218 | |
7219 | [ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet | |
7220 | Security Association and Key Management Protocol | |
7221 | (ISAKMP)", RFC 2408, November 1998. | |
7222 | ||
824a0402 AS |
7223 | |
7224 | ||
7225 | ||
7226 | Kaufman, et al. Standards Track [Page 129] | |
7227 | \f | |
7228 | RFC 5996 IKEv2bis September 2010 | |
7229 | ||
a6d7a610 MW |
7230 | |
7231 | [MAILFORMAT] | |
824a0402 AS |
7232 | Resnick, P., Ed., "Internet Message Format", RFC 5322, |
7233 | October 2008. | |
a6d7a610 MW |
7234 | |
7235 | [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, | |
7236 | April 1992. | |
7237 | ||
7238 | [MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support | |
7239 | in IPv6", RFC 3775, June 2004. | |
7240 | ||
7241 | [MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery | |
7242 | Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. | |
7243 | ||
82f0707f MW |
7244 | [MOBIKE] Eronen, P., "IKEv2 Mobility and Multihoming Protocol |
7245 | (MOBIKE)", RFC 4555, June 2006. | |
7246 | ||
a6d7a610 MW |
7247 | [MODES] National Institute of Standards and Technology, U.S. |
7248 | Department of Commerce, "Recommendation for Block Cipher | |
7249 | Modes of Operation", SP 800-38A, 2001. | |
7250 | ||
824a0402 | 7251 | [NAI] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The |
a6d7a610 MW |
7252 | Network Access Identifier", RFC 4282, December 2005. |
7253 | ||
7254 | [NATREQ] Aboba, B. and W. Dixon, "IPsec-Network Address Translation | |
7255 | (NAT) Compatibility Requirements", RFC 3715, March 2004. | |
7256 | ||
7257 | [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", | |
7258 | RFC 2412, November 1998. | |
7259 | ||
82f0707f | 7260 | [PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key |
a6d7a610 MW |
7261 | Management API, Version 2", RFC 2367, July 1998. |
7262 | ||
824a0402 | 7263 | [PHOTURIS] Karn, P. and W. Simpson, "Photuris: Session-Key Management |
a6d7a610 MW |
7264 | Protocol", RFC 2522, March 1999. |
7265 | ||
a6d7a610 MW |
7266 | [RANDOMNESS] |
7267 | Eastlake, D., Schiller, J., and S. Crocker, "Randomness | |
7268 | Requirements for Security", BCP 106, RFC 4086, June 2005. | |
7269 | ||
7270 | [REAUTH] Nir, Y., "Repeated Authentication in Internet Key Exchange | |
7271 | (IKEv2) Protocol", RFC 4478, April 2006. | |
7272 | ||
82f0707f MW |
7273 | [REUSE] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys In |
7274 | Diffie-Hellman Key Agreement Protocols", December 2008, | |
824a0402 AS |
7275 | <http://www.cacr.math.uwaterloo.ca/techreports/2008/ |
7276 | cacr2008-24.pdf>. | |
7277 | ||
7278 | ||
7279 | ||
7280 | ||
7281 | ||
7282 | Kaufman, et al. Standards Track [Page 130] | |
7283 | \f | |
7284 | RFC 5996 IKEv2bis September 2010 | |
7285 | ||
82f0707f | 7286 | |
824a0402 AS |
7287 | [ROHCV2] Ertekin, E., Christou, C., Jasani, R., Kivinen, T., and C. |
7288 | Bormann, "IKEv2 Extensions to Support Robust Header | |
7289 | Compression over IPsec", RFC 5857, May 2010. | |
a6d7a610 MW |
7290 | |
7291 | [RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for | |
7292 | Obtaining Digital Signatures and Public-Key | |
7293 | Cryptosystems", February 1978. | |
7294 | ||
7295 | [SHA] National Institute of Standards and Technology, U.S. | |
7296 | Department of Commerce, "Secure Hash Standard", | |
7297 | FIPS 180-3, October 2008. | |
7298 | ||
7299 | [SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to | |
7300 | Authenticated Diffie-Hellman and its Use in the IKE | |
7301 | Protocols", Advances in Cryptography - CRYPTO 2003 | |
7302 | Proceedings LNCS 2729, 2003, <http:// | |
7303 | www.informatik.uni-trier.de/~ley/db/conf/crypto/ | |
7304 | crypto2003.html>. | |
7305 | ||
7306 | [SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange | |
7307 | Mechanism for Internet", IEEE Proceedings of the 1996 | |
7308 | Symposium on Network and Distributed Systems Security , | |
7309 | 1996. | |
7310 | ||
7311 | [TRANSPARENCY] | |
7312 | Carpenter, B., "Internet Transparency", RFC 2775, | |
7313 | February 2000. | |
7314 | ||
a6d7a610 | 7315 | |
a6d7a610 MW |
7316 | |
7317 | ||
824a0402 AS |
7318 | |
7319 | ||
7320 | ||
7321 | ||
7322 | ||
7323 | ||
7324 | ||
7325 | ||
7326 | ||
7327 | ||
7328 | ||
7329 | ||
7330 | ||
7331 | ||
7332 | ||
7333 | ||
7334 | ||
7335 | ||
7336 | ||
7337 | ||
7338 | Kaufman, et al. Standards Track [Page 131] | |
7339 | \f | |
7340 | RFC 5996 IKEv2bis September 2010 | |
7341 | ||
7342 | ||
7343 | Appendix A. Summary of Changes from IKEv1 | |
a6d7a610 MW |
7344 | |
7345 | The goals of this revision to IKE are: | |
7346 | ||
7347 | 1. To define the entire IKE protocol in a single document, | |
7348 | replacing RFCs 2407, 2408, and 2409 and incorporating subsequent | |
7349 | changes to support NAT Traversal, Extensible Authentication, and | |
7350 | Remote Address acquisition; | |
7351 | ||
7352 | 2. To simplify IKE by replacing the eight different initial | |
7353 | exchanges with a single four-message exchange (with changes in | |
7354 | authentication mechanisms affecting only a single AUTH payload | |
7355 | rather than restructuring the entire exchange) see | |
7356 | [EXCHANGEANALYSIS]; | |
7357 | ||
7358 | 3. To remove the Domain of Interpretation (DOI), Situation (SIT), | |
7359 | and Labeled Domain Identifier fields, and the Commit and | |
7360 | Authentication only bits; | |
7361 | ||
7362 | 4. To decrease IKE's latency in the common case by making the | |
7363 | initial exchange be 2 round trips (4 messages), and allowing the | |
7364 | ability to piggyback setup of a Child SA on that exchange; | |
7365 | ||
7366 | 5. To replace the cryptographic syntax for protecting the IKE | |
7367 | messages themselves with one based closely on ESP to simplify | |
7368 | implementation and security analysis; | |
7369 | ||
7370 | 6. To reduce the number of possible error states by making the | |
7371 | protocol reliable (all messages are acknowledged) and sequenced. | |
7372 | This allows shortening CREATE_CHILD_SA exchanges from 3 messages | |
7373 | to 2; | |
7374 | ||
7375 | 7. To increase robustness by allowing the responder to not do | |
7376 | significant processing until it receives a message proving that | |
7377 | the initiator can receive messages at its claimed IP address; | |
7378 | ||
7379 | 8. To fix cryptographic weaknesses such as the problem with | |
824a0402 AS |
7380 | symmetries in hashes used for authentication (documented by Tero |
7381 | Kivinen); | |
a6d7a610 | 7382 | |
a6d7a610 MW |
7383 | 9. To specify Traffic Selectors in their own payloads type rather |
7384 | than overloading ID payloads, and making more flexible the | |
7385 | Traffic Selectors that may be specified; | |
7386 | ||
7387 | 10. To specify required behavior under certain error conditions or | |
7388 | when data that is not understood is received in order to make it | |
7389 | easier to make future revisions in a way that does not break | |
824a0402 AS |
7390 | backward compatibility; |
7391 | ||
7392 | ||
7393 | ||
7394 | Kaufman, et al. Standards Track [Page 132] | |
7395 | \f | |
7396 | RFC 5996 IKEv2bis September 2010 | |
7397 | ||
a6d7a610 MW |
7398 | |
7399 | 11. To simplify and clarify how shared state is maintained in the | |
824a0402 | 7400 | presence of network failures and DoS attacks; and |
a6d7a610 MW |
7401 | |
7402 | 12. To maintain existing syntax and magic numbers to the extent | |
7403 | possible to make it likely that implementations of IKEv1 can be | |
7404 | enhanced to support IKEv2 with minimum effort. | |
7405 | ||
a6d7a610 MW |
7406 | Appendix B. Diffie-Hellman Groups |
7407 | ||
7408 | There are two Diffie-Hellman groups defined here for use in IKE. | |
7409 | These groups were generated by Richard Schroeppel at the University | |
7410 | of Arizona. Properties of these primes are described in [OAKLEY]. | |
7411 | ||
824a0402 AS |
7412 | The strength supplied by group 1 may not be sufficient for typical |
7413 | uses and is here for historic reasons. | |
a6d7a610 MW |
7414 | |
7415 | Additional Diffie-Hellman groups have been defined in [ADDGROUP]. | |
7416 | ||
824a0402 | 7417 | B.1. Group 1 - 768-bit MODP |
2eac2578 | 7418 | |
824a0402 | 7419 | This group is assigned ID 1 (one). |
2eac2578 | 7420 | |
a6d7a610 MW |
7421 | The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } |
7422 | Its hexadecimal value is: | |
7423 | ||
7424 | FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 | |
7425 | 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD | |
7426 | EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 | |
7427 | E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF | |
7428 | ||
7429 | The generator is 2. | |
7430 | ||
824a0402 | 7431 | B.2. Group 2 - 1024-bit MODP |
a6d7a610 | 7432 | |
824a0402 | 7433 | This group is assigned ID 2 (two). |
a6d7a610 | 7434 | |
a6d7a610 MW |
7435 | The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. |
7436 | Its hexadecimal value is: | |
7437 | ||
7438 | FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 | |
7439 | 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD | |
7440 | EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 | |
7441 | E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED | |
7442 | EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 | |
7443 | FFFFFFFF FFFFFFFF | |
7444 | ||
7445 | The generator is 2. | |
7446 | ||
7447 | ||
2eac2578 MW |
7448 | |
7449 | ||
824a0402 AS |
7450 | Kaufman, et al. Standards Track [Page 133] |
7451 | \f | |
7452 | RFC 5996 IKEv2bis September 2010 | |
2eac2578 MW |
7453 | |
7454 | ||
824a0402 | 7455 | Appendix C. Exchanges and Payloads |
2eac2578 | 7456 | |
824a0402 AS |
7457 | This appendix contains a short summary of the IKEv2 exchanges, and |
7458 | what payloads can appear in which message. This appendix is purely | |
7459 | informative; if it disagrees with the body of this document, the | |
7460 | other text is considered correct. | |
82f0707f | 7461 | |
824a0402 AS |
7462 | Vendor ID (V) payloads may be included in any place in any message. |
7463 | This sequence here shows what are the most logical places for them. | |
82f0707f | 7464 | |
a6d7a610 MW |
7465 | C.1. IKE_SA_INIT Exchange |
7466 | ||
7467 | request --> [N(COOKIE)], | |
7468 | SA, KE, Ni, | |
7469 | [N(NAT_DETECTION_SOURCE_IP)+, | |
7470 | N(NAT_DETECTION_DESTINATION_IP)], | |
82f0707f | 7471 | [V+][N+] |
a6d7a610 MW |
7472 | |
7473 | normal response <-- SA, KE, Nr, | |
7474 | (no cookie) [N(NAT_DETECTION_SOURCE_IP), | |
7475 | N(NAT_DETECTION_DESTINATION_IP)], | |
7476 | [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], | |
82f0707f | 7477 | [V+][N+] |
a6d7a610 MW |
7478 | |
7479 | cookie response <-- N(COOKIE), | |
82f0707f | 7480 | [V+][N+] |
a6d7a610 | 7481 | |
824a0402 AS |
7482 | different Diffie- <-- N(INVALID_KE_PAYLOAD), |
7483 | Hellman group [V+][N+] | |
7484 | wanted | |
82f0707f MW |
7485 | |
7486 | ||
7487 | ||
7488 | ||
7489 | ||
7490 | ||
7491 | ||
7492 | ||
7493 | ||
a6d7a610 MW |
7494 | |
7495 | ||
7496 | ||
7497 | ||
7498 | ||
7499 | ||
7500 | ||
82f0707f MW |
7501 | |
7502 | ||
7503 | ||
7504 | ||
7505 | ||
824a0402 | 7506 | Kaufman, et al. Standards Track [Page 134] |
a6d7a610 | 7507 | \f |
824a0402 | 7508 | RFC 5996 IKEv2bis September 2010 |
a6d7a610 MW |
7509 | |
7510 | ||
7511 | C.2. IKE_AUTH Exchange without EAP | |
7512 | ||
7513 | request --> IDi, [CERT+], | |
7514 | [N(INITIAL_CONTACT)], | |
7515 | [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], | |
7516 | [IDr], | |
7517 | AUTH, | |
7518 | [CP(CFG_REQUEST)], | |
7519 | [N(IPCOMP_SUPPORTED)+], | |
7520 | [N(USE_TRANSPORT_MODE)], | |
7521 | [N(ESP_TFC_PADDING_NOT_SUPPORTED)], | |
7522 | [N(NON_FIRST_FRAGMENTS_ALSO)], | |
7523 | SA, TSi, TSr, | |
82f0707f | 7524 | [V+][N+] |
a6d7a610 MW |
7525 | |
7526 | response <-- IDr, [CERT+], | |
7527 | AUTH, | |
7528 | [CP(CFG_REPLY)], | |
7529 | [N(IPCOMP_SUPPORTED)], | |
7530 | [N(USE_TRANSPORT_MODE)], | |
7531 | [N(ESP_TFC_PADDING_NOT_SUPPORTED)], | |
7532 | [N(NON_FIRST_FRAGMENTS_ALSO)], | |
7533 | SA, TSi, TSr, | |
7534 | [N(ADDITIONAL_TS_POSSIBLE)], | |
82f0707f | 7535 | [V+][N+] |
a6d7a610 MW |
7536 | |
7537 | error in Child SA <-- IDr, [CERT+], | |
7538 | creation AUTH, | |
7539 | N(error), | |
82f0707f | 7540 | [V+][N+] |
a6d7a610 MW |
7541 | |
7542 | ||
7543 | ||
7544 | ||
7545 | ||
7546 | ||
7547 | ||
7548 | ||
7549 | ||
7550 | ||
7551 | ||
7552 | ||
7553 | ||
7554 | ||
7555 | ||
7556 | ||
7557 | ||
7558 | ||
7559 | ||
7560 | ||
7561 | ||
824a0402 | 7562 | Kaufman, et al. Standards Track [Page 135] |
a6d7a610 | 7563 | \f |
824a0402 | 7564 | RFC 5996 IKEv2bis September 2010 |
a6d7a610 MW |
7565 | |
7566 | ||
7567 | C.3. IKE_AUTH Exchange with EAP | |
7568 | ||
7569 | first request --> IDi, | |
7570 | [N(INITIAL_CONTACT)], | |
7571 | [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], | |
7572 | [IDr], | |
7573 | [CP(CFG_REQUEST)], | |
7574 | [N(IPCOMP_SUPPORTED)+], | |
7575 | [N(USE_TRANSPORT_MODE)], | |
7576 | [N(ESP_TFC_PADDING_NOT_SUPPORTED)], | |
7577 | [N(NON_FIRST_FRAGMENTS_ALSO)], | |
7578 | SA, TSi, TSr, | |
82f0707f | 7579 | [V+][N+] |
a6d7a610 MW |
7580 | |
7581 | first response <-- IDr, [CERT+], AUTH, | |
7582 | EAP, | |
82f0707f | 7583 | [V+][N+] |
a6d7a610 MW |
7584 | |
7585 | / --> EAP | |
7586 | repeat 1..N times | | |
7587 | \ <-- EAP | |
7588 | ||
7589 | last request --> AUTH | |
7590 | ||
7591 | last response <-- AUTH, | |
7592 | [CP(CFG_REPLY)], | |
7593 | [N(IPCOMP_SUPPORTED)], | |
7594 | [N(USE_TRANSPORT_MODE)], | |
7595 | [N(ESP_TFC_PADDING_NOT_SUPPORTED)], | |
7596 | [N(NON_FIRST_FRAGMENTS_ALSO)], | |
7597 | SA, TSi, TSr, | |
7598 | [N(ADDITIONAL_TS_POSSIBLE)], | |
82f0707f | 7599 | [V+][N+] |
a6d7a610 MW |
7600 | |
7601 | ||
7602 | ||
7603 | ||
7604 | ||
7605 | ||
7606 | ||
7607 | ||
7608 | ||
7609 | ||
7610 | ||
7611 | ||
7612 | ||
7613 | ||
7614 | ||
7615 | ||
7616 | ||
7617 | ||
824a0402 | 7618 | Kaufman, et al. Standards Track [Page 136] |
a6d7a610 | 7619 | \f |
824a0402 | 7620 | RFC 5996 IKEv2bis September 2010 |
a6d7a610 MW |
7621 | |
7622 | ||
7623 | C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying Child SAs | |
7624 | ||
7625 | request --> [N(REKEY_SA)], | |
7626 | [CP(CFG_REQUEST)], | |
7627 | [N(IPCOMP_SUPPORTED)+], | |
7628 | [N(USE_TRANSPORT_MODE)], | |
7629 | [N(ESP_TFC_PADDING_NOT_SUPPORTED)], | |
7630 | [N(NON_FIRST_FRAGMENTS_ALSO)], | |
7631 | SA, Ni, [KEi], TSi, TSr | |
82f0707f | 7632 | [V+][N+] |
a6d7a610 MW |
7633 | |
7634 | normal <-- [CP(CFG_REPLY)], | |
7635 | response [N(IPCOMP_SUPPORTED)], | |
7636 | [N(USE_TRANSPORT_MODE)], | |
7637 | [N(ESP_TFC_PADDING_NOT_SUPPORTED)], | |
7638 | [N(NON_FIRST_FRAGMENTS_ALSO)], | |
7639 | SA, Nr, [KEr], TSi, TSr, | |
7640 | [N(ADDITIONAL_TS_POSSIBLE)] | |
82f0707f | 7641 | [V+][N+] |
a6d7a610 MW |
7642 | |
7643 | error case <-- N(error) | |
7644 | ||
824a0402 AS |
7645 | different Diffie- <-- N(INVALID_KE_PAYLOAD), |
7646 | Hellman group [V+][N+] | |
7647 | wanted | |
a6d7a610 MW |
7648 | |
7649 | C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE SA | |
7650 | ||
824a0402 | 7651 | request --> SA, Ni, KEi |
82f0707f | 7652 | [V+][N+] |
a6d7a610 | 7653 | |
824a0402 | 7654 | response <-- SA, Nr, KEr |
82f0707f | 7655 | [V+][N+] |
a6d7a610 MW |
7656 | |
7657 | C.6. INFORMATIONAL Exchange | |
7658 | ||
7659 | request --> [N+], | |
7660 | [D+], | |
7661 | [CP(CFG_REQUEST)] | |
7662 | ||
7663 | response <-- [N+], | |
7664 | [D+], | |
7665 | [CP(CFG_REPLY)] | |
7666 | ||
7667 | ||
a6d7a610 MW |
7668 | |
7669 | ||
a6d7a610 | 7670 | |
a6d7a610 | 7671 | |
a6d7a610 | 7672 | |
a6d7a610 | 7673 | |
824a0402 | 7674 | Kaufman, et al. Standards Track [Page 137] |
82f0707f | 7675 | \f |
824a0402 | 7676 | RFC 5996 IKEv2bis September 2010 |
a6d7a610 MW |
7677 | |
7678 | ||
7679 | Authors' Addresses | |
7680 | ||
7681 | Charlie Kaufman | |
7682 | Microsoft | |
7683 | 1 Microsoft Way | |
7684 | Redmond, WA 98052 | |
7685 | US | |
7686 | ||
7687 | Phone: 1-425-707-3335 | |
824a0402 | 7688 | EMail: charliek@microsoft.com |
a6d7a610 MW |
7689 | |
7690 | ||
7691 | Paul Hoffman | |
7692 | VPN Consortium | |
7693 | 127 Segre Place | |
7694 | Santa Cruz, CA 95060 | |
7695 | US | |
7696 | ||
7697 | Phone: 1-831-426-9827 | |
824a0402 | 7698 | EMail: paul.hoffman@vpnc.org |
a6d7a610 MW |
7699 | |
7700 | ||
7701 | Yoav Nir | |
7702 | Check Point Software Technologies Ltd. | |
7703 | 5 Hasolelim St. | |
7704 | Tel Aviv 67897 | |
7705 | Israel | |
7706 | ||
824a0402 | 7707 | EMail: ynir@checkpoint.com |
a6d7a610 MW |
7708 | |
7709 | ||
7710 | Pasi Eronen | |
824a0402 AS |
7711 | Independent |
7712 | ||
7713 | EMail: pe@iki.fi | |
7714 | ||
7715 | ||
a6d7a610 | 7716 | |
a6d7a610 MW |
7717 | |
7718 | ||
7719 | ||
7720 | ||
7721 | ||
7722 | ||
a6d7a610 | 7723 | |
a6d7a610 | 7724 | |
a6d7a610 MW |
7725 | |
7726 | ||
7727 | ||
7728 | ||
7729 | ||
824a0402 | 7730 | Kaufman, et al. Standards Track [Page 138] |
a6d7a610 | 7731 | \f |