]>
Commit | Line | Data |
---|---|---|
f91513e3 MW |
1 | |
2 | ||
3 | ||
4 | ||
5 | ||
6 | ||
7 | Network Working Group C. Kaufman, Ed. | |
8 | Request for Comments: 4306 Microsoft | |
9 | Obsoletes: 2407, 2408, 2409 December 2005 | |
10 | Category: Standards Track | |
11 | ||
12 | ||
13 | Internet Key Exchange (IKEv2) Protocol | |
14 | ||
15 | Status of This Memo | |
16 | ||
17 | This document specifies an Internet standards track protocol for the | |
18 | Internet community, and requests discussion and suggestions for | |
19 | improvements. Please refer to the current edition of the "Internet | |
20 | Official Protocol Standards" (STD 1) for the standardization state | |
21 | and status of this protocol. Distribution of this memo is unlimited. | |
22 | ||
23 | Copyright Notice | |
24 | ||
25 | Copyright (C) The Internet Society (2005). | |
26 | ||
27 | Abstract | |
28 | ||
29 | This document describes version 2 of the Internet Key Exchange (IKE) | |
30 | protocol. IKE is a component of IPsec used for performing mutual | |
31 | authentication and establishing and maintaining security associations | |
32 | (SAs). | |
33 | ||
34 | This version of the IKE specification combines the contents of what | |
35 | were previously separate documents, including Internet Security | |
36 | Association and Key Management Protocol (ISAKMP, RFC 2408), IKE (RFC | |
37 | 2409), the Internet Domain of Interpretation (DOI, RFC 2407), Network | |
38 | Address Translation (NAT) Traversal, Legacy authentication, and | |
39 | remote address acquisition. | |
40 | ||
41 | Version 2 of IKE does not interoperate with version 1, but it has | |
42 | enough of the header format in common that both versions can | |
43 | unambiguously run over the same UDP port. | |
44 | ||
45 | ||
46 | ||
47 | ||
48 | ||
49 | ||
50 | ||
51 | ||
52 | ||
53 | ||
54 | ||
55 | ||
56 | ||
57 | ||
58 | Kaufman Standards Track [Page 1] | |
59 | \f | |
60 | RFC 4306 IKEv2 December 2005 | |
61 | ||
62 | ||
63 | Table of Contents | |
64 | ||
65 | 1. Introduction ....................................................3 | |
66 | 1.1. Usage Scenarios ............................................5 | |
67 | 1.2. The Initial Exchanges ......................................7 | |
68 | 1.3. The CREATE_CHILD_SA Exchange ...............................9 | |
69 | 1.4. The INFORMATIONAL Exchange ................................11 | |
70 | 1.5. Informational Messages outside of an IKE_SA ...............12 | |
71 | 2. IKE Protocol Details and Variations ............................12 | |
72 | 2.1. Use of Retransmission Timers ..............................13 | |
73 | 2.2. Use of Sequence Numbers for Message ID ....................14 | |
74 | 2.3. Window Size for Overlapping Requests ......................14 | |
75 | 2.4. State Synchronization and Connection Timeouts .............15 | |
76 | 2.5. Version Numbers and Forward Compatibility .................17 | |
77 | 2.6. Cookies ...................................................18 | |
78 | 2.7. Cryptographic Algorithm Negotiation .......................21 | |
79 | 2.8. Rekeying ..................................................22 | |
80 | 2.9. Traffic Selector Negotiation ..............................24 | |
81 | 2.10. Nonces ...................................................26 | |
82 | 2.11. Address and Port Agility .................................26 | |
83 | 2.12. Reuse of Diffie-Hellman Exponentials .....................27 | |
84 | 2.13. Generating Keying Material ...............................27 | |
85 | 2.14. Generating Keying Material for the IKE_SA ................28 | |
86 | 2.15. Authentication of the IKE_SA .............................29 | |
87 | 2.16. Extensible Authentication Protocol Methods ...............31 | |
88 | 2.17. Generating Keying Material for CHILD_SAs .................33 | |
89 | 2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA exchange ........34 | |
90 | 2.19. Requesting an Internal Address on a Remote Network .......34 | |
91 | 2.20. Requesting the Peer's Version ............................35 | |
92 | 2.21. Error Handling ...........................................36 | |
93 | 2.22. IPComp ...................................................37 | |
94 | 2.23. NAT Traversal ............................................38 | |
95 | 2.24. Explicit Congestion Notification (ECN) ...................40 | |
96 | 3. Header and Payload Formats .....................................41 | |
97 | 3.1. The IKE Header ............................................41 | |
98 | 3.2. Generic Payload Header ....................................44 | |
99 | 3.3. Security Association Payload ..............................46 | |
100 | 3.4. Key Exchange Payload ......................................56 | |
101 | 3.5. Identification Payloads ...................................56 | |
102 | 3.6. Certificate Payload .......................................59 | |
103 | 3.7. Certificate Request Payload ...............................61 | |
104 | 3.8. Authentication Payload ....................................63 | |
105 | 3.9. Nonce Payload .............................................64 | |
106 | 3.10. Notify Payload ...........................................64 | |
107 | 3.11. Delete Payload ...........................................72 | |
108 | 3.12. Vendor ID Payload ........................................73 | |
109 | 3.13. Traffic Selector Payload .................................74 | |
110 | 3.14. Encrypted Payload ........................................77 | |
111 | ||
112 | ||
113 | ||
114 | Kaufman Standards Track [Page 2] | |
115 | \f | |
116 | RFC 4306 IKEv2 December 2005 | |
117 | ||
118 | ||
119 | 3.15. Configuration Payload ....................................79 | |
120 | 3.16. Extensible Authentication Protocol (EAP) Payload .........84 | |
121 | 4. Conformance Requirements .......................................85 | |
122 | 5. Security Considerations ........................................88 | |
123 | 6. IANA Considerations ............................................90 | |
124 | 7. Acknowledgements ...............................................91 | |
125 | 8. References .....................................................91 | |
126 | 8.1. Normative References ......................................91 | |
127 | 8.2. Informative References ....................................92 | |
128 | Appendix A: Summary of Changes from IKEv1 .........................96 | |
129 | Appendix B: Diffie-Hellman Groups .................................97 | |
130 | B.1. Group 1 - 768 Bit MODP ....................................97 | |
131 | B.2. Group 2 - 1024 Bit MODP ...................................97 | |
132 | ||
133 | 1. Introduction | |
134 | ||
135 | IP Security (IPsec) provides confidentiality, data integrity, access | |
136 | control, and data source authentication to IP datagrams. These | |
137 | services are provided by maintaining shared state between the source | |
138 | and the sink of an IP datagram. This state defines, among other | |
139 | things, the specific services provided to the datagram, which | |
140 | cryptographic algorithms will be used to provide the services, and | |
141 | the keys used as input to the cryptographic algorithms. | |
142 | ||
143 | Establishing this shared state in a manual fashion does not scale | |
144 | well. Therefore, a protocol to establish this state dynamically is | |
145 | needed. This memo describes such a protocol -- the Internet Key | |
146 | Exchange (IKE). This is version 2 of IKE. Version 1 of IKE was | |
147 | defined in RFCs 2407, 2408, and 2409 [Pip98, MSST98, HC98]. This | |
148 | single document is intended to replace all three of those RFCs. | |
149 | ||
150 | Definitions of the primitive terms in this document (such as Security | |
151 | Association or SA) can be found in [RFC4301]. | |
152 | ||
153 | Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and | |
154 | "MAY" that appear in this document are to be interpreted as described | |
155 | in [Bra97]. | |
156 | ||
157 | The term "Expert Review" is to be interpreted as defined in | |
158 | [RFC2434]. | |
159 | ||
160 | IKE performs mutual authentication between two parties and | |
161 | establishes an IKE security association (SA) that includes shared | |
162 | secret information that can be used to efficiently establish SAs for | |
163 | Encapsulating Security Payload (ESP) [RFC4303] and/or Authentication | |
164 | Header (AH) [RFC4302] and a set of cryptographic algorithms to be | |
165 | used by the SAs to protect the traffic that they carry. In this | |
166 | document, the term "suite" or "cryptographic suite" refers to a | |
167 | ||
168 | ||
169 | ||
170 | Kaufman Standards Track [Page 3] | |
171 | \f | |
172 | RFC 4306 IKEv2 December 2005 | |
173 | ||
174 | ||
175 | complete set of algorithms used to protect an SA. An initiator | |
176 | proposes one or more suites by listing supported algorithms that can | |
177 | be combined into suites in a mix-and-match fashion. IKE can also | |
178 | negotiate use of IP Compression (IPComp) [IPCOMP] in connection with | |
179 | an ESP and/or AH SA. We call the IKE SA an "IKE_SA". The SAs for | |
180 | ESP and/or AH that get set up through that IKE_SA we call | |
181 | "CHILD_SAs". | |
182 | ||
183 | All IKE communications consist of pairs of messages: a request and a | |
184 | response. The pair is called an "exchange". We call the first | |
185 | messages establishing an IKE_SA IKE_SA_INIT and IKE_AUTH exchanges | |
186 | and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL | |
187 | exchanges. In the common case, there is a single IKE_SA_INIT | |
188 | exchange and a single IKE_AUTH exchange (a total of four messages) to | |
189 | establish the IKE_SA and the first CHILD_SA. In exceptional cases, | |
190 | there may be more than one of each of these exchanges. In all cases, | |
191 | all IKE_SA_INIT exchanges MUST complete before any other exchange | |
192 | type, then all IKE_AUTH exchanges MUST complete, and following that | |
193 | any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur | |
194 | in any order. In some scenarios, only a single CHILD_SA is needed | |
195 | between the IPsec endpoints, and therefore there would be no | |
196 | additional exchanges. Subsequent exchanges MAY be used to establish | |
197 | additional CHILD_SAs between the same authenticated pair of endpoints | |
198 | and to perform housekeeping functions. | |
199 | ||
200 | IKE message flow always consists of a request followed by a response. | |
201 | It is the responsibility of the requester to ensure reliability. If | |
202 | the response is not received within a timeout interval, the requester | |
203 | needs to retransmit the request (or abandon the connection). | |
204 | ||
205 | The first request/response of an IKE session (IKE_SA_INIT) negotiates | |
206 | security parameters for the IKE_SA, sends nonces, and sends Diffie- | |
207 | Hellman values. | |
208 | ||
209 | The second request/response (IKE_AUTH) transmits identities, proves | |
210 | knowledge of the secrets corresponding to the two identities, and | |
211 | sets up an SA for the first (and often only) AH and/or ESP CHILD_SA. | |
212 | ||
213 | The types of subsequent exchanges are CREATE_CHILD_SA (which creates | |
214 | a CHILD_SA) and INFORMATIONAL (which deletes an SA, reports error | |
215 | conditions, or does other housekeeping). Every request requires a | |
216 | response. An INFORMATIONAL request with no payloads (other than the | |
217 | empty Encrypted payload required by the syntax) is commonly used as a | |
218 | check for liveness. These subsequent exchanges cannot be used until | |
219 | the initial exchanges have completed. | |
220 | ||
221 | ||
222 | ||
223 | ||
224 | ||
225 | ||
226 | Kaufman Standards Track [Page 4] | |
227 | \f | |
228 | RFC 4306 IKEv2 December 2005 | |
229 | ||
230 | ||
231 | In the description that follows, we assume that no errors occur. | |
232 | Modifications to the flow should errors occur are described in | |
233 | section 2.21. | |
234 | ||
235 | 1.1. Usage Scenarios | |
236 | ||
237 | IKE is expected to be used to negotiate ESP and/or AH SAs in a number | |
238 | of different scenarios, each with its own special requirements. | |
239 | ||
240 | 1.1.1. Security Gateway to Security Gateway Tunnel | |
241 | ||
242 | +-+-+-+-+-+ +-+-+-+-+-+ | |
243 | ! ! IPsec ! ! | |
244 | Protected !Tunnel ! tunnel !Tunnel ! Protected | |
245 | Subnet <-->!Endpoint !<---------->!Endpoint !<--> Subnet | |
246 | ! ! ! ! | |
247 | +-+-+-+-+-+ +-+-+-+-+-+ | |
248 | ||
249 | Figure 1: Security Gateway to Security Gateway Tunnel | |
250 | ||
251 | In this scenario, neither endpoint of the IP connection implements | |
252 | IPsec, but network nodes between them protect traffic for part of the | |
253 | way. Protection is transparent to the endpoints, and depends on | |
254 | ordinary routing to send packets through the tunnel endpoints for | |
255 | processing. Each endpoint would announce the set of addresses | |
256 | "behind" it, and packets would be sent in tunnel mode where the inner | |
257 | IP header would contain the IP addresses of the actual endpoints. | |
258 | ||
259 | 1.1.2. Endpoint-to-Endpoint Transport | |
260 | ||
261 | +-+-+-+-+-+ +-+-+-+-+-+ | |
262 | ! ! IPsec transport ! ! | |
263 | !Protected! or tunnel mode SA !Protected! | |
264 | !Endpoint !<---------------------------------------->!Endpoint ! | |
265 | ! ! ! ! | |
266 | +-+-+-+-+-+ +-+-+-+-+-+ | |
267 | ||
268 | Figure 2: Endpoint to Endpoint | |
269 | ||
270 | In this scenario, both endpoints of the IP connection implement | |
271 | IPsec, as required of hosts in [RFC4301]. Transport mode will | |
272 | commonly be used with no inner IP header. If there is an inner IP | |
273 | header, the inner addresses will be the same as the outer addresses. | |
274 | A single pair of addresses will be negotiated for packets to be | |
275 | protected by this SA. These endpoints MAY implement application | |
276 | layer access controls based on the IPsec authenticated identities of | |
277 | the participants. This scenario enables the end-to-end security that | |
278 | has been a guiding principle for the Internet since [RFC1958], | |
279 | ||
280 | ||
281 | ||
282 | Kaufman Standards Track [Page 5] | |
283 | \f | |
284 | RFC 4306 IKEv2 December 2005 | |
285 | ||
286 | ||
287 | [RFC2775], and a method of limiting the inherent problems with | |
288 | complexity in networks noted by [RFC3439]. Although this scenario | |
289 | may not be fully applicable to the IPv4 Internet, it has been | |
290 | deployed successfully in specific scenarios within intranets using | |
291 | IKEv1. It should be more broadly enabled during the transition to | |
292 | IPv6 and with the adoption of IKEv2. | |
293 | ||
294 | It is possible in this scenario that one or both of the protected | |
295 | endpoints will be behind a network address translation (NAT) node, in | |
296 | which case the tunneled packets will have to be UDP encapsulated so | |
297 | that port numbers in the UDP headers can be used to identify | |
298 | individual endpoints "behind" the NAT (see section 2.23). | |
299 | ||
300 | 1.1.3. Endpoint to Security Gateway Tunnel | |
301 | ||
302 | +-+-+-+-+-+ +-+-+-+-+-+ | |
303 | ! ! IPsec ! ! Protected | |
304 | !Protected! tunnel !Tunnel ! Subnet | |
305 | !Endpoint !<------------------------>!Endpoint !<--- and/or | |
306 | ! ! ! ! Internet | |
307 | +-+-+-+-+-+ +-+-+-+-+-+ | |
308 | ||
309 | Figure 3: Endpoint to Security Gateway Tunnel | |
310 | ||
311 | In this scenario, a protected endpoint (typically a portable roaming | |
312 | computer) connects back to its corporate network through an IPsec- | |
313 | protected tunnel. It might use this tunnel only to access | |
314 | information on the corporate network, or it might tunnel all of its | |
315 | traffic back through the corporate network in order to take advantage | |
316 | of protection provided by a corporate firewall against Internet-based | |
317 | attacks. In either case, the protected endpoint will want an IP | |
318 | address associated with the security gateway so that packets returned | |
319 | to it will go to the security gateway and be tunneled back. This IP | |
320 | address may be static or may be dynamically allocated by the security | |
321 | gateway. In support of the latter case, IKEv2 includes a mechanism | |
322 | for the initiator to request an IP address owned by the security | |
323 | gateway for use for the duration of its SA. | |
324 | ||
325 | In this scenario, packets will use tunnel mode. On each packet from | |
326 | the protected endpoint, the outer IP header will contain the source | |
327 | IP address associated with its current location (i.e., the address | |
328 | that will get traffic routed to the endpoint directly), while the | |
329 | inner IP header will contain the source IP address assigned by the | |
330 | security gateway (i.e., the address that will get traffic routed to | |
331 | the security gateway for forwarding to the endpoint). The outer | |
332 | destination address will always be that of the security gateway, | |
333 | while the inner destination address will be the ultimate destination | |
334 | for the packet. | |
335 | ||
336 | ||
337 | ||
338 | Kaufman Standards Track [Page 6] | |
339 | \f | |
340 | RFC 4306 IKEv2 December 2005 | |
341 | ||
342 | ||
343 | In this scenario, it is possible that the protected endpoint will be | |
344 | behind a NAT. In that case, the IP address as seen by the security | |
345 | gateway will not be the same as the IP address sent by the protected | |
346 | endpoint, and packets will have to be UDP encapsulated in order to be | |
347 | routed properly. | |
348 | ||
349 | 1.1.4. Other Scenarios | |
350 | ||
351 | Other scenarios are possible, as are nested combinations of the | |
352 | above. One notable example combines aspects of 1.1.1 and 1.1.3. A | |
353 | subnet may make all external accesses through a remote security | |
354 | gateway using an IPsec tunnel, where the addresses on the subnet are | |
355 | routed to the security gateway by the rest of the Internet. An | |
356 | example would be someone's home network being virtually on the | |
357 | Internet with static IP addresses even though connectivity is | |
358 | provided by an ISP that assigns a single dynamically assigned IP | |
359 | address to the user's security gateway (where the static IP addresses | |
360 | and an IPsec relay are provided by a third party located elsewhere). | |
361 | ||
362 | 1.2. The Initial Exchanges | |
363 | ||
364 | Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH | |
365 | exchanges (known in IKEv1 as Phase 1). These initial exchanges | |
366 | normally consist of four messages, though in some scenarios that | |
367 | number can grow. All communications using IKE consist of | |
368 | request/response pairs. We'll describe the base exchange first, | |
369 | followed by variations. The first pair of messages (IKE_SA_INIT) | |
370 | negotiate cryptographic algorithms, exchange nonces, and do a | |
371 | Diffie-Hellman exchange [DH]. | |
372 | ||
373 | The second pair of messages (IKE_AUTH) authenticate the previous | |
374 | messages, exchange identities and certificates, and establish the | |
375 | first CHILD_SA. Parts of these messages are encrypted and integrity | |
376 | protected with keys established through the IKE_SA_INIT exchange, so | |
377 | the identities are hidden from eavesdroppers and all fields in all | |
378 | the messages are authenticated. | |
379 | ||
380 | In the following descriptions, the payloads contained in the message | |
381 | are indicated by names as listed below. | |
382 | ||
383 | Notation Payload | |
384 | ||
385 | AUTH Authentication | |
386 | CERT Certificate | |
387 | CERTREQ Certificate Request | |
388 | CP Configuration | |
389 | D Delete | |
390 | E Encrypted | |
391 | ||
392 | ||
393 | ||
394 | Kaufman Standards Track [Page 7] | |
395 | \f | |
396 | RFC 4306 IKEv2 December 2005 | |
397 | ||
398 | ||
399 | EAP Extensible Authentication | |
400 | HDR IKE Header | |
401 | IDi Identification - Initiator | |
402 | IDr Identification - Responder | |
403 | KE Key Exchange | |
404 | Ni, Nr Nonce | |
405 | N Notify | |
406 | SA Security Association | |
407 | TSi Traffic Selector - Initiator | |
408 | TSr Traffic Selector - Responder | |
409 | V Vendor ID | |
410 | ||
411 | The details of the contents of each payload are described in section | |
412 | 3. Payloads that may optionally appear will be shown in brackets, | |
413 | such as [CERTREQ], indicate that optionally a certificate request | |
414 | payload can be included. | |
415 | ||
416 | The initial exchanges are as follows: | |
417 | ||
418 | Initiator Responder | |
419 | ----------- ----------- | |
420 | HDR, SAi1, KEi, Ni --> | |
421 | ||
422 | HDR contains the Security Parameter Indexes (SPIs), version numbers, | |
423 | and flags of various sorts. The SAi1 payload states the | |
424 | cryptographic algorithms the initiator supports for the IKE_SA. The | |
425 | KE payload sends the initiator's Diffie-Hellman value. Ni is the | |
426 | initiator's nonce. | |
427 | ||
428 | <-- HDR, SAr1, KEr, Nr, [CERTREQ] | |
429 | ||
430 | The responder chooses a cryptographic suite from the initiator's | |
431 | offered choices and expresses that choice in the SAr1 payload, | |
432 | completes the Diffie-Hellman exchange with the KEr payload, and sends | |
433 | its nonce in the Nr payload. | |
434 | ||
435 | At this point in the negotiation, each party can generate SKEYSEED, | |
436 | from which all keys are derived for that IKE_SA. All but the headers | |
437 | of all the messages that follow are encrypted and integrity | |
438 | protected. The keys used for the encryption and integrity protection | |
439 | are derived from SKEYSEED and are known as SK_e (encryption) and SK_a | |
440 | (authentication, a.k.a. integrity protection). A separate SK_e and | |
441 | SK_a is computed for each direction. In addition to the keys SK_e | |
442 | and SK_a derived from the DH value for protection of the IKE_SA, | |
443 | another quantity SK_d is derived and used for derivation of further | |
444 | keying material for CHILD_SAs. The notation SK { ... } indicates | |
445 | that these payloads are encrypted and integrity protected using that | |
446 | direction's SK_e and SK_a. | |
447 | ||
448 | ||
449 | ||
450 | Kaufman Standards Track [Page 8] | |
451 | \f | |
452 | RFC 4306 IKEv2 December 2005 | |
453 | ||
454 | ||
455 | HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] | |
456 | AUTH, SAi2, TSi, TSr} --> | |
457 | ||
458 | The initiator asserts its identity with the IDi payload, proves | |
459 | knowledge of the secret corresponding to IDi and integrity protects | |
460 | the contents of the first message using the AUTH payload (see section | |
461 | 2.15). It might also send its certificate(s) in CERT payload(s) and | |
462 | a list of its trust anchors in CERTREQ payload(s). If any CERT | |
463 | payloads are included, the first certificate provided MUST contain | |
464 | the public key used to verify the AUTH field. The optional payload | |
465 | IDr enables the initiator to specify which of the responder's | |
466 | identities it wants to talk to. This is useful when the machine on | |
467 | which the responder is running is hosting multiple identities at the | |
468 | same IP address. The initiator begins negotiation of a CHILD_SA | |
469 | using the SAi2 payload. The final fields (starting with SAi2) are | |
470 | described in the description of the CREATE_CHILD_SA exchange. | |
471 | ||
472 | <-- HDR, SK {IDr, [CERT,] AUTH, | |
473 | SAr2, TSi, TSr} | |
474 | ||
475 | The responder asserts its identity with the IDr payload, optionally | |
476 | sends one or more certificates (again with the certificate containing | |
477 | the public key used to verify AUTH listed first), authenticates its | |
478 | identity and protects the integrity of the second message with the | |
479 | AUTH payload, and completes negotiation of a CHILD_SA with the | |
480 | additional fields described below in the CREATE_CHILD_SA exchange. | |
481 | ||
482 | The recipients of messages 3 and 4 MUST verify that all signatures | |
483 | and MACs are computed correctly and that the names in the ID payloads | |
484 | correspond to the keys used to generate the AUTH payload. | |
485 | ||
486 | 1.3. The CREATE_CHILD_SA Exchange | |
487 | ||
488 | This exchange consists of a single request/response pair, and was | |
489 | referred to as a phase 2 exchange in IKEv1. It MAY be initiated by | |
490 | either end of the IKE_SA after the initial exchanges are completed. | |
491 | ||
492 | All messages following the initial exchange are cryptographically | |
493 | protected using the cryptographic algorithms and keys negotiated in | |
494 | the first two messages of the IKE exchange. These subsequent | |
495 | messages use the syntax of the Encrypted Payload described in section | |
496 | 3.14. All subsequent messages included an Encrypted Payload, even if | |
497 | they are referred to in the text as "empty". | |
498 | ||
499 | Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this | |
500 | section the term "initiator" refers to the endpoint initiating this | |
501 | exchange. | |
502 | ||
503 | ||
504 | ||
505 | ||
506 | Kaufman Standards Track [Page 9] | |
507 | \f | |
508 | RFC 4306 IKEv2 December 2005 | |
509 | ||
510 | ||
511 | A CHILD_SA is created by sending a CREATE_CHILD_SA request. The | |
512 | CREATE_CHILD_SA request MAY optionally contain a KE payload for an | |
513 | additional Diffie-Hellman exchange to enable stronger guarantees of | |
514 | forward secrecy for the CHILD_SA. The keying material for the | |
515 | CHILD_SA is a function of SK_d established during the establishment | |
516 | of the IKE_SA, the nonces exchanged during the CREATE_CHILD_SA | |
517 | exchange, and the Diffie-Hellman value (if KE payloads are included | |
518 | in the CREATE_CHILD_SA exchange). | |
519 | ||
520 | In the CHILD_SA created as part of the initial exchange, a second KE | |
521 | payload and nonce MUST NOT be sent. The nonces from the initial | |
522 | exchange are used in computing the keys for the CHILD_SA. | |
523 | ||
524 | The CREATE_CHILD_SA request contains: | |
525 | ||
526 | Initiator Responder | |
527 | ----------- ----------- | |
528 | HDR, SK {[N], SA, Ni, [KEi], | |
529 | [TSi, TSr]} --> | |
530 | ||
531 | The initiator sends SA offer(s) in the SA payload, a nonce in the Ni | |
532 | payload, optionally a Diffie-Hellman value in the KEi payload, and | |
533 | the proposed traffic selectors in the TSi and TSr payloads. If this | |
534 | CREATE_CHILD_SA exchange is rekeying an existing SA other than the | |
535 | IKE_SA, the leading N payload of type REKEY_SA MUST identify the SA | |
536 | being rekeyed. If this CREATE_CHILD_SA exchange is not rekeying an | |
537 | existing SA, the N payload MUST be omitted. If the SA offers include | |
538 | different Diffie-Hellman groups, KEi MUST be an element of the group | |
539 | the initiator expects the responder to accept. If it guesses wrong, | |
540 | the CREATE_CHILD_SA exchange will fail, and it will have to retry | |
541 | with a different KEi. | |
542 | ||
543 | The message following the header is encrypted and the message | |
544 | including the header is integrity protected using the cryptographic | |
545 | algorithms negotiated for the IKE_SA. | |
546 | ||
547 | The CREATE_CHILD_SA response contains: | |
548 | ||
549 | <-- HDR, SK {SA, Nr, [KEr], | |
550 | [TSi, TSr]} | |
551 | ||
552 | The responder replies (using the same Message ID to respond) with the | |
553 | accepted offer in an SA payload, and a Diffie-Hellman value in the | |
554 | KEr payload if KEi was included in the request and the selected | |
555 | cryptographic suite includes that group. If the responder chooses a | |
556 | cryptographic suite with a different group, it MUST reject the | |
557 | request. The initiator SHOULD repeat the request, but now with a KEi | |
558 | payload from the group the responder selected. | |
559 | ||
560 | ||
561 | ||
562 | Kaufman Standards Track [Page 10] | |
563 | \f | |
564 | RFC 4306 IKEv2 December 2005 | |
565 | ||
566 | ||
567 | The traffic selectors for traffic to be sent on that SA are specified | |
568 | in the TS payloads, which may be a subset of what the initiator of | |
569 | the CHILD_SA proposed. Traffic selectors are omitted if this | |
570 | CREATE_CHILD_SA request is being used to change the key of the | |
571 | IKE_SA. | |
572 | ||
573 | 1.4. The INFORMATIONAL Exchange | |
574 | ||
575 | At various points during the operation of an IKE_SA, peers may desire | |
576 | to convey control messages to each other regarding errors or | |
577 | notifications of certain events. To accomplish this, IKE defines an | |
578 | INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur | |
579 | after the initial exchanges and are cryptographically protected with | |
580 | the negotiated keys. | |
581 | ||
582 | Control messages that pertain to an IKE_SA MUST be sent under that | |
583 | IKE_SA. Control messages that pertain to CHILD_SAs MUST be sent | |
584 | under the protection of the IKE_SA which generated them (or its | |
585 | successor if the IKE_SA was replaced for the purpose of rekeying). | |
586 | ||
587 | Messages in an INFORMATIONAL exchange contain zero or more | |
588 | Notification, Delete, and Configuration payloads. The Recipient of | |
589 | an INFORMATIONAL exchange request MUST send some response (else the | |
590 | Sender will assume the message was lost in the network and will | |
591 | retransmit it). That response MAY be a message with no payloads. | |
592 | The request message in an INFORMATIONAL exchange MAY also contain no | |
593 | payloads. This is the expected way an endpoint can ask the other | |
594 | endpoint to verify that it is alive. | |
595 | ||
596 | ESP and AH SAs always exist in pairs, with one SA in each direction. | |
597 | When an SA is closed, both members of the pair MUST be closed. When | |
598 | SAs are nested, as when data (and IP headers if in tunnel mode) are | |
599 | encapsulated first with IPComp, then with ESP, and finally with AH | |
600 | between the same pair of endpoints, all of the SAs MUST be deleted | |
601 | together. Each endpoint MUST close its incoming SAs and allow the | |
602 | other endpoint to close the other SA in each pair. To delete an SA, | |
603 | an INFORMATIONAL exchange with one or more delete payloads is sent | |
604 | listing the SPIs (as they would be expected in the headers of inbound | |
605 | packets) of the SAs to be deleted. The recipient MUST close the | |
606 | designated SAs. Normally, the reply in the INFORMATIONAL exchange | |
607 | will contain delete payloads for the paired SAs going in the other | |
608 | direction. There is one exception. If by chance both ends of a set | |
609 | of SAs independently decide to close them, each may send a delete | |
610 | payload and the two requests may cross in the network. If a node | |
611 | receives a delete request for SAs for which it has already issued a | |
612 | delete request, it MUST delete the outgoing SAs while processing the | |
613 | request and the incoming SAs while processing the response. In that | |
614 | ||
615 | ||
616 | ||
617 | ||
618 | Kaufman Standards Track [Page 11] | |
619 | \f | |
620 | RFC 4306 IKEv2 December 2005 | |
621 | ||
622 | ||
623 | case, the responses MUST NOT include delete payloads for the deleted | |
624 | SAs, since that would result in duplicate deletion and could in | |
625 | theory delete the wrong SA. | |
626 | ||
627 | A node SHOULD regard half-closed connections as anomalous and audit | |
628 | their existence should they persist. Note that this specification | |
629 | nowhere specifies time periods, so it is up to individual endpoints | |
630 | to decide how long to wait. A node MAY refuse to accept incoming | |
631 | data on half-closed connections but MUST NOT unilaterally close them | |
632 | and reuse the SPIs. If connection state becomes sufficiently messed | |
633 | up, a node MAY close the IKE_SA; doing so will implicitly close all | |
634 | SAs negotiated under it. It can then rebuild the SAs it needs on a | |
635 | clean base under a new IKE_SA. | |
636 | ||
637 | The INFORMATIONAL exchange is defined as: | |
638 | ||
639 | Initiator Responder | |
640 | ----------- ----------- | |
641 | HDR, SK {[N,] [D,] [CP,] ...} --> | |
642 | <-- HDR, SK {[N,] [D,] [CP], ...} | |
643 | ||
644 | The processing of an INFORMATIONAL exchange is determined by its | |
645 | component payloads. | |
646 | ||
647 | 1.5. Informational Messages outside of an IKE_SA | |
648 | ||
649 | If an encrypted IKE packet arrives on port 500 or 4500 with an | |
650 | unrecognized SPI, it could be because the receiving node has recently | |
651 | crashed and lost state or because of some other system malfunction or | |
652 | attack. If the receiving node has an active IKE_SA to the IP address | |
653 | from whence the packet came, it MAY send a notification of the | |
654 | wayward packet over that IKE_SA in an INFORMATIONAL exchange. If it | |
655 | does not have such an IKE_SA, it MAY send an Informational message | |
656 | without cryptographic protection to the source IP address. Such a | |
657 | message is not part of an informational exchange, and the receiving | |
658 | node MUST NOT respond to it. Doing so could cause a message loop. | |
659 | ||
660 | 2. IKE Protocol Details and Variations | |
661 | ||
662 | IKE normally listens and sends on UDP port 500, though IKE messages | |
663 | may also be received on UDP port 4500 with a slightly different | |
664 | format (see section 2.23). Since UDP is a datagram (unreliable) | |
665 | protocol, IKE includes in its definition recovery from transmission | |
666 | errors, including packet loss, packet replay, and packet forgery. | |
667 | IKE is designed to function so long as (1) at least one of a series | |
668 | of retransmitted packets reaches its destination before timing out; | |
669 | and (2) the channel is not so full of forged and replayed packets so | |
670 | ||
671 | ||
672 | ||
673 | ||
674 | Kaufman Standards Track [Page 12] | |
675 | \f | |
676 | RFC 4306 IKEv2 December 2005 | |
677 | ||
678 | ||
679 | as to exhaust the network or CPU capacities of either endpoint. Even | |
680 | in the absence of those minimum performance requirements, IKE is | |
681 | designed to fail cleanly (as though the network were broken). | |
682 | ||
683 | Although IKEv2 messages are intended to be short, they contain | |
684 | structures with no hard upper bound on size (in particular, X.509 | |
685 | certificates), and IKEv2 itself does not have a mechanism for | |
686 | fragmenting large messages. IP defines a mechanism for fragmentation | |
687 | of oversize UDP messages, but implementations vary in the maximum | |
688 | message size supported. Furthermore, use of IP fragmentation opens | |
689 | an implementation to denial of service attacks [KPS03]. Finally, | |
690 | some NAT and/or firewall implementations may block IP fragments. | |
691 | ||
692 | All IKEv2 implementations MUST be able to send, receive, and process | |
693 | IKE messages that are up to 1280 bytes long, and they SHOULD be able | |
694 | to send, receive, and process messages that are up to 3000 bytes | |
695 | long. IKEv2 implementations SHOULD be aware of the maximum UDP | |
696 | message size supported and MAY shorten messages by leaving out some | |
697 | certificates or cryptographic suite proposals if that will keep | |
698 | messages below the maximum. Use of the "Hash and URL" formats rather | |
699 | than including certificates in exchanges where possible can avoid | |
700 | most problems. Implementations and configuration should keep in | |
701 | mind, however, that if the URL lookups are possible only after the | |
702 | IPsec SA is established, recursion issues could prevent this | |
703 | technique from working. | |
704 | ||
705 | 2.1. Use of Retransmission Timers | |
706 | ||
707 | All messages in IKE exist in pairs: a request and a response. The | |
708 | setup of an IKE_SA normally consists of two request/response pairs. | |
709 | Once the IKE_SA is set up, either end of the security association may | |
710 | initiate requests at any time, and there can be many requests and | |
711 | responses "in flight" at any given moment. But each message is | |
712 | labeled as either a request or a response, and for each | |
713 | request/response pair one end of the security association is the | |
714 | initiator and the other is the responder. | |
715 | ||
716 | For every pair of IKE messages, the initiator is responsible for | |
717 | retransmission in the event of a timeout. The responder MUST never | |
718 | retransmit a response unless it receives a retransmission of the | |
719 | request. In that event, the responder MUST ignore the retransmitted | |
720 | request except insofar as it triggers a retransmission of the | |
721 | response. The initiator MUST remember each request until it receives | |
722 | the corresponding response. The responder MUST remember each | |
723 | response until it receives a request whose sequence number is larger | |
724 | than the sequence number in the response plus its window size (see | |
725 | section 2.3). | |
726 | ||
727 | ||
728 | ||
729 | ||
730 | Kaufman Standards Track [Page 13] | |
731 | \f | |
732 | RFC 4306 IKEv2 December 2005 | |
733 | ||
734 | ||
735 | IKE is a reliable protocol, in the sense that the initiator MUST | |
736 | retransmit a request until either it receives a corresponding reply | |
737 | OR it deems the IKE security association to have failed and it | |
738 | discards all state associated with the IKE_SA and any CHILD_SAs | |
739 | negotiated using that IKE_SA. | |
740 | ||
741 | 2.2. Use of Sequence Numbers for Message ID | |
742 | ||
743 | Every IKE message contains a Message ID as part of its fixed header. | |
744 | This Message ID is used to match up requests and responses, and to | |
745 | identify retransmissions of messages. | |
746 | ||
747 | The Message ID is a 32-bit quantity, which is zero for the first IKE | |
748 | request in each direction. The IKE_SA initial setup messages will | |
749 | always be numbered 0 and 1. Each endpoint in the IKE Security | |
750 | Association maintains two "current" Message IDs: the next one to be | |
751 | used for a request it initiates and the next one it expects to see in | |
752 | a request from the other end. These counters increment as requests | |
753 | are generated and received. Responses always contain the same | |
754 | message ID as the corresponding request. That means that after the | |
755 | initial exchange, each integer n may appear as the message ID in four | |
756 | distinct messages: the nth request from the original IKE initiator, | |
757 | the corresponding response, the nth request from the original IKE | |
758 | responder, and the corresponding response. If the two ends make very | |
759 | different numbers of requests, the Message IDs in the two directions | |
760 | can be very different. There is no ambiguity in the messages, | |
761 | however, because the (I)nitiator and (R)esponse bits in the message | |
762 | header specify which of the four messages a particular one is. | |
763 | ||
764 | Note that Message IDs are cryptographically protected and provide | |
765 | protection against message replays. In the unlikely event that | |
766 | Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be | |
767 | closed. Rekeying an IKE_SA resets the sequence numbers. | |
768 | ||
769 | 2.3. Window Size for Overlapping Requests | |
770 | ||
771 | In order to maximize IKE throughput, an IKE endpoint MAY issue | |
772 | multiple requests before getting a response to any of them if the | |
773 | other endpoint has indicated its ability to handle such requests. | |
774 | For simplicity, an IKE implementation MAY choose to process requests | |
775 | strictly in order and/or wait for a response to one request before | |
776 | issuing another. Certain rules must be followed to ensure | |
777 | interoperability between implementations using different strategies. | |
778 | ||
779 | After an IKE_SA is set up, either end can initiate one or more | |
780 | requests. These requests may pass one another over the network. An | |
781 | IKE endpoint MUST be prepared to accept and process a request while | |
782 | ||
783 | ||
784 | ||
785 | ||
786 | Kaufman Standards Track [Page 14] | |
787 | \f | |
788 | RFC 4306 IKEv2 December 2005 | |
789 | ||
790 | ||
791 | it has a request outstanding in order to avoid a deadlock in this | |
792 | situation. An IKE endpoint SHOULD be prepared to accept and process | |
793 | multiple requests while it has a request outstanding. | |
794 | ||
795 | An IKE endpoint MUST wait for a response to each of its messages | |
796 | before sending a subsequent message unless it has received a | |
797 | SET_WINDOW_SIZE Notify message from its peer informing it that the | |
798 | peer is prepared to maintain state for multiple outstanding messages | |
799 | in order to allow greater throughput. | |
800 | ||
801 | An IKE endpoint MUST NOT exceed the peer's stated window size for | |
802 | transmitted IKE requests. In other words, if the responder stated | |
803 | its window size is N, then when the initiator needs to make a request | |
804 | X, it MUST wait until it has received responses to all requests up | |
805 | through request X-N. An IKE endpoint MUST keep a copy of (or be able | |
806 | to regenerate exactly) each request it has sent until it receives the | |
807 | corresponding response. An IKE endpoint MUST keep a copy of (or be | |
808 | able to regenerate exactly) the number of previous responses equal to | |
809 | its declared window size in case its response was lost and the | |
810 | initiator requests its retransmission by retransmitting the request. | |
811 | ||
812 | An IKE endpoint supporting a window size greater than one SHOULD be | |
813 | capable of processing incoming requests out of order to maximize | |
814 | performance in the event of network failures or packet reordering. | |
815 | ||
816 | 2.4. State Synchronization and Connection Timeouts | |
817 | ||
818 | An IKE endpoint is allowed to forget all of its state associated with | |
819 | an IKE_SA and the collection of corresponding CHILD_SAs at any time. | |
820 | This is the anticipated behavior in the event of an endpoint crash | |
821 | and restart. It is important when an endpoint either fails or | |
822 | reinitializes its state that the other endpoint detect those | |
823 | conditions and not continue to waste network bandwidth by sending | |
824 | packets over discarded SAs and having them fall into a black hole. | |
825 | ||
826 | Since IKE is designed to operate in spite of Denial of Service (DoS) | |
827 | attacks from the network, an endpoint MUST NOT conclude that the | |
828 | other endpoint has failed based on any routing information (e.g., | |
829 | ICMP messages) or IKE messages that arrive without cryptographic | |
830 | protection (e.g., Notify messages complaining about unknown SPIs). | |
831 | An endpoint MUST conclude that the other endpoint has failed only | |
832 | when repeated attempts to contact it have gone unanswered for a | |
833 | timeout period or when a cryptographically protected INITIAL_CONTACT | |
834 | notification is received on a different IKE_SA to the same | |
835 | authenticated identity. An endpoint SHOULD suspect that the other | |
836 | endpoint has failed based on routing information and initiate a | |
837 | request to see whether the other endpoint is alive. To check whether | |
838 | the other side is alive, IKE specifies an empty INFORMATIONAL message | |
839 | ||
840 | ||
841 | ||
842 | Kaufman Standards Track [Page 15] | |
843 | \f | |
844 | RFC 4306 IKEv2 December 2005 | |
845 | ||
846 | ||
847 | that (like all IKE requests) requires an acknowledgement (note that | |
848 | within the context of an IKE_SA, an "empty" message consists of an | |
849 | IKE header followed by an Encrypted payload that contains no | |
850 | payloads). If a cryptographically protected message has been | |
851 | received from the other side recently, unprotected notifications MAY | |
852 | be ignored. Implementations MUST limit the rate at which they take | |
853 | actions based on unprotected messages. | |
854 | ||
855 | Numbers of retries and lengths of timeouts are not covered in this | |
856 | specification because they do not affect interoperability. It is | |
857 | suggested that messages be retransmitted at least a dozen times over | |
858 | a period of at least several minutes before giving up on an SA, but | |
859 | different environments may require different rules. To be a good | |
860 | network citizen, retranmission times MUST increase exponentially to | |
861 | avoid flooding the network and making an existing congestion | |
862 | situation worse. If there has only been outgoing traffic on all of | |
863 | the SAs associated with an IKE_SA, it is essential to confirm | |
864 | liveness of the other endpoint to avoid black holes. If no | |
865 | cryptographically protected messages have been received on an IKE_SA | |
866 | or any of its CHILD_SAs recently, the system needs to perform a | |
867 | liveness check in order to prevent sending messages to a dead peer. | |
868 | Receipt of a fresh cryptographically protected message on an IKE_SA | |
869 | or any of its CHILD_SAs ensures liveness of the IKE_SA and all of its | |
870 | CHILD_SAs. Note that this places requirements on the failure modes | |
871 | of an IKE endpoint. An implementation MUST NOT continue sending on | |
872 | any SA if some failure prevents it from receiving on all of the | |
873 | associated SAs. If CHILD_SAs can fail independently from one another | |
874 | without the associated IKE_SA being able to send a delete message, | |
875 | then they MUST be negotiated by separate IKE_SAs. | |
876 | ||
877 | There is a Denial of Service attack on the initiator of an IKE_SA | |
878 | that can be avoided if the initiator takes the proper care. Since | |
879 | the first two messages of an SA setup are not cryptographically | |
880 | protected, an attacker could respond to the initiator's message | |
881 | before the genuine responder and poison the connection setup attempt. | |
882 | To prevent this, the initiator MAY be willing to accept multiple | |
883 | responses to its first message, treat each as potentially legitimate, | |
884 | respond to it, and then discard all the invalid half-open connections | |
885 | when it receives a valid cryptographically protected response to any | |
886 | one of its requests. Once a cryptographically valid response is | |
887 | received, all subsequent responses should be ignored whether or not | |
888 | they are cryptographically valid. | |
889 | ||
890 | Note that with these rules, there is no reason to negotiate and agree | |
891 | upon an SA lifetime. If IKE presumes the partner is dead, based on | |
892 | repeated lack of acknowledgement to an IKE message, then the IKE SA | |
893 | and all CHILD_SAs set up through that IKE_SA are deleted. | |
894 | ||
895 | ||
896 | ||
897 | ||
898 | Kaufman Standards Track [Page 16] | |
899 | \f | |
900 | RFC 4306 IKEv2 December 2005 | |
901 | ||
902 | ||
903 | An IKE endpoint may at any time delete inactive CHILD_SAs to recover | |
904 | resources used to hold their state. If an IKE endpoint chooses to | |
905 | delete CHILD_SAs, it MUST send Delete payloads to the other end | |
906 | notifying it of the deletion. It MAY similarly time out the IKE_SA. | |
907 | Closing the IKE_SA implicitly closes all associated CHILD_SAs. In | |
908 | this case, an IKE endpoint SHOULD send a Delete payload indicating | |
909 | that it has closed the IKE_SA. | |
910 | ||
911 | 2.5. Version Numbers and Forward Compatibility | |
912 | ||
913 | This document describes version 2.0 of IKE, meaning the major version | |
914 | number is 2 and the minor version number is zero. It is likely that | |
915 | some implementations will want to support both version 1.0 and | |
916 | version 2.0, and in the future, other versions. | |
917 | ||
918 | The major version number should be incremented only if the packet | |
919 | formats or required actions have changed so dramatically that an | |
920 | older version node would not be able to interoperate with a newer | |
921 | version node if it simply ignored the fields it did not understand | |
922 | and took the actions specified in the older specification. The minor | |
923 | version number indicates new capabilities, and MUST be ignored by a | |
924 | node with a smaller minor version number, but used for informational | |
925 | purposes by the node with the larger minor version number. For | |
926 | example, it might indicate the ability to process a newly defined | |
927 | notification message. The node with the larger minor version number | |
928 | would simply note that its correspondent would not be able to | |
929 | understand that message and therefore would not send it. | |
930 | ||
931 | If an endpoint receives a message with a higher major version number, | |
932 | it MUST drop the message and SHOULD send an unauthenticated | |
933 | notification message containing the highest version number it | |
934 | supports. If an endpoint supports major version n, and major version | |
935 | m, it MUST support all versions between n and m. If it receives a | |
936 | message with a major version that it supports, it MUST respond with | |
937 | that version number. In order to prevent two nodes from being | |
938 | tricked into corresponding with a lower major version number than the | |
939 | maximum that they both support, IKE has a flag that indicates that | |
940 | the node is capable of speaking a higher major version number. | |
941 | ||
942 | Thus, the major version number in the IKE header indicates the | |
943 | version number of the message, not the highest version number that | |
944 | the transmitter supports. If the initiator is capable of speaking | |
945 | versions n, n+1, and n+2, and the responder is capable of speaking | |
946 | versions n and n+1, then they will negotiate speaking n+1, where the | |
947 | initiator will set the flag indicating its ability to speak a higher | |
948 | version. If they mistakenly (perhaps through an active attacker | |
949 | ||
950 | ||
951 | ||
952 | ||
953 | ||
954 | Kaufman Standards Track [Page 17] | |
955 | \f | |
956 | RFC 4306 IKEv2 December 2005 | |
957 | ||
958 | ||
959 | sending error messages) negotiate to version n, then both will notice | |
960 | that the other side can support a higher version number, and they | |
961 | MUST break the connection and reconnect using version n+1. | |
962 | ||
963 | Note that IKEv1 does not follow these rules, because there is no way | |
964 | in v1 of noting that you are capable of speaking a higher version | |
965 | number. So an active attacker can trick two v2-capable nodes into | |
966 | speaking v1. When a v2-capable node negotiates down to v1, it SHOULD | |
967 | note that fact in its logs. | |
968 | ||
969 | Also for forward compatibility, all fields marked RESERVED MUST be | |
970 | set to zero by a version 2.0 implementation and their content MUST be | |
971 | ignored by a version 2.0 implementation ("Be conservative in what you | |
972 | send and liberal in what you receive"). In this way, future versions | |
973 | of the protocol can use those fields in a way that is guaranteed to | |
974 | be ignored by implementations that do not understand them. | |
975 | Similarly, payload types that are not defined are reserved for future | |
976 | use; implementations of version 2.0 MUST skip over those payloads and | |
977 | ignore their contents. | |
978 | ||
979 | IKEv2 adds a "critical" flag to each payload header for further | |
980 | flexibility for forward compatibility. If the critical flag is set | |
981 | and the payload type is unrecognized, the message MUST be rejected | |
982 | and the response to the IKE request containing that payload MUST | |
983 | include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an | |
984 | unsupported critical payload was included. If the critical flag is | |
985 | not set and the payload type is unsupported, that payload MUST be | |
986 | ignored. | |
987 | ||
988 | Although new payload types may be added in the future and may appear | |
989 | interleaved with the fields defined in this specification, | |
990 | implementations MUST send the payloads defined in this specification | |
991 | in the order shown in the figures in section 2 and implementations | |
992 | SHOULD reject as invalid a message with those payloads in any other | |
993 | order. | |
994 | ||
995 | 2.6. Cookies | |
996 | ||
997 | The term "cookies" originates with Karn and Simpson [RFC2522] in | |
998 | Photuris, an early proposal for key management with IPsec, and it has | |
999 | persisted. The Internet Security Association and Key Management | |
1000 | Protocol (ISAKMP) [MSST98] fixed message header includes two eight- | |
1001 | octet fields titled "cookies", and that syntax is used by both IKEv1 | |
1002 | and IKEv2 though in IKEv2 they are referred to as the IKE SPI and | |
1003 | there is a new separate field in a Notify payload holding the cookie. | |
1004 | The initial two eight-octet fields in the header are used as a | |
1005 | connection identifier at the beginning of IKE packets. Each endpoint | |
1006 | ||
1007 | ||
1008 | ||
1009 | ||
1010 | Kaufman Standards Track [Page 18] | |
1011 | \f | |
1012 | RFC 4306 IKEv2 December 2005 | |
1013 | ||
1014 | ||
1015 | chooses one of the two SPIs and SHOULD choose them so as to be unique | |
1016 | identifiers of an IKE_SA. An SPI value of zero is special and | |
1017 | indicates that the remote SPI value is not yet known by the sender. | |
1018 | ||
1019 | Unlike ESP and AH where only the recipient's SPI appears in the | |
1020 | header of a message, in IKE the sender's SPI is also sent in every | |
1021 | message. Since the SPI chosen by the original initiator of the | |
1022 | IKE_SA is always sent first, an endpoint with multiple IKE_SAs open | |
1023 | that wants to find the appropriate IKE_SA using the SPI it assigned | |
1024 | must look at the I(nitiator) Flag bit in the header to determine | |
1025 | whether it assigned the first or the second eight octets. | |
1026 | ||
1027 | In the first message of an initial IKE exchange, the initiator will | |
1028 | not know the responder's SPI value and will therefore set that field | |
1029 | to zero. | |
1030 | ||
1031 | An expected attack against IKE is state and CPU exhaustion, where the | |
1032 | target is flooded with session initiation requests from forged IP | |
1033 | addresses. This attack can be made less effective if an | |
1034 | implementation of a responder uses minimal CPU and commits no state | |
1035 | to an SA until it knows the initiator can receive packets at the | |
1036 | address from which it claims to be sending them. To accomplish this, | |
1037 | a responder SHOULD -- when it detects a large number of half-open | |
1038 | IKE_SAs -- reject initial IKE messages unless they contain a Notify | |
1039 | payload of type COOKIE. It SHOULD instead send an unprotected IKE | |
1040 | message as a response and include COOKIE Notify payload with the | |
1041 | cookie data to be returned. Initiators who receive such responses | |
1042 | MUST retry the IKE_SA_INIT with a Notify payload of type COOKIE | |
1043 | containing the responder supplied cookie data as the first payload | |
1044 | and all other payloads unchanged. The initial exchange will then be | |
1045 | as follows: | |
1046 | ||
1047 | Initiator Responder | |
1048 | ----------- ----------- | |
1049 | HDR(A,0), SAi1, KEi, Ni --> | |
1050 | ||
1051 | <-- HDR(A,0), N(COOKIE) | |
1052 | ||
1053 | HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> | |
1054 | ||
1055 | <-- HDR(A,B), SAr1, KEr, Nr, [CERTREQ] | |
1056 | ||
1057 | HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,] | |
1058 | AUTH, SAi2, TSi, TSr} --> | |
1059 | ||
1060 | <-- HDR(A,B), SK {IDr, [CERT,] AUTH, | |
1061 | SAr2, TSi, TSr} | |
1062 | ||
1063 | ||
1064 | ||
1065 | ||
1066 | Kaufman Standards Track [Page 19] | |
1067 | \f | |
1068 | RFC 4306 IKEv2 December 2005 | |
1069 | ||
1070 | ||
1071 | The first two messages do not affect any initiator or responder state | |
1072 | except for communicating the cookie. In particular, the message | |
1073 | sequence numbers in the first four messages will all be zero and the | |
1074 | message sequence numbers in the last two messages will be one. 'A' is | |
1075 | the SPI assigned by the initiator, while 'B' is the SPI assigned by | |
1076 | the responder. | |
1077 | ||
1078 | An IKE implementation SHOULD implement its responder cookie | |
1079 | generation in such a way as to not require any saved state to | |
1080 | recognize its valid cookie when the second IKE_SA_INIT message | |
1081 | arrives. The exact algorithms and syntax they use to generate | |
1082 | cookies do not affect interoperability and hence are not specified | |
1083 | here. The following is an example of how an endpoint could use | |
1084 | cookies to implement limited DOS protection. | |
1085 | ||
1086 | A good way to do this is to set the responder cookie to be: | |
1087 | ||
1088 | Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>) | |
1089 | ||
1090 | where <secret> is a randomly generated secret known only to the | |
1091 | responder and periodically changed and | indicates concatenation. | |
1092 | <VersionIDofSecret> should be changed whenever <secret> is | |
1093 | regenerated. The cookie can be recomputed when the IKE_SA_INIT | |
1094 | arrives the second time and compared to the cookie in the received | |
1095 | message. If it matches, the responder knows that the cookie was | |
1096 | generated since the last change to <secret> and that IPi must be the | |
1097 | same as the source address it saw the first time. Incorporating SPIi | |
1098 | into the calculation ensures that if multiple IKE_SAs are being set | |
1099 | up in parallel they will all get different cookies (assuming the | |
1100 | initiator chooses unique SPIi's). Incorporating Ni into the hash | |
1101 | ensures that an attacker who sees only message 2 can't successfully | |
1102 | forge a message 3. | |
1103 | ||
1104 | If a new value for <secret> is chosen while there are connections in | |
1105 | the process of being initialized, an IKE_SA_INIT might be returned | |
1106 | with other than the current <VersionIDofSecret>. The responder in | |
1107 | that case MAY reject the message by sending another response with a | |
1108 | new cookie or it MAY keep the old value of <secret> around for a | |
1109 | short time and accept cookies computed from either one. The | |
1110 | responder SHOULD NOT accept cookies indefinitely after <secret> is | |
1111 | changed, since that would defeat part of the denial of service | |
1112 | protection. The responder SHOULD change the value of <secret> | |
1113 | frequently, especially if under attack. | |
1114 | ||
1115 | ||
1116 | ||
1117 | ||
1118 | ||
1119 | ||
1120 | ||
1121 | ||
1122 | Kaufman Standards Track [Page 20] | |
1123 | \f | |
1124 | RFC 4306 IKEv2 December 2005 | |
1125 | ||
1126 | ||
1127 | 2.7. Cryptographic Algorithm Negotiation | |
1128 | ||
1129 | The payload type known as "SA" indicates a proposal for a set of | |
1130 | choices of IPsec protocols (IKE, ESP, and/or AH) for the SA as well | |
1131 | as cryptographic algorithms associated with each protocol. | |
1132 | ||
1133 | An SA payload consists of one or more proposals. Each proposal | |
1134 | includes one or more protocols (usually one). Each protocol contains | |
1135 | one or more transforms -- each specifying a cryptographic algorithm. | |
1136 | Each transform contains zero or more attributes (attributes are | |
1137 | needed only if the transform identifier does not completely specify | |
1138 | the cryptographic algorithm). | |
1139 | ||
1140 | This hierarchical structure was designed to efficiently encode | |
1141 | proposals for cryptographic suites when the number of supported | |
1142 | suites is large because multiple values are acceptable for multiple | |
1143 | transforms. The responder MUST choose a single suite, which MAY be | |
1144 | any subset of the SA proposal following the rules below: | |
1145 | ||
1146 | Each proposal contains one or more protocols. If a proposal is | |
1147 | accepted, the SA response MUST contain the same protocols in the | |
1148 | same order as the proposal. The responder MUST accept a single | |
1149 | proposal or reject them all and return an error. (Example: if a | |
1150 | single proposal contains ESP and AH and that proposal is accepted, | |
1151 | both ESP and AH MUST be accepted. If ESP and AH are included in | |
1152 | separate proposals, the responder MUST accept only one of them). | |
1153 | ||
1154 | Each IPsec protocol proposal contains one or more transforms. | |
1155 | Each transform contains a transform type. The accepted | |
1156 | cryptographic suite MUST contain exactly one transform of each | |
1157 | type included in the proposal. For example: if an ESP proposal | |
1158 | includes transforms ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES | |
1159 | w/keysize 256, AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted | |
1160 | suite MUST contain one of the ENCR_ transforms and one of the | |
1161 | AUTH_ transforms. Thus, six combinations are acceptable. | |
1162 | ||
1163 | Since the initiator sends its Diffie-Hellman value in the | |
1164 | IKE_SA_INIT, it must guess the Diffie-Hellman group that the | |
1165 | responder will select from its list of supported groups. If the | |
1166 | initiator guesses wrong, the responder will respond with a Notify | |
1167 | payload of type INVALID_KE_PAYLOAD indicating the selected group. In | |
1168 | this case, the initiator MUST retry the IKE_SA_INIT with the | |
1169 | corrected Diffie-Hellman group. The initiator MUST again propose its | |
1170 | full set of acceptable cryptographic suites because the rejection | |
1171 | message was unauthenticated and otherwise an active attacker could | |
1172 | trick the endpoints into negotiating a weaker suite than a stronger | |
1173 | one that they both prefer. | |
1174 | ||
1175 | ||
1176 | ||
1177 | ||
1178 | Kaufman Standards Track [Page 21] | |
1179 | \f | |
1180 | RFC 4306 IKEv2 December 2005 | |
1181 | ||
1182 | ||
1183 | 2.8. Rekeying | |
1184 | ||
1185 | IKE, ESP, and AH security associations use secret keys that SHOULD be | |
1186 | used only for a limited amount of time and to protect a limited | |
1187 | amount of data. This limits the lifetime of the entire security | |
1188 | association. When the lifetime of a security association expires, | |
1189 | the security association MUST NOT be used. If there is demand, new | |
1190 | security associations MAY be established. Reestablishment of | |
1191 | security associations to take the place of ones that expire is | |
1192 | referred to as "rekeying". | |
1193 | ||
1194 | To allow for minimal IPsec implementations, the ability to rekey SAs | |
1195 | without restarting the entire IKE_SA is optional. An implementation | |
1196 | MAY refuse all CREATE_CHILD_SA requests within an IKE_SA. If an SA | |
1197 | has expired or is about to expire and rekeying attempts using the | |
1198 | mechanisms described here fail, an implementation MUST close the | |
1199 | IKE_SA and any associated CHILD_SAs and then MAY start new ones. | |
1200 | Implementations SHOULD support in-place rekeying of SAs, since doing | |
1201 | so offers better performance and is likely to reduce the number of | |
1202 | packets lost during the transition. | |
1203 | ||
1204 | To rekey a CHILD_SA within an existing IKE_SA, create a new, | |
1205 | equivalent SA (see section 2.17 below), and when the new one is | |
1206 | established, delete the old one. To rekey an IKE_SA, establish a new | |
1207 | equivalent IKE_SA (see section 2.18 below) with the peer to whom the | |
1208 | old IKE_SA is shared using a CREATE_CHILD_SA within the existing | |
1209 | IKE_SA. An IKE_SA so created inherits all of the original IKE_SA's | |
1210 | CHILD_SAs. Use the new IKE_SA for all control messages needed to | |
1211 | maintain the CHILD_SAs created by the old IKE_SA, and delete the old | |
1212 | IKE_SA. The Delete payload to delete itself MUST be the last request | |
1213 | sent over an IKE_SA. | |
1214 | ||
1215 | SAs SHOULD be rekeyed proactively, i.e., the new SA should be | |
1216 | established before the old one expires and becomes unusable. Enough | |
1217 | time should elapse between the time the new SA is established and the | |
1218 | old one becomes unusable so that traffic can be switched over to the | |
1219 | new SA. | |
1220 | ||
1221 | A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes | |
1222 | were negotiated. In IKEv2, each end of the SA is responsible for | |
1223 | enforcing its own lifetime policy on the SA and rekeying the SA when | |
1224 | necessary. If the two ends have different lifetime policies, the end | |
1225 | with the shorter lifetime will end up always being the one to request | |
1226 | the rekeying. If an SA bundle has been inactive for a long time and | |
1227 | if an endpoint would not initiate the SA in the absence of traffic, | |
1228 | the endpoint MAY choose to close the SA instead of rekeying it when | |
1229 | its lifetime expires. It SHOULD do so if there has been no traffic | |
1230 | since the last time the SA was rekeyed. | |
1231 | ||
1232 | ||
1233 | ||
1234 | Kaufman Standards Track [Page 22] | |
1235 | \f | |
1236 | RFC 4306 IKEv2 December 2005 | |
1237 | ||
1238 | ||
1239 | If the two ends have the same lifetime policies, it is possible that | |
1240 | both will initiate a rekeying at the same time (which will result in | |
1241 | redundant SAs). To reduce the probability of this happening, the | |
1242 | timing of rekeying requests SHOULD be jittered (delayed by a random | |
1243 | amount of time after the need for rekeying is noticed). | |
1244 | ||
1245 | This form of rekeying may temporarily result in multiple similar SAs | |
1246 | between the same pairs of nodes. When there are two SAs eligible to | |
1247 | receive packets, a node MUST accept incoming packets through either | |
1248 | SA. If redundant SAs are created though such a collision, the SA | |
1249 | created with the lowest of the four nonces used in the two exchanges | |
1250 | SHOULD be closed by the endpoint that created it. | |
1251 | ||
1252 | Note that IKEv2 deliberately allows parallel SAs with the same | |
1253 | traffic selectors between common endpoints. One of the purposes of | |
1254 | this is to support traffic quality of service (QoS) differences among | |
1255 | the SAs (see [RFC2474], [RFC2475], and section 4.1 of [RFC2983]). | |
1256 | Hence unlike IKEv1, the combination of the endpoints and the traffic | |
1257 | selectors may not uniquely identify an SA between those endpoints, so | |
1258 | the IKEv1 rekeying heuristic of deleting SAs on the basis of | |
1259 | duplicate traffic selectors SHOULD NOT be used. | |
1260 | ||
1261 | The node that initiated the surviving rekeyed SA SHOULD delete the | |
1262 | replaced SA after the new one is established. | |
1263 | ||
1264 | There are timing windows -- particularly in the presence of lost | |
1265 | packets -- where endpoints may not agree on the state of an SA. The | |
1266 | responder to a CREATE_CHILD_SA MUST be prepared to accept messages on | |
1267 | an SA before sending its response to the creation request, so there | |
1268 | is no ambiguity for the initiator. The initiator MAY begin sending | |
1269 | on an SA as soon as it processes the response. The initiator, | |
1270 | however, cannot receive on a newly created SA until it receives and | |
1271 | processes the response to its CREATE_CHILD_SA request. How, then, is | |
1272 | the responder to know when it is OK to send on the newly created SA? | |
1273 | ||
1274 | From a technical correctness and interoperability perspective, the | |
1275 | responder MAY begin sending on an SA as soon as it sends its response | |
1276 | to the CREATE_CHILD_SA request. In some situations, however, this | |
1277 | could result in packets unnecessarily being dropped, so an | |
1278 | implementation MAY want to defer such sending. | |
1279 | ||
1280 | The responder can be assured that the initiator is prepared to | |
1281 | receive messages on an SA if either (1) it has received a | |
1282 | cryptographically valid message on the new SA, or (2) the new SA | |
1283 | rekeys an existing SA and it receives an IKE request to close the | |
1284 | replaced SA. When rekeying an SA, the responder SHOULD continue to | |
1285 | send messages on the old SA until one of those events occurs. When | |
1286 | establishing a new SA, the responder MAY defer sending messages on a | |
1287 | ||
1288 | ||
1289 | ||
1290 | Kaufman Standards Track [Page 23] | |
1291 | \f | |
1292 | RFC 4306 IKEv2 December 2005 | |
1293 | ||
1294 | ||
1295 | new SA until either it receives one or a timeout has occurred. If an | |
1296 | initiator receives a message on an SA for which it has not received a | |
1297 | response to its CREATE_CHILD_SA request, it SHOULD interpret that as | |
1298 | a likely packet loss and retransmit the CREATE_CHILD_SA request. An | |
1299 | initiator MAY send a dummy message on a newly created SA if it has no | |
1300 | messages queued in order to assure the responder that the initiator | |
1301 | is ready to receive messages. | |
1302 | ||
1303 | 2.9. Traffic Selector Negotiation | |
1304 | ||
1305 | When an IP packet is received by an RFC4301-compliant IPsec subsystem | |
1306 | and matches a "protect" selector in its Security Policy Database | |
1307 | (SPD), the subsystem MUST protect that packet with IPsec. When no SA | |
1308 | exists yet, it is the task of IKE to create it. Maintenance of a | |
1309 | system's SPD is outside the scope of IKE (see [PFKEY] for an example | |
1310 | protocol), though some implementations might update their SPD in | |
1311 | connection with the running of IKE (for an example scenario, see | |
1312 | section 1.1.3). | |
1313 | ||
1314 | Traffic Selector (TS) payloads allow endpoints to communicate some of | |
1315 | the information from their SPD to their peers. TS payloads specify | |
1316 | the selection criteria for packets that will be forwarded over the | |
1317 | newly set up SA. This can serve as a consistency check in some | |
1318 | scenarios to assure that the SPDs are consistent. In others, it | |
1319 | guides the dynamic update of the SPD. | |
1320 | ||
1321 | Two TS payloads appear in each of the messages in the exchange that | |
1322 | creates a CHILD_SA pair. Each TS payload contains one or more | |
1323 | Traffic Selectors. Each Traffic Selector consists of an address | |
1324 | range (IPv4 or IPv6), a port range, and an IP protocol ID. In | |
1325 | support of the scenario described in section 1.1.3, an initiator may | |
1326 | request that the responder assign an IP address and tell the | |
1327 | initiator what it is. | |
1328 | ||
1329 | IKEv2 allows the responder to choose a subset of the traffic proposed | |
1330 | by the initiator. This could happen when the configurations of the | |
1331 | two endpoints are being updated but only one end has received the new | |
1332 | information. Since the two endpoints may be configured by different | |
1333 | people, the incompatibility may persist for an extended period even | |
1334 | in the absence of errors. It also allows for intentionally different | |
1335 | configurations, as when one end is configured to tunnel all addresses | |
1336 | and depends on the other end to have the up-to-date list. | |
1337 | ||
1338 | The first of the two TS payloads is known as TSi (Traffic Selector- | |
1339 | initiator). The second is known as TSr (Traffic Selector-responder). | |
1340 | TSi specifies the source address of traffic forwarded from (or the | |
1341 | destination address of traffic forwarded to) the initiator of the | |
1342 | CHILD_SA pair. TSr specifies the destination address of the traffic | |
1343 | ||
1344 | ||
1345 | ||
1346 | Kaufman Standards Track [Page 24] | |
1347 | \f | |
1348 | RFC 4306 IKEv2 December 2005 | |
1349 | ||
1350 | ||
1351 | forwarded to (or the source address of the traffic forwarded from) | |
1352 | the responder of the CHILD_SA pair. For example, if the original | |
1353 | initiator request the creation of a CHILD_SA pair, and wishes to | |
1354 | tunnel all traffic from subnet 192.0.1.* on the initiator's side to | |
1355 | subnet 192.0.2.* on the responder's side, the initiator would include | |
1356 | a single traffic selector in each TS payload. TSi would specify the | |
1357 | address range (192.0.1.0 - 192.0.1.255) and TSr would specify the | |
1358 | address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was | |
1359 | acceptable to the responder, it would send identical TS payloads | |
1360 | back. (Note: The IP address range 192.0.2.* has been reserved for | |
1361 | use in examples in RFCs and similar documents. This document needed | |
1362 | two such ranges, and so also used 192.0.1.*. This should not be | |
1363 | confused with any actual address.) | |
1364 | ||
1365 | The responder is allowed to narrow the choices by selecting a subset | |
1366 | of the traffic, for instance by eliminating or narrowing the range of | |
1367 | one or more members of the set of traffic selectors, provided the set | |
1368 | does not become the NULL set. | |
1369 | ||
1370 | It is possible for the responder's policy to contain multiple smaller | |
1371 | ranges, all encompassed by the initiator's traffic selector, and with | |
1372 | the responder's policy being that each of those ranges should be sent | |
1373 | over a different SA. Continuing the example above, the responder | |
1374 | might have a policy of being willing to tunnel those addresses to and | |
1375 | from the initiator, but might require that each address pair be on a | |
1376 | separately negotiated CHILD_SA. If the initiator generated its | |
1377 | request in response to an incoming packet from 192.0.1.43 to | |
1378 | 192.0.2.123, there would be no way for the responder to determine | |
1379 | which pair of addresses should be included in this tunnel, and it | |
1380 | would have to make a guess or reject the request with a status of | |
1381 | SINGLE_PAIR_REQUIRED. | |
1382 | ||
1383 | To enable the responder to choose the appropriate range in this case, | |
1384 | if the initiator has requested the SA due to a data packet, the | |
1385 | initiator SHOULD include as the first traffic selector in each of TSi | |
1386 | and TSr a very specific traffic selector including the addresses in | |
1387 | the packet triggering the request. In the example, the initiator | |
1388 | would include in TSi two traffic selectors: the first containing the | |
1389 | address range (192.0.1.43 - 192.0.1.43) and the source port and IP | |
1390 | protocol from the packet and the second containing (192.0.1.0 - | |
1391 | 192.0.1.255) with all ports and IP protocols. The initiator would | |
1392 | similarly include two traffic selectors in TSr. | |
1393 | ||
1394 | If the responder's policy does not allow it to accept the entire set | |
1395 | of traffic selectors in the initiator's request, but does allow him | |
1396 | to accept the first selector of TSi and TSr, then the responder MUST | |
1397 | narrow the traffic selectors to a subset that includes the | |
1398 | ||
1399 | ||
1400 | ||
1401 | ||
1402 | Kaufman Standards Track [Page 25] | |
1403 | \f | |
1404 | RFC 4306 IKEv2 December 2005 | |
1405 | ||
1406 | ||
1407 | initiator's first choices. In this example, the responder might | |
1408 | respond with TSi being (192.0.1.43 - 192.0.1.43) with all ports and | |
1409 | IP protocols. | |
1410 | ||
1411 | If the initiator creates the CHILD_SA pair not in response to an | |
1412 | arriving packet, but rather, say, upon startup, then there may be no | |
1413 | specific addresses the initiator prefers for the initial tunnel over | |
1414 | any other. In that case, the first values in TSi and TSr MAY be | |
1415 | ranges rather than specific values, and the responder chooses a | |
1416 | subset of the initiator's TSi and TSr that are acceptable. If more | |
1417 | than one subset is acceptable but their union is not, the responder | |
1418 | MUST accept some subset and MAY include a Notify payload of type | |
1419 | ADDITIONAL_TS_POSSIBLE to indicate that the initiator might want to | |
1420 | try again. This case will occur only when the initiator and | |
1421 | responder are configured differently from one another. If the | |
1422 | initiator and responder agree on the granularity of tunnels, the | |
1423 | initiator will never request a tunnel wider than the responder will | |
1424 | accept. Such misconfigurations SHOULD be recorded in error logs. | |
1425 | ||
1426 | 2.10. Nonces | |
1427 | ||
1428 | The IKE_SA_INIT messages each contain a nonce. These nonces are used | |
1429 | as inputs to cryptographic functions. The CREATE_CHILD_SA request | |
1430 | and the CREATE_CHILD_SA response also contain nonces. These nonces | |
1431 | are used to add freshness to the key derivation technique used to | |
1432 | obtain keys for CHILD_SA, and to ensure creation of strong pseudo- | |
1433 | random bits from the Diffie-Hellman key. Nonces used in IKEv2 MUST | |
1434 | be randomly chosen, MUST be at least 128 bits in size, and MUST be at | |
1435 | least half the key size of the negotiated prf. ("prf" refers to | |
1436 | "pseudo-random function", one of the cryptographic algorithms | |
1437 | negotiated in the IKE exchange.) If the same random number source is | |
1438 | used for both keys and nonces, care must be taken to ensure that the | |
1439 | latter use does not compromise the former. | |
1440 | ||
1441 | 2.11. Address and Port Agility | |
1442 | ||
1443 | IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and | |
1444 | AH associations for the same IP addresses it runs over. The IP | |
1445 | addresses and ports in the outer header are, however, not themselves | |
1446 | cryptographically protected, and IKE is designed to work even through | |
1447 | Network Address Translation (NAT) boxes. An implementation MUST | |
1448 | accept incoming requests even if the source port is not 500 or 4500, | |
1449 | and MUST respond to the address and port from which the request was | |
1450 | received. It MUST specify the address and port at which the request | |
1451 | was received as the source address and port in the response. IKE | |
1452 | functions identically over IPv4 or IPv6. | |
1453 | ||
1454 | ||
1455 | ||
1456 | ||
1457 | ||
1458 | Kaufman Standards Track [Page 26] | |
1459 | \f | |
1460 | RFC 4306 IKEv2 December 2005 | |
1461 | ||
1462 | ||
1463 | 2.12. Reuse of Diffie-Hellman Exponentials | |
1464 | ||
1465 | IKE generates keying material using an ephemeral Diffie-Hellman | |
1466 | exchange in order to gain the property of "perfect forward secrecy". | |
1467 | This means that once a connection is closed and its corresponding | |
1468 | keys are forgotten, even someone who has recorded all of the data | |
1469 | from the connection and gets access to all of the long-term keys of | |
1470 | the two endpoints cannot reconstruct the keys used to protect the | |
1471 | conversation without doing a brute force search of the session key | |
1472 | space. | |
1473 | ||
1474 | Achieving perfect forward secrecy requires that when a connection is | |
1475 | closed, each endpoint MUST forget not only the keys used by the | |
1476 | connection but also any information that could be used to recompute | |
1477 | those keys. In particular, it MUST forget the secrets used in the | |
1478 | Diffie-Hellman calculation and any state that may persist in the | |
1479 | state of a pseudo-random number generator that could be used to | |
1480 | recompute the Diffie-Hellman secrets. | |
1481 | ||
1482 | Since the computing of Diffie-Hellman exponentials is computationally | |
1483 | expensive, an endpoint may find it advantageous to reuse those | |
1484 | exponentials for multiple connection setups. There are several | |
1485 | reasonable strategies for doing this. An endpoint could choose a new | |
1486 | exponential only periodically though this could result in less-than- | |
1487 | perfect forward secrecy if some connection lasts for less than the | |
1488 | lifetime of the exponential. Or it could keep track of which | |
1489 | exponential was used for each connection and delete the information | |
1490 | associated with the exponential only when some corresponding | |
1491 | connection was closed. This would allow the exponential to be reused | |
1492 | without losing perfect forward secrecy at the cost of maintaining | |
1493 | more state. | |
1494 | ||
1495 | Decisions as to whether and when to reuse Diffie-Hellman exponentials | |
1496 | is a private decision in the sense that it will not affect | |
1497 | interoperability. An implementation that reuses exponentials MAY | |
1498 | choose to remember the exponential used by the other endpoint on past | |
1499 | exchanges and if one is reused to avoid the second half of the | |
1500 | calculation. | |
1501 | ||
1502 | 2.13. Generating Keying Material | |
1503 | ||
1504 | In the context of the IKE_SA, four cryptographic algorithms are | |
1505 | negotiated: an encryption algorithm, an integrity protection | |
1506 | algorithm, a Diffie-Hellman group, and a pseudo-random function | |
1507 | (prf). The pseudo-random function is used for the construction of | |
1508 | keying material for all of the cryptographic algorithms used in both | |
1509 | the IKE_SA and the CHILD_SAs. | |
1510 | ||
1511 | ||
1512 | ||
1513 | ||
1514 | Kaufman Standards Track [Page 27] | |
1515 | \f | |
1516 | RFC 4306 IKEv2 December 2005 | |
1517 | ||
1518 | ||
1519 | We assume that each encryption algorithm and integrity protection | |
1520 | algorithm uses a fixed-size key and that any randomly chosen value of | |
1521 | that fixed size can serve as an appropriate key. For algorithms that | |
1522 | accept a variable length key, a fixed key size MUST be specified as | |
1523 | part of the cryptographic transform negotiated. For algorithms for | |
1524 | which not all values are valid keys (such as DES or 3DES with key | |
1525 | parity), the algorithm by which keys are derived from arbitrary | |
1526 | values MUST be specified by the cryptographic transform. For | |
1527 | integrity protection functions based on Hashed Message Authentication | |
1528 | Code (HMAC), the fixed key size is the size of the output of the | |
1529 | underlying hash function. When the prf function takes a variable | |
1530 | length key, variable length data, and produces a fixed-length output | |
1531 | (e.g., when using HMAC), the formulas in this document apply. When | |
1532 | the key for the prf function has fixed length, the data provided as a | |
1533 | key is truncated or padded with zeros as necessary unless exceptional | |
1534 | processing is explained following the formula. | |
1535 | ||
1536 | Keying material will always be derived as the output of the | |
1537 | negotiated prf algorithm. Since the amount of keying material needed | |
1538 | may be greater than the size of the output of the prf algorithm, we | |
1539 | will use the prf iteratively. We will use the terminology prf+ to | |
1540 | describe the function that outputs a pseudo-random stream based on | |
1541 | the inputs to a prf as follows: (where | indicates concatenation) | |
1542 | ||
1543 | prf+ (K,S) = T1 | T2 | T3 | T4 | ... | |
1544 | ||
1545 | where: | |
1546 | T1 = prf (K, S | 0x01) | |
1547 | T2 = prf (K, T1 | S | 0x02) | |
1548 | T3 = prf (K, T2 | S | 0x03) | |
1549 | T4 = prf (K, T3 | S | 0x04) | |
1550 | ||
1551 | continuing as needed to compute all required keys. The keys are | |
1552 | taken from the output string without regard to boundaries (e.g., if | |
1553 | the required keys are a 256-bit Advanced Encryption Standard (AES) | |
1554 | key and a 160-bit HMAC key, and the prf function generates 160 bits, | |
1555 | the AES key will come from T1 and the beginning of T2, while the HMAC | |
1556 | key will come from the rest of T2 and the beginning of T3). | |
1557 | ||
1558 | The constant concatenated to the end of each string feeding the prf | |
1559 | is a single octet. prf+ in this document is not defined beyond 255 | |
1560 | times the size of the prf output. | |
1561 | ||
1562 | 2.14. Generating Keying Material for the IKE_SA | |
1563 | ||
1564 | The shared keys are computed as follows. A quantity called SKEYSEED | |
1565 | is calculated from the nonces exchanged during the IKE_SA_INIT | |
1566 | exchange and the Diffie-Hellman shared secret established during that | |
1567 | ||
1568 | ||
1569 | ||
1570 | Kaufman Standards Track [Page 28] | |
1571 | \f | |
1572 | RFC 4306 IKEv2 December 2005 | |
1573 | ||
1574 | ||
1575 | exchange. SKEYSEED is used to calculate seven other secrets: SK_d | |
1576 | used for deriving new keys for the CHILD_SAs established with this | |
1577 | IKE_SA; SK_ai and SK_ar used as a key to the integrity protection | |
1578 | algorithm for authenticating the component messages of subsequent | |
1579 | exchanges; SK_ei and SK_er used for encrypting (and of course | |
1580 | decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are | |
1581 | used when generating an AUTH payload. | |
1582 | ||
1583 | SKEYSEED and its derivatives are computed as follows: | |
1584 | ||
1585 | SKEYSEED = prf(Ni | Nr, g^ir) | |
1586 | ||
1587 | {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } = prf+ | |
1588 | (SKEYSEED, Ni | Nr | SPIi | SPIr ) | |
1589 | ||
1590 | (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, | |
1591 | SK_pi, and SK_pr are taken in order from the generated bits of the | |
1592 | prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman | |
1593 | exchange. g^ir is represented as a string of octets in big endian | |
1594 | order padded with zeros if necessary to make it the length of the | |
1595 | modulus. Ni and Nr are the nonces, stripped of any headers. If the | |
1596 | negotiated prf takes a fixed-length key and the lengths of Ni and Nr | |
1597 | do not add up to that length, half the bits must come from Ni and | |
1598 | half from Nr, taking the first bits of each. | |
1599 | ||
1600 | The two directions of traffic flow use different keys. The keys used | |
1601 | to protect messages from the original initiator are SK_ai and SK_ei. | |
1602 | The keys used to protect messages in the other direction are SK_ar | |
1603 | and SK_er. Each algorithm takes a fixed number of bits of keying | |
1604 | material, which is specified as part of the algorithm. For integrity | |
1605 | algorithms based on a keyed hash, the key size is always equal to the | |
1606 | length of the output of the underlying hash function. | |
1607 | ||
1608 | 2.15. Authentication of the IKE_SA | |
1609 | ||
1610 | When not using extensible authentication (see section 2.16), the | |
1611 | peers are authenticated by having each sign (or MAC using a shared | |
1612 | secret as the key) a block of data. For the responder, the octets to | |
1613 | be signed start with the first octet of the first SPI in the header | |
1614 | of the second message and end with the last octet of the last payload | |
1615 | in the second message. Appended to this (for purposes of computing | |
1616 | the signature) are the initiator's nonce Ni (just the value, not the | |
1617 | payload containing it), and the value prf(SK_pr,IDr') where IDr' is | |
1618 | the responder's ID payload excluding the fixed header. Note that | |
1619 | neither the nonce Ni nor the value prf(SK_pr,IDr') are transmitted. | |
1620 | Similarly, the initiator signs the first message, starting with the | |
1621 | first octet of the first SPI in the header and ending with the last | |
1622 | octet of the last payload. Appended to this (for purposes of | |
1623 | ||
1624 | ||
1625 | ||
1626 | Kaufman Standards Track [Page 29] | |
1627 | \f | |
1628 | RFC 4306 IKEv2 December 2005 | |
1629 | ||
1630 | ||
1631 | computing the signature) are the responder's nonce Nr, and the value | |
1632 | prf(SK_pi,IDi'). In the above calculation, IDi' and IDr' are the | |
1633 | entire ID payloads excluding the fixed header. It is critical to the | |
1634 | security of the exchange that each side sign the other side's nonce. | |
1635 | ||
1636 | Note that all of the payloads are included under the signature, | |
1637 | including any payload types not defined in this document. If the | |
1638 | first message of the exchange is sent twice (the second time with a | |
1639 | responder cookie and/or a different Diffie-Hellman group), it is the | |
1640 | second version of the message that is signed. | |
1641 | ||
1642 | Optionally, messages 3 and 4 MAY include a certificate, or | |
1643 | certificate chain providing evidence that the key used to compute a | |
1644 | digital signature belongs to the name in the ID payload. The | |
1645 | signature or MAC will be computed using algorithms dictated by the | |
1646 | type of key used by the signer, and specified by the Auth Method | |
1647 | field in the Authentication payload. There is no requirement that | |
1648 | the initiator and responder sign with the same cryptographic | |
1649 | algorithms. The choice of cryptographic algorithms depends on the | |
1650 | type of key each has. In particular, the initiator may be using a | |
1651 | shared key while the responder may have a public signature key and | |
1652 | certificate. It will commonly be the case (but it is not required) | |
1653 | that if a shared secret is used for authentication that the same key | |
1654 | is used in both directions. Note that it is a common but typically | |
1655 | insecure practice to have a shared key derived solely from a user- | |
1656 | chosen password without incorporating another source of randomness. | |
1657 | ||
1658 | This is typically insecure because user-chosen passwords are unlikely | |
1659 | to have sufficient unpredictability to resist dictionary attacks and | |
1660 | these attacks are not prevented in this authentication method. | |
1661 | (Applications using password-based authentication for bootstrapping | |
1662 | and IKE_SA should use the authentication method in section 2.16, | |
1663 | which is designed to prevent off-line dictionary attacks.) The pre- | |
1664 | shared key SHOULD contain as much unpredictability as the strongest | |
1665 | key being negotiated. In the case of a pre-shared key, the AUTH | |
1666 | value is computed as: | |
1667 | ||
1668 | AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), <msg octets>) | |
1669 | ||
1670 | where the string "Key Pad for IKEv2" is 17 ASCII characters without | |
1671 | null termination. The shared secret can be variable length. The pad | |
1672 | string is added so that if the shared secret is derived from a | |
1673 | password, the IKE implementation need not store the password in | |
1674 | cleartext, but rather can store the value prf(Shared Secret,"Key Pad | |
1675 | for IKEv2"), which could not be used as a password equivalent for | |
1676 | protocols other than IKEv2. As noted above, deriving the shared | |
1677 | secret from a password is not secure. This construction is used | |
1678 | because it is anticipated that people will do it anyway. The | |
1679 | ||
1680 | ||
1681 | ||
1682 | Kaufman Standards Track [Page 30] | |
1683 | \f | |
1684 | RFC 4306 IKEv2 December 2005 | |
1685 | ||
1686 | ||
1687 | management interface by which the Shared Secret is provided MUST | |
1688 | accept ASCII strings of at least 64 octets and MUST NOT add a null | |
1689 | terminator before using them as shared secrets. It MUST also accept | |
1690 | a HEX encoding of the Shared Secret. The management interface MAY | |
1691 | accept other encodings if the algorithm for translating the encoding | |
1692 | to a binary string is specified. If the negotiated prf takes a | |
1693 | fixed-size key, the shared secret MUST be of that fixed size. | |
1694 | ||
1695 | 2.16. Extensible Authentication Protocol Methods | |
1696 | ||
1697 | In addition to authentication using public key signatures and shared | |
1698 | secrets, IKE supports authentication using methods defined in RFC | |
1699 | 3748 [EAP]. Typically, these methods are asymmetric (designed for a | |
1700 | user authenticating to a server), and they may not be mutual. For | |
1701 | this reason, these protocols are typically used to authenticate the | |
1702 | initiator to the responder and MUST be used in conjunction with a | |
1703 | public key signature based authentication of the responder to the | |
1704 | initiator. These methods are often associated with mechanisms | |
1705 | referred to as "Legacy Authentication" mechanisms. | |
1706 | ||
1707 | While this memo references [EAP] with the intent that new methods can | |
1708 | be added in the future without updating this specification, some | |
1709 | simpler variations are documented here and in section 3.16. [EAP] | |
1710 | defines an authentication protocol requiring a variable number of | |
1711 | messages. Extensible Authentication is implemented in IKE as | |
1712 | additional IKE_AUTH exchanges that MUST be completed in order to | |
1713 | initialize the IKE_SA. | |
1714 | ||
1715 | An initiator indicates a desire to use extensible authentication by | |
1716 | leaving out the AUTH payload from message 3. By including an IDi | |
1717 | payload but not an AUTH payload, the initiator has declared an | |
1718 | identity but has not proven it. If the responder is willing to use | |
1719 | an extensible authentication method, it will place an Extensible | |
1720 | Authentication Protocol (EAP) payload in message 4 and defer sending | |
1721 | SAr2, TSi, and TSr until initiator authentication is complete in a | |
1722 | subsequent IKE_AUTH exchange. In the case of a minimal extensible | |
1723 | authentication, the initial SA establishment will appear as follows: | |
1724 | ||
1725 | ||
1726 | ||
1727 | ||
1728 | ||
1729 | ||
1730 | ||
1731 | ||
1732 | ||
1733 | ||
1734 | ||
1735 | ||
1736 | ||
1737 | ||
1738 | Kaufman Standards Track [Page 31] | |
1739 | \f | |
1740 | RFC 4306 IKEv2 December 2005 | |
1741 | ||
1742 | ||
1743 | Initiator Responder | |
1744 | ----------- ----------- | |
1745 | HDR, SAi1, KEi, Ni --> | |
1746 | ||
1747 | <-- HDR, SAr1, KEr, Nr, [CERTREQ] | |
1748 | ||
1749 | HDR, SK {IDi, [CERTREQ,] [IDr,] | |
1750 | SAi2, TSi, TSr} --> | |
1751 | ||
1752 | <-- HDR, SK {IDr, [CERT,] AUTH, | |
1753 | EAP } | |
1754 | ||
1755 | HDR, SK {EAP} --> | |
1756 | ||
1757 | <-- HDR, SK {EAP (success)} | |
1758 | ||
1759 | HDR, SK {AUTH} --> | |
1760 | ||
1761 | <-- HDR, SK {AUTH, SAr2, TSi, TSr } | |
1762 | ||
1763 | For EAP methods that create a shared key as a side effect of | |
1764 | authentication, that shared key MUST be used by both the initiator | |
1765 | and responder to generate AUTH payloads in messages 7 and 8 using the | |
1766 | syntax for shared secrets specified in section 2.15. The shared key | |
1767 | from EAP is the field from the EAP specification named MSK. The | |
1768 | shared key generated during an IKE exchange MUST NOT be used for any | |
1769 | other purpose. | |
1770 | ||
1771 | EAP methods that do not establish a shared key SHOULD NOT be used, as | |
1772 | they are subject to a number of man-in-the-middle attacks [EAPMITM] | |
1773 | if these EAP methods are used in other protocols that do not use a | |
1774 | server-authenticated tunnel. Please see the Security Considerations | |
1775 | section for more details. If EAP methods that do not generate a | |
1776 | shared key are used, the AUTH payloads in messages 7 and 8 MUST be | |
1777 | generated using SK_pi and SK_pr, respectively. | |
1778 | ||
1779 | The initiator of an IKE_SA using EAP SHOULD be capable of extending | |
1780 | the initial protocol exchange to at least ten IKE_AUTH exchanges in | |
1781 | the event the responder sends notification messages and/or retries | |
1782 | the authentication prompt. Once the protocol exchange defined by the | |
1783 | chosen EAP authentication method has successfully terminated, the | |
1784 | responder MUST send an EAP payload containing the Success message. | |
1785 | Similarly, if the authentication method has failed, the responder | |
1786 | MUST send an EAP payload containing the Failure message. The | |
1787 | responder MAY at any time terminate the IKE exchange by sending an | |
1788 | EAP payload containing the Failure message. | |
1789 | ||
1790 | ||
1791 | ||
1792 | ||
1793 | ||
1794 | Kaufman Standards Track [Page 32] | |
1795 | \f | |
1796 | RFC 4306 IKEv2 December 2005 | |
1797 | ||
1798 | ||
1799 | Following such an extended exchange, the EAP AUTH payloads MUST be | |
1800 | included in the two messages following the one containing the EAP | |
1801 | Success message. | |
1802 | ||
1803 | 2.17. Generating Keying Material for CHILD_SAs | |
1804 | ||
1805 | A single CHILD_SA is created by the IKE_AUTH exchange, and additional | |
1806 | CHILD_SAs can optionally be created in CREATE_CHILD_SA exchanges. | |
1807 | Keying material for them is generated as follows: | |
1808 | ||
1809 | KEYMAT = prf+(SK_d, Ni | Nr) | |
1810 | ||
1811 | Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this | |
1812 | request is the first CHILD_SA created or the fresh Ni and Nr from the | |
1813 | CREATE_CHILD_SA exchange if this is a subsequent creation. | |
1814 | ||
1815 | For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman | |
1816 | exchange, the keying material is defined as: | |
1817 | ||
1818 | KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) | |
1819 | ||
1820 | where g^ir (new) is the shared secret from the ephemeral Diffie- | |
1821 | Hellman exchange of this CREATE_CHILD_SA exchange (represented as an | |
1822 | octet string in big endian order padded with zeros in the high-order | |
1823 | bits if necessary to make it the length of the modulus). | |
1824 | ||
1825 | A single CHILD_SA negotiation may result in multiple security | |
1826 | associations. ESP and AH SAs exist in pairs (one in each direction), | |
1827 | and four SAs could be created in a single CHILD_SA negotiation if a | |
1828 | combination of ESP and AH is being negotiated. | |
1829 | ||
1830 | Keying material MUST be taken from the expanded KEYMAT in the | |
1831 | following order: | |
1832 | ||
1833 | All keys for SAs carrying data from the initiator to the responder | |
1834 | are taken before SAs going in the reverse direction. | |
1835 | ||
1836 | If multiple IPsec protocols are negotiated, keying material is | |
1837 | taken in the order in which the protocol headers will appear in | |
1838 | the encapsulated packet. | |
1839 | ||
1840 | If a single protocol has both encryption and authentication keys, | |
1841 | the encryption key is taken from the first octets of KEYMAT and | |
1842 | the authentication key is taken from the next octets. | |
1843 | ||
1844 | Each cryptographic algorithm takes a fixed number of bits of keying | |
1845 | material specified as part of the algorithm. | |
1846 | ||
1847 | ||
1848 | ||
1849 | ||
1850 | Kaufman Standards Track [Page 33] | |
1851 | \f | |
1852 | RFC 4306 IKEv2 December 2005 | |
1853 | ||
1854 | ||
1855 | 2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA exchange | |
1856 | ||
1857 | The CREATE_CHILD_SA exchange can be used to rekey an existing IKE_SA | |
1858 | (see section 2.8). New initiator and responder SPIs are supplied in | |
1859 | the SPI fields. The TS payloads are omitted when rekeying an IKE_SA. | |
1860 | SKEYSEED for the new IKE_SA is computed using SK_d from the existing | |
1861 | IKE_SA as follows: | |
1862 | ||
1863 | SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr) | |
1864 | ||
1865 | where g^ir (new) is the shared secret from the ephemeral Diffie- | |
1866 | Hellman exchange of this CREATE_CHILD_SA exchange (represented as an | |
1867 | octet string in big endian order padded with zeros if necessary to | |
1868 | make it the length of the modulus) and Ni and Nr are the two nonces | |
1869 | stripped of any headers. | |
1870 | ||
1871 | The new IKE_SA MUST reset its message counters to 0. | |
1872 | ||
1873 | SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as | |
1874 | specified in section 2.14. | |
1875 | ||
1876 | 2.19. Requesting an Internal Address on a Remote Network | |
1877 | ||
1878 | Most commonly occurring in the endpoint-to-security-gateway scenario, | |
1879 | an endpoint may need an IP address in the network protected by the | |
1880 | security gateway and may need to have that address dynamically | |
1881 | assigned. A request for such a temporary address can be included in | |
1882 | any request to create a CHILD_SA (including the implicit request in | |
1883 | message 3) by including a CP payload. | |
1884 | ||
1885 | This function provides address allocation to an IPsec Remote Access | |
1886 | Client (IRAC) trying to tunnel into a network protected by an IPsec | |
1887 | Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an | |
1888 | IKE_SA and a CHILD_SA, the IRAC MUST request the IRAS-controlled | |
1889 | address (and optionally other information concerning the protected | |
1890 | network) in the IKE_AUTH exchange. The IRAS may procure an address | |
1891 | for the IRAC from any number of sources such as a DHCP/BOOTP server | |
1892 | or its own address pool. | |
1893 | ||
1894 | Initiator Responder | |
1895 | ----------------------------- --------------------------- | |
1896 | HDR, SK {IDi, [CERT,] [CERTREQ,] | |
1897 | [IDr,] AUTH, CP(CFG_REQUEST), | |
1898 | SAi2, TSi, TSr} --> | |
1899 | ||
1900 | <-- HDR, SK {IDr, [CERT,] AUTH, | |
1901 | CP(CFG_REPLY), SAr2, | |
1902 | TSi, TSr} | |
1903 | ||
1904 | ||
1905 | ||
1906 | Kaufman Standards Track [Page 34] | |
1907 | \f | |
1908 | RFC 4306 IKEv2 December 2005 | |
1909 | ||
1910 | ||
1911 | In all cases, the CP payload MUST be inserted before the SA payload. | |
1912 | In variations of the protocol where there are multiple IKE_AUTH | |
1913 | exchanges, the CP payloads MUST be inserted in the messages | |
1914 | containing the SA payloads. | |
1915 | ||
1916 | CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute | |
1917 | (either IPv4 or IPv6) but MAY contain any number of additional | |
1918 | attributes the initiator wants returned in the response. | |
1919 | ||
1920 | For example, message from initiator to responder: | |
1921 | CP(CFG_REQUEST)= | |
1922 | INTERNAL_ADDRESS(0.0.0.0) | |
1923 | INTERNAL_NETMASK(0.0.0.0) | |
1924 | INTERNAL_DNS(0.0.0.0) | |
1925 | TSi = (0, 0-65535,0.0.0.0-255.255.255.255) | |
1926 | TSr = (0, 0-65535,0.0.0.0-255.255.255.255) | |
1927 | ||
1928 | NOTE: Traffic Selectors contain (protocol, port range, address | |
1929 | range). | |
1930 | ||
1931 | Message from responder to initiator: | |
1932 | ||
1933 | CP(CFG_REPLY)= | |
1934 | INTERNAL_ADDRESS(192.0.2.202) | |
1935 | INTERNAL_NETMASK(255.255.255.0) | |
1936 | INTERNAL_SUBNET(192.0.2.0/255.255.255.0) | |
1937 | TSi = (0, 0-65535,192.0.2.202-192.0.2.202) | |
1938 | TSr = (0, 0-65535,192.0.2.0-192.0.2.255) | |
1939 | ||
1940 | All returned values will be implementation dependent. As can be seen | |
1941 | in the above example, the IRAS MAY also send other attributes that | |
1942 | were not included in CP(CFG_REQUEST) and MAY ignore the non-mandatory | |
1943 | attributes that it does not support. | |
1944 | ||
1945 | The responder MUST NOT send a CFG_REPLY without having first received | |
1946 | a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS | |
1947 | to perform an unnecessary configuration lookup if the IRAC cannot | |
1948 | process the REPLY. In the case where the IRAS's configuration | |
1949 | requires that CP be used for a given identity IDi, but IRAC has | |
1950 | failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and | |
1951 | terminate the IKE exchange with a FAILED_CP_REQUIRED error. | |
1952 | ||
1953 | 2.20. Requesting the Peer's Version | |
1954 | ||
1955 | An IKE peer wishing to inquire about the other peer's IKE software | |
1956 | version information MAY use the method below. This is an example of | |
1957 | a configuration request within an INFORMATIONAL exchange, after the | |
1958 | IKE_SA and first CHILD_SA have been created. | |
1959 | ||
1960 | ||
1961 | ||
1962 | Kaufman Standards Track [Page 35] | |
1963 | \f | |
1964 | RFC 4306 IKEv2 December 2005 | |
1965 | ||
1966 | ||
1967 | An IKE implementation MAY decline to give out version information | |
1968 | prior to authentication or even after authentication to prevent | |
1969 | trolling in case some implementation is known to have some security | |
1970 | weakness. In that case, it MUST either return an empty string or no | |
1971 | CP payload if CP is not supported. | |
1972 | ||
1973 | Initiator Responder | |
1974 | ----------------------------- -------------------------- | |
1975 | HDR, SK{CP(CFG_REQUEST)} --> | |
1976 | <-- HDR, SK{CP(CFG_REPLY)} | |
1977 | ||
1978 | CP(CFG_REQUEST)= | |
1979 | APPLICATION_VERSION("") | |
1980 | ||
1981 | CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar | |
1982 | Inc.") | |
1983 | ||
1984 | 2.21. Error Handling | |
1985 | ||
1986 | There are many kinds of errors that can occur during IKE processing. | |
1987 | If a request is received that is badly formatted or unacceptable for | |
1988 | reasons of policy (e.g., no matching cryptographic algorithms), the | |
1989 | response MUST contain a Notify payload indicating the error. If an | |
1990 | error occurs outside the context of an IKE request (e.g., the node is | |
1991 | getting ESP messages on a nonexistent SPI), the node SHOULD initiate | |
1992 | an INFORMATIONAL exchange with a Notify payload describing the | |
1993 | problem. | |
1994 | ||
1995 | Errors that occur before a cryptographically protected IKE_SA is | |
1996 | established must be handled very carefully. There is a trade-off | |
1997 | between wanting to be helpful in diagnosing a problem and responding | |
1998 | to it and wanting to avoid being a dupe in a denial of service attack | |
1999 | based on forged messages. | |
2000 | ||
2001 | If a node receives a message on UDP port 500 or 4500 outside the | |
2002 | context of an IKE_SA known to it (and not a request to start one), it | |
2003 | may be the result of a recent crash of the node. If the message is | |
2004 | marked as a response, the node MAY audit the suspicious event but | |
2005 | MUST NOT respond. If the message is marked as a request, the node | |
2006 | MAY audit the suspicious event and MAY send a response. If a | |
2007 | response is sent, the response MUST be sent to the IP address and | |
2008 | port from whence it came with the same IKE SPIs and the Message ID | |
2009 | copied. The response MUST NOT be cryptographically protected and | |
2010 | MUST contain a Notify payload indicating INVALID_IKE_SPI. | |
2011 | ||
2012 | A node receiving such an unprotected Notify payload MUST NOT respond | |
2013 | and MUST NOT change the state of any existing SAs. The message might | |
2014 | be a forgery or might be a response the genuine correspondent was | |
2015 | ||
2016 | ||
2017 | ||
2018 | Kaufman Standards Track [Page 36] | |
2019 | \f | |
2020 | RFC 4306 IKEv2 December 2005 | |
2021 | ||
2022 | ||
2023 | tricked into sending. A node SHOULD treat such a message (and also a | |
2024 | network message like ICMP destination unreachable) as a hint that | |
2025 | there might be problems with SAs to that IP address and SHOULD | |
2026 | initiate a liveness test for any such IKE_SA. An implementation | |
2027 | SHOULD limit the frequency of such tests to avoid being tricked into | |
2028 | participating in a denial of service attack. | |
2029 | ||
2030 | A node receiving a suspicious message from an IP address with which | |
2031 | it has an IKE_SA MAY send an IKE Notify payload in an IKE | |
2032 | INFORMATIONAL exchange over that SA. The recipient MUST NOT change | |
2033 | the state of any SA's as a result but SHOULD audit the event to aid | |
2034 | in diagnosing malfunctions. A node MUST limit the rate at which it | |
2035 | will send messages in response to unprotected messages. | |
2036 | ||
2037 | 2.22. IPComp | |
2038 | ||
2039 | Use of IP compression [IPCOMP] can be negotiated as part of the setup | |
2040 | of a CHILD_SA. While IP compression involves an extra header in each | |
2041 | packet and a compression parameter index (CPI), the virtual | |
2042 | "compression association" has no life outside the ESP or AH SA that | |
2043 | contains it. Compression associations disappear when the | |
2044 | corresponding ESP or AH SA goes away. It is not explicitly mentioned | |
2045 | in any DELETE payload. | |
2046 | ||
2047 | Negotiation of IP compression is separate from the negotiation of | |
2048 | cryptographic parameters associated with a CHILD_SA. A node | |
2049 | requesting a CHILD_SA MAY advertise its support for one or more | |
2050 | compression algorithms through one or more Notify payloads of type | |
2051 | IPCOMP_SUPPORTED. The response MAY indicate acceptance of a single | |
2052 | compression algorithm with a Notify payload of type IPCOMP_SUPPORTED. | |
2053 | These payloads MUST NOT occur in messages that do not contain SA | |
2054 | payloads. | |
2055 | ||
2056 | Although there has been discussion of allowing multiple compression | |
2057 | algorithms to be accepted and to have different compression | |
2058 | algorithms available for the two directions of a CHILD_SA, | |
2059 | implementations of this specification MUST NOT accept an IPComp | |
2060 | algorithm that was not proposed, MUST NOT accept more than one, and | |
2061 | MUST NOT compress using an algorithm other than one proposed and | |
2062 | accepted in the setup of the CHILD_SA. | |
2063 | ||
2064 | A side effect of separating the negotiation of IPComp from | |
2065 | cryptographic parameters is that it is not possible to propose | |
2066 | multiple cryptographic suites and propose IP compression with some of | |
2067 | them but not others. | |
2068 | ||
2069 | ||
2070 | ||
2071 | ||
2072 | ||
2073 | ||
2074 | Kaufman Standards Track [Page 37] | |
2075 | \f | |
2076 | RFC 4306 IKEv2 December 2005 | |
2077 | ||
2078 | ||
2079 | 2.23. NAT Traversal | |
2080 | ||
2081 | Network Address Translation (NAT) gateways are a controversial | |
2082 | subject. This section briefly describes what they are and how they | |
2083 | are likely to act on IKE traffic. Many people believe that NATs are | |
2084 | evil and that we should not design our protocols so as to make them | |
2085 | work better. IKEv2 does specify some unintuitive processing rules in | |
2086 | order that NATs are more likely to work. | |
2087 | ||
2088 | NATs exist primarily because of the shortage of IPv4 addresses, | |
2089 | though there are other rationales. IP nodes that are "behind" a NAT | |
2090 | have IP addresses that are not globally unique, but rather are | |
2091 | assigned from some space that is unique within the network behind the | |
2092 | NAT but that are likely to be reused by nodes behind other NATs. | |
2093 | Generally, nodes behind NATs can communicate with other nodes behind | |
2094 | the same NAT and with nodes with globally unique addresses, but not | |
2095 | with nodes behind other NATs. There are exceptions to that rule. | |
2096 | When those nodes make connections to nodes on the real Internet, the | |
2097 | NAT gateway "translates" the IP source address to an address that | |
2098 | will be routed back to the gateway. Messages to the gateway from the | |
2099 | Internet have their destination addresses "translated" to the | |
2100 | internal address that will route the packet to the correct endnode. | |
2101 | ||
2102 | NATs are designed to be "transparent" to endnodes. Neither software | |
2103 | on the node behind the NAT nor the node on the Internet requires | |
2104 | modification to communicate through the NAT. Achieving this | |
2105 | transparency is more difficult with some protocols than with others. | |
2106 | Protocols that include IP addresses of the endpoints within the | |
2107 | payloads of the packet will fail unless the NAT gateway understands | |
2108 | the protocol and modifies the internal references as well as those in | |
2109 | the headers. Such knowledge is inherently unreliable, is a network | |
2110 | layer violation, and often results in subtle problems. | |
2111 | ||
2112 | Opening an IPsec connection through a NAT introduces special | |
2113 | problems. If the connection runs in transport mode, changing the IP | |
2114 | addresses on packets will cause the checksums to fail and the NAT | |
2115 | cannot correct the checksums because they are cryptographically | |
2116 | protected. Even in tunnel mode, there are routing problems because | |
2117 | transparently translating the addresses of AH and ESP packets | |
2118 | requires special logic in the NAT and that logic is heuristic and | |
2119 | unreliable in nature. For that reason, IKEv2 can negotiate UDP | |
2120 | encapsulation of IKE and ESP packets. This encoding is slightly less | |
2121 | efficient but is easier for NATs to process. In addition, firewalls | |
2122 | may be configured to pass IPsec traffic over UDP but not ESP/AH or | |
2123 | vice versa. | |
2124 | ||
2125 | ||
2126 | ||
2127 | ||
2128 | ||
2129 | ||
2130 | Kaufman Standards Track [Page 38] | |
2131 | \f | |
2132 | RFC 4306 IKEv2 December 2005 | |
2133 | ||
2134 | ||
2135 | It is a common practice of NATs to translate TCP and UDP port numbers | |
2136 | as well as addresses and use the port numbers of inbound packets to | |
2137 | decide which internal node should get a given packet. For this | |
2138 | reason, even though IKE packets MUST be sent from and to UDP port | |
2139 | 500, they MUST be accepted coming from any port and responses MUST be | |
2140 | sent to the port from whence they came. This is because the ports | |
2141 | may be modified as the packets pass through NATs. Similarly, IP | |
2142 | addresses of the IKE endpoints are generally not included in the IKE | |
2143 | payloads because the payloads are cryptographically protected and | |
2144 | could not be transparently modified by NATs. | |
2145 | ||
2146 | Port 4500 is reserved for UDP-encapsulated ESP and IKE. When working | |
2147 | through a NAT, it is generally better to pass IKE packets over port | |
2148 | 4500 because some older NATs handle IKE traffic on port 500 cleverly | |
2149 | in an attempt to transparently establish IPsec connections between | |
2150 | endpoints that don't handle NAT traversal themselves. Such NATs may | |
2151 | interfere with the straightforward NAT traversal envisioned by this | |
2152 | document, so an IPsec endpoint that discovers a NAT between it and | |
2153 | its correspondent MUST send all subsequent traffic to and from port | |
2154 | 4500, which NATs should not treat specially (as they might with port | |
2155 | 500). | |
2156 | ||
2157 | The specific requirements for supporting NAT traversal [RFC3715] are | |
2158 | listed below. Support for NAT traversal is optional. In this | |
2159 | section only, requirements listed as MUST apply only to | |
2160 | implementations supporting NAT traversal. | |
2161 | ||
2162 | IKE MUST listen on port 4500 as well as port 500. IKE MUST | |
2163 | respond to the IP address and port from which packets arrived. | |
2164 | ||
2165 | Both IKE initiator and responder MUST include in their IKE_SA_INIT | |
2166 | packets Notify payloads of type NAT_DETECTION_SOURCE_IP and | |
2167 | NAT_DETECTION_DESTINATION_IP. Those payloads can be used to | |
2168 | detect if there is NAT between the hosts, and which end is behind | |
2169 | the NAT. The location of the payloads in the IKE_SA_INIT packets | |
2170 | are just after the Ni and Nr payloads (before the optional CERTREQ | |
2171 | payload). | |
2172 | ||
2173 | If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches | |
2174 | the hash of the source IP and port found from the IP header of the | |
2175 | packet containing the payload, it means that the other end is | |
2176 | behind NAT (i.e., someone along the route changed the source | |
2177 | address of the original packet to match the address of the NAT | |
2178 | box). In this case, this end should allow dynamic update of the | |
2179 | other ends IP address, as described later. | |
2180 | ||
2181 | ||
2182 | ||
2183 | ||
2184 | ||
2185 | ||
2186 | Kaufman Standards Track [Page 39] | |
2187 | \f | |
2188 | RFC 4306 IKEv2 December 2005 | |
2189 | ||
2190 | ||
2191 | If the NAT_DETECTION_DESTINATION_IP payload received does not | |
2192 | match the hash of the destination IP and port found from the IP | |
2193 | header of the packet containing the payload, it means that this | |
2194 | end is behind a NAT. In this case, this end SHOULD start sending | |
2195 | keepalive packets as explained in [Hutt05]. | |
2196 | ||
2197 | The IKE initiator MUST check these payloads if present and if they | |
2198 | do not match the addresses in the outer packet MUST tunnel all | |
2199 | future IKE and ESP packets associated with this IKE_SA over UDP | |
2200 | port 4500. | |
2201 | ||
2202 | To tunnel IKE packets over UDP port 4500, the IKE header has four | |
2203 | octets of zero prepended and the result immediately follows the | |
2204 | UDP header. To tunnel ESP packets over UDP port 4500, the ESP | |
2205 | header immediately follows the UDP header. Since the first four | |
2206 | bytes of the ESP header contain the SPI, and the SPI cannot | |
2207 | validly be zero, it is always possible to distinguish ESP and IKE | |
2208 | messages. | |
2209 | ||
2210 | The original source and destination IP address required for the | |
2211 | transport mode TCP and UDP packet checksum fixup (see [Hutt05]) | |
2212 | are obtained from the Traffic Selectors associated with the | |
2213 | exchange. In the case of NAT traversal, the Traffic Selectors | |
2214 | MUST contain exactly one IP address, which is then used as the | |
2215 | original IP address. | |
2216 | ||
2217 | There are cases where a NAT box decides to remove mappings that | |
2218 | are still alive (for example, the keepalive interval is too long, | |
2219 | or the NAT box is rebooted). To recover in these cases, hosts | |
2220 | that are not behind a NAT SHOULD send all packets (including | |
2221 | retransmission packets) to the IP address and port from the last | |
2222 | valid authenticated packet from the other end (i.e., dynamically | |
2223 | update the address). A host behind a NAT SHOULD NOT do this | |
2224 | because it opens a DoS attack possibility. Any authenticated IKE | |
2225 | packet or any authenticated UDP-encapsulated ESP packet can be | |
2226 | used to detect that the IP address or the port has changed. | |
2227 | ||
2228 | Note that similar but probably not identical actions will likely | |
2229 | be needed to make IKE work with Mobile IP, but such processing is | |
2230 | not addressed by this document. | |
2231 | ||
2232 | 2.24. Explicit Congestion Notification (ECN) | |
2233 | ||
2234 | When IPsec tunnels behave as originally specified in [RFC2401], ECN | |
2235 | usage is not appropriate for the outer IP headers because tunnel | |
2236 | decapsulation processing discards ECN congestion indications to the | |
2237 | detriment of the network. ECN support for IPsec tunnels for IKEv1- | |
2238 | based IPsec requires multiple operating modes and negotiation (see | |
2239 | ||
2240 | ||
2241 | ||
2242 | Kaufman Standards Track [Page 40] | |
2243 | \f | |
2244 | RFC 4306 IKEv2 December 2005 | |
2245 | ||
2246 | ||
2247 | [RFC3168]). IKEv2 simplifies this situation by requiring that ECN be | |
2248 | usable in the outer IP headers of all tunnel-mode IPsec SAs created | |
2249 | by IKEv2. Specifically, tunnel encapsulators and decapsulators for | |
2250 | all tunnel-mode SAs created by IKEv2 MUST support the ECN full- | |
2251 | functionality option for tunnels specified in [RFC3168] and MUST | |
2252 | implement the tunnel encapsulation and decapsulation processing | |
2253 | specified in [RFC4301] to prevent discarding of ECN congestion | |
2254 | indications. | |
2255 | ||
2256 | 3. Header and Payload Formats | |
2257 | ||
2258 | 3.1. The IKE Header | |
2259 | ||
2260 | IKE messages use UDP ports 500 and/or 4500, with one IKE message per | |
2261 | UDP datagram. Information from the beginning of the packet through | |
2262 | the UDP header is largely ignored except that the IP addresses and | |
2263 | UDP ports from the headers are reversed and used for return packets. | |
2264 | When sent on UDP port 500, IKE messages begin immediately following | |
2265 | the UDP header. When sent on UDP port 4500, IKE messages have | |
2266 | prepended four octets of zero. These four octets of zero are not | |
2267 | part of the IKE message and are not included in any of the length | |
2268 | fields or checksums defined by IKE. Each IKE message begins with the | |
2269 | IKE header, denoted HDR in this memo. Following the header are one | |
2270 | or more IKE payloads each identified by a "Next Payload" field in the | |
2271 | preceding payload. Payloads are processed in the order in which they | |
2272 | appear in an IKE message by invoking the appropriate processing | |
2273 | routine according to the "Next Payload" field in the IKE header and | |
2274 | subsequently according to the "Next Payload" field in the IKE payload | |
2275 | itself until a "Next Payload" field of zero indicates that no | |
2276 | payloads follow. If a payload of type "Encrypted" is found, that | |
2277 | payload is decrypted and its contents parsed as additional payloads. | |
2278 | An Encrypted payload MUST be the last payload in a packet and an | |
2279 | Encrypted payload MUST NOT contain another Encrypted payload. | |
2280 | ||
2281 | The Recipient SPI in the header identifies an instance of an IKE | |
2282 | security association. It is therefore possible for a single instance | |
2283 | of IKE to multiplex distinct sessions with multiple peers. | |
2284 | ||
2285 | All multi-octet fields representing integers are laid out in big | |
2286 | endian order (aka most significant byte first, or network byte | |
2287 | order). | |
2288 | ||
2289 | The format of the IKE header is shown in Figure 4. | |
2290 | ||
2291 | ||
2292 | ||
2293 | ||
2294 | ||
2295 | ||
2296 | ||
2297 | ||
2298 | Kaufman Standards Track [Page 41] | |
2299 | \f | |
2300 | RFC 4306 IKEv2 December 2005 | |
2301 | ||
2302 | ||
2303 | 1 2 3 | |
2304 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
2305 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2306 | ! IKE_SA Initiator's SPI ! | |
2307 | ! ! | |
2308 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2309 | ! IKE_SA Responder's SPI ! | |
2310 | ! ! | |
2311 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2312 | ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! | |
2313 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2314 | ! Message ID ! | |
2315 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2316 | ! Length ! | |
2317 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2318 | ||
2319 | Figure 4: IKE Header Format | |
2320 | ||
2321 | o Initiator's SPI (8 octets) - A value chosen by the | |
2322 | initiator to identify a unique IKE security association. This | |
2323 | value MUST NOT be zero. | |
2324 | ||
2325 | o Responder's SPI (8 octets) - A value chosen by the | |
2326 | responder to identify a unique IKE security association. This | |
2327 | value MUST be zero in the first message of an IKE Initial | |
2328 | Exchange (including repeats of that message including a | |
2329 | cookie) and MUST NOT be zero in any other message. | |
2330 | ||
2331 | o Next Payload (1 octet) - Indicates the type of payload that | |
2332 | immediately follows the header. The format and value of each | |
2333 | payload are defined below. | |
2334 | ||
2335 | o Major Version (4 bits) - Indicates the major version of the IKE | |
2336 | protocol in use. Implementations based on this version of IKE | |
2337 | MUST set the Major Version to 2. Implementations based on | |
2338 | previous versions of IKE and ISAKMP MUST set the Major Version | |
2339 | to 1. Implementations based on this version of IKE MUST reject | |
2340 | or ignore messages containing a version number greater than | |
2341 | 2. | |
2342 | ||
2343 | o Minor Version (4 bits) - Indicates the minor version of the | |
2344 | IKE protocol in use. Implementations based on this version of | |
2345 | IKE MUST set the Minor Version to 0. They MUST ignore the | |
2346 | minor version number of received messages. | |
2347 | ||
2348 | o Exchange Type (1 octet) - Indicates the type of exchange being | |
2349 | used. This constrains the payloads sent in each message and | |
2350 | orderings of messages in an exchange. | |
2351 | ||
2352 | ||
2353 | ||
2354 | Kaufman Standards Track [Page 42] | |
2355 | \f | |
2356 | RFC 4306 IKEv2 December 2005 | |
2357 | ||
2358 | ||
2359 | Exchange Type Value | |
2360 | ||
2361 | RESERVED 0-33 | |
2362 | IKE_SA_INIT 34 | |
2363 | IKE_AUTH 35 | |
2364 | CREATE_CHILD_SA 36 | |
2365 | INFORMATIONAL 37 | |
2366 | RESERVED TO IANA 38-239 | |
2367 | Reserved for private use 240-255 | |
2368 | ||
2369 | o Flags (1 octet) - Indicates specific options that are set | |
2370 | for the message. Presence of options are indicated by the | |
2371 | appropriate bit in the flags field being set. The bits are | |
2372 | defined LSB first, so bit 0 would be the least significant | |
2373 | bit of the Flags octet. In the description below, a bit | |
2374 | being 'set' means its value is '1', while 'cleared' means | |
2375 | its value is '0'. | |
2376 | ||
2377 | -- X(reserved) (bits 0-2) - These bits MUST be cleared | |
2378 | when sending and MUST be ignored on receipt. | |
2379 | ||
2380 | -- I(nitiator) (bit 3 of Flags) - This bit MUST be set in | |
2381 | messages sent by the original initiator of the IKE_SA | |
2382 | and MUST be cleared in messages sent by the original | |
2383 | responder. It is used by the recipient to determine | |
2384 | which eight octets of the SPI were generated by the | |
2385 | recipient. | |
2386 | ||
2387 | -- V(ersion) (bit 4 of Flags) - This bit indicates that | |
2388 | the transmitter is capable of speaking a higher major | |
2389 | version number of the protocol than the one indicated | |
2390 | in the major version number field. Implementations of | |
2391 | IKEv2 must clear this bit when sending and MUST ignore | |
2392 | it in incoming messages. | |
2393 | ||
2394 | -- R(esponse) (bit 5 of Flags) - This bit indicates that | |
2395 | this message is a response to a message containing | |
2396 | the same message ID. This bit MUST be cleared in all | |
2397 | request messages and MUST be set in all responses. | |
2398 | An IKE endpoint MUST NOT generate a response to a | |
2399 | message that is marked as being a response. | |
2400 | ||
2401 | -- X(reserved) (bits 6-7 of Flags) - These bits MUST be | |
2402 | cleared when sending and MUST be ignored on receipt. | |
2403 | ||
2404 | ||
2405 | ||
2406 | ||
2407 | ||
2408 | ||
2409 | ||
2410 | Kaufman Standards Track [Page 43] | |
2411 | \f | |
2412 | RFC 4306 IKEv2 December 2005 | |
2413 | ||
2414 | ||
2415 | o Message ID (4 octets) - Message identifier used to control | |
2416 | retransmission of lost packets and matching of requests and | |
2417 | responses. It is essential to the security of the protocol | |
2418 | because it is used to prevent message replay attacks. | |
2419 | See sections 2.1 and 2.2. | |
2420 | ||
2421 | o Length (4 octets) - Length of total message (header + payloads) | |
2422 | in octets. | |
2423 | ||
2424 | 3.2. Generic Payload Header | |
2425 | ||
2426 | Each IKE payload defined in sections 3.3 through 3.16 begins with a | |
2427 | generic payload header, shown in Figure 5. Figures for each payload | |
2428 | below will include the generic payload header, but for brevity the | |
2429 | description of each field will be omitted. | |
2430 | ||
2431 | 1 2 3 | |
2432 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
2433 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2434 | ! Next Payload !C! RESERVED ! Payload Length ! | |
2435 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2436 | ||
2437 | Figure 5: Generic Payload Header | |
2438 | ||
2439 | The Generic Payload Header fields are defined as follows: | |
2440 | ||
2441 | o Next Payload (1 octet) - Identifier for the payload type of the | |
2442 | next payload in the message. If the current payload is the last | |
2443 | in the message, then this field will be 0. This field provides a | |
2444 | "chaining" capability whereby additional payloads can be added to | |
2445 | a message by appending it to the end of the message and setting | |
2446 | the "Next Payload" field of the preceding payload to indicate the | |
2447 | new payload's type. An Encrypted payload, which must always be | |
2448 | the last payload of a message, is an exception. It contains data | |
2449 | structures in the format of additional payloads. In the header of | |
2450 | an Encrypted payload, the Next Payload field is set to the payload | |
2451 | type of the first contained payload (instead of 0). | |
2452 | ||
2453 | Payload Type Values | |
2454 | ||
2455 | Next Payload Type Notation Value | |
2456 | ||
2457 | No Next Payload 0 | |
2458 | ||
2459 | RESERVED 1-32 | |
2460 | Security Association SA 33 | |
2461 | Key Exchange KE 34 | |
2462 | Identification - Initiator IDi 35 | |
2463 | ||
2464 | ||
2465 | ||
2466 | Kaufman Standards Track [Page 44] | |
2467 | \f | |
2468 | RFC 4306 IKEv2 December 2005 | |
2469 | ||
2470 | ||
2471 | Identification - Responder IDr 36 | |
2472 | Certificate CERT 37 | |
2473 | Certificate Request CERTREQ 38 | |
2474 | Authentication AUTH 39 | |
2475 | Nonce Ni, Nr 40 | |
2476 | Notify N 41 | |
2477 | Delete D 42 | |
2478 | Vendor ID V 43 | |
2479 | Traffic Selector - Initiator TSi 44 | |
2480 | Traffic Selector - Responder TSr 45 | |
2481 | Encrypted E 46 | |
2482 | Configuration CP 47 | |
2483 | Extensible Authentication EAP 48 | |
2484 | RESERVED TO IANA 49-127 | |
2485 | PRIVATE USE 128-255 | |
2486 | ||
2487 | Payload type values 1-32 should not be used so that there is no | |
2488 | overlap with the code assignments for IKEv1. Payload type values | |
2489 | 49-127 are reserved to IANA for future assignment in IKEv2 (see | |
2490 | section 6). Payload type values 128-255 are for private use among | |
2491 | mutually consenting parties. | |
2492 | ||
2493 | o Critical (1 bit) - MUST be set to zero if the sender wants the | |
2494 | recipient to skip this payload if it does not understand the | |
2495 | payload type code in the Next Payload field of the previous | |
2496 | payload. MUST be set to one if the sender wants the recipient to | |
2497 | reject this entire message if it does not understand the payload | |
2498 | type. MUST be ignored by the recipient if the recipient | |
2499 | understands the payload type code. MUST be set to zero for | |
2500 | payload types defined in this document. Note that the critical | |
2501 | bit applies to the current payload rather than the "next" payload | |
2502 | whose type code appears in the first octet. The reasoning behind | |
2503 | not setting the critical bit for payloads defined in this document | |
2504 | is that all implementations MUST understand all payload types | |
2505 | defined in this document and therefore must ignore the Critical | |
2506 | bit's value. Skipped payloads are expected to have valid Next | |
2507 | Payload and Payload Length fields. | |
2508 | ||
2509 | o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on | |
2510 | receipt. | |
2511 | ||
2512 | o Payload Length (2 octets) - Length in octets of the current | |
2513 | payload, including the generic payload header. | |
2514 | ||
2515 | ||
2516 | ||
2517 | ||
2518 | ||
2519 | ||
2520 | ||
2521 | ||
2522 | Kaufman Standards Track [Page 45] | |
2523 | \f | |
2524 | RFC 4306 IKEv2 December 2005 | |
2525 | ||
2526 | ||
2527 | 3.3. Security Association Payload | |
2528 | ||
2529 | The Security Association Payload, denoted SA in this memo, is used to | |
2530 | negotiate attributes of a security association. Assembly of Security | |
2531 | Association Payloads requires great peace of mind. An SA payload MAY | |
2532 | contain multiple proposals. If there is more than one, they MUST be | |
2533 | ordered from most preferred to least preferred. Each proposal may | |
2534 | contain multiple IPsec protocols (where a protocol is IKE, ESP, or | |
2535 | AH), each protocol MAY contain multiple transforms, and each | |
2536 | transform MAY contain multiple attributes. When parsing an SA, an | |
2537 | implementation MUST check that the total Payload Length is consistent | |
2538 | with the payload's internal lengths and counts. Proposals, | |
2539 | Transforms, and Attributes each have their own variable length | |
2540 | encodings. They are nested such that the Payload Length of an SA | |
2541 | includes the combined contents of the SA, Proposal, Transform, and | |
2542 | Attribute information. The length of a Proposal includes the lengths | |
2543 | of all Transforms and Attributes it contains. The length of a | |
2544 | Transform includes the lengths of all Attributes it contains. | |
2545 | ||
2546 | The syntax of Security Associations, Proposals, Transforms, and | |
2547 | Attributes is based on ISAKMP; however, the semantics are somewhat | |
2548 | different. The reason for the complexity and the hierarchy is to | |
2549 | allow for multiple possible combinations of algorithms to be encoded | |
2550 | in a single SA. Sometimes there is a choice of multiple algorithms, | |
2551 | whereas other times there is a combination of algorithms. For | |
2552 | example, an initiator might want to propose using (AH w/MD5 and ESP | |
2553 | w/3DES) OR (ESP w/MD5 and 3DES). | |
2554 | ||
2555 | One of the reasons the semantics of the SA payload has changed from | |
2556 | ISAKMP and IKEv1 is to make the encodings more compact in common | |
2557 | cases. | |
2558 | ||
2559 | The Proposal structure contains within it a Proposal # and an IPsec | |
2560 | protocol ID. Each structure MUST have the same Proposal # as the | |
2561 | previous one or be one (1) greater. The first Proposal MUST have a | |
2562 | Proposal # of one (1). If two successive structures have the same | |
2563 | Proposal number, it means that the proposal consists of the first | |
2564 | structure AND the second. So a proposal of AH AND ESP would have two | |
2565 | proposal structures, one for AH and one for ESP and both would have | |
2566 | Proposal #1. A proposal of AH OR ESP would have two proposal | |
2567 | structures, one for AH with Proposal #1 and one for ESP with Proposal | |
2568 | #2. | |
2569 | ||
2570 | Each Proposal/Protocol structure is followed by one or more transform | |
2571 | structures. The number of different transforms is generally | |
2572 | determined by the Protocol. AH generally has a single transform: an | |
2573 | integrity check algorithm. ESP generally has two: an encryption | |
2574 | algorithm and an integrity check algorithm. IKE generally has four | |
2575 | ||
2576 | ||
2577 | ||
2578 | Kaufman Standards Track [Page 46] | |
2579 | \f | |
2580 | RFC 4306 IKEv2 December 2005 | |
2581 | ||
2582 | ||
2583 | transforms: a Diffie-Hellman group, an integrity check algorithm, a | |
2584 | prf algorithm, and an encryption algorithm. If an algorithm that | |
2585 | combines encryption and integrity protection is proposed, it MUST be | |
2586 | proposed as an encryption algorithm and an integrity protection | |
2587 | algorithm MUST NOT be proposed. For each Protocol, the set of | |
2588 | permissible transforms is assigned transform ID numbers, which appear | |
2589 | in the header of each transform. | |
2590 | ||
2591 | If there are multiple transforms with the same Transform Type, the | |
2592 | proposal is an OR of those transforms. If there are multiple | |
2593 | Transforms with different Transform Types, the proposal is an AND of | |
2594 | the different groups. For example, to propose ESP with (3DES or | |
2595 | IDEA) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two | |
2596 | Transform Type 1 candidates (one for 3DES and one for IDEA) and two | |
2597 | Transform Type 2 candidates (one for HMAC_MD5 and one for HMAC_SHA). | |
2598 | This effectively proposes four combinations of algorithms. If the | |
2599 | initiator wanted to propose only a subset of those, for example (3DES | |
2600 | and HMAC_MD5) or (IDEA and HMAC_SHA), there is no way to encode that | |
2601 | as multiple transforms within a single Proposal. Instead, the | |
2602 | initiator would have to construct two different Proposals, each with | |
2603 | two transforms. | |
2604 | ||
2605 | A given transform MAY have one or more Attributes. Attributes are | |
2606 | necessary when the transform can be used in more than one way, as | |
2607 | when an encryption algorithm has a variable key size. The transform | |
2608 | would specify the algorithm and the attribute would specify the key | |
2609 | size. Most transforms do not have attributes. A transform MUST NOT | |
2610 | have multiple attributes of the same type. To propose alternate | |
2611 | values for an attribute (for example, multiple key sizes for the AES | |
2612 | encryption algorithm), and implementation MUST include multiple | |
2613 | Transforms with the same Transform Type each with a single Attribute. | |
2614 | ||
2615 | Note that the semantics of Transforms and Attributes are quite | |
2616 | different from those in IKEv1. In IKEv1, a single Transform carried | |
2617 | multiple algorithms for a protocol with one carried in the Transform | |
2618 | and the others carried in the Attributes. | |
2619 | ||
2620 | 1 2 3 | |
2621 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
2622 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2623 | ! Next Payload !C! RESERVED ! Payload Length ! | |
2624 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2625 | ! ! | |
2626 | ~ <Proposals> ~ | |
2627 | ! ! | |
2628 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2629 | ||
2630 | Figure 6: Security Association Payload | |
2631 | ||
2632 | ||
2633 | ||
2634 | Kaufman Standards Track [Page 47] | |
2635 | \f | |
2636 | RFC 4306 IKEv2 December 2005 | |
2637 | ||
2638 | ||
2639 | o Proposals (variable) - One or more proposal substructures. | |
2640 | ||
2641 | The payload type for the Security Association Payload is thirty | |
2642 | three (33). | |
2643 | ||
2644 | 3.3.1. Proposal Substructure | |
2645 | ||
2646 | 1 2 3 | |
2647 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
2648 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2649 | ! 0 (last) or 2 ! RESERVED ! Proposal Length ! | |
2650 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2651 | ! Proposal # ! Protocol ID ! SPI Size !# of Transforms! | |
2652 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2653 | ~ SPI (variable) ~ | |
2654 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2655 | ! ! | |
2656 | ~ <Transforms> ~ | |
2657 | ! ! | |
2658 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2659 | ||
2660 | Figure 7: Proposal Substructure | |
2661 | ||
2662 | o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the | |
2663 | last Proposal Substructure in the SA. This syntax is inherited | |
2664 | from ISAKMP, but is unnecessary because the last Proposal could | |
2665 | be identified from the length of the SA. The value (2) | |
2666 | corresponds to a Payload Type of Proposal in IKEv1, and the | |
2667 | first 4 octets of the Proposal structure are designed to look | |
2668 | somewhat like the header of a Payload. | |
2669 | ||
2670 | o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on | |
2671 | receipt. | |
2672 | ||
2673 | o Proposal Length (2 octets) - Length of this proposal, including | |
2674 | all transforms and attributes that follow. | |
2675 | ||
2676 | o Proposal # (1 octet) - When a proposal is made, the first | |
2677 | proposal in an SA payload MUST be #1, and subsequent proposals | |
2678 | MUST either be the same as the previous proposal (indicating an | |
2679 | AND of the two proposals) or one more than the previous | |
2680 | proposal (indicating an OR of the two proposals). When a | |
2681 | proposal is accepted, all of the proposal numbers in the SA | |
2682 | payload MUST be the same and MUST match the number on the | |
2683 | proposal sent that was accepted. | |
2684 | ||
2685 | ||
2686 | ||
2687 | ||
2688 | ||
2689 | ||
2690 | Kaufman Standards Track [Page 48] | |
2691 | \f | |
2692 | RFC 4306 IKEv2 December 2005 | |
2693 | ||
2694 | ||
2695 | o Protocol ID (1 octet) - Specifies the IPsec protocol identifier | |
2696 | for the current negotiation. The defined values are: | |
2697 | ||
2698 | Protocol Protocol ID | |
2699 | RESERVED 0 | |
2700 | IKE 1 | |
2701 | AH 2 | |
2702 | ESP 3 | |
2703 | RESERVED TO IANA 4-200 | |
2704 | PRIVATE USE 201-255 | |
2705 | ||
2706 | o SPI Size (1 octet) - For an initial IKE_SA negotiation, this | |
2707 | field MUST be zero; the SPI is obtained from the outer header. | |
2708 | During subsequent negotiations, it is equal to the size, in | |
2709 | octets, of the SPI of the corresponding protocol (8 for IKE, 4 | |
2710 | for ESP and AH). | |
2711 | ||
2712 | o # of Transforms (1 octet) - Specifies the number of transforms | |
2713 | in this proposal. | |
2714 | ||
2715 | o SPI (variable) - The sending entity's SPI. Even if the SPI Size | |
2716 | is not a multiple of 4 octets, there is no padding applied to | |
2717 | the payload. When the SPI Size field is zero, this field is | |
2718 | not present in the Security Association payload. | |
2719 | ||
2720 | o Transforms (variable) - One or more transform substructures. | |
2721 | ||
2722 | 3.3.2. Transform Substructure | |
2723 | ||
2724 | 1 2 3 | |
2725 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
2726 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2727 | ! 0 (last) or 3 ! RESERVED ! Transform Length ! | |
2728 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2729 | !Transform Type ! RESERVED ! Transform ID ! | |
2730 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2731 | ! ! | |
2732 | ~ Transform Attributes ~ | |
2733 | ! ! | |
2734 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2735 | ||
2736 | Figure 8: Transform Substructure | |
2737 | ||
2738 | o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the | |
2739 | last Transform Substructure in the Proposal. This syntax is | |
2740 | inherited from ISAKMP, but is unnecessary because the last | |
2741 | Proposal could be identified from the length of the SA. The | |
2742 | ||
2743 | ||
2744 | ||
2745 | ||
2746 | Kaufman Standards Track [Page 49] | |
2747 | \f | |
2748 | RFC 4306 IKEv2 December 2005 | |
2749 | ||
2750 | ||
2751 | value (3) corresponds to a Payload Type of Transform in IKEv1, | |
2752 | and the first 4 octets of the Transform structure are designed | |
2753 | to look somewhat like the header of a Payload. | |
2754 | ||
2755 | o RESERVED - MUST be sent as zero; MUST be ignored on receipt. | |
2756 | ||
2757 | o Transform Length - The length (in octets) of the Transform | |
2758 | Substructure including Header and Attributes. | |
2759 | ||
2760 | o Transform Type (1 octet) - The type of transform being | |
2761 | specified in this transform. Different protocols support | |
2762 | different transform types. For some protocols, some of the | |
2763 | transforms may be optional. If a transform is optional and the | |
2764 | initiator wishes to propose that the transform be omitted, no | |
2765 | transform of the given type is included in the proposal. If | |
2766 | the initiator wishes to make use of the transform optional to | |
2767 | the responder, it includes a transform substructure with | |
2768 | transform ID = 0 as one of the options. | |
2769 | ||
2770 | o Transform ID (2 octets) - The specific instance of the | |
2771 | transform type being proposed. | |
2772 | ||
2773 | Transform Type Values | |
2774 | ||
2775 | Transform Used In | |
2776 | Type | |
2777 | RESERVED 0 | |
2778 | Encryption Algorithm (ENCR) 1 (IKE and ESP) | |
2779 | Pseudo-random Function (PRF) 2 (IKE) | |
2780 | Integrity Algorithm (INTEG) 3 (IKE, AH, optional in ESP) | |
2781 | Diffie-Hellman Group (D-H) 4 (IKE, optional in AH & ESP) | |
2782 | Extended Sequence Numbers (ESN) 5 (AH and ESP) | |
2783 | RESERVED TO IANA 6-240 | |
2784 | PRIVATE USE 241-255 | |
2785 | ||
2786 | For Transform Type 1 (Encryption Algorithm), defined Transform IDs | |
2787 | are: | |
2788 | ||
2789 | Name Number Defined In | |
2790 | RESERVED 0 | |
2791 | ENCR_DES_IV64 1 (RFC1827) | |
2792 | ENCR_DES 2 (RFC2405), [DES] | |
2793 | ENCR_3DES 3 (RFC2451) | |
2794 | ENCR_RC5 4 (RFC2451) | |
2795 | ENCR_IDEA 5 (RFC2451), [IDEA] | |
2796 | ENCR_CAST 6 (RFC2451) | |
2797 | ENCR_BLOWFISH 7 (RFC2451) | |
2798 | ENCR_3IDEA 8 (RFC2451) | |
2799 | ||
2800 | ||
2801 | ||
2802 | Kaufman Standards Track [Page 50] | |
2803 | \f | |
2804 | RFC 4306 IKEv2 December 2005 | |
2805 | ||
2806 | ||
2807 | ENCR_DES_IV32 9 | |
2808 | RESERVED 10 | |
2809 | ENCR_NULL 11 (RFC2410) | |
2810 | ENCR_AES_CBC 12 (RFC3602) | |
2811 | ENCR_AES_CTR 13 (RFC3664) | |
2812 | ||
2813 | values 14-1023 are reserved to IANA. Values 1024-65535 are | |
2814 | for private use among mutually consenting parties. | |
2815 | ||
2816 | For Transform Type 2 (Pseudo-random Function), defined Transform IDs | |
2817 | are: | |
2818 | ||
2819 | Name Number Defined In | |
2820 | RESERVED 0 | |
2821 | PRF_HMAC_MD5 1 (RFC2104), [MD5] | |
2822 | PRF_HMAC_SHA1 2 (RFC2104), [SHA] | |
2823 | PRF_HMAC_TIGER 3 (RFC2104) | |
2824 | PRF_AES128_XCBC 4 (RFC3664) | |
2825 | ||
2826 | values 5-1023 are reserved to IANA. Values 1024-65535 are for | |
2827 | private use among mutually consenting parties. | |
2828 | ||
2829 | For Transform Type 3 (Integrity Algorithm), defined Transform IDs | |
2830 | are: | |
2831 | ||
2832 | Name Number Defined In | |
2833 | NONE 0 | |
2834 | AUTH_HMAC_MD5_96 1 (RFC2403) | |
2835 | AUTH_HMAC_SHA1_96 2 (RFC2404) | |
2836 | AUTH_DES_MAC 3 | |
2837 | AUTH_KPDK_MD5 4 (RFC1826) | |
2838 | AUTH_AES_XCBC_96 5 (RFC3566) | |
2839 | ||
2840 | values 6-1023 are reserved to IANA. Values 1024-65535 are for | |
2841 | private use among mutually consenting parties. | |
2842 | ||
2843 | For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs | |
2844 | are: | |
2845 | ||
2846 | Name Number | |
2847 | NONE 0 | |
2848 | Defined in Appendix B 1 - 2 | |
2849 | RESERVED 3 - 4 | |
2850 | Defined in [ADDGROUP] 5 | |
2851 | RESERVED TO IANA 6 - 13 | |
2852 | Defined in [ADDGROUP] 14 - 18 | |
2853 | RESERVED TO IANA 19 - 1023 | |
2854 | PRIVATE USE 1024-65535 | |
2855 | ||
2856 | ||
2857 | ||
2858 | Kaufman Standards Track [Page 51] | |
2859 | \f | |
2860 | RFC 4306 IKEv2 December 2005 | |
2861 | ||
2862 | ||
2863 | For Transform Type 5 (Extended Sequence Numbers), defined Transform | |
2864 | IDs are: | |
2865 | ||
2866 | Name Number | |
2867 | No Extended Sequence Numbers 0 | |
2868 | Extended Sequence Numbers 1 | |
2869 | RESERVED 2 - 65535 | |
2870 | ||
2871 | 3.3.3. Valid Transform Types by Protocol | |
2872 | ||
2873 | The number and type of transforms that accompany an SA payload are | |
2874 | dependent on the protocol in the SA itself. An SA payload proposing | |
2875 | the establishment of an SA has the following mandatory and optional | |
2876 | transform types. A compliant implementation MUST understand all | |
2877 | mandatory and optional types for each protocol it supports (though it | |
2878 | need not accept proposals with unacceptable suites). A proposal MAY | |
2879 | omit the optional types if the only value for them it will accept is | |
2880 | NONE. | |
2881 | ||
2882 | Protocol Mandatory Types Optional Types | |
2883 | IKE ENCR, PRF, INTEG, D-H | |
2884 | ESP ENCR, ESN INTEG, D-H | |
2885 | AH INTEG, ESN D-H | |
2886 | ||
2887 | 3.3.4. Mandatory Transform IDs | |
2888 | ||
2889 | The specification of suites that MUST and SHOULD be supported for | |
2890 | interoperability has been removed from this document because they are | |
2891 | likely to change more rapidly than this document evolves. | |
2892 | ||
2893 | An important lesson learned from IKEv1 is that no system should only | |
2894 | implement the mandatory algorithms and expect them to be the best | |
2895 | choice for all customers. For example, at the time that this | |
2896 | document was written, many IKEv1 implementers were starting to | |
2897 | migrate to AES in Cipher Block Chaining (CBC) mode for Virtual | |
2898 | Private Network (VPN) applications. Many IPsec systems based on | |
2899 | IKEv2 will implement AES, additional Diffie-Hellman groups, and | |
2900 | additional hash algorithms, and some IPsec customers already require | |
2901 | these algorithms in addition to the ones listed above. | |
2902 | ||
2903 | It is likely that IANA will add additional transforms in the future, | |
2904 | and some users may want to use private suites, especially for IKE | |
2905 | where implementations should be capable of supporting different | |
2906 | parameters, up to certain size limits. In support of this goal, all | |
2907 | implementations of IKEv2 SHOULD include a management facility that | |
2908 | allows specification (by a user or system administrator) of Diffie- | |
2909 | Hellman (DH) parameters (the generator, modulus, and exponent lengths | |
2910 | and values) for new DH groups. Implementations SHOULD provide a | |
2911 | ||
2912 | ||
2913 | ||
2914 | Kaufman Standards Track [Page 52] | |
2915 | \f | |
2916 | RFC 4306 IKEv2 December 2005 | |
2917 | ||
2918 | ||
2919 | management interface via which these parameters and the associated | |
2920 | transform IDs may be entered (by a user or system administrator), to | |
2921 | enable negotiating such groups. | |
2922 | ||
2923 | All implementations of IKEv2 MUST include a management facility that | |
2924 | enables a user or system administrator to specify the suites that are | |
2925 | acceptable for use with IKE. Upon receipt of a payload with a set of | |
2926 | transform IDs, the implementation MUST compare the transmitted | |
2927 | transform IDs against those locally configured via the management | |
2928 | controls, to verify that the proposed suite is acceptable based on | |
2929 | local policy. The implementation MUST reject SA proposals that are | |
2930 | not authorized by these IKE suite controls. Note that cryptographic | |
2931 | suites that MUST be implemented need not be configured as acceptable | |
2932 | to local policy. | |
2933 | ||
2934 | 3.3.5. Transform Attributes | |
2935 | ||
2936 | Each transform in a Security Association payload may include | |
2937 | attributes that modify or complete the specification of the | |
2938 | transform. These attributes are type/value pairs and are defined | |
2939 | below. For example, if an encryption algorithm has a variable-length | |
2940 | key, the key length to be used may be specified as an attribute. | |
2941 | Attributes can have a value with a fixed two octet length or a | |
2942 | variable-length value. For the latter, the attribute is encoded as | |
2943 | type/length/value. | |
2944 | ||
2945 | 1 2 3 | |
2946 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
2947 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2948 | !A! Attribute Type ! AF=0 Attribute Length ! | |
2949 | !F! ! AF=1 Attribute Value ! | |
2950 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2951 | ! AF=0 Attribute Value ! | |
2952 | ! AF=1 Not Transmitted ! | |
2953 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
2954 | ||
2955 | Figure 9: Data Attributes | |
2956 | ||
2957 | o Attribute Type (2 octets) - Unique identifier for each type of | |
2958 | attribute (see below). | |
2959 | ||
2960 | The most significant bit of this field is the Attribute Format | |
2961 | bit (AF). It indicates whether the data attributes follow the | |
2962 | Type/Length/Value (TLV) format or a shortened Type/Value (TV) | |
2963 | format. If the AF bit is zero (0), then the Data Attributes | |
2964 | are of the Type/Length/Value (TLV) form. If the AF bit is a | |
2965 | one (1), then the Data Attributes are of the Type/Value form. | |
2966 | ||
2967 | ||
2968 | ||
2969 | ||
2970 | Kaufman Standards Track [Page 53] | |
2971 | \f | |
2972 | RFC 4306 IKEv2 December 2005 | |
2973 | ||
2974 | ||
2975 | o Attribute Length (2 octets) - Length in octets of the Attribute | |
2976 | Value. When the AF bit is a one (1), the Attribute Value is | |
2977 | only 2 octets and the Attribute Length field is not present. | |
2978 | ||
2979 | o Attribute Value (variable length) - Value of the Attribute | |
2980 | associated with the Attribute Type. If the AF bit is a zero | |
2981 | (0), this field has a variable length defined by the Attribute | |
2982 | Length field. If the AF bit is a one (1), the Attribute Value | |
2983 | has a length of 2 octets. | |
2984 | ||
2985 | Note that only a single attribute type (Key Length) is defined, and | |
2986 | it is fixed length. The variable-length encoding specification is | |
2987 | included only for future extensions. The only algorithms defined in | |
2988 | this document that accept attributes are the AES-based encryption, | |
2989 | integrity, and pseudo-random functions, which require a single | |
2990 | attribute specifying key width. | |
2991 | ||
2992 | Attributes described as basic MUST NOT be encoded using the | |
2993 | variable-length encoding. Variable-length attributes MUST NOT be | |
2994 | encoded as basic even if their value can fit into two octets. NOTE: | |
2995 | This is a change from IKEv1, where increased flexibility may have | |
2996 | simplified the composer of messages but certainly complicated the | |
2997 | parser. | |
2998 | ||
2999 | Attribute Type Value Attribute Format | |
3000 | -------------------------------------------------------------- | |
3001 | RESERVED 0-13 Key Length (in bits) | |
3002 | 14 TV RESERVED 15-17 | |
3003 | RESERVED TO IANA 18-16383 PRIVATE USE | |
3004 | 16384-32767 | |
3005 | ||
3006 | Values 0-13 and 15-17 were used in a similar context in IKEv1 and | |
3007 | should not be assigned except to matching values. Values 18-16383 | |
3008 | are reserved to IANA. Values 16384-32767 are for private use among | |
3009 | mutually consenting parties. | |
3010 | ||
3011 | - Key Length | |
3012 | ||
3013 | When using an Encryption Algorithm that has a variable-length key, | |
3014 | this attribute specifies the key length in bits (MUST use network | |
3015 | byte order). This attribute MUST NOT be used when the specified | |
3016 | Encryption Algorithm uses a fixed-length key. | |
3017 | ||
3018 | ||
3019 | ||
3020 | ||
3021 | ||
3022 | ||
3023 | ||
3024 | ||
3025 | ||
3026 | Kaufman Standards Track [Page 54] | |
3027 | \f | |
3028 | RFC 4306 IKEv2 December 2005 | |
3029 | ||
3030 | ||
3031 | 3.3.6. Attribute Negotiation | |
3032 | ||
3033 | During security association negotiation, initiators present offers to | |
3034 | responders. Responders MUST select a single complete set of | |
3035 | parameters from the offers (or reject all offers if none are | |
3036 | acceptable). If there are multiple proposals, the responder MUST | |
3037 | choose a single proposal number and return all of the Proposal | |
3038 | substructures with that Proposal number. If there are multiple | |
3039 | Transforms with the same type, the responder MUST choose a single | |
3040 | one. Any attributes of a selected transform MUST be returned | |
3041 | unmodified. The initiator of an exchange MUST check that the | |
3042 | accepted offer is consistent with one of its proposals, and if not | |
3043 | that response MUST be rejected. | |
3044 | ||
3045 | Negotiating Diffie-Hellman groups presents some special challenges. | |
3046 | SA offers include proposed attributes and a Diffie-Hellman public | |
3047 | number (KE) in the same message. If in the initial exchange the | |
3048 | initiator offers to use one of several Diffie-Hellman groups, it | |
3049 | SHOULD pick the one the responder is most likely to accept and | |
3050 | include a KE corresponding to that group. If the guess turns out to | |
3051 | be wrong, the responder will indicate the correct group in the | |
3052 | response and the initiator SHOULD pick an element of that group for | |
3053 | its KE value when retrying the first message. It SHOULD, however, | |
3054 | continue to propose its full supported set of groups in order to | |
3055 | prevent a man-in-the-middle downgrade attack. | |
3056 | ||
3057 | Implementation Note: | |
3058 | ||
3059 | Certain negotiable attributes can have ranges or could have | |
3060 | multiple acceptable values. These include the key length of a | |
3061 | variable key length symmetric cipher. To further interoperability | |
3062 | and to support upgrading endpoints independently, implementers of | |
3063 | this protocol SHOULD accept values that they deem to supply | |
3064 | greater security. For instance, if a peer is configured to accept | |
3065 | a variable-length cipher with a key length of X bits and is | |
3066 | offered that cipher with a larger key length, the implementation | |
3067 | SHOULD accept the offer if it supports use of the longer key. | |
3068 | ||
3069 | Support of this capability allows an implementation to express a | |
3070 | concept of "at least" a certain level of security -- "a key length of | |
3071 | _at least_ X bits for cipher Y". | |
3072 | ||
3073 | ||
3074 | ||
3075 | ||
3076 | ||
3077 | ||
3078 | ||
3079 | ||
3080 | ||
3081 | ||
3082 | Kaufman Standards Track [Page 55] | |
3083 | \f | |
3084 | RFC 4306 IKEv2 December 2005 | |
3085 | ||
3086 | ||
3087 | 3.4. Key Exchange Payload | |
3088 | ||
3089 | The Key Exchange Payload, denoted KE in this memo, is used to | |
3090 | exchange Diffie-Hellman public numbers as part of a Diffie-Hellman | |
3091 | key exchange. The Key Exchange Payload consists of the IKE generic | |
3092 | payload header followed by the Diffie-Hellman public value itself. | |
3093 | ||
3094 | 1 2 3 | |
3095 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
3096 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3097 | ! Next Payload !C! RESERVED ! Payload Length ! | |
3098 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3099 | ! DH Group # ! RESERVED ! | |
3100 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3101 | ! ! | |
3102 | ~ Key Exchange Data ~ | |
3103 | ! ! | |
3104 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3105 | ||
3106 | Figure 10: Key Exchange Payload Format | |
3107 | ||
3108 | A key exchange payload is constructed by copying one's Diffie-Hellman | |
3109 | public value into the "Key Exchange Data" portion of the payload. | |
3110 | The length of the Diffie-Hellman public value MUST be equal to the | |
3111 | length of the prime modulus over which the exponentiation was | |
3112 | performed, prepending zero bits to the value if necessary. | |
3113 | ||
3114 | The DH Group # identifies the Diffie-Hellman group in which the Key | |
3115 | Exchange Data was computed (see section 3.3.2). If the selected | |
3116 | proposal uses a different Diffie-Hellman group, the message MUST be | |
3117 | rejected with a Notify payload of type INVALID_KE_PAYLOAD. | |
3118 | ||
3119 | The payload type for the Key Exchange payload is thirty four (34). | |
3120 | ||
3121 | 3.5. Identification Payloads | |
3122 | ||
3123 | The Identification Payloads, denoted IDi and IDr in this memo, allow | |
3124 | peers to assert an identity to one another. This identity may be | |
3125 | used for policy lookup, but does not necessarily have to match | |
3126 | anything in the CERT payload; both fields may be used by an | |
3127 | implementation to perform access control decisions. | |
3128 | ||
3129 | NOTE: In IKEv1, two ID payloads were used in each direction to hold | |
3130 | Traffic Selector (TS) information for data passing over the SA. In | |
3131 | IKEv2, this information is carried in TS payloads (see section 3.13). | |
3132 | ||
3133 | ||
3134 | ||
3135 | ||
3136 | ||
3137 | ||
3138 | Kaufman Standards Track [Page 56] | |
3139 | \f | |
3140 | RFC 4306 IKEv2 December 2005 | |
3141 | ||
3142 | ||
3143 | The Identification Payload consists of the IKE generic payload header | |
3144 | followed by identification fields as follows: | |
3145 | ||
3146 | 1 2 3 | |
3147 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
3148 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3149 | ! Next Payload !C! RESERVED ! Payload Length ! | |
3150 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3151 | ! ID Type ! RESERVED | | |
3152 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3153 | ! ! | |
3154 | ~ Identification Data ~ | |
3155 | ! ! | |
3156 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3157 | ||
3158 | Figure 11: Identification Payload Format | |
3159 | ||
3160 | o ID Type (1 octet) - Specifies the type of Identification being | |
3161 | used. | |
3162 | ||
3163 | o RESERVED - MUST be sent as zero; MUST be ignored on receipt. | |
3164 | ||
3165 | o Identification Data (variable length) - Value, as indicated by the | |
3166 | Identification Type. The length of the Identification Data is | |
3167 | computed from the size in the ID payload header. | |
3168 | ||
3169 | The payload types for the Identification Payload are thirty five (35) | |
3170 | for IDi and thirty six (36) for IDr. | |
3171 | ||
3172 | The following table lists the assigned values for the Identification | |
3173 | Type field, followed by a description of the Identification Data | |
3174 | which follows: | |
3175 | ||
3176 | ID Type Value | |
3177 | ------- ----- | |
3178 | RESERVED 0 | |
3179 | ||
3180 | ID_IPV4_ADDR 1 | |
3181 | ||
3182 | A single four (4) octet IPv4 address. | |
3183 | ||
3184 | ID_FQDN 2 | |
3185 | ||
3186 | A fully-qualified domain name string. An example of a | |
3187 | ID_FQDN is, "example.com". The string MUST not contain any | |
3188 | terminators (e.g., NULL, CR, etc.). | |
3189 | ||
3190 | ||
3191 | ||
3192 | ||
3193 | ||
3194 | Kaufman Standards Track [Page 57] | |
3195 | \f | |
3196 | RFC 4306 IKEv2 December 2005 | |
3197 | ||
3198 | ||
3199 | ID_RFC822_ADDR 3 | |
3200 | ||
3201 | A fully-qualified RFC822 email address string, An example of | |
3202 | a ID_RFC822_ADDR is, "jsmith@example.com". The string MUST | |
3203 | not contain any terminators. | |
3204 | ||
3205 | Reserved to IANA 4 | |
3206 | ||
3207 | ID_IPV6_ADDR 5 | |
3208 | ||
3209 | A single sixteen (16) octet IPv6 address. | |
3210 | ||
3211 | Reserved to IANA 6 - 8 | |
3212 | ||
3213 | ID_DER_ASN1_DN 9 | |
3214 | ||
3215 | The binary Distinguished Encoding Rules (DER) encoding of an | |
3216 | ASN.1 X.500 Distinguished Name [X.501]. | |
3217 | ||
3218 | ID_DER_ASN1_GN 10 | |
3219 | ||
3220 | The binary DER encoding of an ASN.1 X.500 GeneralName | |
3221 | [X.509]. | |
3222 | ||
3223 | ID_KEY_ID 11 | |
3224 | ||
3225 | An opaque octet stream which may be used to pass vendor- | |
3226 | specific information necessary to do certain proprietary | |
3227 | types of identification. | |
3228 | ||
3229 | Reserved to IANA 12-200 | |
3230 | ||
3231 | Reserved for private use 201-255 | |
3232 | ||
3233 | Two implementations will interoperate only if each can generate a | |
3234 | type of ID acceptable to the other. To assure maximum | |
3235 | interoperability, implementations MUST be configurable to send at | |
3236 | least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and | |
3237 | MUST be configurable to accept all of these types. Implementations | |
3238 | SHOULD be capable of generating and accepting all of these types. | |
3239 | IPv6-capable implementations MUST additionally be configurable to | |
3240 | accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable | |
3241 | to send only ID_IPV6_ADDR. | |
3242 | ||
3243 | ||
3244 | ||
3245 | ||
3246 | ||
3247 | ||
3248 | ||
3249 | ||
3250 | Kaufman Standards Track [Page 58] | |
3251 | \f | |
3252 | RFC 4306 IKEv2 December 2005 | |
3253 | ||
3254 | ||
3255 | 3.6. Certificate Payload | |
3256 | ||
3257 | The Certificate Payload, denoted CERT in this memo, provides a means | |
3258 | to transport certificates or other authentication-related information | |
3259 | via IKE. Certificate payloads SHOULD be included in an exchange if | |
3260 | certificates are available to the sender unless the peer has | |
3261 | indicated an ability to retrieve this information from elsewhere | |
3262 | using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the | |
3263 | term "Certificate Payload" is somewhat misleading, because not all | |
3264 | authentication mechanisms use certificates and data other than | |
3265 | certificates may be passed in this payload. | |
3266 | ||
3267 | The Certificate Payload is defined as follows: | |
3268 | ||
3269 | 1 2 3 | |
3270 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
3271 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3272 | ! Next Payload !C! RESERVED ! Payload Length ! | |
3273 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3274 | ! Cert Encoding ! ! | |
3275 | +-+-+-+-+-+-+-+-+ ! | |
3276 | ~ Certificate Data ~ | |
3277 | ! ! | |
3278 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3279 | ||
3280 | Figure 12: Certificate Payload Format | |
3281 | ||
3282 | o Certificate Encoding (1 octet) - This field indicates the type | |
3283 | of certificate or certificate-related information contained in | |
3284 | the Certificate Data field. | |
3285 | ||
3286 | Certificate Encoding Value | |
3287 | -------------------- ----- | |
3288 | RESERVED 0 | |
3289 | PKCS #7 wrapped X.509 certificate 1 | |
3290 | PGP Certificate 2 | |
3291 | DNS Signed Key 3 | |
3292 | X.509 Certificate - Signature 4 | |
3293 | Kerberos Token 6 | |
3294 | Certificate Revocation List (CRL) 7 | |
3295 | Authority Revocation List (ARL) 8 | |
3296 | SPKI Certificate 9 | |
3297 | X.509 Certificate - Attribute 10 | |
3298 | Raw RSA Key 11 | |
3299 | Hash and URL of X.509 certificate 12 | |
3300 | Hash and URL of X.509 bundle 13 | |
3301 | RESERVED to IANA 14 - 200 | |
3302 | PRIVATE USE 201 - 255 | |
3303 | ||
3304 | ||
3305 | ||
3306 | Kaufman Standards Track [Page 59] | |
3307 | \f | |
3308 | RFC 4306 IKEv2 December 2005 | |
3309 | ||
3310 | ||
3311 | o Certificate Data (variable length) - Actual encoding of | |
3312 | certificate data. The type of certificate is indicated by the | |
3313 | Certificate Encoding field. | |
3314 | ||
3315 | The payload type for the Certificate Payload is thirty seven (37). | |
3316 | ||
3317 | Specific syntax is for some of the certificate type codes above is | |
3318 | not defined in this document. The types whose syntax is defined in | |
3319 | this document are: | |
3320 | ||
3321 | X.509 Certificate - Signature (4) contains a DER encoded X.509 | |
3322 | certificate whose public key is used to validate the sender's AUTH | |
3323 | payload. | |
3324 | ||
3325 | Certificate Revocation List (7) contains a DER encoded X.509 | |
3326 | certificate revocation list. | |
3327 | ||
3328 | Raw RSA Key (11) contains a PKCS #1 encoded RSA key (see [RSA] and | |
3329 | [PKCS1]). | |
3330 | ||
3331 | Hash and URL encodings (12-13) allow IKE messages to remain short | |
3332 | by replacing long data structures with a 20 octet SHA-1 hash (see | |
3333 | [SHA]) of the replaced value followed by a variable-length URL | |
3334 | that resolves to the DER encoded data structure itself. This | |
3335 | improves efficiency when the endpoints have certificate data | |
3336 | cached and makes IKE less subject to denial of service attacks | |
3337 | that become easier to mount when IKE messages are large enough to | |
3338 | require IP fragmentation [KPS03]. | |
3339 | ||
3340 | Use the following ASN.1 definition for an X.509 bundle: | |
3341 | ||
3342 | CertBundle | |
3343 | { iso(1) identified-organization(3) dod(6) internet(1) | |
3344 | security(5) mechanisms(5) pkix(7) id-mod(0) | |
3345 | id-mod-cert-bundle(34) } | |
3346 | ||
3347 | DEFINITIONS EXPLICIT TAGS ::= | |
3348 | BEGIN | |
3349 | ||
3350 | IMPORTS | |
3351 | Certificate, CertificateList | |
3352 | FROM PKIX1Explicit88 | |
3353 | { iso(1) identified-organization(3) dod(6) | |
3354 | internet(1) security(5) mechanisms(5) pkix(7) | |
3355 | id-mod(0) id-pkix1-explicit(18) } ; | |
3356 | ||
3357 | ||
3358 | ||
3359 | ||
3360 | ||
3361 | ||
3362 | Kaufman Standards Track [Page 60] | |
3363 | \f | |
3364 | RFC 4306 IKEv2 December 2005 | |
3365 | ||
3366 | ||
3367 | CertificateOrCRL ::= CHOICE { | |
3368 | cert [0] Certificate, | |
3369 | crl [1] CertificateList } | |
3370 | ||
3371 | CertificateBundle ::= SEQUENCE OF CertificateOrCRL | |
3372 | ||
3373 | END | |
3374 | ||
3375 | Implementations MUST be capable of being configured to send and | |
3376 | accept up to four X.509 certificates in support of authentication, | |
3377 | and also MUST be capable of being configured to send and accept the | |
3378 | first two Hash and URL formats (with HTTP URLs). Implementations | |
3379 | SHOULD be capable of being configured to send and accept Raw RSA | |
3380 | keys. If multiple certificates are sent, the first certificate MUST | |
3381 | contain the public key used to sign the AUTH payload. The other | |
3382 | certificates may be sent in any order. | |
3383 | ||
3384 | 3.7. Certificate Request Payload | |
3385 | ||
3386 | The Certificate Request Payload, denoted CERTREQ in this memo, | |
3387 | provides a means to request preferred certificates via IKE and can | |
3388 | appear in the IKE_INIT_SA response and/or the IKE_AUTH request. | |
3389 | Certificate Request payloads MAY be included in an exchange when the | |
3390 | sender needs to get the certificate of the receiver. If multiple CAs | |
3391 | are trusted and the cert encoding does not allow a list, then | |
3392 | multiple Certificate Request payloads SHOULD be transmitted. | |
3393 | ||
3394 | The Certificate Request Payload is defined as follows: | |
3395 | ||
3396 | 1 2 3 | |
3397 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
3398 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3399 | ! Next Payload !C! RESERVED ! Payload Length ! | |
3400 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3401 | ! Cert Encoding ! ! | |
3402 | +-+-+-+-+-+-+-+-+ ! | |
3403 | ~ Certification Authority ~ | |
3404 | ! ! | |
3405 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3406 | ||
3407 | Figure 13: Certificate Request Payload Format | |
3408 | ||
3409 | o Certificate Encoding (1 octet) - Contains an encoding of the type | |
3410 | or format of certificate requested. Values are listed in section | |
3411 | 3.6. | |
3412 | ||
3413 | ||
3414 | ||
3415 | ||
3416 | ||
3417 | ||
3418 | Kaufman Standards Track [Page 61] | |
3419 | \f | |
3420 | RFC 4306 IKEv2 December 2005 | |
3421 | ||
3422 | ||
3423 | o Certification Authority (variable length) - Contains an encoding | |
3424 | of an acceptable certification authority for the type of | |
3425 | certificate requested. | |
3426 | ||
3427 | The payload type for the Certificate Request Payload is thirty eight | |
3428 | (38). | |
3429 | ||
3430 | The Certificate Encoding field has the same values as those defined | |
3431 | in section 3.6. The Certification Authority field contains an | |
3432 | indicator of trusted authorities for this certificate type. The | |
3433 | Certification Authority value is a concatenated list of SHA-1 hashes | |
3434 | of the public keys of trusted Certification Authorities (CAs). Each | |
3435 | is encoded as the SHA-1 hash of the Subject Public Key Info element | |
3436 | (see section 4.1.2.7 of [RFC3280]) from each Trust Anchor | |
3437 | certificate. The twenty-octet hashes are concatenated and included | |
3438 | with no other formatting. | |
3439 | ||
3440 | Note that the term "Certificate Request" is somewhat misleading, in | |
3441 | that values other than certificates are defined in a "Certificate" | |
3442 | payload and requests for those values can be present in a Certificate | |
3443 | Request Payload. The syntax of the Certificate Request payload in | |
3444 | such cases is not defined in this document. | |
3445 | ||
3446 | The Certificate Request Payload is processed by inspecting the "Cert | |
3447 | Encoding" field to determine whether the processor has any | |
3448 | certificates of this type. If so, the "Certification Authority" | |
3449 | field is inspected to determine if the processor has any certificates | |
3450 | that can be validated up to one of the specified certification | |
3451 | authorities. This can be a chain of certificates. | |
3452 | ||
3453 | If an end-entity certificate exists that satisfies the criteria | |
3454 | specified in the CERTREQ, a certificate or certificate chain SHOULD | |
3455 | be sent back to the certificate requestor if the recipient of the | |
3456 | CERTREQ: | |
3457 | ||
3458 | - is configured to use certificate authentication, | |
3459 | ||
3460 | - is allowed to send a CERT payload, | |
3461 | ||
3462 | - has matching CA trust policy governing the current negotiation, and | |
3463 | ||
3464 | - has at least one time-wise and usage appropriate end-entity | |
3465 | certificate chaining to a CA provided in the CERTREQ. | |
3466 | ||
3467 | Certificate revocation checking must be considered during the | |
3468 | chaining process used to select a certificate. Note that even if two | |
3469 | peers are configured to use two different CAs, cross-certification | |
3470 | relationships should be supported by appropriate selection logic. | |
3471 | ||
3472 | ||
3473 | ||
3474 | Kaufman Standards Track [Page 62] | |
3475 | \f | |
3476 | RFC 4306 IKEv2 December 2005 | |
3477 | ||
3478 | ||
3479 | The intent is not to prevent communication through the strict | |
3480 | adherence of selection of a certificate based on CERTREQ, when an | |
3481 | alternate certificate could be selected by the sender that would | |
3482 | still enable the recipient to successfully validate and trust it | |
3483 | through trust conveyed by cross-certification, CRLs, or other out- | |
3484 | of-band configured means. Thus, the processing of a CERTREQ should | |
3485 | be seen as a suggestion for a certificate to select, not a mandated | |
3486 | one. If no certificates exist, then the CERTREQ is ignored. This is | |
3487 | not an error condition of the protocol. There may be cases where | |
3488 | there is a preferred CA sent in the CERTREQ, but an alternate might | |
3489 | be acceptable (perhaps after prompting a human operator). | |
3490 | ||
3491 | 3.8. Authentication Payload | |
3492 | ||
3493 | The Authentication Payload, denoted AUTH in this memo, contains data | |
3494 | used for authentication purposes. The syntax of the Authentication | |
3495 | data varies according to the Auth Method as specified below. | |
3496 | ||
3497 | The Authentication Payload is defined as follows: | |
3498 | ||
3499 | 1 2 3 | |
3500 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
3501 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3502 | ! Next Payload !C! RESERVED ! Payload Length ! | |
3503 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3504 | ! Auth Method ! RESERVED ! | |
3505 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3506 | ! ! | |
3507 | ~ Authentication Data ~ | |
3508 | ! ! | |
3509 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3510 | ||
3511 | Figure 14: Authentication Payload Format | |
3512 | ||
3513 | o Auth Method (1 octet) - Specifies the method of authentication | |
3514 | used. Values defined are: | |
3515 | ||
3516 | RSA Digital Signature (1) - Computed as specified in section | |
3517 | 2.15 using an RSA private key over a PKCS#1 padded hash (see | |
3518 | [RSA] and [PKCS1]). | |
3519 | ||
3520 | Shared Key Message Integrity Code (2) - Computed as specified in | |
3521 | section 2.15 using the shared key associated with the identity | |
3522 | in the ID payload and the negotiated prf function | |
3523 | ||
3524 | DSS Digital Signature (3) - Computed as specified in section | |
3525 | 2.15 using a DSS private key (see [DSS]) over a SHA-1 hash. | |
3526 | ||
3527 | ||
3528 | ||
3529 | ||
3530 | Kaufman Standards Track [Page 63] | |
3531 | \f | |
3532 | RFC 4306 IKEv2 December 2005 | |
3533 | ||
3534 | ||
3535 | The values 0 and 4-200 are reserved to IANA. The values 201-255 | |
3536 | are available for private use. | |
3537 | ||
3538 | o Authentication Data (variable length) - see section 2.15. | |
3539 | ||
3540 | The payload type for the Authentication Payload is thirty nine (39). | |
3541 | ||
3542 | 3.9. Nonce Payload | |
3543 | ||
3544 | The Nonce Payload, denoted Ni and Nr in this memo for the initiator's | |
3545 | and responder's nonce respectively, contains random data used to | |
3546 | guarantee liveness during an exchange and protect against replay | |
3547 | attacks. | |
3548 | ||
3549 | The Nonce Payload is defined as follows: | |
3550 | ||
3551 | 1 2 3 | |
3552 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
3553 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3554 | ! Next Payload !C! RESERVED ! Payload Length ! | |
3555 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3556 | ! ! | |
3557 | ~ Nonce Data ~ | |
3558 | ! ! | |
3559 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3560 | ||
3561 | Figure 15: Nonce Payload Format | |
3562 | ||
3563 | o Nonce Data (variable length) - Contains the random data generated | |
3564 | by the transmitting entity. | |
3565 | ||
3566 | The payload type for the Nonce Payload is forty (40). | |
3567 | ||
3568 | The size of a Nonce MUST be between 16 and 256 octets inclusive. | |
3569 | Nonce values MUST NOT be reused. | |
3570 | ||
3571 | 3.10. Notify Payload | |
3572 | ||
3573 | The Notify Payload, denoted N in this document, is used to transmit | |
3574 | informational data, such as error conditions and state transitions, | |
3575 | to an IKE peer. A Notify Payload may appear in a response message | |
3576 | (usually specifying why a request was rejected), in an INFORMATIONAL | |
3577 | Exchange (to report an error not in an IKE request), or in any other | |
3578 | message to indicate sender capabilities or to modify the meaning of | |
3579 | the request. | |
3580 | ||
3581 | ||
3582 | ||
3583 | ||
3584 | ||
3585 | ||
3586 | Kaufman Standards Track [Page 64] | |
3587 | \f | |
3588 | RFC 4306 IKEv2 December 2005 | |
3589 | ||
3590 | ||
3591 | The Notify Payload is defined as follows: | |
3592 | ||
3593 | 1 2 3 | |
3594 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
3595 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3596 | ! Next Payload !C! RESERVED ! Payload Length ! | |
3597 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3598 | ! Protocol ID ! SPI Size ! Notify Message Type ! | |
3599 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3600 | ! ! | |
3601 | ~ Security Parameter Index (SPI) ~ | |
3602 | ! ! | |
3603 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3604 | ! ! | |
3605 | ~ Notification Data ~ | |
3606 | ! ! | |
3607 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
3608 | ||
3609 | Figure 16: Notify Payload Format | |
3610 | ||
3611 | o Protocol ID (1 octet) - If this notification concerns an existing | |
3612 | SA, this field indicates the type of that SA. For IKE_SA | |
3613 | notifications, this field MUST be one (1). For notifications | |
3614 | concerning IPsec SAs this field MUST contain either (2) to | |
3615 | indicate AH or (3) to indicate ESP. For notifications that do not | |
3616 | relate to an existing SA, this field MUST be sent as zero and MUST | |
3617 | be ignored on receipt. All other values for this field are | |
3618 | reserved to IANA for future assignment. | |
3619 | ||
3620 | o SPI Size (1 octet) - Length in octets of the SPI as defined by the | |
3621 | IPsec protocol ID or zero if no SPI is applicable. For a | |
3622 | notification concerning the IKE_SA, the SPI Size MUST be zero. | |
3623 | ||
3624 | o Notify Message Type (2 octets) - Specifies the type of | |
3625 | notification message. | |
3626 | ||
3627 | o SPI (variable length) - Security Parameter Index. | |
3628 | ||
3629 | o Notification Data (variable length) - Informational or error data | |
3630 | transmitted in addition to the Notify Message Type. Values for | |
3631 | this field are type specific (see below). | |
3632 | ||
3633 | The payload type for the Notify Payload is forty one (41). | |
3634 | ||
3635 | ||
3636 | ||
3637 | ||
3638 | ||
3639 | ||
3640 | ||
3641 | ||
3642 | Kaufman Standards Track [Page 65] | |
3643 | \f | |
3644 | RFC 4306 IKEv2 December 2005 | |
3645 | ||
3646 | ||
3647 | 3.10.1. Notify Message Types | |
3648 | ||
3649 | Notification information can be error messages specifying why an SA | |
3650 | could not be established. It can also be status data that a process | |
3651 | managing an SA database wishes to communicate with a peer process. | |
3652 | The table below lists the Notification messages and their | |
3653 | corresponding values. The number of different error statuses was | |
3654 | greatly reduced from IKEv1 both for simplification and to avoid | |
3655 | giving configuration information to probers. | |
3656 | ||
3657 | Types in the range 0 - 16383 are intended for reporting errors. An | |
3658 | implementation receiving a Notify payload with one of these types | |
3659 | that it does not recognize in a response MUST assume that the | |
3660 | corresponding request has failed entirely. Unrecognized error types | |
3661 | in a request and status types in a request or response MUST be | |
3662 | ignored except that they SHOULD be logged. | |
3663 | ||
3664 | Notify payloads with status types MAY be added to any message and | |
3665 | MUST be ignored if not recognized. They are intended to indicate | |
3666 | capabilities, and as part of SA negotiation are used to negotiate | |
3667 | non-cryptographic parameters. | |
3668 | ||
3669 | NOTIFY MESSAGES - ERROR TYPES Value | |
3670 | ----------------------------- ----- | |
3671 | RESERVED 0 | |
3672 | ||
3673 | UNSUPPORTED_CRITICAL_PAYLOAD 1 | |
3674 | ||
3675 | Sent if the payload has the "critical" bit set and the | |
3676 | payload type is not recognized. Notification Data contains | |
3677 | the one-octet payload type. | |
3678 | ||
3679 | INVALID_IKE_SPI 4 | |
3680 | ||
3681 | Indicates an IKE message was received with an unrecognized | |
3682 | destination SPI. This usually indicates that the recipient | |
3683 | has rebooted and forgotten the existence of an IKE_SA. | |
3684 | ||
3685 | INVALID_MAJOR_VERSION 5 | |
3686 | ||
3687 | Indicates the recipient cannot handle the version of IKE | |
3688 | specified in the header. The closest version number that | |
3689 | the recipient can support will be in the reply header. | |
3690 | ||
3691 | INVALID_SYNTAX 7 | |
3692 | ||
3693 | Indicates the IKE message that was received was invalid | |
3694 | because some type, length, or value was out of range or | |
3695 | ||
3696 | ||
3697 | ||
3698 | Kaufman Standards Track [Page 66] | |
3699 | \f | |
3700 | RFC 4306 IKEv2 December 2005 | |
3701 | ||
3702 | ||
3703 | because the request was rejected for policy reasons. To | |
3704 | avoid a denial of service attack using forged messages, this | |
3705 | status may only be returned for and in an encrypted packet | |
3706 | if the message ID and cryptographic checksum were valid. To | |
3707 | avoid leaking information to someone probing a node, this | |
3708 | status MUST be sent in response to any error not covered by | |
3709 | one of the other status types. To aid debugging, more | |
3710 | detailed error information SHOULD be written to a console or | |
3711 | log. | |
3712 | ||
3713 | INVALID_MESSAGE_ID 9 | |
3714 | ||
3715 | Sent when an IKE message ID outside the supported window is | |
3716 | received. This Notify MUST NOT be sent in a response; the | |
3717 | invalid request MUST NOT be acknowledged. Instead, inform | |
3718 | the other side by initiating an INFORMATIONAL exchange with | |
3719 | Notification data containing the four octet invalid message | |
3720 | ID. Sending this notification is optional, and | |
3721 | notifications of this type MUST be rate limited. | |
3722 | ||
3723 | INVALID_SPI 11 | |
3724 | ||
3725 | MAY be sent in an IKE INFORMATIONAL exchange when a node | |
3726 | receives an ESP or AH packet with an invalid SPI. The | |
3727 | Notification Data contains the SPI of the invalid packet. | |
3728 | This usually indicates a node has rebooted and forgotten an | |
3729 | SA. If this Informational Message is sent outside the | |
3730 | context of an IKE_SA, it should be used by the recipient | |
3731 | only as a "hint" that something might be wrong (because it | |
3732 | could easily be forged). | |
3733 | ||
3734 | NO_PROPOSAL_CHOSEN 14 | |
3735 | ||
3736 | None of the proposed crypto suites was acceptable. | |
3737 | ||
3738 | INVALID_KE_PAYLOAD 17 | |
3739 | ||
3740 | The D-H Group # field in the KE payload is not the group # | |
3741 | selected by the responder for this exchange. There are two | |
3742 | octets of data associated with this notification: the | |
3743 | accepted D-H Group # in big endian order. | |
3744 | ||
3745 | AUTHENTICATION_FAILED 24 | |
3746 | ||
3747 | Sent in the response to an IKE_AUTH message when for some | |
3748 | reason the authentication failed. There is no associated | |
3749 | data. | |
3750 | ||
3751 | ||
3752 | ||
3753 | ||
3754 | Kaufman Standards Track [Page 67] | |
3755 | \f | |
3756 | RFC 4306 IKEv2 December 2005 | |
3757 | ||
3758 | ||
3759 | SINGLE_PAIR_REQUIRED 34 | |
3760 | ||
3761 | This error indicates that a CREATE_CHILD_SA request is | |
3762 | unacceptable because its sender is only willing to accept | |
3763 | traffic selectors specifying a single pair of addresses. The | |
3764 | requestor is expected to respond by requesting an SA for only | |
3765 | the specific traffic it is trying to forward. | |
3766 | ||
3767 | NO_ADDITIONAL_SAS 35 | |
3768 | ||
3769 | This error indicates that a CREATE_CHILD_SA request is | |
3770 | unacceptable because the responder is unwilling to accept any | |
3771 | more CHILD_SAs on this IKE_SA. Some minimal implementations may | |
3772 | only accept a single CHILD_SA setup in the context of an initial | |
3773 | IKE exchange and reject any subsequent attempts to add more. | |
3774 | ||
3775 | INTERNAL_ADDRESS_FAILURE 36 | |
3776 | ||
3777 | Indicates an error assigning an internal address (i.e., | |
3778 | INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the | |
3779 | processing of a Configuration Payload by a responder. If this | |
3780 | error is generated within an IKE_AUTH exchange, no CHILD_SA will | |
3781 | be created. | |
3782 | ||
3783 | FAILED_CP_REQUIRED 37 | |
3784 | ||
3785 | Sent by responder in the case where CP(CFG_REQUEST) was expected | |
3786 | but not received, and so is a conflict with locally configured | |
3787 | policy. There is no associated data. | |
3788 | ||
3789 | TS_UNACCEPTABLE 38 | |
3790 | ||
3791 | Indicates that none of the addresses/protocols/ports in the | |
3792 | supplied traffic selectors is acceptable. | |
3793 | ||
3794 | INVALID_SELECTORS 39 | |
3795 | ||
3796 | MAY be sent in an IKE INFORMATIONAL exchange when a node | |
3797 | receives an ESP or AH packet whose selectors do not match | |
3798 | those of the SA on which it was delivered (and that caused | |
3799 | the packet to be dropped). The Notification Data contains | |
3800 | the start of the offending packet (as in ICMP messages) and | |
3801 | the SPI field of the notification is set to match the SPI of | |
3802 | the IPsec SA. | |
3803 | ||
3804 | RESERVED TO IANA - Error types 40 - 8191 | |
3805 | ||
3806 | Private Use - Errors 8192 - 16383 | |
3807 | ||
3808 | ||
3809 | ||
3810 | Kaufman Standards Track [Page 68] | |
3811 | \f | |
3812 | RFC 4306 IKEv2 December 2005 | |
3813 | ||
3814 | ||
3815 | NOTIFY MESSAGES - STATUS TYPES Value | |
3816 | ------------------------------ ----- | |
3817 | ||
3818 | INITIAL_CONTACT 16384 | |
3819 | ||
3820 | This notification asserts that this IKE_SA is the only | |
3821 | IKE_SA currently active between the authenticated | |
3822 | identities. It MAY be sent when an IKE_SA is established | |
3823 | after a crash, and the recipient MAY use this information to | |
3824 | delete any other IKE_SAs it has to the same authenticated | |
3825 | identity without waiting for a timeout. This notification | |
3826 | MUST NOT be sent by an entity that may be replicated (e.g., | |
3827 | a roaming user's credentials where the user is allowed to | |
3828 | connect to the corporate firewall from two remote systems at | |
3829 | the same time). | |
3830 | ||
3831 | SET_WINDOW_SIZE 16385 | |
3832 | ||
3833 | This notification asserts that the sending endpoint is | |
3834 | capable of keeping state for multiple outstanding exchanges, | |
3835 | permitting the recipient to send multiple requests before | |
3836 | getting a response to the first. The data associated with a | |
3837 | SET_WINDOW_SIZE notification MUST be 4 octets long and | |
3838 | contain the big endian representation of the number of | |
3839 | messages the sender promises to keep. Window size is always | |
3840 | one until the initial exchanges complete. | |
3841 | ||
3842 | ADDITIONAL_TS_POSSIBLE 16386 | |
3843 | ||
3844 | This notification asserts that the sending endpoint narrowed | |
3845 | the proposed traffic selectors but that other traffic | |
3846 | selectors would also have been acceptable, though only in a | |
3847 | separate SA (see section 2.9). There is no data associated | |
3848 | with this Notify type. It may be sent only as an additional | |
3849 | payload in a message including accepted TSs. | |
3850 | ||
3851 | IPCOMP_SUPPORTED 16387 | |
3852 | ||
3853 | This notification may be included only in a message | |
3854 | containing an SA payload negotiating a CHILD_SA and | |
3855 | indicates a willingness by its sender to use IPComp on this | |
3856 | SA. The data associated with this notification includes a | |
3857 | two-octet IPComp CPI followed by a one-octet transform ID | |
3858 | optionally followed by attributes whose length and format | |
3859 | are defined by that transform ID. A message proposing an SA | |
3860 | may contain multiple IPCOMP_SUPPORTED notifications to | |
3861 | indicate multiple supported algorithms. A message accepting | |
3862 | an SA may contain at most one. | |
3863 | ||
3864 | ||
3865 | ||
3866 | Kaufman Standards Track [Page 69] | |
3867 | \f | |
3868 | RFC 4306 IKEv2 December 2005 | |
3869 | ||
3870 | ||
3871 | The transform IDs currently defined are: | |
3872 | ||
3873 | NAME NUMBER DEFINED IN | |
3874 | ----------- ------ ----------- | |
3875 | RESERVED 0 | |
3876 | IPCOMP_OUI 1 | |
3877 | IPCOMP_DEFLATE 2 RFC 2394 | |
3878 | IPCOMP_LZS 3 RFC 2395 | |
3879 | IPCOMP_LZJH 4 RFC 3051 | |
3880 | ||
3881 | values 5-240 are reserved to IANA. Values 241-255 are | |
3882 | for private use among mutually consenting parties. | |
3883 | ||
3884 | NAT_DETECTION_SOURCE_IP 16388 | |
3885 | ||
3886 | This notification is used by its recipient to determine | |
3887 | whether the source is behind a NAT box. The data associated | |
3888 | with this notification is a SHA-1 digest of the SPIs (in the | |
3889 | order they appear in the header), IP address, and port on | |
3890 | which this packet was sent. There MAY be multiple Notify | |
3891 | payloads of this type in a message if the sender does not | |
3892 | know which of several network attachments will be used to | |
3893 | send the packet. The recipient of this notification MAY | |
3894 | compare the supplied value to a SHA-1 hash of the SPIs, | |
3895 | source IP address, and port, and if they don't match it | |
3896 | SHOULD enable NAT traversal (see section 2.23). | |
3897 | Alternately, it MAY reject the connection attempt if NAT | |
3898 | traversal is not supported. | |
3899 | ||
3900 | NAT_DETECTION_DESTINATION_IP 16389 | |
3901 | ||
3902 | This notification is used by its recipient to determine | |
3903 | whether it is behind a NAT box. The data associated with | |
3904 | this notification is a SHA-1 digest of the SPIs (in the | |
3905 | order they appear in the header), IP address, and port to | |
3906 | which this packet was sent. The recipient of this | |
3907 | notification MAY compare the supplied value to a hash of the | |
3908 | SPIs, destination IP address, and port, and if they don't | |
3909 | match it SHOULD invoke NAT traversal (see section 2.23). If | |
3910 | they don't match, it means that this end is behind a NAT and | |
3911 | this end SHOULD start sending keepalive packets as defined | |
3912 | in [Hutt05]. Alternately, it MAY reject the connection | |
3913 | attempt if NAT traversal is not supported. | |
3914 | ||
3915 | ||
3916 | ||
3917 | ||
3918 | ||
3919 | ||
3920 | ||
3921 | ||
3922 | Kaufman Standards Track [Page 70] | |
3923 | \f | |
3924 | RFC 4306 IKEv2 December 2005 | |
3925 | ||
3926 | ||
3927 | COOKIE 16390 | |
3928 | ||
3929 | This notification MAY be included in an IKE_SA_INIT | |
3930 | response. It indicates that the request should be retried | |
3931 | with a copy of this notification as the first payload. This | |
3932 | notification MUST be included in an IKE_SA_INIT request | |
3933 | retry if a COOKIE notification was included in the initial | |
3934 | response. The data associated with this notification MUST | |
3935 | be between 1 and 64 octets in length (inclusive). | |
3936 | ||
3937 | USE_TRANSPORT_MODE 16391 | |
3938 | ||
3939 | This notification MAY be included in a request message that | |
3940 | also includes an SA payload requesting a CHILD_SA. It | |
3941 | requests that the CHILD_SA use transport mode rather than | |
3942 | tunnel mode for the SA created. If the request is accepted, | |
3943 | the response MUST also include a notification of type | |
3944 | USE_TRANSPORT_MODE. If the responder declines the request, | |
3945 | the CHILD_SA will be established in tunnel mode. If this is | |
3946 | unacceptable to the initiator, the initiator MUST delete the | |
3947 | SA. Note: Except when using this option to negotiate | |
3948 | transport mode, all CHILD_SAs will use tunnel mode. | |
3949 | ||
3950 | Note: The ECN decapsulation modifications specified in | |
3951 | [RFC4301] MUST be performed for every tunnel mode SA created | |
3952 | by IKEv2. | |
3953 | ||
3954 | HTTP_CERT_LOOKUP_SUPPORTED 16392 | |
3955 | ||
3956 | This notification MAY be included in any message that can | |
3957 | include a CERTREQ payload and indicates that the sender is | |
3958 | capable of looking up certificates based on an HTTP-based | |
3959 | URL (and hence presumably would prefer to receive | |
3960 | certificate specifications in that format). | |
3961 | ||
3962 | REKEY_SA 16393 | |
3963 | ||
3964 | This notification MUST be included in a CREATE_CHILD_SA | |
3965 | exchange if the purpose of the exchange is to replace an | |
3966 | existing ESP or AH SA. The SPI field identifies the SA | |
3967 | being rekeyed. There is no data. | |
3968 | ||
3969 | ESP_TFC_PADDING_NOT_SUPPORTED 16394 | |
3970 | ||
3971 | This notification asserts that the sending endpoint will NOT | |
3972 | accept packets that contain Flow Confidentiality (TFC) | |
3973 | padding. | |
3974 | ||
3975 | ||
3976 | ||
3977 | ||
3978 | Kaufman Standards Track [Page 71] | |
3979 | \f | |
3980 | RFC 4306 IKEv2 December 2005 | |
3981 | ||
3982 | ||
3983 | NON_FIRST_FRAGMENTS_ALSO 16395 | |
3984 | ||
3985 | Used for fragmentation control. See [RFC4301] for | |
3986 | explanation. | |
3987 | ||
3988 | RESERVED TO IANA - STATUS TYPES 16396 - 40959 | |
3989 | ||
3990 | Private Use - STATUS TYPES 40960 - 65535 | |
3991 | ||
3992 | 3.11. Delete Payload | |
3993 | ||
3994 | The Delete Payload, denoted D in this memo, contains a protocol- | |
3995 | specific security association identifier that the sender has removed | |
3996 | from its security association database and is, therefore, no longer | |
3997 | valid. Figure 17 shows the format of the Delete Payload. It is | |
3998 | possible to send multiple SPIs in a Delete payload; however, each SPI | |
3999 | MUST be for the same protocol. Mixing of protocol identifiers MUST | |
4000 | NOT be performed in a Delete payload. It is permitted, however, to | |
4001 | include multiple Delete payloads in a single INFORMATIONAL exchange | |
4002 | where each Delete payload lists SPIs for a different protocol. | |
4003 | ||
4004 | Deletion of the IKE_SA is indicated by a protocol ID of 1 (IKE) but | |
4005 | no SPIs. Deletion of a CHILD_SA, such as ESP or AH, will contain the | |
4006 | IPsec protocol ID of that protocol (2 for AH, 3 for ESP), and the SPI | |
4007 | is the SPI the sending endpoint would expect in inbound ESP or AH | |
4008 | packets. | |
4009 | ||
4010 | The Delete Payload is defined as follows: | |
4011 | ||
4012 | 1 2 3 | |
4013 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
4014 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4015 | ! Next Payload !C! RESERVED ! Payload Length ! | |
4016 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4017 | ! Protocol ID ! SPI Size ! # of SPIs ! | |
4018 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4019 | ! ! | |
4020 | ~ Security Parameter Index(es) (SPI) ~ | |
4021 | ! ! | |
4022 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4023 | ||
4024 | Figure 17: Delete Payload Format | |
4025 | ||
4026 | o Protocol ID (1 octet) - Must be 1 for an IKE_SA, 2 for AH, or 3 | |
4027 | for ESP. | |
4028 | ||
4029 | ||
4030 | ||
4031 | ||
4032 | ||
4033 | ||
4034 | Kaufman Standards Track [Page 72] | |
4035 | \f | |
4036 | RFC 4306 IKEv2 December 2005 | |
4037 | ||
4038 | ||
4039 | o SPI Size (1 octet) - Length in octets of the SPI as defined by the | |
4040 | protocol ID. It MUST be zero for IKE (SPI is in message header) | |
4041 | or four for AH and ESP. | |
4042 | ||
4043 | o # of SPIs (2 octets) - The number of SPIs contained in the Delete | |
4044 | payload. The size of each SPI is defined by the SPI Size field. | |
4045 | ||
4046 | o Security Parameter Index(es) (variable length) - Identifies the | |
4047 | specific security association(s) to delete. The length of this | |
4048 | field is determined by the SPI Size and # of SPIs fields. | |
4049 | ||
4050 | The payload type for the Delete Payload is forty two (42). | |
4051 | ||
4052 | 3.12. Vendor ID Payload | |
4053 | ||
4054 | The Vendor ID Payload, denoted V in this memo, contains a vendor | |
4055 | defined constant. The constant is used by vendors to identify and | |
4056 | recognize remote instances of their implementations. This mechanism | |
4057 | allows a vendor to experiment with new features while maintaining | |
4058 | backward compatibility. | |
4059 | ||
4060 | A Vendor ID payload MAY announce that the sender is capable to | |
4061 | accepting certain extensions to the protocol, or it MAY simply | |
4062 | identify the implementation as an aid in debugging. A Vendor ID | |
4063 | payload MUST NOT change the interpretation of any information defined | |
4064 | in this specification (i.e., the critical bit MUST be set to 0). | |
4065 | Multiple Vendor ID payloads MAY be sent. An implementation is NOT | |
4066 | REQUIRED to send any Vendor ID payload at all. | |
4067 | ||
4068 | A Vendor ID payload may be sent as part of any message. Reception of | |
4069 | a familiar Vendor ID payload allows an implementation to make use of | |
4070 | Private USE numbers described throughout this memo -- private | |
4071 | payloads, private exchanges, private notifications, etc. Unfamiliar | |
4072 | Vendor IDs MUST be ignored. | |
4073 | ||
4074 | Writers of Internet-Drafts who wish to extend this protocol MUST | |
4075 | define a Vendor ID payload to announce the ability to implement the | |
4076 | extension in the Internet-Draft. It is expected that Internet-Drafts | |
4077 | that gain acceptance and are standardized will be given "magic | |
4078 | numbers" out of the Future Use range by IANA, and the requirement to | |
4079 | use a Vendor ID will go away. | |
4080 | ||
4081 | ||
4082 | ||
4083 | ||
4084 | ||
4085 | ||
4086 | ||
4087 | ||
4088 | ||
4089 | ||
4090 | Kaufman Standards Track [Page 73] | |
4091 | \f | |
4092 | RFC 4306 IKEv2 December 2005 | |
4093 | ||
4094 | ||
4095 | The Vendor ID Payload fields are defined as follows: | |
4096 | ||
4097 | 1 2 3 | |
4098 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
4099 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4100 | ! Next Payload !C! RESERVED ! Payload Length ! | |
4101 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4102 | ! ! | |
4103 | ~ Vendor ID (VID) ~ | |
4104 | ! ! | |
4105 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4106 | ||
4107 | Figure 18: Vendor ID Payload Format | |
4108 | ||
4109 | o Vendor ID (variable length) - It is the responsibility of the | |
4110 | person choosing the Vendor ID to assure its uniqueness in spite of | |
4111 | the absence of any central registry for IDs. Good practice is to | |
4112 | include a company name, a person name, or some such. If you want | |
4113 | to show off, you might include the latitude and longitude and time | |
4114 | where you were when you chose the ID and some random input. A | |
4115 | message digest of a long unique string is preferable to the long | |
4116 | unique string itself. | |
4117 | ||
4118 | The payload type for the Vendor ID Payload is forty three (43). | |
4119 | ||
4120 | 3.13. Traffic Selector Payload | |
4121 | ||
4122 | The Traffic Selector Payload, denoted TS in this memo, allows peers | |
4123 | to identify packet flows for processing by IPsec security services. | |
4124 | The Traffic Selector Payload consists of the IKE generic payload | |
4125 | header followed by individual traffic selectors as follows: | |
4126 | ||
4127 | 1 2 3 | |
4128 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
4129 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4130 | ! Next Payload !C! RESERVED ! Payload Length ! | |
4131 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4132 | ! Number of TSs ! RESERVED ! | |
4133 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4134 | ! ! | |
4135 | ~ <Traffic Selectors> ~ | |
4136 | ! ! | |
4137 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4138 | ||
4139 | Figure 19: Traffic Selectors Payload Format | |
4140 | ||
4141 | o Number of TSs (1 octet) - Number of traffic selectors being | |
4142 | provided. | |
4143 | ||
4144 | ||
4145 | ||
4146 | Kaufman Standards Track [Page 74] | |
4147 | \f | |
4148 | RFC 4306 IKEv2 December 2005 | |
4149 | ||
4150 | ||
4151 | o RESERVED - This field MUST be sent as zero and MUST be ignored on | |
4152 | receipt. | |
4153 | ||
4154 | o Traffic Selectors (variable length) - One or more individual | |
4155 | traffic selectors. | |
4156 | ||
4157 | The length of the Traffic Selector payload includes the TS header and | |
4158 | all the traffic selectors. | |
4159 | ||
4160 | The payload type for the Traffic Selector payload is forty four (44) | |
4161 | for addresses at the initiator's end of the SA and forty five (45) | |
4162 | for addresses at the responder's end. | |
4163 | ||
4164 | 3.13.1. Traffic Selector | |
4165 | ||
4166 | 1 2 3 | |
4167 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
4168 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4169 | ! TS Type !IP Protocol ID*| Selector Length | | |
4170 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4171 | | Start Port* | End Port* | | |
4172 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4173 | ! ! | |
4174 | ~ Starting Address* ~ | |
4175 | ! ! | |
4176 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4177 | ! ! | |
4178 | ~ Ending Address* ~ | |
4179 | ! ! | |
4180 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4181 | ||
4182 | Figure 20: Traffic Selector | |
4183 | ||
4184 | * Note: All fields other than TS Type and Selector Length depend on | |
4185 | the TS Type. The fields shown are for TS Types 7 and 8, the only two | |
4186 | values currently defined. | |
4187 | ||
4188 | o TS Type (one octet) - Specifies the type of traffic selector. | |
4189 | ||
4190 | o IP protocol ID (1 octet) - Value specifying an associated IP | |
4191 | protocol ID (e.g., UDP/TCP/ICMP). A value of zero means that the | |
4192 | protocol ID is not relevant to this traffic selector -- the SA can | |
4193 | carry all protocols. | |
4194 | ||
4195 | o Selector Length - Specifies the length of this Traffic Selector | |
4196 | Substructure including the header. | |
4197 | ||
4198 | ||
4199 | ||
4200 | ||
4201 | ||
4202 | Kaufman Standards Track [Page 75] | |
4203 | \f | |
4204 | RFC 4306 IKEv2 December 2005 | |
4205 | ||
4206 | ||
4207 | o Start Port (2 octets) - Value specifying the smallest port number | |
4208 | allowed by this Traffic Selector. For protocols for which port is | |
4209 | undefined, or if all ports are allowed, this field MUST be zero. | |
4210 | For the ICMP protocol, the two one-octet fields Type and Code are | |
4211 | treated as a single 16-bit integer (with Type in the most | |
4212 | significant eight bits and Code in the least significant eight | |
4213 | bits) port number for the purposes of filtering based on this | |
4214 | field. | |
4215 | ||
4216 | o End Port (2 octets) - Value specifying the largest port number | |
4217 | allowed by this Traffic Selector. For protocols for which port is | |
4218 | undefined, or if all ports are allowed, this field MUST be 65535. | |
4219 | For the ICMP protocol, the two one-octet fields Type and Code are | |
4220 | treated as a single 16-bit integer (with Type in the most | |
4221 | significant eight bits and Code in the least significant eight | |
4222 | bits) port number for the purposed of filtering based on this | |
4223 | field. | |
4224 | ||
4225 | o Starting Address - The smallest address included in this Traffic | |
4226 | Selector (length determined by TS type). | |
4227 | ||
4228 | o Ending Address - The largest address included in this Traffic | |
4229 | Selector (length determined by TS type). | |
4230 | ||
4231 | Systems that are complying with [RFC4301] that wish to indicate "ANY" | |
4232 | ports MUST set the start port to 0 and the end port to 65535; note | |
4233 | that according to [RFC4301], "ANY" includes "OPAQUE". Systems | |
4234 | working with [RFC4301] that wish to indicate "OPAQUE" ports, but not | |
4235 | "ANY" ports, MUST set the start port to 65535 and the end port to 0. | |
4236 | ||
4237 | The following table lists the assigned values for the Traffic | |
4238 | Selector Type field and the corresponding Address Selector Data. | |
4239 | ||
4240 | TS Type Value | |
4241 | ------- ----- | |
4242 | RESERVED 0-6 | |
4243 | ||
4244 | TS_IPV4_ADDR_RANGE 7 | |
4245 | ||
4246 | A range of IPv4 addresses, represented by two four-octet | |
4247 | values. The first value is the beginning IPv4 address | |
4248 | (inclusive) and the second value is the ending IPv4 address | |
4249 | (inclusive). All addresses falling between the two | |
4250 | specified addresses are considered to be within the list. | |
4251 | ||
4252 | ||
4253 | ||
4254 | ||
4255 | ||
4256 | ||
4257 | ||
4258 | Kaufman Standards Track [Page 76] | |
4259 | \f | |
4260 | RFC 4306 IKEv2 December 2005 | |
4261 | ||
4262 | ||
4263 | TS_IPV6_ADDR_RANGE 8 | |
4264 | ||
4265 | A range of IPv6 addresses, represented by two sixteen-octet | |
4266 | values. The first value is the beginning IPv6 address | |
4267 | (inclusive) and the second value is the ending IPv6 address | |
4268 | (inclusive). All addresses falling between the two | |
4269 | specified addresses are considered to be within the list. | |
4270 | ||
4271 | RESERVED TO IANA 9-240 | |
4272 | PRIVATE USE 241-255 | |
4273 | ||
4274 | 3.14. Encrypted Payload | |
4275 | ||
4276 | The Encrypted Payload, denoted SK{...} or E in this memo, contains | |
4277 | other payloads in encrypted form. The Encrypted Payload, if present | |
4278 | in a message, MUST be the last payload in the message. Often, it is | |
4279 | the only payload in the message. | |
4280 | ||
4281 | The algorithms for encryption and integrity protection are negotiated | |
4282 | during IKE_SA setup, and the keys are computed as specified in | |
4283 | sections 2.14 and 2.18. | |
4284 | ||
4285 | The encryption and integrity protection algorithms are modeled after | |
4286 | the ESP algorithms described in RFCs 2104 [KBC96], 4303 [RFC4303], | |
4287 | and 2451 [ESPCBC]. This document completely specifies the | |
4288 | cryptographic processing of IKE data, but those documents should be | |
4289 | consulted for design rationale. We require a block cipher with a | |
4290 | fixed block size and an integrity check algorithm that computes a | |
4291 | fixed-length checksum over a variable size message. | |
4292 | ||
4293 | The payload type for an Encrypted payload is forty six (46). The | |
4294 | Encrypted Payload consists of the IKE generic payload header followed | |
4295 | by individual fields as follows: | |
4296 | ||
4297 | ||
4298 | ||
4299 | ||
4300 | ||
4301 | ||
4302 | ||
4303 | ||
4304 | ||
4305 | ||
4306 | ||
4307 | ||
4308 | ||
4309 | ||
4310 | ||
4311 | ||
4312 | ||
4313 | ||
4314 | Kaufman Standards Track [Page 77] | |
4315 | \f | |
4316 | RFC 4306 IKEv2 December 2005 | |
4317 | ||
4318 | ||
4319 | 1 2 3 | |
4320 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
4321 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4322 | ! Next Payload !C! RESERVED ! Payload Length ! | |
4323 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4324 | ! Initialization Vector ! | |
4325 | ! (length is block size for encryption algorithm) ! | |
4326 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4327 | ~ Encrypted IKE Payloads ~ | |
4328 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4329 | ! ! Padding (0-255 octets) ! | |
4330 | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ | |
4331 | ! ! Pad Length ! | |
4332 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4333 | ~ Integrity Checksum Data ~ | |
4334 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4335 | ||
4336 | Figure 21: Encrypted Payload Format | |
4337 | ||
4338 | o Next Payload - The payload type of the first embedded payload. | |
4339 | Note that this is an exception in the standard header format, | |
4340 | since the Encrypted payload is the last payload in the message and | |
4341 | therefore the Next Payload field would normally be zero. But | |
4342 | because the content of this payload is embedded payloads and there | |
4343 | was no natural place to put the type of the first one, that type | |
4344 | is placed here. | |
4345 | ||
4346 | o Payload Length - Includes the lengths of the header, IV, Encrypted | |
4347 | IKE Payloads, Padding, Pad Length, and Integrity Checksum Data. | |
4348 | ||
4349 | o Initialization Vector - A randomly chosen value whose length is | |
4350 | equal to the block length of the underlying encryption algorithm. | |
4351 | Recipients MUST accept any value. Senders SHOULD either pick this | |
4352 | value pseudo-randomly and independently for each message or use | |
4353 | the final ciphertext block of the previous message sent. Senders | |
4354 | MUST NOT use the same value for each message, use a sequence of | |
4355 | values with low hamming distance (e.g., a sequence number), or use | |
4356 | ciphertext from a received message. | |
4357 | ||
4358 | o IKE Payloads are as specified earlier in this section. This field | |
4359 | is encrypted with the negotiated cipher. | |
4360 | ||
4361 | o Padding MAY contain any value chosen by the sender, and MUST have | |
4362 | a length that makes the combination of the Payloads, the Padding, | |
4363 | and the Pad Length to be a multiple of the encryption block size. | |
4364 | This field is encrypted with the negotiated cipher. | |
4365 | ||
4366 | ||
4367 | ||
4368 | ||
4369 | ||
4370 | Kaufman Standards Track [Page 78] | |
4371 | \f | |
4372 | RFC 4306 IKEv2 December 2005 | |
4373 | ||
4374 | ||
4375 | o Pad Length is the length of the Padding field. The sender SHOULD | |
4376 | set the Pad Length to the minimum value that makes the combination | |
4377 | of the Payloads, the Padding, and the Pad Length a multiple of the | |
4378 | block size, but the recipient MUST accept any length that results | |
4379 | in proper alignment. This field is encrypted with the negotiated | |
4380 | cipher. | |
4381 | ||
4382 | o Integrity Checksum Data is the cryptographic checksum of the | |
4383 | entire message starting with the Fixed IKE Header through the Pad | |
4384 | Length. The checksum MUST be computed over the encrypted message. | |
4385 | Its length is determined by the integrity algorithm negotiated. | |
4386 | ||
4387 | 3.15. Configuration Payload | |
4388 | ||
4389 | The Configuration payload, denoted CP in this document, is used to | |
4390 | exchange configuration information between IKE peers. The exchange | |
4391 | is for an IRAC to request an internal IP address from an IRAS and to | |
4392 | exchange other information of the sort that one would acquire with | |
4393 | Dynamic Host Configuration Protocol (DHCP) if the IRAC were directly | |
4394 | connected to a LAN. | |
4395 | ||
4396 | Configuration payloads are of type CFG_REQUEST/CFG_REPLY or | |
4397 | CFG_SET/CFG_ACK (see CFG Type in the payload description below). | |
4398 | CFG_REQUEST and CFG_SET payloads may optionally be added to any IKE | |
4399 | request. The IKE response MUST include either a corresponding | |
4400 | CFG_REPLY or CFG_ACK or a Notify payload with an error type | |
4401 | indicating why the request could not be honored. An exception is | |
4402 | that a minimal implementation MAY ignore all CFG_REQUEST and CFG_SET | |
4403 | payloads, so a response message without a corresponding CFG_REPLY or | |
4404 | CFG_ACK MUST be accepted as an indication that the request was not | |
4405 | supported. | |
4406 | ||
4407 | "CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information | |
4408 | from its peer. If an attribute in the CFG_REQUEST Configuration | |
4409 | Payload is not zero-length, it is taken as a suggestion for that | |
4410 | attribute. The CFG_REPLY Configuration Payload MAY return that | |
4411 | value, or a new one. It MAY also add new attributes and not include | |
4412 | some requested ones. Requestors MUST ignore returned attributes that | |
4413 | they do not recognize. | |
4414 | ||
4415 | Some attributes MAY be multi-valued, in which case multiple attribute | |
4416 | values of the same type are sent and/or returned. Generally, all | |
4417 | values of an attribute are returned when the attribute is requested. | |
4418 | For some attributes (in this version of the specification only | |
4419 | internal addresses), multiple requests indicates a request that | |
4420 | multiple values be assigned. For these attributes, the number of | |
4421 | values returned SHOULD NOT exceed the number requested. | |
4422 | ||
4423 | ||
4424 | ||
4425 | ||
4426 | Kaufman Standards Track [Page 79] | |
4427 | \f | |
4428 | RFC 4306 IKEv2 December 2005 | |
4429 | ||
4430 | ||
4431 | If the data type requested in a CFG_REQUEST is not recognized or not | |
4432 | supported, the responder MUST NOT return an error type but rather | |
4433 | MUST either send a CFG_REPLY that MAY be empty or a reply not | |
4434 | containing a CFG_REPLY payload at all. Error returns are reserved | |
4435 | for cases where the request is recognized but cannot be performed as | |
4436 | requested or the request is badly formatted. | |
4437 | ||
4438 | "CFG_SET/CFG_ACK" allows an IKE endpoint to push configuration data | |
4439 | to its peer. In this case, the CFG_SET Configuration Payload | |
4440 | contains attributes the initiator wants its peer to alter. The | |
4441 | responder MUST return a Configuration Payload if it accepted any of | |
4442 | the configuration data and it MUST contain the attributes that the | |
4443 | responder accepted with zero-length data. Those attributes that it | |
4444 | did not accept MUST NOT be in the CFG_ACK Configuration Payload. If | |
4445 | no attributes were accepted, the responder MUST return either an | |
4446 | empty CFG_ACK payload or a response message without a CFG_ACK | |
4447 | payload. There are currently no defined uses for the CFG_SET/CFG_ACK | |
4448 | exchange, though they may be used in connection with extensions based | |
4449 | on Vendor IDs. An minimal implementation of this specification MAY | |
4450 | ignore CFG_SET payloads. | |
4451 | ||
4452 | Extensions via the CP payload SHOULD NOT be used for general purpose | |
4453 | management. Its main intent is to provide a bootstrap mechanism to | |
4454 | exchange information within IPsec from IRAS to IRAC. While it MAY be | |
4455 | useful to use such a method to exchange information between some | |
4456 | Security Gateways (SGW) or small networks, existing management | |
4457 | protocols such as DHCP [DHCP], RADIUS [RADIUS], SNMP, or LDAP [LDAP] | |
4458 | should be preferred for enterprise management as well as subsequent | |
4459 | information exchanges. | |
4460 | ||
4461 | The Configuration Payload is defined as follows: | |
4462 | ||
4463 | 1 2 3 | |
4464 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
4465 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4466 | ! Next Payload !C! RESERVED ! Payload Length ! | |
4467 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4468 | ! CFG Type ! RESERVED ! | |
4469 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4470 | ! ! | |
4471 | ~ Configuration Attributes ~ | |
4472 | ! ! | |
4473 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4474 | ||
4475 | Figure 22: Configuration Payload Format | |
4476 | ||
4477 | The payload type for the Configuration Payload is forty seven (47). | |
4478 | ||
4479 | ||
4480 | ||
4481 | ||
4482 | Kaufman Standards Track [Page 80] | |
4483 | \f | |
4484 | RFC 4306 IKEv2 December 2005 | |
4485 | ||
4486 | ||
4487 | o CFG Type (1 octet) - The type of exchange represented by the | |
4488 | Configuration Attributes. | |
4489 | ||
4490 | CFG Type Value | |
4491 | =========== ===== | |
4492 | RESERVED 0 | |
4493 | CFG_REQUEST 1 | |
4494 | CFG_REPLY 2 | |
4495 | CFG_SET 3 | |
4496 | CFG_ACK 4 | |
4497 | ||
4498 | values 5-127 are reserved to IANA. Values 128-255 are for private | |
4499 | use among mutually consenting parties. | |
4500 | ||
4501 | o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on | |
4502 | receipt. | |
4503 | ||
4504 | o Configuration Attributes (variable length) - These are type length | |
4505 | values specific to the Configuration Payload and are defined | |
4506 | below. There may be zero or more Configuration Attributes in this | |
4507 | payload. | |
4508 | ||
4509 | 3.15.1. Configuration Attributes | |
4510 | ||
4511 | 1 2 3 | |
4512 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
4513 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4514 | !R| Attribute Type ! Length | | |
4515 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4516 | | | | |
4517 | ~ Value ~ | |
4518 | | | | |
4519 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4520 | ||
4521 | Figure 23: Configuration Attribute Format | |
4522 | ||
4523 | o Reserved (1 bit) - This bit MUST be set to zero and MUST be | |
4524 | ignored on receipt. | |
4525 | ||
4526 | o Attribute Type (15 bits) - A unique identifier for each of the | |
4527 | Configuration Attribute Types. | |
4528 | ||
4529 | o Length (2 octets) - Length in octets of Value. | |
4530 | ||
4531 | o Value (0 or more octets) - The variable-length value of this | |
4532 | Configuration Attribute. | |
4533 | ||
4534 | ||
4535 | ||
4536 | ||
4537 | ||
4538 | Kaufman Standards Track [Page 81] | |
4539 | \f | |
4540 | RFC 4306 IKEv2 December 2005 | |
4541 | ||
4542 | ||
4543 | The following attribute types have been defined: | |
4544 | ||
4545 | Multi- | |
4546 | Attribute Type Value Valued Length | |
4547 | ======================= ===== ====== ================== | |
4548 | RESERVED 0 | |
4549 | INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets | |
4550 | INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets | |
4551 | INTERNAL_IP4_DNS 3 YES 0 or 4 octets | |
4552 | INTERNAL_IP4_NBNS 4 YES 0 or 4 octets | |
4553 | INTERNAL_ADDRESS_EXPIRY 5 NO 0 or 4 octets | |
4554 | INTERNAL_IP4_DHCP 6 YES 0 or 4 octets | |
4555 | APPLICATION_VERSION 7 NO 0 or more | |
4556 | INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets | |
4557 | RESERVED 9 | |
4558 | INTERNAL_IP6_DNS 10 YES 0 or 16 octets | |
4559 | INTERNAL_IP6_NBNS 11 YES 0 or 16 octets | |
4560 | INTERNAL_IP6_DHCP 12 YES 0 or 16 octets | |
4561 | INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets | |
4562 | SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 | |
4563 | INTERNAL_IP6_SUBNET 15 YES 17 octets | |
4564 | ||
4565 | * These attributes may be multi-valued on return only if multiple | |
4566 | values were requested. | |
4567 | ||
4568 | Types 16-16383 are reserved to IANA. Values 16384-32767 are for | |
4569 | private use among mutually consenting parties. | |
4570 | ||
4571 | o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the | |
4572 | internal network, sometimes called a red node address or | |
4573 | private address and MAY be a private address on the Internet. | |
4574 | In a request message, the address specified is a requested | |
4575 | address (or zero if no specific address is requested). If a | |
4576 | specific address is requested, it likely indicates that a | |
4577 | previous connection existed with this address and the requestor | |
4578 | would like to reuse that address. With IPv6, a requestor MAY | |
4579 | supply the low-order address bytes it wants to use. Multiple | |
4580 | internal addresses MAY be requested by requesting multiple | |
4581 | internal address attributes. The responder MAY only send up to | |
4582 | the number of addresses requested. The INTERNAL_IP6_ADDRESS is | |
4583 | made up of two fields: the first is a sixteen-octet IPv6 | |
4584 | address and the second is a one-octet prefix-length as defined | |
4585 | in [ADDRIPV6]. | |
4586 | ||
4587 | The requested address is valid until the expiry time defined | |
4588 | with the INTERNAL_ADDRESS EXPIRY attribute or there are no | |
4589 | IKE_SAs between the peers. | |
4590 | ||
4591 | ||
4592 | ||
4593 | ||
4594 | Kaufman Standards Track [Page 82] | |
4595 | \f | |
4596 | RFC 4306 IKEv2 December 2005 | |
4597 | ||
4598 | ||
4599 | o INTERNAL_IP4_NETMASK - The internal network's netmask. Only | |
4600 | one netmask is allowed in the request and reply messages (e.g., | |
4601 | 255.255.255.0), and it MUST be used only with an | |
4602 | INTERNAL_IP4_ADDRESS attribute. | |
4603 | ||
4604 | o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a | |
4605 | DNS server within the network. Multiple DNS servers MAY be | |
4606 | requested. The responder MAY respond with zero or more DNS | |
4607 | server attributes. | |
4608 | ||
4609 | o INTERNAL_IP4_NBNS, INTERNAL_IP6_NBNS - Specifies an address of | |
4610 | a NetBios Name Server (WINS) within the network. Multiple NBNS | |
4611 | servers MAY be requested. The responder MAY respond with zero | |
4612 | or more NBNS server attributes. | |
4613 | ||
4614 | o INTERNAL_ADDRESS_EXPIRY - Specifies the number of seconds that | |
4615 | the host can use the internal IP address. The host MUST renew | |
4616 | the IP address before this expiry time. Only one of these | |
4617 | attributes MAY be present in the reply. | |
4618 | ||
4619 | o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to | |
4620 | send any internal DHCP requests to the address contained within | |
4621 | the attribute. Multiple DHCP servers MAY be requested. The | |
4622 | responder MAY respond with zero or more DHCP server attributes. | |
4623 | ||
4624 | o APPLICATION_VERSION - The version or application information of | |
4625 | the IPsec host. This is a string of printable ASCII characters | |
4626 | that is NOT null terminated. | |
4627 | ||
4628 | o INTERNAL_IP4_SUBNET - The protected sub-networks that this | |
4629 | edge-device protects. This attribute is made up of two fields: | |
4630 | the first is an IP address and the second is a netmask. | |
4631 | Multiple sub-networks MAY be requested. The responder MAY | |
4632 | respond with zero or more sub-network attributes. | |
4633 | ||
4634 | o SUPPORTED_ATTRIBUTES - When used within a Request, this | |
4635 | attribute MUST be zero-length and specifies a query to the | |
4636 | responder to reply back with all of the attributes that it | |
4637 | supports. The response contains an attribute that contains a | |
4638 | set of attribute identifiers each in 2 octets. The length | |
4639 | divided by 2 (octets) would state the number of supported | |
4640 | attributes contained in the response. | |
4641 | ||
4642 | ||
4643 | ||
4644 | ||
4645 | ||
4646 | ||
4647 | ||
4648 | ||
4649 | ||
4650 | Kaufman Standards Track [Page 83] | |
4651 | \f | |
4652 | RFC 4306 IKEv2 December 2005 | |
4653 | ||
4654 | ||
4655 | o INTERNAL_IP6_SUBNET - The protected sub-networks that this | |
4656 | edge-device protects. This attribute is made up of two fields: | |
4657 | the first is a sixteen-octet IPv6 address and the second is a | |
4658 | one-octet prefix-length as defined in [ADDRIPV6]. Multiple | |
4659 | sub-networks MAY be requested. The responder MAY respond with | |
4660 | zero or more sub-network attributes. | |
4661 | ||
4662 | Note that no recommendations are made in this document as to how | |
4663 | an implementation actually figures out what information to send in | |
4664 | a reply. That is, we do not recommend any specific method of an | |
4665 | IRAS determining which DNS server should be returned to a | |
4666 | requesting IRAC. | |
4667 | ||
4668 | 3.16. Extensible Authentication Protocol (EAP) Payload | |
4669 | ||
4670 | The Extensible Authentication Protocol Payload, denoted EAP in this | |
4671 | memo, allows IKE_SAs to be authenticated using the protocol defined | |
4672 | in RFC 3748 [EAP] and subsequent extensions to that protocol. The | |
4673 | full set of acceptable values for the payload is defined elsewhere, | |
4674 | but a short summary of RFC 3748 is included here to make this | |
4675 | document stand alone in the common cases. | |
4676 | ||
4677 | 1 2 3 | |
4678 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
4679 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4680 | ! Next Payload !C! RESERVED ! Payload Length ! | |
4681 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4682 | ! ! | |
4683 | ~ EAP Message ~ | |
4684 | ! ! | |
4685 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4686 | ||
4687 | Figure 24: EAP Payload Format | |
4688 | ||
4689 | The payload type for an EAP Payload is forty eight (48). | |
4690 | ||
4691 | 1 2 3 | |
4692 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |
4693 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4694 | ! Code ! Identifier ! Length ! | |
4695 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4696 | ! Type ! Type_Data... | |
4697 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | |
4698 | ||
4699 | Figure 25: EAP Message Format | |
4700 | ||
4701 | o Code (1 octet) indicates whether this message is a Request (1), | |
4702 | Response (2), Success (3), or Failure (4). | |
4703 | ||
4704 | ||
4705 | ||
4706 | Kaufman Standards Track [Page 84] | |
4707 | \f | |
4708 | RFC 4306 IKEv2 December 2005 | |
4709 | ||
4710 | ||
4711 | o Identifier (1 octet) is used in PPP to distinguish replayed | |
4712 | messages from repeated ones. Since in IKE, EAP runs over a | |
4713 | reliable protocol, it serves no function here. In a response | |
4714 | message, this octet MUST be set to match the identifier in the | |
4715 | corresponding request. In other messages, this field MAY be set | |
4716 | to any value. | |
4717 | ||
4718 | o Length (2 octets) is the length of the EAP message and MUST be | |
4719 | four less than the Payload Length of the encapsulating payload. | |
4720 | ||
4721 | o Type (1 octet) is present only if the Code field is Request (1) or | |
4722 | Response (2). For other codes, the EAP message length MUST be | |
4723 | four octets and the Type and Type_Data fields MUST NOT be present. | |
4724 | In a Request (1) message, Type indicates the data being requested. | |
4725 | In a Response (2) message, Type MUST either be Nak or match the | |
4726 | type of the data requested. The following types are defined in | |
4727 | RFC 3748: | |
4728 | ||
4729 | 1 Identity | |
4730 | 2 Notification | |
4731 | 3 Nak (Response Only) | |
4732 | 4 MD5-Challenge | |
4733 | 5 One-Time Password (OTP) | |
4734 | 6 Generic Token Card | |
4735 | ||
4736 | o Type_Data (Variable Length) varies with the Type of Request and | |
4737 | the associated Response. For the documentation of the EAP | |
4738 | methods, see [EAP]. | |
4739 | ||
4740 | Note that since IKE passes an indication of initiator identity in | |
4741 | message 3 of the protocol, the responder SHOULD NOT send EAP Identity | |
4742 | requests. The initiator SHOULD, however, respond to such requests if | |
4743 | it receives them. | |
4744 | ||
4745 | 4. Conformance Requirements | |
4746 | ||
4747 | In order to assure that all implementations of IKEv2 can | |
4748 | interoperate, there are "MUST support" requirements in addition to | |
4749 | those listed elsewhere. Of course, IKEv2 is a security protocol, and | |
4750 | one of its major functions is to allow only authorized parties to | |
4751 | successfully complete establishment of SAs. So a particular | |
4752 | implementation may be configured with any of a number of restrictions | |
4753 | concerning algorithms and trusted authorities that will prevent | |
4754 | universal interoperability. | |
4755 | ||
4756 | ||
4757 | ||
4758 | ||
4759 | ||
4760 | ||
4761 | ||
4762 | Kaufman Standards Track [Page 85] | |
4763 | \f | |
4764 | RFC 4306 IKEv2 December 2005 | |
4765 | ||
4766 | ||
4767 | IKEv2 is designed to permit minimal implementations that can | |
4768 | interoperate with all compliant implementations. There are a series | |
4769 | of optional features that can easily be ignored by a particular | |
4770 | implementation if it does not support that feature. Those features | |
4771 | include: | |
4772 | ||
4773 | Ability to negotiate SAs through a NAT and tunnel the resulting | |
4774 | ESP SA over UDP. | |
4775 | ||
4776 | Ability to request (and respond to a request for) a temporary IP | |
4777 | address on the remote end of a tunnel. | |
4778 | ||
4779 | Ability to support various types of legacy authentication. | |
4780 | ||
4781 | Ability to support window sizes greater than one. | |
4782 | ||
4783 | Ability to establish multiple ESP and/or AH SAs within a single | |
4784 | IKE_SA. | |
4785 | ||
4786 | Ability to rekey SAs. | |
4787 | ||
4788 | To assure interoperability, all implementations MUST be capable of | |
4789 | parsing all payload types (if only to skip over them) and to ignore | |
4790 | payload types that it does not support unless the critical bit is set | |
4791 | in the payload header. If the critical bit is set in an unsupported | |
4792 | payload header, all implementations MUST reject the messages | |
4793 | containing those payloads. | |
4794 | ||
4795 | Every implementation MUST be capable of doing four-message | |
4796 | IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, | |
4797 | one for ESP and/or AH). Implementations MAY be initiate-only or | |
4798 | respond-only if appropriate for their platform. Every implementation | |
4799 | MUST be capable of responding to an INFORMATIONAL exchange, but a | |
4800 | minimal implementation MAY respond to any INFORMATIONAL message with | |
4801 | an empty INFORMATIONAL reply (note that within the context of an | |
4802 | IKE_SA, an "empty" message consists of an IKE header followed by an | |
4803 | Encrypted payload with no payloads contained in it). A minimal | |
4804 | implementation MAY support the CREATE_CHILD_SA exchange only in so | |
4805 | far as to recognize requests and reject them with a Notify payload of | |
4806 | type NO_ADDITIONAL_SAS. A minimal implementation need not be able to | |
4807 | initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA | |
4808 | expires (based on locally configured values of either lifetime or | |
4809 | octets passed), and implementation MAY either try to renew it with a | |
4810 | CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and | |
4811 | create a new one. If the responder rejects the CREATE_CHILD_SA | |
4812 | request with a NO_ADDITIONAL_SAS notification, the implementation | |
4813 | MUST be capable of instead closing the old SA and creating a new one. | |
4814 | ||
4815 | ||
4816 | ||
4817 | ||
4818 | Kaufman Standards Track [Page 86] | |
4819 | \f | |
4820 | RFC 4306 IKEv2 December 2005 | |
4821 | ||
4822 | ||
4823 | Implementations are not required to support requesting temporary IP | |
4824 | addresses or responding to such requests. If an implementation does | |
4825 | support issuing such requests, it MUST include a CP payload in | |
4826 | message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or | |
4827 | INTERNAL_IP6_ADDRESS. All other fields are optional. If an | |
4828 | implementation supports responding to such requests, it MUST parse | |
4829 | the CP payload of type CFG_REQUEST in message 3 and recognize a field | |
4830 | of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports | |
4831 | leasing an address of the appropriate type, it MUST return a CP | |
4832 | payload of type CFG_REPLY containing an address of the requested | |
4833 | type. The responder SHOULD include all of the other related | |
4834 | attributes if it has them. | |
4835 | ||
4836 | A minimal IPv4 responder implementation will ignore the contents of | |
4837 | the CP payload except to determine that it includes an | |
4838 | INTERNAL_IP4_ADDRESS attribute and will respond with the address and | |
4839 | other related attributes regardless of whether the initiator | |
4840 | requested them. | |
4841 | ||
4842 | A minimal IPv4 initiator will generate a CP payload containing only | |
4843 | an INTERNAL_IP4_ADDRESS attribute and will parse the response | |
4844 | ignoring attributes it does not know how to use. The only attribute | |
4845 | it MUST be able to process is INTERNAL_ADDRESS_EXPIRY, which it must | |
4846 | use to bound the lifetime of the SA unless it successfully renews the | |
4847 | lease before it expires. Minimal initiators need not be able to | |
4848 | request lease renewals and minimal responders need not respond to | |
4849 | them. | |
4850 | ||
4851 | For an implementation to be called conforming to this specification, | |
4852 | it MUST be possible to configure it to accept the following: | |
4853 | ||
4854 | PKIX Certificates containing and signed by RSA keys of size 1024 or | |
4855 | 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, | |
4856 | ID_RFC822_ADDR, or ID_DER_ASN1_DN. | |
4857 | ||
4858 | Shared key authentication where the ID passes is any of ID_KEY_ID, | |
4859 | ID_FQDN, or ID_RFC822_ADDR. | |
4860 | ||
4861 | Authentication where the responder is authenticated using PKIX | |
4862 | Certificates and the initiator is authenticated using shared key | |
4863 | authentication. | |
4864 | ||
4865 | ||
4866 | ||
4867 | ||
4868 | ||
4869 | ||
4870 | ||
4871 | ||
4872 | ||
4873 | ||
4874 | Kaufman Standards Track [Page 87] | |
4875 | \f | |
4876 | RFC 4306 IKEv2 December 2005 | |
4877 | ||
4878 | ||
4879 | 5. Security Considerations | |
4880 | ||
4881 | While this protocol is designed to minimize disclosure of | |
4882 | configuration information to unauthenticated peers, some such | |
4883 | disclosure is unavoidable. One peer or the other must identify | |
4884 | itself first and prove its identity first. To avoid probing, the | |
4885 | initiator of an exchange is required to identify itself first, and | |
4886 | usually is required to authenticate itself first. The initiator can, | |
4887 | however, learn that the responder supports IKE and what cryptographic | |
4888 | protocols it supports. The responder (or someone impersonating the | |
4889 | responder) can probe the initiator not only for its identity, but | |
4890 | using CERTREQ payloads may be able to determine what certificates the | |
4891 | initiator is willing to use. | |
4892 | ||
4893 | Use of EAP authentication changes the probing possibilities somewhat. | |
4894 | When EAP authentication is used, the responder proves its identity | |
4895 | before the initiator does, so an initiator that knew the name of a | |
4896 | valid initiator could probe the responder for both its name and | |
4897 | certificates. | |
4898 | ||
4899 | Repeated rekeying using CREATE_CHILD_SA without additional Diffie- | |
4900 | Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a | |
4901 | single key or overrun of either endpoint. Implementers should take | |
4902 | note of this fact and set a limit on CREATE_CHILD_SA exchanges | |
4903 | between exponentiations. This memo does not prescribe such a limit. | |
4904 | ||
4905 | The strength of a key derived from a Diffie-Hellman exchange using | |
4906 | any of the groups defined here depends on the inherent strength of | |
4907 | the group, the size of the exponent used, and the entropy provided by | |
4908 | the random number generator used. Due to these inputs, it is | |
4909 | difficult to determine the strength of a key for any of the defined | |
4910 | groups. Diffie-Hellman group number two, when used with a strong | |
4911 | random number generator and an exponent no less than 200 bits, is | |
4912 | common for use with 3DES. Group five provides greater security than | |
4913 | group two. Group one is for historic purposes only and does not | |
4914 | provide sufficient strength except for use with DES, which is also | |
4915 | for historic use only. Implementations should make note of these | |
4916 | estimates when establishing policy and negotiating security | |
4917 | parameters. | |
4918 | ||
4919 | Note that these limitations are on the Diffie-Hellman groups | |
4920 | themselves. There is nothing in IKE that prohibits using stronger | |
4921 | groups nor is there anything that will dilute the strength obtained | |
4922 | from stronger groups (limited by the strength of the other algorithms | |
4923 | negotiated including the prf function). In fact, the extensible | |
4924 | framework of IKE encourages the definition of more groups; use of | |
4925 | elliptical curve groups may greatly increase strength using much | |
4926 | smaller numbers. | |
4927 | ||
4928 | ||
4929 | ||
4930 | Kaufman Standards Track [Page 88] | |
4931 | \f | |
4932 | RFC 4306 IKEv2 December 2005 | |
4933 | ||
4934 | ||
4935 | It is assumed that all Diffie-Hellman exponents are erased from | |
4936 | memory after use. In particular, these exponents MUST NOT be derived | |
4937 | from long-lived secrets like the seed to a pseudo-random generator | |
4938 | that is not erased after use. | |
4939 | ||
4940 | The strength of all keys is limited by the size of the output of the | |
4941 | negotiated prf function. For this reason, a prf function whose | |
4942 | output is less than 128 bits (e.g., 3DES-CBC) MUST NOT be used with | |
4943 | this protocol. | |
4944 | ||
4945 | The security of this protocol is critically dependent on the | |
4946 | randomness of the randomly chosen parameters. These should be | |
4947 | generated by a strong random or properly seeded pseudo-random source | |
4948 | (see [RFC4086]). Implementers should take care to ensure that use of | |
4949 | random numbers for both keys and nonces is engineered in a fashion | |
4950 | that does not undermine the security of the keys. | |
4951 | ||
4952 | For information on the rationale of many of the cryptographic design | |
4953 | choices in this protocol, see [SIGMA] and [SKEME]. Though the | |
4954 | security of negotiated CHILD_SAs does not depend on the strength of | |
4955 | the encryption and integrity protection negotiated in the IKE_SA, | |
4956 | implementations MUST NOT negotiate NONE as the IKE integrity | |
4957 | protection algorithm or ENCR_NULL as the IKE encryption algorithm. | |
4958 | ||
4959 | When using pre-shared keys, a critical consideration is how to assure | |
4960 | the randomness of these secrets. The strongest practice is to ensure | |
4961 | that any pre-shared key contain as much randomness as the strongest | |
4962 | key being negotiated. Deriving a shared secret from a password, | |
4963 | name, or other low-entropy source is not secure. These sources are | |
4964 | subject to dictionary and social engineering attacks, among others. | |
4965 | ||
4966 | The NAT_DETECTION_*_IP notifications contain a hash of the addresses | |
4967 | and ports in an attempt to hide internal IP addresses behind a NAT. | |
4968 | Since the IPv4 address space is only 32 bits, and it is usually very | |
4969 | sparse, it would be possible for an attacker to find out the internal | |
4970 | address used behind the NAT box by trying all possible IP addresses | |
4971 | and trying to find the matching hash. The port numbers are normally | |
4972 | fixed to 500, and the SPIs can be extracted from the packet. This | |
4973 | reduces the number of hash calculations to 2^32. With an educated | |
4974 | guess of the use of private address space, the number of hash | |
4975 | calculations is much smaller. Designers should therefore not assume | |
4976 | that use of IKE will not leak internal address information. | |
4977 | ||
4978 | When using an EAP authentication method that does not generate a | |
4979 | shared key for protecting a subsequent AUTH payload, certain man-in- | |
4980 | the-middle and server impersonation attacks are possible [EAPMITM]. | |
4981 | These vulnerabilities occur when EAP is also used in protocols that | |
4982 | are not protected with a secure tunnel. Since EAP is a general- | |
4983 | ||
4984 | ||
4985 | ||
4986 | Kaufman Standards Track [Page 89] | |
4987 | \f | |
4988 | RFC 4306 IKEv2 December 2005 | |
4989 | ||
4990 | ||
4991 | purpose authentication protocol, which is often used to provide | |
4992 | single-signon facilities, a deployed IPsec solution that relies on an | |
4993 | EAP authentication method that does not generate a shared key (also | |
4994 | known as a non-key-generating EAP method) can become compromised due | |
4995 | to the deployment of an entirely unrelated application that also | |
4996 | happens to use the same non-key-generating EAP method, but in an | |
4997 | unprotected fashion. Note that this vulnerability is not limited to | |
4998 | just EAP, but can occur in other scenarios where an authentication | |
4999 | infrastructure is reused. For example, if the EAP mechanism used by | |
5000 | IKEv2 utilizes a token authenticator, a man-in-the-middle attacker | |
5001 | could impersonate the web server, intercept the token authentication | |
5002 | exchange, and use it to initiate an IKEv2 connection. For this | |
5003 | reason, use of non-key-generating EAP methods SHOULD be avoided where | |
5004 | possible. Where they are used, it is extremely important that all | |
5005 | usages of these EAP methods SHOULD utilize a protected tunnel, where | |
5006 | the initiator validates the responder's certificate before initiating | |
5007 | the EAP exchange. Implementers SHOULD describe the vulnerabilities | |
5008 | of using non-key-generating EAP methods in the documentation of their | |
5009 | implementations so that the administrators deploying IPsec solutions | |
5010 | are aware of these dangers. | |
5011 | ||
5012 | An implementation using EAP MUST also use a public-key-based | |
5013 | authentication of the server to the client before the EAP exchange | |
5014 | begins, even if the EAP method offers mutual authentication. This | |
5015 | avoids having additional IKEv2 protocol variations and protects the | |
5016 | EAP data from active attackers. | |
5017 | ||
5018 | If the messages of IKEv2 are long enough that IP-level fragmentation | |
5019 | is necessary, it is possible that attackers could prevent the | |
5020 | exchange from completing by exhausting the reassembly buffers. The | |
5021 | chances of this can be minimized by using the Hash and URL encodings | |
5022 | instead of sending certificates (see section 3.6). Additional | |
5023 | mitigations are discussed in [KPS03]. | |
5024 | ||
5025 | 6. IANA Considerations | |
5026 | ||
5027 | This document defines a number of new field types and values where | |
5028 | future assignments will be managed by the IANA. | |
5029 | ||
5030 | The following registries have been created by the IANA: | |
5031 | ||
5032 | IKEv2 Exchange Types (section 3.1) | |
5033 | IKEv2 Payload Types (section 3.2) | |
5034 | IKEv2 Transform Types (section 3.3.2) | |
5035 | IKEv2 Transform Attribute Types (section 3.3.2) | |
5036 | IKEv2 Encryption Transform IDs (section 3.3.2) | |
5037 | IKEv2 Pseudo-random Function Transform IDs (section 3.3.2) | |
5038 | IKEv2 Integrity Algorithm Transform IDs (section 3.3.2) | |
5039 | ||
5040 | ||
5041 | ||
5042 | Kaufman Standards Track [Page 90] | |
5043 | \f | |
5044 | RFC 4306 IKEv2 December 2005 | |
5045 | ||
5046 | ||
5047 | IKEv2 Diffie-Hellman Transform IDs (section 3.3.2) | |
5048 | IKEv2 Identification Payload ID Types (section 3.5) | |
5049 | IKEv2 Certificate Encodings (section 3.6) | |
5050 | IKEv2 Authentication Method (section 3.8) | |
5051 | IKEv2 Notify Message Types (section 3.10.1) | |
5052 | IKEv2 Notification IPCOMP Transform IDs (section 3.10.1) | |
5053 | IKEv2 Security Protocol Identifiers (section 3.3.1) | |
5054 | IKEv2 Traffic Selector Types (section 3.13.1) | |
5055 | IKEv2 Configuration Payload CFG Types (section 3.15) | |
5056 | IKEv2 Configuration Payload Attribute Types (section 3.15.1) | |
5057 | ||
5058 | Note: When creating a new Transform Type, a new registry for it must | |
5059 | be created. | |
5060 | ||
5061 | Changes and additions to any of those registries are by expert | |
5062 | review. | |
5063 | ||
5064 | 7. Acknowledgements | |
5065 | ||
5066 | This document is a collaborative effort of the entire IPsec WG. If | |
5067 | there were no limit to the number of authors that could appear on an | |
5068 | RFC, the following, in alphabetical order, would have been listed: | |
5069 | Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt | |
5070 | Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John | |
5071 | Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero | |
5072 | Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer | |
5073 | Reingold, and Michael Richardson. Many other people contributed to | |
5074 | the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI, | |
5075 | each of which has its own list of authors. Hugh Daniel suggested the | |
5076 | feature of having the initiator, in message 3, specify a name for the | |
5077 | responder, and gave the feature the cute name "You Tarzan, Me Jane". | |
5078 | David Faucher and Valery Smyzlov helped refine the design of the | |
5079 | traffic selector negotiation. | |
5080 | ||
5081 | 8. References | |
5082 | ||
5083 | 8.1. Normative References | |
5084 | ||
5085 | [ADDGROUP] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) | |
5086 | Diffie-Hellman groups for Internet Key Exchange (IKE)", | |
5087 | RFC 3526, May 2003. | |
5088 | ||
5089 | [ADDRIPV6] Hinden, R. and S. Deering, "Internet Protocol Version 6 | |
5090 | (IPv6) Addressing Architecture", RFC 3513, April 2003. | |
5091 | ||
5092 | [Bra97] Bradner, S., "Key Words for use in RFCs to indicate | |
5093 | Requirement Levels", BCP 14, RFC 2119, March 1997. | |
5094 | ||
5095 | ||
5096 | ||
5097 | ||
5098 | Kaufman Standards Track [Page 91] | |
5099 | \f | |
5100 | RFC 4306 IKEv2 December 2005 | |
5101 | ||
5102 | ||
5103 | [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. | |
5104 | Levkowetz, "Extensible Authentication Protocol (EAP)", RFC | |
5105 | 3748, June 2004. | |
5106 | ||
5107 | [ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher | |
5108 | Algorithms", RFC 2451, November 1998. | |
5109 | ||
5110 | [Hutt05] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. | |
5111 | Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC | |
5112 | 3948, January 2005. | |
5113 | ||
5114 | [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |
5115 | IANA Considerations Section in RFCs", BCP 26, RFC 2434, | |
5116 | October 1998. | |
5117 | ||
5118 | [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition | |
5119 | of Explicit Congestion Notification (ECN) to IP", RFC | |
5120 | 3168, September 2001. | |
5121 | ||
5122 | [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet | |
5123 | X.509 Public Key Infrastructure Certificate and | |
5124 | Certificate Revocation List (CRL) Profile", RFC 3280, | |
5125 | April 2002. | |
5126 | ||
5127 | [RFC4301] Kent, S. and K. Seo, "Security Architecture for the | |
5128 | Internet Protocol", RFC 4301, December 2005. | |
5129 | ||
5130 | 8.2. Informative References | |
5131 | ||
5132 | [DES] ANSI X3.106, "American National Standard for Information | |
5133 | Systems-Data Link Encryption", American National Standards | |
5134 | Institute, 1983. | |
5135 | ||
5136 | [DH] Diffie, W., and Hellman M., "New Directions in | |
5137 | Cryptography", IEEE Transactions on Information Theory, V. | |
5138 | IT-22, n. 6, June 1977. | |
5139 | ||
5140 | [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC | |
5141 | 2131, March 1997. | |
5142 | ||
5143 | [DSS] NIST, "Digital Signature Standard", FIPS 186, National | |
5144 | Institute of Standards and Technology, U.S. Department of | |
5145 | Commerce, May, 1994. | |
5146 | ||
5147 | [EAPMITM] Asokan, N., Nierni, V., and Nyberg, K., "Man-in-the-Middle | |
5148 | in Tunneled Authentication Protocols", | |
5149 | http://eprint.iacr.org/2002/163, November 2002. | |
5150 | ||
5151 | ||
5152 | ||
5153 | ||
5154 | Kaufman Standards Track [Page 92] | |
5155 | \f | |
5156 | RFC 4306 IKEv2 December 2005 | |
5157 | ||
5158 | ||
5159 | [HC98] Harkins, D. and D. Carrel, "The Internet Key Exchange | |
5160 | (IKE)", RFC 2409, November 1998. | |
5161 | ||
5162 | [IDEA] Lai, X., "On the Design and Security of Block Ciphers," | |
5163 | ETH Series in Information Processing, v. 1, Konstanz: | |
5164 | Hartung-Gorre Verlag, 1992. | |
5165 | ||
5166 | [IPCOMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP | |
5167 | Payload Compression Protocol (IPComp)", RFC 3173, | |
5168 | September 2001. | |
5169 | ||
5170 | [KPS03] Kaufman, C., Perlman, R., and Sommerfeld, B., "DoS | |
5171 | protection for UDP-based protocols", ACM Conference on | |
5172 | Computer and Communications Security, October 2003. | |
5173 | ||
5174 | [KBC96] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | |
5175 | Hashing for Message Authentication", RFC 2104, February | |
5176 | 1997. | |
5177 | ||
5178 | [LDAP] Wahl, M., Howes, T., and S Kille, "Lightweight Directory | |
5179 | Access Protocol (v3)", RFC 2251, December 1997. | |
5180 | ||
5181 | [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, | |
5182 | April 1992. | |
5183 | ||
5184 | [MSST98] Maughan, D., Schertler, M., Schneider, M., and J. Turner, | |
5185 | "Internet Security Association and Key Management Protocol | |
5186 | (ISAKMP)", RFC 2408, November 1998. | |
5187 | ||
5188 | [Orm96] Orman, H., "The OAKLEY Key Determination Protocol", RFC | |
5189 | 2412, November 1998. | |
5190 | ||
5191 | [PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key | |
5192 | Management API, Version 2", RFC 2367, July 1998. | |
5193 | ||
5194 | [PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography | |
5195 | Standards (PKCS) #1: RSA Cryptography Specifications | |
5196 | Version 2.1", RFC 3447, February 2003. | |
5197 | ||
5198 | [PK01] Perlman, R., and Kaufman, C., "Analysis of the IPsec key | |
5199 | exchange Standard", WET-ICE Security Conference, MIT,2001, | |
5200 | http://sec.femto.org/wetice-2001/papers/radia-paper.pdf. | |
5201 | ||
5202 | [Pip98] Piper, D., "The Internet IP Security Domain Of | |
5203 | Interpretation for ISAKMP", RFC 2407, November 1998. | |
5204 | ||
5205 | ||
5206 | ||
5207 | ||
5208 | ||
5209 | ||
5210 | Kaufman Standards Track [Page 93] | |
5211 | \f | |
5212 | RFC 4306 IKEv2 December 2005 | |
5213 | ||
5214 | ||
5215 | [RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson, | |
5216 | "Remote Authentication Dial In User Service (RADIUS)", RFC | |
5217 | 2865, June 2000. | |
5218 | ||
5219 | [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, | |
5220 | "Randomness Requirements for Security", BCP 106, RFC 4086, | |
5221 | June 2005. | |
5222 | ||
5223 | [RFC1958] Carpenter, B., "Architectural Principles of the Internet", | |
5224 | RFC 1958, June 1996. | |
5225 | ||
5226 | [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the | |
5227 | Internet Protocol", RFC 2401, November 1998. | |
5228 | ||
5229 | [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, | |
5230 | "Definition of the Differentiated Services Field (DS | |
5231 | Field) in the IPv4 and IPv6 Headers", RFC 2474, December | |
5232 | 1998. | |
5233 | ||
5234 | [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., | |
5235 | and W. Weiss, "An Architecture for Differentiated | |
5236 | Service", RFC 2475, December 1998. | |
5237 | ||
5238 | [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management | |
5239 | Protocol", RFC 2522, March 1999. | |
5240 | ||
5241 | [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, February | |
5242 | 2000. | |
5243 | ||
5244 | [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC | |
5245 | 2983, October 2000. | |
5246 | ||
5247 | [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural | |
5248 | Guidelines and Philosophy", RFC 3439, December 2002. | |
5249 | ||
5250 | [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation | |
5251 | (NAT) Compatibility Requirements", RFC 3715, March 2004. | |
5252 | ||
5253 | [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December | |
5254 | 2005. | |
5255 | ||
5256 | [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC | |
5257 | 4303, December 2005. | |
5258 | ||
5259 | [RSA] Rivest, R., Shamir, A., and Adleman, L., "A Method for | |
5260 | Obtaining Digital Signatures and Public-Key | |
5261 | Cryptosystems", Communications of the ACM, v. 21, n. 2, | |
5262 | February 1978. | |
5263 | ||
5264 | ||
5265 | ||
5266 | Kaufman Standards Track [Page 94] | |
5267 | \f | |
5268 | RFC 4306 IKEv2 December 2005 | |
5269 | ||
5270 | ||
5271 | [SHA] NIST, "Secure Hash Standard", FIPS 180-1, National | |
5272 | Institute of Standards and Technology, U.S. Department of | |
5273 | Commerce, May 1994. | |
5274 | ||
5275 | [SIGMA] Krawczyk, H., "SIGMA: the `SIGn-and-MAc' Approach to | |
5276 | Authenticated Diffie-Hellman and its Use in the IKE | |
5277 | Protocols", in Advances in Cryptography - CRYPTO 2003 | |
5278 | Proceedings, LNCS 2729, Springer, 2003. Available at: | |
5279 | http://www.informatik.uni-trier.de/~ley/db/conf/ | |
5280 | crypto/crypto2003.html. | |
5281 | ||
5282 | [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange | |
5283 | Mechanism for Internet", from IEEE Proceedings of the 1996 | |
5284 | Symposium on Network and Distributed Systems Security. | |
5285 | ||
5286 | [X.501] ITU-T Recommendation X.501: Information Technology - Open | |
5287 | Systems Interconnection - The Directory: Models, 1993. | |
5288 | ||
5289 | [X.509] ITU-T Recommendation X.509 (1997 E): Information | |
5290 | Technology - Open Systems Interconnection - The Directory: | |
5291 | Authentication Framework, June 1997. | |
5292 | ||
5293 | ||
5294 | ||
5295 | ||
5296 | ||
5297 | ||
5298 | ||
5299 | ||
5300 | ||
5301 | ||
5302 | ||
5303 | ||
5304 | ||
5305 | ||
5306 | ||
5307 | ||
5308 | ||
5309 | ||
5310 | ||
5311 | ||
5312 | ||
5313 | ||
5314 | ||
5315 | ||
5316 | ||
5317 | ||
5318 | ||
5319 | ||
5320 | ||
5321 | ||
5322 | Kaufman Standards Track [Page 95] | |
5323 | \f | |
5324 | RFC 4306 IKEv2 December 2005 | |
5325 | ||
5326 | ||
5327 | Appendix A: Summary of changes from IKEv1 | |
5328 | ||
5329 | The goals of this revision to IKE are: | |
5330 | ||
5331 | 1) To define the entire IKE protocol in a single document, replacing | |
5332 | RFCs 2407, 2408, and 2409 and incorporating subsequent changes to | |
5333 | support NAT Traversal, Extensible Authentication, and Remote Address | |
5334 | acquisition; | |
5335 | ||
5336 | 2) To simplify IKE by replacing the eight different initial exchanges | |
5337 | with a single four-message exchange (with changes in authentication | |
5338 | mechanisms affecting only a single AUTH payload rather than | |
5339 | restructuring the entire exchange) see [PK01]; | |
5340 | ||
5341 | 3) To remove the Domain of Interpretation (DOI), Situation (SIT), and | |
5342 | Labeled Domain Identifier fields, and the Commit and Authentication | |
5343 | only bits; | |
5344 | ||
5345 | 4) To decrease IKE's latency in the common case by making the initial | |
5346 | exchange be 2 round trips (4 messages), and allowing the ability to | |
5347 | piggyback setup of a CHILD_SA on that exchange; | |
5348 | ||
5349 | 5) To replace the cryptographic syntax for protecting the IKE | |
5350 | messages themselves with one based closely on ESP to simplify | |
5351 | implementation and security analysis; | |
5352 | ||
5353 | 6) To reduce the number of possible error states by making the | |
5354 | protocol reliable (all messages are acknowledged) and sequenced. | |
5355 | This allows shortening CREATE_CHILD_SA exchanges from 3 messages to | |
5356 | 2; | |
5357 | ||
5358 | 7) To increase robustness by allowing the responder to not do | |
5359 | significant processing until it receives a message proving that the | |
5360 | initiator can receive messages at its claimed IP address, and not | |
5361 | commit any state to an exchange until the initiator can be | |
5362 | cryptographically authenticated; | |
5363 | ||
5364 | 8) To fix cryptographic weaknesses such as the problem with | |
5365 | symmetries in hashes used for authentication documented by Tero | |
5366 | Kivinen; | |
5367 | ||
5368 | 9) To specify Traffic Selectors in their own payloads type rather | |
5369 | than overloading ID payloads, and making more flexible the Traffic | |
5370 | Selectors that may be specified; | |
5371 | ||
5372 | 10) To specify required behavior under certain error conditions or | |
5373 | when data that is not understood is received, to make it easier to | |
5374 | make future revisions that do not break backward compatibility; | |
5375 | ||
5376 | ||
5377 | ||
5378 | Kaufman Standards Track [Page 96] | |
5379 | \f | |
5380 | RFC 4306 IKEv2 December 2005 | |
5381 | ||
5382 | ||
5383 | 11) To simplify and clarify how shared state is maintained in the | |
5384 | presence of network failures and Denial of Service attacks; and | |
5385 | ||
5386 | 12) To maintain existing syntax and magic numbers to the extent | |
5387 | possible to make it likely that implementations of IKEv1 can be | |
5388 | enhanced to support IKEv2 with minimum effort. | |
5389 | ||
5390 | Appendix B: Diffie-Hellman Groups | |
5391 | ||
5392 | There are two Diffie-Hellman groups defined here for use in IKE. | |
5393 | These groups were generated by Richard Schroeppel at the University | |
5394 | of Arizona. Properties of these primes are described in [Orm96]. | |
5395 | ||
5396 | The strength supplied by group one may not be sufficient for the | |
5397 | mandatory-to-implement encryption algorithm and is here for historic | |
5398 | reasons. | |
5399 | ||
5400 | Additional Diffie-Hellman groups have been defined in [ADDGROUP]. | |
5401 | ||
5402 | B.1. Group 1 - 768 Bit MODP | |
5403 | ||
5404 | This group is assigned id 1 (one). | |
5405 | ||
5406 | The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } Its | |
5407 | hexadecimal value is: | |
5408 | ||
5409 | FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 | |
5410 | 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B | |
5411 | 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 | |
5412 | A63A3620 FFFFFFFF FFFFFFFF | |
5413 | ||
5414 | The generator is 2. | |
5415 | ||
5416 | B.2. Group 2 - 1024 Bit MODP | |
5417 | ||
5418 | This group is assigned id 2 (two). | |
5419 | ||
5420 | The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. | |
5421 | Its hexadecimal value is: | |
5422 | ||
5423 | FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 29024E08 | |
5424 | 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD EF9519B3 CD3A431B | |
5425 | 302B0A6D F25F1437 4FE1356D 6D51C245 E485B576 625E7EC6 F44C42E9 | |
5426 | A637ED6B 0BFF5CB6 F406B7ED EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 | |
5427 | 49286651 ECE65381 FFFFFFFF FFFFFFFF | |
5428 | ||
5429 | The generator is 2. | |
5430 | ||
5431 | ||
5432 | ||
5433 | ||
5434 | Kaufman Standards Track [Page 97] | |
5435 | \f | |
5436 | RFC 4306 IKEv2 December 2005 | |
5437 | ||
5438 | ||
5439 | Editor's Address | |
5440 | ||
5441 | Charlie Kaufman | |
5442 | Microsoft Corporation | |
5443 | 1 Microsoft Way | |
5444 | Redmond, WA 98052 | |
5445 | ||
5446 | Phone: 1-425-707-3335 | |
5447 | EMail: charliek@microsoft.com | |
5448 | ||
5449 | ||
5450 | ||
5451 | ||
5452 | ||
5453 | ||
5454 | ||
5455 | ||
5456 | ||
5457 | ||
5458 | ||
5459 | ||
5460 | ||
5461 | ||
5462 | ||
5463 | ||
5464 | ||
5465 | ||
5466 | ||
5467 | ||
5468 | ||
5469 | ||
5470 | ||
5471 | ||
5472 | ||
5473 | ||
5474 | ||
5475 | ||
5476 | ||
5477 | ||
5478 | ||
5479 | ||
5480 | ||
5481 | ||
5482 | ||
5483 | ||
5484 | ||
5485 | ||
5486 | ||
5487 | ||
5488 | ||
5489 | ||
5490 | Kaufman Standards Track [Page 98] | |
5491 | \f | |
5492 | RFC 4306 IKEv2 December 2005 | |
5493 | ||
5494 | ||
5495 | Full Copyright Statement | |
5496 | ||
5497 | Copyright (C) The Internet Society (2005). | |
5498 | ||
5499 | This document is subject to the rights, licenses and restrictions | |
5500 | contained in BCP 78, and except as set forth therein, the authors | |
5501 | retain all their rights. | |
5502 | ||
5503 | This document and the information contained herein are provided on an | |
5504 | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |
5505 | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | |
5506 | ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | |
5507 | INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | |
5508 | INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | |
5509 | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
5510 | ||
5511 | Intellectual Property | |
5512 | ||
5513 | The IETF takes no position regarding the validity or scope of any | |
5514 | Intellectual Property Rights or other rights that might be claimed to | |
5515 | pertain to the implementation or use of the technology described in | |
5516 | this document or the extent to which any license under such rights | |
5517 | might or might not be available; nor does it represent that it has | |
5518 | made any independent effort to identify any such rights. Information | |
5519 | on the procedures with respect to rights in RFC documents can be | |
5520 | found in BCP 78 and BCP 79. | |
5521 | ||
5522 | Copies of IPR disclosures made to the IETF Secretariat and any | |
5523 | assurances of licenses to be made available, or the result of an | |
5524 | attempt made to obtain a general license or permission for the use of | |
5525 | such proprietary rights by implementers or users of this | |
5526 | specification can be obtained from the IETF on-line IPR repository at | |
5527 | http://www.ietf.org/ipr. | |
5528 | ||
5529 | The IETF invites any interested party to bring to its attention any | |
5530 | copyrights, patents or patent applications, or other proprietary | |
5531 | rights that may cover technology that may be required to implement | |
5532 | this standard. Please address the information to the IETF at ietf- | |
5533 | ipr@ietf.org. | |
5534 | ||
5535 | Acknowledgement | |
5536 | ||
5537 | Funding for the RFC Editor function is currently provided by the | |
5538 | Internet Society. | |
5539 | ||
5540 | ||
5541 | ||
5542 | ||
5543 | ||
5544 | ||
5545 | ||
5546 | Kaufman Standards Track [Page 99] | |
5547 | \f |