]>
Commit | Line | Data |
---|---|---|
f91513e3 MW |
1 | |
2 | ||
3 | ||
4 | Network Working Group C. Kaufman | |
5 | Internet-Draft Microsoft | |
d6bd078a MW |
6 | Obsoletes: 4306, 4718 P. Hoffman |
7 | (if approved) VPN Consortium | |
8 | Intended status: Standards Track P. Eronen | |
9 | Expires: August 28, 2008 Nokia | |
10 | February 25, 2008 | |
f91513e3 MW |
11 | |
12 | ||
13 | Internet Key Exchange Protocol: IKEv2 | |
d6bd078a | 14 | draft-hoffman-ikev2bis-03 |
f91513e3 MW |
15 | |
16 | Status of this Memo | |
17 | ||
18 | By submitting this Internet-Draft, each author represents that any | |
19 | applicable patent or other IPR claims of which he or she is aware | |
20 | have been or will be disclosed, and any of which he or she becomes | |
21 | aware will be disclosed, in accordance with Section 6 of BCP 79. | |
22 | ||
23 | Internet-Drafts are working documents of the Internet Engineering | |
24 | Task Force (IETF), its areas, and its working groups. Note that | |
25 | other groups may also distribute working documents as Internet- | |
26 | Drafts. | |
27 | ||
28 | Internet-Drafts are draft documents valid for a maximum of six months | |
29 | and may be updated, replaced, or obsoleted by other documents at any | |
30 | time. It is inappropriate to use Internet-Drafts as reference | |
31 | material or to cite them other than as "work in progress." | |
32 | ||
33 | The list of current Internet-Drafts can be accessed at | |
34 | http://www.ietf.org/ietf/1id-abstracts.txt. | |
35 | ||
36 | The list of Internet-Draft Shadow Directories can be accessed at | |
37 | http://www.ietf.org/shadow.html. | |
38 | ||
d6bd078a | 39 | This Internet-Draft will expire on August 28, 2008. |
f91513e3 MW |
40 | |
41 | Copyright Notice | |
42 | ||
d6bd078a | 43 | Copyright (C) The IETF Trust (2008). |
f91513e3 MW |
44 | |
45 | Abstract | |
46 | ||
47 | This document describes version 2 of the Internet Key Exchange (IKE) | |
48 | protocol. It is a restatement of RFC 4306, and includes all of the | |
d6bd078a | 49 | clarifications from RFC 4718. |
f91513e3 MW |
50 | |
51 | ||
52 | ||
53 | ||
54 | ||
d6bd078a | 55 | Kaufman, et al. Expires August 28, 2008 [Page 1] |
f91513e3 | 56 | \f |
d6bd078a | 57 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
58 | |
59 | ||
60 | Table of Contents | |
61 | ||
62 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 | |
63 | 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 6 | |
d6bd078a | 64 | 1.1.1. Security Gateway to Security Gateway Tunnel . . . . . 6 |
f91513e3 MW |
65 | 1.1.2. Endpoint-to-Endpoint Transport . . . . . . . . . . . 7 |
66 | 1.1.3. Endpoint to Security Gateway Tunnel . . . . . . . . . 8 | |
d6bd078a | 67 | 1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . 8 |
f91513e3 | 68 | 1.2. The Initial Exchanges . . . . . . . . . . . . . . . . . . 9 |
d6bd078a | 69 | 1.3. The CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 11 |
f91513e3 MW |
70 | 1.3.1. Creating New CHILD_SAs with the CREATE_CHILD_SA |
71 | Exchange . . . . . . . . . . . . . . . . . . . . . . 13 | |
72 | 1.3.2. Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange . 14 | |
73 | 1.3.3. Rekeying CHILD_SAs with the CREATE_CHILD_SA | |
74 | Exchange . . . . . . . . . . . . . . . . . . . . . . 14 | |
75 | 1.4. The INFORMATIONAL Exchange . . . . . . . . . . . . . . . 15 | |
d6bd078a | 76 | 1.5. Informational Messages outside of an IKE_SA . . . . . . . 17 |
f91513e3 | 77 | 1.6. Requirements Terminology . . . . . . . . . . . . . . . . 17 |
d6bd078a MW |
78 | 1.7. Differences Between RFC 4306 and This Document . . . . . 18 |
79 | 2. IKE Protocol Details and Variations . . . . . . . . . . . . . 19 | |
80 | 2.1. Use of Retransmission Timers . . . . . . . . . . . . . . 20 | |
81 | 2.2. Use of Sequence Numbers for Message ID . . . . . . . . . 21 | |
82 | 2.3. Window Size for Overlapping Requests . . . . . . . . . . 21 | |
83 | 2.4. State Synchronization and Connection Timeouts . . . . . . 23 | |
84 | 2.5. Version Numbers and Forward Compatibility . . . . . . . . 25 | |
85 | 2.6. Cookies . . . . . . . . . . . . . . . . . . . . . . . . . 27 | |
86 | 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD . . . . 29 | |
87 | 2.7. Cryptographic Algorithm Negotiation . . . . . . . . . . . 30 | |
88 | 2.8. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 31 | |
89 | 2.8.1. Simultaneous CHILD_SA rekeying . . . . . . . . . . . 33 | |
90 | 2.8.2. Rekeying the IKE_SA Versus Reauthentication . . . . . 35 | |
91 | 2.9. Traffic Selector Negotiation . . . . . . . . . . . . . . 36 | |
92 | 2.9.1. Traffic Selectors Violating Own Policy . . . . . . . 38 | |
93 | 2.10. Nonces . . . . . . . . . . . . . . . . . . . . . . . . . 39 | |
94 | 2.11. Address and Port Agility . . . . . . . . . . . . . . . . 39 | |
95 | 2.12. Reuse of Diffie-Hellman Exponentials . . . . . . . . . . 40 | |
96 | 2.13. Generating Keying Material . . . . . . . . . . . . . . . 40 | |
97 | 2.14. Generating Keying Material for the IKE_SA . . . . . . . . 42 | |
98 | 2.15. Authentication of the IKE_SA . . . . . . . . . . . . . . 42 | |
99 | 2.16. Extensible Authentication Protocol Methods . . . . . . . 44 | |
100 | 2.17. Generating Keying Material for CHILD_SAs . . . . . . . . 46 | |
101 | 2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA Exchange . . . . 47 | |
102 | 2.19. Requesting an Internal Address on a Remote Network . . . 48 | |
103 | 2.19.1. Configuration Payloads . . . . . . . . . . . . . . . 49 | |
104 | 2.20. Requesting the Peer's Version . . . . . . . . . . . . . . 51 | |
105 | 2.21. Error Handling . . . . . . . . . . . . . . . . . . . . . 51 | |
106 | 2.22. IPComp . . . . . . . . . . . . . . . . . . . . . . . . . 52 | |
107 | 2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 54 | |
108 | ||
109 | ||
110 | ||
111 | Kaufman, et al. Expires August 28, 2008 [Page 2] | |
112 | \f | |
113 | Internet-Draft IKEv2bis February 2008 | |
114 | ||
115 | ||
116 | 2.24. Explicit Congestion Notification (ECN) . . . . . . . . . 57 | |
117 | 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 57 | |
118 | 3.1. The IKE Header . . . . . . . . . . . . . . . . . . . . . 58 | |
119 | 3.2. Generic Payload Header . . . . . . . . . . . . . . . . . 61 | |
120 | 3.3. Security Association Payload . . . . . . . . . . . . . . 63 | |
121 | 3.3.1. Proposal Substructure . . . . . . . . . . . . . . . . 65 | |
122 | 3.3.2. Transform Substructure . . . . . . . . . . . . . . . 66 | |
123 | 3.3.3. Valid Transform Types by Protocol . . . . . . . . . . 69 | |
124 | 3.3.4. Mandatory Transform IDs . . . . . . . . . . . . . . . 70 | |
125 | 3.3.5. Transform Attributes . . . . . . . . . . . . . . . . 71 | |
126 | 3.3.6. Attribute Negotiation . . . . . . . . . . . . . . . . 73 | |
127 | 3.4. Key Exchange Payload . . . . . . . . . . . . . . . . . . 73 | |
128 | 3.5. Identification Payloads . . . . . . . . . . . . . . . . . 74 | |
129 | 3.6. Certificate Payload . . . . . . . . . . . . . . . . . . . 77 | |
130 | 3.7. Certificate Request Payload . . . . . . . . . . . . . . . 79 | |
131 | 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 81 | |
132 | 3.9. Nonce Payload . . . . . . . . . . . . . . . . . . . . . . 82 | |
133 | 3.10. Notify Payload . . . . . . . . . . . . . . . . . . . . . 83 | |
134 | 3.10.1. Notify Message Types . . . . . . . . . . . . . . . . 84 | |
135 | 3.11. Delete Payload . . . . . . . . . . . . . . . . . . . . . 87 | |
136 | 3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . . 89 | |
137 | 3.13. Traffic Selector Payload . . . . . . . . . . . . . . . . 90 | |
138 | 3.13.1. Traffic Selector . . . . . . . . . . . . . . . . . . 91 | |
139 | 3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . . 93 | |
140 | 3.15. Configuration Payload . . . . . . . . . . . . . . . . . . 95 | |
141 | 3.15.1. Configuration Attributes . . . . . . . . . . . . . . 96 | |
142 | 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET . 99 | |
143 | 3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 101 | |
144 | 3.15.4. Address Assignment Failures . . . . . . . . . . . . . 101 | |
145 | 3.16. Extensible Authentication Protocol (EAP) Payload . . . . 102 | |
146 | 4. Conformance Requirements . . . . . . . . . . . . . . . . . . 104 | |
147 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 106 | |
148 | 5.1. Traffic selector authorization . . . . . . . . . . . . . 108 | |
149 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 109 | |
150 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 110 | |
151 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 110 | |
152 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 110 | |
153 | 8.2. Informative References . . . . . . . . . . . . . . . . . 112 | |
154 | Appendix A. Summary of changes from IKEv1 . . . . . . . . . . . 115 | |
155 | Appendix B. Diffie-Hellman Groups . . . . . . . . . . . . . . . 117 | |
156 | B.1. Group 1 - 768 Bit MODP . . . . . . . . . . . . . . . . . 117 | |
157 | B.2. Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 117 | |
158 | Appendix C. Exchanges and Payloads . . . . . . . . . . . . . . . 118 | |
159 | C.1. IKE_SA_INIT Exchange . . . . . . . . . . . . . . . . . . 118 | |
160 | C.2. IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 119 | |
161 | C.3. IKE_AUTH Exchange with EAP . . . . . . . . . . . . . . . 120 | |
f91513e3 | 162 | C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying |
d6bd078a | 163 | CHILD_SAs . . . . . . . . . . . . . . . . . . . . . . . . 121 |
f91513e3 MW |
164 | |
165 | ||
166 | ||
d6bd078a | 167 | Kaufman, et al. Expires August 28, 2008 [Page 3] |
f91513e3 | 168 | \f |
d6bd078a | 169 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
170 | |
171 | ||
d6bd078a MW |
172 | C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA . . . . 121 |
173 | C.6. INFORMATIONAL Exchange . . . . . . . . . . . . . . . . . 121 | |
174 | Appendix D. Changes Between Internet Draft Versions . . . . . . 121 | |
175 | D.1. Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 121 | |
176 | D.2. Changes from draft -00 to draft -01 . . . . . . . . . . . 122 | |
177 | D.3. Changes from draft -00 to draft -01 . . . . . . . . . . . 124 | |
178 | D.4. Changes from draft -01 to draft -02 . . . . . . . . . . . 124 | |
179 | D.5. Changes from draft -02 to draft -03 . . . . . . . . . . . 125 | |
180 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 127 | |
181 | Intellectual Property and Copyright Statements . . . . . . . . . 129 | |
f91513e3 MW |
182 | |
183 | ||
184 | ||
185 | ||
186 | ||
187 | ||
188 | ||
189 | ||
190 | ||
191 | ||
192 | ||
193 | ||
194 | ||
195 | ||
196 | ||
197 | ||
198 | ||
199 | ||
200 | ||
201 | ||
202 | ||
203 | ||
204 | ||
205 | ||
206 | ||
207 | ||
208 | ||
209 | ||
210 | ||
211 | ||
212 | ||
213 | ||
214 | ||
215 | ||
216 | ||
217 | ||
218 | ||
219 | ||
220 | ||
221 | ||
222 | ||
d6bd078a | 223 | Kaufman, et al. Expires August 28, 2008 [Page 4] |
f91513e3 | 224 | \f |
d6bd078a | 225 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
226 | |
227 | ||
228 | 1. Introduction | |
229 | ||
230 | {{ An introduction to the differences between RFC 4306 [IKEV2] and | |
231 | this document is given at the end of Section 1. It is put there | |
d6bd078a | 232 | (instead of here) to preserve the section numbering of RFC 4306. }} |
f91513e3 MW |
233 | |
234 | IP Security (IPsec) provides confidentiality, data integrity, access | |
235 | control, and data source authentication to IP datagrams. These | |
236 | services are provided by maintaining shared state between the source | |
237 | and the sink of an IP datagram. This state defines, among other | |
238 | things, the specific services provided to the datagram, which | |
239 | cryptographic algorithms will be used to provide the services, and | |
240 | the keys used as input to the cryptographic algorithms. | |
241 | ||
242 | Establishing this shared state in a manual fashion does not scale | |
243 | well. Therefore, a protocol to establish this state dynamically is | |
244 | needed. This memo describes such a protocol -- the Internet Key | |
245 | Exchange (IKE). Version 1 of IKE was defined in RFCs 2407 [DOI], | |
d6bd078a MW |
246 | 2408 [ISAKMP], and 2409 [IKEV1]. IKEv2 was defined in [IKEV2] and |
247 | clarified in [Clarif]. This single document is intended to replace | |
248 | all of those RFCs. | |
f91513e3 MW |
249 | |
250 | IKE performs mutual authentication between two parties and | |
251 | establishes an IKE security association (SA) that includes shared | |
252 | secret information that can be used to efficiently establish SAs for | |
253 | Encapsulating Security Payload (ESP) [ESP] and/or Authentication | |
254 | Header (AH) [AH] and a set of cryptographic algorithms to be used by | |
255 | the SAs to protect the traffic that they carry. In this document, | |
256 | the term "suite" or "cryptographic suite" refers to a complete set of | |
257 | algorithms used to protect an SA. An initiator proposes one or more | |
258 | suites by listing supported algorithms that can be combined into | |
259 | suites in a mix-and-match fashion. IKE can also negotiate use of IP | |
260 | Compression (IPComp) [IPCOMP] in connection with an ESP and/or AH SA. | |
261 | We call the IKE SA an "IKE_SA". The SAs for ESP and/or AH that get | |
262 | set up through that IKE_SA we call "CHILD_SAs". | |
263 | ||
264 | All IKE communications consist of pairs of messages: a request and a | |
265 | response. The pair is called an "exchange". We call the first | |
266 | messages establishing an IKE_SA IKE_SA_INIT and IKE_AUTH exchanges | |
267 | and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL | |
268 | exchanges. In the common case, there is a single IKE_SA_INIT | |
269 | exchange and a single IKE_AUTH exchange (a total of four messages) to | |
f91513e3 MW |
270 | establish the IKE_SA and the first CHILD_SA. In exceptional cases, |
271 | there may be more than one of each of these exchanges. In all cases, | |
272 | all IKE_SA_INIT exchanges MUST complete before any other exchange | |
273 | type, then all IKE_AUTH exchanges MUST complete, and following that | |
274 | any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur | |
275 | in any order. In some scenarios, only a single CHILD_SA is needed | |
d6bd078a MW |
276 | |
277 | ||
278 | ||
279 | Kaufman, et al. Expires August 28, 2008 [Page 5] | |
280 | \f | |
281 | Internet-Draft IKEv2bis February 2008 | |
282 | ||
283 | ||
f91513e3 MW |
284 | between the IPsec endpoints, and therefore there would be no |
285 | additional exchanges. Subsequent exchanges MAY be used to establish | |
286 | additional CHILD_SAs between the same authenticated pair of endpoints | |
287 | and to perform housekeeping functions. | |
288 | ||
289 | IKE message flow always consists of a request followed by a response. | |
290 | It is the responsibility of the requester to ensure reliability. If | |
291 | the response is not received within a timeout interval, the requester | |
292 | needs to retransmit the request (or abandon the connection). | |
293 | ||
294 | The first request/response of an IKE session (IKE_SA_INIT) negotiates | |
295 | security parameters for the IKE_SA, sends nonces, and sends Diffie- | |
296 | Hellman values. | |
297 | ||
298 | The second request/response (IKE_AUTH) transmits identities, proves | |
299 | knowledge of the secrets corresponding to the two identities, and | |
300 | sets up an SA for the first (and often only) AH and/or ESP CHILD_SA. | |
301 | ||
302 | The types of subsequent exchanges are CREATE_CHILD_SA (which creates | |
303 | a CHILD_SA) and INFORMATIONAL (which deletes an SA, reports error | |
304 | conditions, or does other housekeeping). Every request requires a | |
305 | response. An INFORMATIONAL request with no payloads (other than the | |
306 | empty Encrypted payload required by the syntax) is commonly used as a | |
307 | check for liveness. These subsequent exchanges cannot be used until | |
308 | the initial exchanges have completed. | |
309 | ||
310 | In the description that follows, we assume that no errors occur. | |
311 | Modifications to the flow should errors occur are described in | |
312 | Section 2.21. | |
313 | ||
314 | 1.1. Usage Scenarios | |
315 | ||
316 | IKE is expected to be used to negotiate ESP and/or AH SAs in a number | |
317 | of different scenarios, each with its own special requirements. | |
318 | ||
f91513e3 MW |
319 | 1.1.1. Security Gateway to Security Gateway Tunnel |
320 | ||
321 | +-+-+-+-+-+ +-+-+-+-+-+ | |
d6bd078a MW |
322 | | | IPsec | | |
323 | Protected |Tunnel | tunnel |Tunnel | Protected | |
324 | Subnet <-->|Endpoint |<---------->|Endpoint |<--> Subnet | |
325 | | | | | | |
f91513e3 MW |
326 | +-+-+-+-+-+ +-+-+-+-+-+ |
327 | ||
328 | Figure 1: Security Gateway to Security Gateway Tunnel | |
329 | ||
330 | In this scenario, neither endpoint of the IP connection implements | |
331 | IPsec, but network nodes between them protect traffic for part of the | |
d6bd078a MW |
332 | |
333 | ||
334 | ||
335 | Kaufman, et al. Expires August 28, 2008 [Page 6] | |
336 | \f | |
337 | Internet-Draft IKEv2bis February 2008 | |
338 | ||
339 | ||
f91513e3 MW |
340 | way. Protection is transparent to the endpoints, and depends on |
341 | ordinary routing to send packets through the tunnel endpoints for | |
342 | processing. Each endpoint would announce the set of addresses | |
343 | "behind" it, and packets would be sent in tunnel mode where the inner | |
344 | IP header would contain the IP addresses of the actual endpoints. | |
345 | ||
346 | 1.1.2. Endpoint-to-Endpoint Transport | |
347 | ||
348 | +-+-+-+-+-+ +-+-+-+-+-+ | |
d6bd078a MW |
349 | | | IPsec transport | | |
350 | |Protected| or tunnel mode SA |Protected| | |
351 | |Endpoint |<---------------------------------------->|Endpoint | | |
352 | | | | | | |
f91513e3 MW |
353 | +-+-+-+-+-+ +-+-+-+-+-+ |
354 | ||
355 | Figure 2: Endpoint to Endpoint | |
356 | ||
357 | In this scenario, both endpoints of the IP connection implement | |
358 | IPsec, as required of hosts in [IPSECARCH]. Transport mode will | |
359 | commonly be used with no inner IP header. If there is an inner IP | |
360 | header, the inner addresses will be the same as the outer addresses. | |
361 | A single pair of addresses will be negotiated for packets to be | |
362 | protected by this SA. These endpoints MAY implement application | |
363 | layer access controls based on the IPsec authenticated identities of | |
364 | the participants. This scenario enables the end-to-end security that | |
365 | has been a guiding principle for the Internet since [ARCHPRINC], | |
366 | [TRANSPARENCY], and a method of limiting the inherent problems with | |
367 | complexity in networks noted by [ARCHGUIDEPHIL]. Although this | |
368 | scenario may not be fully applicable to the IPv4 Internet, it has | |
369 | been deployed successfully in specific scenarios within intranets | |
370 | using IKEv1. It should be more broadly enabled during the transition | |
371 | to IPv6 and with the adoption of IKEv2. | |
372 | ||
373 | It is possible in this scenario that one or both of the protected | |
374 | endpoints will be behind a network address translation (NAT) node, in | |
d6bd078a MW |
375 | which case the tunneled packets will have to be UDP encapsulated so |
376 | that port numbers in the UDP headers can be used to identify | |
377 | individual endpoints "behind" the NAT (see Section 2.23). | |
378 | ||
379 | ||
380 | ||
381 | ||
382 | ||
383 | ||
f91513e3 MW |
384 | |
385 | ||
386 | ||
f91513e3 MW |
387 | |
388 | ||
d6bd078a MW |
389 | |
390 | ||
391 | Kaufman, et al. Expires August 28, 2008 [Page 7] | |
392 | \f | |
393 | Internet-Draft IKEv2bis February 2008 | |
394 | ||
f91513e3 MW |
395 | |
396 | 1.1.3. Endpoint to Security Gateway Tunnel | |
397 | ||
398 | +-+-+-+-+-+ +-+-+-+-+-+ | |
d6bd078a MW |
399 | | | IPsec | | Protected |
400 | |Protected| tunnel |Tunnel | Subnet | |
401 | |Endpoint |<------------------------>|Endpoint |<--- and/or | |
402 | | | | | Internet | |
f91513e3 MW |
403 | +-+-+-+-+-+ +-+-+-+-+-+ |
404 | ||
405 | Figure 3: Endpoint to Security Gateway Tunnel | |
406 | ||
407 | In this scenario, a protected endpoint (typically a portable roaming | |
408 | computer) connects back to its corporate network through an IPsec- | |
409 | protected tunnel. It might use this tunnel only to access | |
410 | information on the corporate network, or it might tunnel all of its | |
411 | traffic back through the corporate network in order to take advantage | |
412 | of protection provided by a corporate firewall against Internet-based | |
413 | attacks. In either case, the protected endpoint will want an IP | |
414 | address associated with the security gateway so that packets returned | |
415 | to it will go to the security gateway and be tunneled back. This IP | |
416 | address may be static or may be dynamically allocated by the security | |
417 | gateway. {{ Clarif-6.1 }} In support of the latter case, IKEv2 | |
418 | includes a mechanism (namely, configuration payloads) for the | |
419 | initiator to request an IP address owned by the security gateway for | |
420 | use for the duration of its SA. | |
421 | ||
422 | In this scenario, packets will use tunnel mode. On each packet from | |
423 | the protected endpoint, the outer IP header will contain the source | |
424 | IP address associated with its current location (i.e., the address | |
425 | that will get traffic routed to the endpoint directly), while the | |
426 | inner IP header will contain the source IP address assigned by the | |
427 | security gateway (i.e., the address that will get traffic routed to | |
428 | the security gateway for forwarding to the endpoint). The outer | |
429 | destination address will always be that of the security gateway, | |
430 | while the inner destination address will be the ultimate destination | |
431 | for the packet. | |
432 | ||
433 | In this scenario, it is possible that the protected endpoint will be | |
434 | behind a NAT. In that case, the IP address as seen by the security | |
435 | gateway will not be the same as the IP address sent by the protected | |
436 | endpoint, and packets will have to be UDP encapsulated in order to be | |
437 | routed properly. | |
438 | ||
d6bd078a | 439 | 1.1.4. Other Scenarios |
f91513e3 | 440 | |
d6bd078a MW |
441 | Other scenarios are possible, as are nested combinations of the |
442 | above. One notable example combines aspects of 1.1.1 and 1.1.3. A | |
443 | subnet may make all external accesses through a remote security | |
f91513e3 MW |
444 | |
445 | ||
446 | ||
d6bd078a | 447 | Kaufman, et al. Expires August 28, 2008 [Page 8] |
f91513e3 | 448 | \f |
d6bd078a | 449 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
450 | |
451 | ||
f91513e3 MW |
452 | gateway using an IPsec tunnel, where the addresses on the subnet are |
453 | routed to the security gateway by the rest of the Internet. An | |
454 | example would be someone's home network being virtually on the | |
455 | Internet with static IP addresses even though connectivity is | |
456 | provided by an ISP that assigns a single dynamically assigned IP | |
457 | address to the user's security gateway (where the static IP addresses | |
458 | and an IPsec relay are provided by a third party located elsewhere). | |
459 | ||
460 | 1.2. The Initial Exchanges | |
461 | ||
462 | Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH | |
463 | exchanges (known in IKEv1 as Phase 1). These initial exchanges | |
464 | normally consist of four messages, though in some scenarios that | |
465 | number can grow. All communications using IKE consist of request/ | |
466 | response pairs. We'll describe the base exchange first, followed by | |
467 | variations. The first pair of messages (IKE_SA_INIT) negotiate | |
468 | cryptographic algorithms, exchange nonces, and do a Diffie-Hellman | |
469 | exchange [DH]. | |
470 | ||
471 | The second pair of messages (IKE_AUTH) authenticate the previous | |
472 | messages, exchange identities and certificates, and establish the | |
473 | first CHILD_SA. Parts of these messages are encrypted and integrity | |
474 | protected with keys established through the IKE_SA_INIT exchange, so | |
475 | the identities are hidden from eavesdroppers and all fields in all | |
476 | the messages are authenticated. | |
477 | ||
478 | In the following descriptions, the payloads contained in the message | |
479 | are indicated by names as listed below. | |
480 | ||
f91513e3 MW |
481 | Notation Payload |
482 | ----------------------------------------- | |
483 | AUTH Authentication | |
484 | CERT Certificate | |
485 | CERTREQ Certificate Request | |
486 | CP Configuration | |
487 | D Delete | |
488 | E Encrypted | |
489 | EAP Extensible Authentication | |
490 | HDR IKE Header | |
491 | IDi Identification - Initiator | |
492 | IDr Identification - Responder | |
493 | KE Key Exchange | |
494 | Ni, Nr Nonce | |
495 | N Notify | |
496 | SA Security Association | |
497 | TSi Traffic Selector - Initiator | |
498 | TSr Traffic Selector - Responder | |
499 | V Vendor ID | |
500 | ||
d6bd078a MW |
501 | |
502 | ||
503 | Kaufman, et al. Expires August 28, 2008 [Page 9] | |
504 | \f | |
505 | Internet-Draft IKEv2bis February 2008 | |
506 | ||
507 | ||
f91513e3 MW |
508 | The details of the contents of each payload are described in section |
509 | 3. Payloads that may optionally appear will be shown in brackets, | |
510 | such as [CERTREQ], indicate that optionally a certificate request | |
511 | payload can be included. | |
512 | ||
f91513e3 MW |
513 | The initial exchanges are as follows: |
514 | ||
515 | Initiator Responder | |
516 | ------------------------------------------------------------------- | |
517 | HDR, SAi1, KEi, Ni --> | |
518 | ||
519 | HDR contains the Security Parameter Indexes (SPIs), version numbers, | |
520 | and flags of various sorts. The SAi1 payload states the | |
521 | cryptographic algorithms the initiator supports for the IKE_SA. The | |
522 | KE payload sends the initiator's Diffie-Hellman value. Ni is the | |
523 | initiator's nonce. | |
524 | ||
525 | <-- HDR, SAr1, KEr, Nr, [CERTREQ] | |
526 | ||
527 | The responder chooses a cryptographic suite from the initiator's | |
528 | offered choices and expresses that choice in the SAr1 payload, | |
529 | completes the Diffie-Hellman exchange with the KEr payload, and sends | |
530 | its nonce in the Nr payload. | |
531 | ||
f91513e3 MW |
532 | At this point in the negotiation, each party can generate SKEYSEED, |
533 | from which all keys are derived for that IKE_SA. All but the headers | |
534 | of all the messages that follow are encrypted and integrity | |
535 | protected. The keys used for the encryption and integrity protection | |
536 | are derived from SKEYSEED and are known as SK_e (encryption) and SK_a | |
537 | (authentication, a.k.a. integrity protection). A separate SK_e and | |
538 | SK_a is computed for each direction. In addition to the keys SK_e | |
539 | and SK_a derived from the DH value for protection of the IKE_SA, | |
540 | another quantity SK_d is derived and used for derivation of further | |
541 | keying material for CHILD_SAs. The notation SK { ... } indicates | |
542 | that these payloads are encrypted and integrity protected using that | |
543 | direction's SK_e and SK_a. | |
544 | ||
545 | HDR, SK {IDi, [CERT,] [CERTREQ,] | |
546 | [IDr,] AUTH, SAi2, | |
547 | TSi, TSr} --> | |
548 | ||
549 | The initiator asserts its identity with the IDi payload, proves | |
550 | knowledge of the secret corresponding to IDi and integrity protects | |
551 | the contents of the first message using the AUTH payload (see | |
552 | Section 2.15). It might also send its certificate(s) in CERT | |
553 | payload(s) and a list of its trust anchors in CERTREQ payload(s). If | |
554 | any CERT payloads are included, the first certificate provided MUST | |
555 | contain the public key used to verify the AUTH field. The optional | |
d6bd078a MW |
556 | |
557 | ||
558 | ||
559 | Kaufman, et al. Expires August 28, 2008 [Page 10] | |
560 | \f | |
561 | Internet-Draft IKEv2bis February 2008 | |
562 | ||
563 | ||
f91513e3 MW |
564 | payload IDr enables the initiator to specify which of the responder's |
565 | identities it wants to talk to. This is useful when the machine on | |
566 | which the responder is running is hosting multiple identities at the | |
567 | same IP address. The initiator begins negotiation of a CHILD_SA | |
568 | using the SAi2 payload. The final fields (starting with SAi2) are | |
569 | described in the description of the CREATE_CHILD_SA exchange. | |
570 | ||
571 | <-- HDR, SK {IDr, [CERT,] AUTH, | |
572 | SAr2, TSi, TSr} | |
573 | ||
574 | The responder asserts its identity with the IDr payload, optionally | |
575 | sends one or more certificates (again with the certificate containing | |
576 | the public key used to verify AUTH listed first), authenticates its | |
577 | identity and protects the integrity of the second message with the | |
578 | AUTH payload, and completes negotiation of a CHILD_SA with the | |
579 | additional fields described below in the CREATE_CHILD_SA exchange. | |
580 | ||
581 | The recipients of messages 3 and 4 MUST verify that all signatures | |
582 | and MACs are computed correctly and that the names in the ID payloads | |
583 | correspond to the keys used to generate the AUTH payload. | |
584 | ||
585 | {{ Clarif-4.2}} If creating the CHILD_SA during the IKE_AUTH exchange | |
586 | fails for some reason, the IKE_SA is still created as usual. The | |
587 | list of responses in the IKE_AUTH exchange that do not prevent an | |
f91513e3 MW |
588 | IKE_SA from being set up include at least the following: |
589 | NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, | |
590 | INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED. | |
591 | ||
592 | {{ Clarif-4.3 }} Note that IKE_AUTH messages do not contain KEi/KEr | |
d6bd078a MW |
593 | or Ni/Nr payloads. Thus, the SA payloads in the IKE_AUTH exchange |
594 | cannot contain Transform Type 4 (Diffie-Hellman Group) with any value | |
595 | other than NONE. Implementations SHOULD omit the whole transform | |
596 | substructure instead of sending value NONE. | |
f91513e3 MW |
597 | |
598 | 1.3. The CREATE_CHILD_SA Exchange | |
599 | ||
600 | {{ This is a heavy rewrite of most of this section. The major | |
601 | organization changes are described in Clarif-4.1 and Clarif-5.1. }} | |
602 | ||
603 | The CREATE_CHILD_SA exchange is used to create new CHILD_SAs and to | |
604 | rekey both IKE_SAs and CHILD_SAs. This exchange consists of a single | |
605 | request/response pair, and some of its function was referred to as a | |
606 | phase 2 exchange in IKEv1. It MAY be initiated by either end of the | |
607 | IKE_SA after the initial exchanges are completed. | |
608 | ||
609 | All messages following the initial exchange are cryptographically | |
610 | protected using the cryptographic algorithms and keys negotiated in | |
611 | the first two messages of the IKE exchange. These subsequent | |
d6bd078a MW |
612 | |
613 | ||
614 | ||
615 | Kaufman, et al. Expires August 28, 2008 [Page 11] | |
616 | \f | |
617 | Internet-Draft IKEv2bis February 2008 | |
618 | ||
619 | ||
f91513e3 MW |
620 | messages use the syntax of the Encrypted Payload described in |
621 | Section 3.14. All subsequent messages include an Encrypted Payload, | |
622 | even if they are referred to in the text as "empty". For both | |
623 | messages in the CREATE_CHILD_SA, the message following the header is | |
624 | encrypted and the message including the header is integrity protected | |
625 | using the cryptographic algorithms negotiated for the IKE_SA. | |
626 | ||
627 | The CREATE_CHILD_SA is also used for rekeying IKE_SAs and CHILD_SAs. | |
628 | An SA is rekeyed by creating a new SA and then deleting the old one. | |
629 | This section describes the first part of rekeying, the creation of | |
630 | new SAs; Section 2.8 covers the mechanics of rekeying, including | |
631 | moving traffic from old to new SAs and the deletion of the old SAs. | |
632 | The two sections must be read together to understand the entire | |
633 | process of rekeying. | |
634 | ||
635 | Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this | |
636 | section the term initiator refers to the endpoint initiating this | |
637 | exchange. An implementation MAY refuse all CREATE_CHILD_SA requests | |
638 | within an IKE_SA. | |
639 | ||
640 | The CREATE_CHILD_SA request MAY optionally contain a KE payload for | |
641 | an additional Diffie-Hellman exchange to enable stronger guarantees | |
642 | of forward secrecy for the CHILD_SA. The keying material for the | |
f91513e3 MW |
643 | CHILD_SA is a function of SK_d established during the establishment |
644 | of the IKE_SA, the nonces exchanged during the CREATE_CHILD_SA | |
645 | exchange, and the Diffie-Hellman value (if KE payloads are included | |
646 | in the CREATE_CHILD_SA exchange). | |
647 | ||
648 | If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of | |
649 | the SA offers MUST include the Diffie-Hellman group of the KEi. The | |
650 | Diffie-Hellman group of the KEi MUST be an element of the group the | |
651 | initiator expects the responder to accept (additional Diffie-Hellman | |
d6bd078a MW |
652 | groups can be proposed). If the responder selects a proposal using a |
653 | different Diffie-Hellman group (other than NONE), the responder MUST | |
654 | reject the request and indicate its preferred Diffie-Hellman group in | |
655 | the INVALID_KE_PAYLOAD Notification payload. {{ 3.10.1-17 }} There | |
656 | are two octets of data associated with this notification: the | |
657 | accepted D-H Group number in big endian order. In the case of such a | |
658 | rejection, the CREATE_CHILD_SA exchange fails, and the initiator will | |
659 | probably retry the exchange with a Diffie-Hellman proposal and KEi in | |
660 | the group that the responder gave in the INVALID_KE_PAYLOAD. | |
661 | ||
662 | {{ 3.10.1-35 }} The responder sends a NO_ADDITIONAL_SAS notification | |
663 | to indicate that a CREATE_CHILD_SA request is unacceptable because | |
664 | the responder is unwilling to accept any more CHILD_SAs on this | |
665 | IKE_SA. Some minimal implementations may only accept a single | |
666 | CHILD_SA setup in the context of an initial IKE exchange and reject | |
667 | any subsequent attempts to add more. | |
668 | ||
669 | ||
670 | ||
671 | Kaufman, et al. Expires August 28, 2008 [Page 12] | |
672 | \f | |
673 | Internet-Draft IKEv2bis February 2008 | |
674 | ||
f91513e3 MW |
675 | |
676 | 1.3.1. Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange | |
677 | ||
678 | A CHILD_SA may be created by sending a CREATE_CHILD_SA request. The | |
679 | CREATE_CHILD_SA request for creating a new CHILD_SA is: | |
680 | ||
681 | Initiator Responder | |
682 | ------------------------------------------------------------------- | |
683 | HDR, SK {SA, Ni, [KEi], | |
684 | TSi, TSr} --> | |
685 | ||
686 | The initiator sends SA offer(s) in the SA payload, a nonce in the Ni | |
687 | payload, optionally a Diffie-Hellman value in the KEi payload, and | |
688 | the proposed traffic selectors for the proposed CHILD_SA in the TSi | |
689 | and TSr payloads. | |
690 | ||
691 | The CREATE_CHILD_SA response for creating a new CHILD_SA is: | |
692 | ||
693 | <-- HDR, SK {SA, Nr, [KEr], | |
694 | TSi, TSr} | |
695 | ||
696 | The responder replies (using the same Message ID to respond) with the | |
697 | accepted offer in an SA payload, and a Diffie-Hellman value in the | |
698 | KEr payload if KEi was included in the request and the selected | |
699 | cryptographic suite includes that group. | |
700 | ||
701 | The traffic selectors for traffic to be sent on that SA are specified | |
702 | in the TS payloads in the response, which may be a subset of what the | |
703 | initiator of the CHILD_SA proposed. | |
704 | ||
d6bd078a MW |
705 | {{ 3.10.1-16391 }} The USE_TRANSPORT_MODE notification MAY be |
706 | included in a request message that also includes an SA payload | |
707 | requesting a CHILD_SA. It requests that the CHILD_SA use transport | |
708 | mode rather than tunnel mode for the SA created. If the request is | |
709 | accepted, the response MUST also include a notification of type | |
710 | USE_TRANSPORT_MODE. If the responder declines the request, the | |
711 | CHILD_SA will be established in tunnel mode. If this is unacceptable | |
712 | to the initiator, the initiator MUST delete the SA. Note: Except | |
713 | when using this option to negotiate transport mode, all CHILD_SAs | |
714 | will use tunnel mode. | |
f91513e3 | 715 | |
d6bd078a MW |
716 | {{ 3.10.1-16394 }} The ESP_TFC_PADDING_NOT_SUPPORTED notification |
717 | asserts that the sending endpoint will NOT accept packets that | |
718 | contain Traffic Flow Confidentiality (TFC) padding over the CHILD_SA | |
719 | being negotiated. {{ Clarif-4.5 }} If neither endpoint accepts TFC | |
720 | padding, this notification is included in both the request and the | |
721 | response. If this notification is included in only one of the | |
722 | messages, TFC padding can still be sent in the other direction. | |
f91513e3 MW |
723 | |
724 | ||
725 | ||
726 | ||
d6bd078a | 727 | Kaufman, et al. Expires August 28, 2008 [Page 13] |
f91513e3 | 728 | \f |
d6bd078a MW |
729 | Internet-Draft IKEv2bis February 2008 |
730 | ||
f91513e3 | 731 | |
d6bd078a MW |
732 | {{ 3.10.1-16395 }} The NON_FIRST_FRAGMENTS_ALSO notification is used |
733 | for fragmentation control. See [IPSECARCH] for a fuller explanation. | |
734 | {{ Clarif-4.6 }} Sending non-first fragments is enabled only if | |
735 | NON_FIRST_FRAGMENTS_ALSO notification is included in both the request | |
736 | proposing an SA and the response accepting it. If the peer rejects | |
737 | the proposal of the SA, the peer only omits NON_FIRST_FRAGMENTS_ALSO | |
738 | notification from the response, but does not reject the whole | |
739 | CHILD_SA creation. | |
f91513e3 MW |
740 | |
741 | 1.3.2. Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange | |
742 | ||
743 | The CREATE_CHILD_SA request for rekeying an IKE_SA is: | |
744 | ||
745 | Initiator Responder | |
746 | ------------------------------------------------------------------- | |
d6bd078a | 747 | HDR, SK {SA, Ni, [KEi]} --> |
f91513e3 MW |
748 | |
749 | The initiator sends SA offer(s) in the SA payload, a nonce in the Ni | |
d6bd078a MW |
750 | payload, and a Diffie-Hellman value in the KEi payload. The KEi |
751 | payload SHOULD be included. New initiator and responder SPIs are | |
752 | supplied in the SPI fields. | |
f91513e3 MW |
753 | |
754 | The CREATE_CHILD_SA response for rekeying an IKE_SA is: | |
755 | ||
d6bd078a | 756 | <-- HDR, SK {SA, Nr,[KEr]} |
f91513e3 MW |
757 | |
758 | The responder replies (using the same Message ID to respond) with the | |
759 | accepted offer in an SA payload, and a Diffie-Hellman value in the | |
760 | KEr payload if the selected cryptographic suite includes that group. | |
761 | ||
762 | The new IKE_SA has its message counters set to 0, regardless of what | |
763 | they were in the earlier IKE_SA. The window size starts at 1 for any | |
764 | new IKE_SA. | |
765 | ||
f91513e3 MW |
766 | 1.3.3. Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange |
767 | ||
768 | The CREATE_CHILD_SA request for rekeying a CHILD_SA is: | |
769 | ||
770 | Initiator Responder | |
771 | ------------------------------------------------------------------- | |
772 | HDR, SK {N, SA, Ni, [KEi], | |
773 | TSi, TSr} --> | |
774 | ||
775 | The initiator sends SA offer(s) in the SA payload, a nonce in the Ni | |
776 | payload, optionally a Diffie-Hellman value in the KEi payload, and | |
777 | the proposed traffic selectors for the proposed CHILD_SA in the TSi | |
d6bd078a MW |
778 | and TSr payloads. |
779 | ||
f91513e3 | 780 | |
f91513e3 | 781 | |
f91513e3 | 782 | |
d6bd078a MW |
783 | Kaufman, et al. Expires August 28, 2008 [Page 14] |
784 | \f | |
785 | Internet-Draft IKEv2bis February 2008 | |
f91513e3 MW |
786 | |
787 | ||
d6bd078a MW |
788 | {{ 3.10.1-16393 }} The REKEY_SA notification MUST be included in a |
789 | CREATE_CHILD_SA exchange if the purpose of the exchange is to replace | |
790 | an existing ESP or AH SA. {{ Clarif-5.4 }} The SA being rekeyed is | |
791 | identified by the SPI field in the Notify payload; this is the SPI | |
792 | the exchange initiator would expect in inbound ESP or AH packets. | |
793 | There is no data associated with this Notify type. | |
f91513e3 | 794 | |
d6bd078a | 795 | The CREATE_CHILD_SA response for rekeying a CHILD_SA is: |
f91513e3 | 796 | |
d6bd078a MW |
797 | <-- HDR, SK {SA, Nr, [KEr], |
798 | Si, TSr} | |
f91513e3 MW |
799 | |
800 | The responder replies (using the same Message ID to respond) with the | |
801 | accepted offer in an SA payload, and a Diffie-Hellman value in the | |
802 | KEr payload if KEi was included in the request and the selected | |
803 | cryptographic suite includes that group. | |
804 | ||
805 | The traffic selectors for traffic to be sent on that SA are specified | |
806 | in the TS payloads in the response, which may be a subset of what the | |
807 | initiator of the CHILD_SA proposed. | |
808 | ||
809 | 1.4. The INFORMATIONAL Exchange | |
810 | ||
811 | At various points during the operation of an IKE_SA, peers may desire | |
812 | to convey control messages to each other regarding errors or | |
813 | notifications of certain events. To accomplish this, IKE defines an | |
814 | INFORMATIONAL exchange. INFORMATIONAL exchanges MUST ONLY occur | |
815 | after the initial exchanges and are cryptographically protected with | |
816 | the negotiated keys. | |
817 | ||
818 | Control messages that pertain to an IKE_SA MUST be sent under that | |
819 | IKE_SA. Control messages that pertain to CHILD_SAs MUST be sent | |
820 | under the protection of the IKE_SA which generated them (or its | |
821 | successor if the IKE_SA was replaced for the purpose of rekeying). | |
822 | ||
823 | Messages in an INFORMATIONAL exchange contain zero or more | |
824 | Notification, Delete, and Configuration payloads. The Recipient of | |
825 | an INFORMATIONAL exchange request MUST send some response (else the | |
826 | Sender will assume the message was lost in the network and will | |
827 | retransmit it). That response MAY be a message with no payloads. | |
828 | The request message in an INFORMATIONAL exchange MAY also contain no | |
829 | payloads. This is the expected way an endpoint can ask the other | |
830 | endpoint to verify that it is alive. | |
831 | ||
832 | {{ Clarif-5.6 }} ESP and AH SAs always exist in pairs, with one SA in | |
833 | each direction. When an SA is closed, both members of the pair MUST | |
d6bd078a MW |
834 | be closed (that is, deleted). Each endpoint MUST close its incoming |
835 | SAs and allow the other endpoint to close the other SA in each pair. | |
f91513e3 MW |
836 | |
837 | ||
838 | ||
d6bd078a | 839 | Kaufman, et al. Expires August 28, 2008 [Page 15] |
f91513e3 | 840 | \f |
d6bd078a | 841 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
842 | |
843 | ||
d6bd078a MW |
844 | To delete an SA, an INFORMATIONAL exchange with one or more delete |
845 | payloads is sent listing the SPIs (as they would be expected in the | |
846 | headers of inbound packets) of the SAs to be deleted. The recipient | |
847 | MUST close the designated SAs. {{ Clarif-5.7 }} Note that one never | |
848 | sends delete payloads for the two sides of an SA in a single message. | |
849 | If there are many SAs to delete at the same time, one includes delete | |
850 | payloads for in inbound half of each SA pair in your Informational | |
851 | exchange. | |
852 | ||
f91513e3 MW |
853 | Normally, the reply in the INFORMATIONAL exchange will contain delete |
854 | payloads for the paired SAs going in the other direction. There is | |
855 | one exception. If by chance both ends of a set of SAs independently | |
856 | decide to close them, each may send a delete payload and the two | |
857 | requests may cross in the network. If a node receives a delete | |
858 | request for SAs for which it has already issued a delete request, it | |
859 | MUST delete the outgoing SAs while processing the request and the | |
860 | incoming SAs while processing the response. In that case, the | |
861 | responses MUST NOT include delete payloads for the deleted SAs, since | |
862 | that would result in duplicate deletion and could in theory delete | |
863 | the wrong SA. | |
864 | ||
d6bd078a MW |
865 | {{ Demoted the SHOULD }} Half-closed ESP or AH connections are |
866 | anomalous, and a node with auditing capability should probably audit | |
867 | their existence if they persist. Note that this specification | |
868 | nowhere specifies time periods, so it is up to individual endpoints | |
869 | to decide how long to wait. A node MAY refuse to accept incoming | |
870 | data on half-closed connections but MUST NOT unilaterally close them | |
871 | and reuse the SPIs. If connection state becomes sufficiently messed | |
872 | up, a node MAY close the IKE_SA; doing so will implicitly close all | |
873 | SAs negotiated under it. It can then rebuild the SAs it needs on a | |
874 | clean base under a new IKE_SA. {{ Clarif-5.8 }} The response to a | |
875 | request that deletes the IKE_SA is an empty Informational response. | |
f91513e3 MW |
876 | |
877 | The INFORMATIONAL exchange is defined as: | |
878 | ||
879 | Initiator Responder | |
880 | ------------------------------------------------------------------- | |
881 | HDR, SK {[N,] [D,] | |
882 | [CP,] ...} --> | |
883 | <-- HDR, SK {[N,] [D,] | |
884 | [CP], ...} | |
885 | ||
886 | The processing of an INFORMATIONAL exchange is determined by its | |
887 | component payloads. | |
888 | ||
f91513e3 | 889 | |
f91513e3 MW |
890 | |
891 | ||
892 | ||
d6bd078a MW |
893 | |
894 | ||
895 | Kaufman, et al. Expires August 28, 2008 [Page 16] | |
f91513e3 | 896 | \f |
d6bd078a | 897 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
898 | |
899 | ||
d6bd078a MW |
900 | 1.5. Informational Messages outside of an IKE_SA |
901 | ||
902 | If an encrypted IKE request packet arrives on port 500 or 4500 with | |
903 | an unrecognized SPI, it could be because the receiving node has | |
904 | recently crashed and lost state or because of some other system | |
905 | malfunction or attack. If the receiving node has an active IKE_SA to | |
906 | the IP address from whence the packet came, it MAY send a | |
907 | notification of the wayward packet over that IKE_SA in an | |
908 | INFORMATIONAL exchange. If it does not have such an IKE_SA, it MAY | |
909 | send an Informational message without cryptographic protection to the | |
910 | source IP address. Such a message is not part of an informational | |
911 | exchange, and the receiving node MUST NOT respond to it. Doing so | |
912 | could cause a message loop. | |
913 | ||
914 | {{ 3.10.1-11 }} The INVALID_SPI notification MAY be sent in an IKE | |
915 | INFORMATIONAL exchange when a node receives an ESP or AH packet with | |
916 | an invalid SPI. The Notification Data contains the SPI of the | |
917 | invalid packet. This usually indicates a node has rebooted and | |
918 | forgotten an SA. If this Informational Message is sent outside the | |
919 | context of an IKE_SA, it should only be used by the recipient as a | |
920 | "hint" that something might be wrong (because it could easily be | |
921 | forged). | |
922 | ||
f91513e3 MW |
923 | {{ Clarif-7.7 }} There are two cases when such a one-way notification |
924 | is sent: INVALID_IKE_SPI and INVALID_SPI. These notifications are | |
925 | sent outside of an IKE_SA. Note that such notifications are | |
926 | explicitly not Informational exchanges; these are one-way messages | |
927 | that must not be responded to. In case of INVALID_IKE_SPI, the | |
928 | message sent is a response message, and thus it is sent to the IP | |
929 | address and port from whence it came with the same IKE SPIs and the | |
930 | Message ID copied. In case of INVALID_SPI, however, there are no IKE | |
931 | SPI values that would be meaningful to the recipient of such a | |
932 | notification. Using zero values or random values are both | |
933 | acceptable. | |
934 | ||
935 | 1.6. Requirements Terminology | |
936 | ||
d6bd078a MW |
937 | Definitions of the primitive terms in this document (such as Security |
938 | Association or SA) can be found in [IPSECARCH]. {{ Clarif-7.2 }} It | |
939 | should be noted that parts of IKEv2 rely on some of the processing | |
940 | rules in [IPSECARCH], as described in various sections of this | |
941 | document. | |
942 | ||
f91513e3 MW |
943 | Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and |
944 | "MAY" that appear in this document are to be interpreted as described | |
945 | in [MUSTSHOULD]. | |
946 | ||
d6bd078a MW |
947 | |
948 | ||
949 | ||
950 | ||
951 | Kaufman, et al. Expires August 28, 2008 [Page 17] | |
952 | \f | |
953 | Internet-Draft IKEv2bis February 2008 | |
954 | ||
f91513e3 MW |
955 | |
956 | 1.7. Differences Between RFC 4306 and This Document | |
957 | ||
958 | {{ Added this entire section, including this recursive remark. }} | |
959 | ||
960 | This document contains clarifications and amplifications to IKEv2 | |
961 | [IKEV2]. The clarifications are mostly based on [Clarif]. The | |
962 | changes listed in that document were discussed in the IPsec Working | |
963 | Group and, after the Working Group was disbanded, on the IPsec | |
964 | mailing list. That document contains detailed explanations of areas | |
965 | that were unclear in IKEv2, and is thus useful to implementers of | |
966 | IKEv2. | |
967 | ||
968 | The protocol described in this document retains the same major | |
969 | version number (2) and minor version number (0) as was used in RFC | |
970 | 4306. | |
971 | ||
d6bd078a | 972 | This document makes the figures and references a bit more regular |
f91513e3 MW |
973 | than in [IKEV2]. |
974 | ||
975 | IKEv2 developers have noted that the SHOULD-level requirements are | |
976 | often unclear in that they don't say when it is OK to not obey the | |
977 | requirements. They also have noted that there are MUST-level | |
f91513e3 MW |
978 | requirements that are not related to interoperability. This document |
979 | has more explanation of some of these requirements. All non- | |
980 | capitalized uses of the words SHOULD and MUST now mean their normal | |
981 | English sense, not the interoperability sense of [MUSTSHOULD]. | |
982 | ||
983 | IKEv2 (and IKEv1) developers have noted that there is a great deal of | |
d6bd078a | 984 | material in the tables of codes in Section 3.10.1. This leads to |
f91513e3 | 985 | implementers not having all the needed information in the main body |
d6bd078a MW |
986 | of the docment. Much of the material from those tables has been |
987 | moved into the associated parts of the main body of the document. | |
988 | ||
989 | In the body of this document, notes that are enclosed in double curly | |
990 | braces {{ such as this }} point out changes from IKEv2. Changes that | |
991 | come from [Clarif] are marked with the section from that document, | |
992 | such as "{{ Clarif-2.10 }}". Changes that come from moving | |
993 | descriptive text out of the tables in Section 3.10.1 are marked with | |
994 | that number and the message type that contained the text, such as "{{ | |
995 | 3.10.1-16384 }}". | |
996 | ||
997 | This document removes discussion of nesting AH and ESP. This was a | |
998 | mistake in RFC 4306 caused by the lag between finishing RFC 4306 and | |
999 | RFC 4301. Basically, IKEv2 is based on RFC 4301, which does not | |
1000 | include "SA bundles" that were part of RFC 2401. While a single | |
1001 | packet can go through IPsec processing multiple times, each of these | |
1002 | passes uses a separate SA, and the passes are coordinated by the | |
1003 | forwarding tables. In IKEv2, each of these SAs has to be created | |
1004 | ||
1005 | ||
1006 | ||
1007 | Kaufman, et al. Expires August 28, 2008 [Page 18] | |
1008 | \f | |
1009 | Internet-Draft IKEv2bis February 2008 | |
1010 | ||
1011 | ||
1012 | using a separate CREATE_CHILD_SA exchange. | |
f91513e3 | 1013 | |
d6bd078a MW |
1014 | This document removes discussion of the INTERNAL_ADDRESS_EXPIRY |
1015 | configuration attribute because its implementation was very | |
1016 | problematic. Implementations that conform to this document MUST | |
1017 | ignore proposals that have configuration attribute type 5, the old | |
1018 | value for INTERNAL_ADDRESS_EXPIRY. | |
1019 | ||
1020 | This document adds the restriction in Section 2.13 that all PRFs used | |
1021 | with IKEv2 MUST take variable-sized keys. This should not affect any | |
1022 | implementations because there were no standardized PRFs that have | |
1023 | fixed-size keys. | |
1024 | ||
1025 | A later version of this document may have all the {{ }} comments | |
1026 | removed from the body of the document and instead appear in an | |
1027 | appendix. | |
f91513e3 MW |
1028 | |
1029 | ||
1030 | 2. IKE Protocol Details and Variations | |
1031 | ||
1032 | IKE normally listens and sends on UDP port 500, though IKE messages | |
1033 | may also be received on UDP port 4500 with a slightly different | |
1034 | format (see Section 2.23). Since UDP is a datagram (unreliable) | |
1035 | protocol, IKE includes in its definition recovery from transmission | |
1036 | errors, including packet loss, packet replay, and packet forgery. | |
1037 | IKE is designed to function so long as (1) at least one of a series | |
1038 | of retransmitted packets reaches its destination before timing out; | |
1039 | and (2) the channel is not so full of forged and replayed packets so | |
1040 | as to exhaust the network or CPU capacities of either endpoint. Even | |
1041 | in the absence of those minimum performance requirements, IKE is | |
1042 | designed to fail cleanly (as though the network were broken). | |
1043 | ||
1044 | Although IKEv2 messages are intended to be short, they contain | |
1045 | structures with no hard upper bound on size (in particular, X.509 | |
1046 | certificates), and IKEv2 itself does not have a mechanism for | |
1047 | fragmenting large messages. IP defines a mechanism for fragmentation | |
1048 | of oversize UDP messages, but implementations vary in the maximum | |
1049 | message size supported. Furthermore, use of IP fragmentation opens | |
1050 | an implementation to denial of service attacks [DOSUDPPROT]. | |
1051 | Finally, some NAT and/or firewall implementations may block IP | |
1052 | fragments. | |
1053 | ||
1054 | All IKEv2 implementations MUST be able to send, receive, and process | |
d6bd078a MW |
1055 | IKE messages that are up to 1280 octets long, and they SHOULD be able |
1056 | to send, receive, and process messages that are up to 3000 octets | |
f91513e3 MW |
1057 | long. {{ Demoted the SHOULD }} IKEv2 implementations need to be aware |
1058 | of the maximum UDP message size supported and MAY shorten messages by | |
1059 | leaving out some certificates or cryptographic suite proposals if | |
f91513e3 MW |
1060 | |
1061 | ||
1062 | ||
d6bd078a | 1063 | Kaufman, et al. Expires August 28, 2008 [Page 19] |
f91513e3 | 1064 | \f |
d6bd078a | 1065 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
1066 | |
1067 | ||
d6bd078a | 1068 | that will keep messages below the maximum. Use of the "Hash and URL" |
f91513e3 MW |
1069 | formats rather than including certificates in exchanges where |
1070 | possible can avoid most problems. {{ Demoted the SHOULD }} | |
1071 | Implementations and configuration need to keep in mind, however, that | |
1072 | if the URL lookups are possible only after the IPsec SA is | |
1073 | established, recursion issues could prevent this technique from | |
1074 | working. | |
1075 | ||
d6bd078a MW |
1076 | {{ Clarif-7.5 }} The UDP payload of all packets containing IKE |
1077 | messages sent on port 4500 MUST begin with the prefix of four zeros; | |
1078 | otherwise, the receiver won't know how to handle them. | |
f91513e3 MW |
1079 | |
1080 | 2.1. Use of Retransmission Timers | |
1081 | ||
1082 | All messages in IKE exist in pairs: a request and a response. The | |
1083 | setup of an IKE_SA normally consists of two request/response pairs. | |
1084 | Once the IKE_SA is set up, either end of the security association may | |
1085 | initiate requests at any time, and there can be many requests and | |
1086 | responses "in flight" at any given moment. But each message is | |
1087 | labeled as either a request or a response, and for each request/ | |
1088 | response pair one end of the security association is the initiator | |
1089 | and the other is the responder. | |
1090 | ||
1091 | For every pair of IKE messages, the initiator is responsible for | |
1092 | retransmission in the event of a timeout. The responder MUST never | |
1093 | retransmit a response unless it receives a retransmission of the | |
1094 | request. In that event, the responder MUST ignore the retransmitted | |
1095 | request except insofar as it triggers a retransmission of the | |
1096 | response. The initiator MUST remember each request until it receives | |
1097 | the corresponding response. The responder MUST remember each | |
1098 | response until it receives a request whose sequence number is larger | |
d6bd078a MW |
1099 | than or equal to the sequence number in the response plus its window |
1100 | size (see Section 2.3). | |
f91513e3 MW |
1101 | |
1102 | IKE is a reliable protocol, in the sense that the initiator MUST | |
1103 | retransmit a request until either it receives a corresponding reply | |
1104 | OR it deems the IKE security association to have failed and it | |
1105 | discards all state associated with the IKE_SA and any CHILD_SAs | |
1106 | negotiated using that IKE_SA. | |
1107 | ||
d6bd078a MW |
1108 | {{ Clarif-2.3 }} Retransmissions of the IKE_SA_INIT request require |
1109 | some special handling. When a responder receives an IKE_SA_INIT | |
1110 | request, it has to determine whether the packet is retransmission | |
1111 | belonging to an existing "half-open" IKE_SA (in which case the | |
1112 | responder retransmits the same response), or a new request (in which | |
1113 | case the responder creates a new IKE_SA and sends a fresh response), | |
1114 | or it belongs to an existing IKE_SA where the IKE_AUTH request has | |
1115 | been already received (in which case the responder ignores it). | |
f91513e3 | 1116 | |
f91513e3 | 1117 | |
f91513e3 | 1118 | |
d6bd078a MW |
1119 | Kaufman, et al. Expires August 28, 2008 [Page 20] |
1120 | \f | |
1121 | Internet-Draft IKEv2bis February 2008 | |
f91513e3 MW |
1122 | |
1123 | ||
d6bd078a MW |
1124 | It is not sufficient to use the initiator's SPI and/or IP address to |
1125 | differentiate between these three cases because two different peers | |
1126 | behind a single NAT could choose the same initiator SPI. Instead, a | |
1127 | robust responder will do the IKE_SA lookup using the whole packet, | |
1128 | its hash, or the Ni payload. | |
1129 | ||
1130 | 2.2. Use of Sequence Numbers for Message ID | |
f91513e3 | 1131 | |
d6bd078a MW |
1132 | Every IKE message contains a Message ID as part of its fixed header. |
1133 | This Message ID is used to match up requests and responses, and to | |
1134 | identify retransmissions of messages. | |
f91513e3 | 1135 | |
d6bd078a MW |
1136 | The Message ID is a 32-bit quantity, which is zero for the |
1137 | IKE_SA_INIT messages (including retries of the message due to | |
1138 | responses such as COOKIE and INVALID_KE_PAYLOAD {{ Clarif-2.2 }}), | |
1139 | and incremented for each subsequent exchange. Thus, the first pair | |
1140 | of IKE_AUTH messages will have ID of 1, the second (when EAP is used) | |
1141 | will be 2, and so on. {{ Clarif-3.10 }} | |
f91513e3 MW |
1142 | |
1143 | Each endpoint in the IKE Security Association maintains two "current" | |
1144 | Message IDs: the next one to be used for a request it initiates and | |
1145 | the next one it expects to see in a request from the other end. | |
1146 | These counters increment as requests are generated and received. | |
1147 | Responses always contain the same message ID as the corresponding | |
1148 | request. That means that after the initial exchange, each integer n | |
1149 | may appear as the message ID in four distinct messages: the nth | |
1150 | request from the original IKE initiator, the corresponding response, | |
1151 | the nth request from the original IKE responder, and the | |
1152 | corresponding response. If the two ends make very different numbers | |
1153 | of requests, the Message IDs in the two directions can be very | |
1154 | different. There is no ambiguity in the messages, however, because | |
1155 | the (I)nitiator and (R)esponse bits in the message header specify | |
1156 | which of the four messages a particular one is. | |
1157 | ||
f91513e3 MW |
1158 | Note that Message IDs are cryptographically protected and provide |
1159 | protection against message replays. In the unlikely event that | |
1160 | Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be | |
1161 | closed. Rekeying an IKE_SA resets the sequence numbers. | |
1162 | ||
f91513e3 MW |
1163 | 2.3. Window Size for Overlapping Requests |
1164 | ||
1165 | In order to maximize IKE throughput, an IKE endpoint MAY issue | |
1166 | multiple requests before getting a response to any of them if the | |
1167 | other endpoint has indicated its ability to handle such requests. | |
1168 | For simplicity, an IKE implementation MAY choose to process requests | |
1169 | strictly in order and/or wait for a response to one request before | |
1170 | issuing another. Certain rules must be followed to ensure | |
d6bd078a | 1171 | interoperability between implementations using different strategies. |
f91513e3 MW |
1172 | |
1173 | ||
1174 | ||
d6bd078a | 1175 | Kaufman, et al. Expires August 28, 2008 [Page 21] |
f91513e3 | 1176 | \f |
d6bd078a | 1177 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
1178 | |
1179 | ||
f91513e3 MW |
1180 | After an IKE_SA is set up, either end can initiate one or more |
1181 | requests. These requests may pass one another over the network. An | |
1182 | IKE endpoint MUST be prepared to accept and process a request while | |
1183 | it has a request outstanding in order to avoid a deadlock in this | |
1184 | situation. {{ Downgraded the SHOULD }} An IKE endpoint may also | |
1185 | accept and process multiple requests while it has a request | |
1186 | outstanding. | |
1187 | ||
d6bd078a MW |
1188 | {{ 3.10.1-16385 }} The SET_WINDOW_SIZE notification asserts that the |
1189 | sending endpoint is capable of keeping state for multiple outstanding | |
1190 | exchanges, permitting the recipient to send multiple requests before | |
1191 | getting a response to the first. The data associated with a | |
1192 | SET_WINDOW_SIZE notification MUST be 4 octets long and contain the | |
1193 | big endian representation of the number of messages the sender | |
1194 | promises to keep. The window size is always one until the initial | |
1195 | exchanges complete. | |
1196 | ||
f91513e3 MW |
1197 | An IKE endpoint MUST wait for a response to each of its messages |
1198 | before sending a subsequent message unless it has received a | |
1199 | SET_WINDOW_SIZE Notify message from its peer informing it that the | |
1200 | peer is prepared to maintain state for multiple outstanding messages | |
1201 | in order to allow greater throughput. | |
1202 | ||
1203 | An IKE endpoint MUST NOT exceed the peer's stated window size for | |
1204 | transmitted IKE requests. In other words, if the responder stated | |
1205 | its window size is N, then when the initiator needs to make a request | |
1206 | X, it MUST wait until it has received responses to all requests up | |
1207 | through request X-N. An IKE endpoint MUST keep a copy of (or be able | |
1208 | to regenerate exactly) each request it has sent until it receives the | |
1209 | corresponding response. An IKE endpoint MUST keep a copy of (or be | |
1210 | able to regenerate exactly) the number of previous responses equal to | |
1211 | its declared window size in case its response was lost and the | |
1212 | initiator requests its retransmission by retransmitting the request. | |
1213 | ||
1214 | An IKE endpoint supporting a window size greater than one ought to be | |
1215 | capable of processing incoming requests out of order to maximize | |
1216 | performance in the event of network failures or packet reordering. | |
1217 | ||
1218 | {{ Clarif-7.3 }} The window size is normally a (possibly | |
1219 | configurable) property of a particular implementation, and is not | |
1220 | related to congestion control (unlike the window size in TCP, for | |
1221 | example). In particular, it is not defined what the responder should | |
1222 | do when it receives a SET_WINDOW_SIZE notification containing a | |
1223 | smaller value than is currently in effect. Thus, there is currently | |
1224 | no way to reduce the window size of an existing IKE_SA; you can only | |
1225 | increase it. When rekeying an IKE_SA, the new IKE_SA starts with | |
1226 | window size 1 until it is explicitly increased by sending a new | |
1227 | SET_WINDOW_SIZE notification. | |
1228 | ||
f91513e3 | 1229 | |
f91513e3 | 1230 | |
d6bd078a MW |
1231 | Kaufman, et al. Expires August 28, 2008 [Page 22] |
1232 | \f | |
1233 | Internet-Draft IKEv2bis February 2008 | |
f91513e3 MW |
1234 | |
1235 | ||
d6bd078a MW |
1236 | {{ 3.10.1-9 }}The INVALID_MESSAGE_ID notification is sent when an IKE |
1237 | message ID outside the supported window is received. This Notify | |
1238 | MUST NOT be sent in a response; the invalid request MUST NOT be | |
1239 | acknowledged. Instead, inform the other side by initiating an | |
1240 | INFORMATIONAL exchange with Notification data containing the four | |
1241 | octet invalid message ID. Sending this notification is optional, and | |
1242 | notifications of this type MUST be rate limited. | |
f91513e3 | 1243 | |
d6bd078a | 1244 | 2.4. State Synchronization and Connection Timeouts |
f91513e3 | 1245 | |
d6bd078a MW |
1246 | An IKE endpoint is allowed to forget all of its state associated with |
1247 | an IKE_SA and the collection of corresponding CHILD_SAs at any time. | |
1248 | This is the anticipated behavior in the event of an endpoint crash | |
1249 | and restart. It is important when an endpoint either fails or | |
f91513e3 MW |
1250 | reinitializes its state that the other endpoint detect those |
1251 | conditions and not continue to waste network bandwidth by sending | |
1252 | packets over discarded SAs and having them fall into a black hole. | |
1253 | ||
d6bd078a MW |
1254 | {{ 3.10.1-16384 }} The INITIAL_CONTACT notification asserts that this |
1255 | IKE_SA is the only IKE_SA currently active between the authenticated | |
1256 | identities. It MAY be sent when an IKE_SA is established after a | |
1257 | crash, and the recipient MAY use this information to delete any other | |
1258 | IKE_SAs it has to the same authenticated identity without waiting for | |
1259 | a timeout. This notification MUST NOT be sent by an entity that may | |
1260 | be replicated (e.g., a roaming user's credentials where the user is | |
1261 | allowed to connect to the corporate firewall from two remote systems | |
1262 | at the same time). {{ Clarif-7.9 }} The INITIAL_CONTACT notification, | |
1263 | if sent, MUST be in the first IKE_AUTH request, not as a separate | |
1264 | exchange afterwards; however, receiving parties need to deal with it | |
1265 | in other requests. | |
1266 | ||
f91513e3 MW |
1267 | Since IKE is designed to operate in spite of Denial of Service (DoS) |
1268 | attacks from the network, an endpoint MUST NOT conclude that the | |
1269 | other endpoint has failed based on any routing information (e.g., | |
1270 | ICMP messages) or IKE messages that arrive without cryptographic | |
1271 | protection (e.g., Notify messages complaining about unknown SPIs). | |
1272 | An endpoint MUST conclude that the other endpoint has failed only | |
1273 | when repeated attempts to contact it have gone unanswered for a | |
1274 | timeout period or when a cryptographically protected INITIAL_CONTACT | |
1275 | notification is received on a different IKE_SA to the same | |
1276 | authenticated identity. {{ Demoted the SHOULD }} An endpoint should | |
1277 | suspect that the other endpoint has failed based on routing | |
1278 | information and initiate a request to see whether the other endpoint | |
1279 | is alive. To check whether the other side is alive, IKE specifies an | |
1280 | empty INFORMATIONAL message that (like all IKE requests) requires an | |
1281 | acknowledgement (note that within the context of an IKE_SA, an | |
1282 | "empty" message consists of an IKE header followed by an Encrypted | |
1283 | payload that contains no payloads). If a cryptographically protected | |
d6bd078a MW |
1284 | |
1285 | ||
1286 | ||
1287 | Kaufman, et al. Expires August 28, 2008 [Page 23] | |
1288 | \f | |
1289 | Internet-Draft IKEv2bis February 2008 | |
1290 | ||
1291 | ||
f91513e3 MW |
1292 | message has been received from the other side recently, unprotected |
1293 | notifications MAY be ignored. Implementations MUST limit the rate at | |
1294 | which they take actions based on unprotected messages. | |
1295 | ||
1296 | Numbers of retries and lengths of timeouts are not covered in this | |
1297 | specification because they do not affect interoperability. It is | |
1298 | suggested that messages be retransmitted at least a dozen times over | |
1299 | a period of at least several minutes before giving up on an SA, but | |
1300 | different environments may require different rules. To be a good | |
1301 | network citizen, retranmission times MUST increase exponentially to | |
1302 | avoid flooding the network and making an existing congestion | |
1303 | situation worse. If there has only been outgoing traffic on all of | |
1304 | the SAs associated with an IKE_SA, it is essential to confirm | |
1305 | liveness of the other endpoint to avoid black holes. If no | |
1306 | cryptographically protected messages have been received on an IKE_SA | |
1307 | or any of its CHILD_SAs recently, the system needs to perform a | |
1308 | liveness check in order to prevent sending messages to a dead peer. | |
1309 | Receipt of a fresh cryptographically protected message on an IKE_SA | |
1310 | or any of its CHILD_SAs ensures liveness of the IKE_SA and all of its | |
1311 | CHILD_SAs. Note that this places requirements on the failure modes | |
1312 | of an IKE endpoint. An implementation MUST NOT continue sending on | |
1313 | any SA if some failure prevents it from receiving on all of the | |
1314 | associated SAs. If CHILD_SAs can fail independently from one another | |
1315 | without the associated IKE_SA being able to send a delete message, | |
1316 | then they MUST be negotiated by separate IKE_SAs. | |
1317 | ||
1318 | There is a Denial of Service attack on the initiator of an IKE_SA | |
f91513e3 MW |
1319 | that can be avoided if the initiator takes the proper care. Since |
1320 | the first two messages of an SA setup are not cryptographically | |
1321 | protected, an attacker could respond to the initiator's message | |
1322 | before the genuine responder and poison the connection setup attempt. | |
1323 | To prevent this, the initiator MAY be willing to accept multiple | |
1324 | responses to its first message, treat each as potentially legitimate, | |
1325 | respond to it, and then discard all the invalid half-open connections | |
1326 | when it receives a valid cryptographically protected response to any | |
1327 | one of its requests. Once a cryptographically valid response is | |
1328 | received, all subsequent responses should be ignored whether or not | |
1329 | they are cryptographically valid. | |
1330 | ||
1331 | Note that with these rules, there is no reason to negotiate and agree | |
1332 | upon an SA lifetime. If IKE presumes the partner is dead, based on | |
1333 | repeated lack of acknowledgement to an IKE message, then the IKE SA | |
1334 | and all CHILD_SAs set up through that IKE_SA are deleted. | |
1335 | ||
1336 | An IKE endpoint may at any time delete inactive CHILD_SAs to recover | |
1337 | resources used to hold their state. If an IKE endpoint chooses to | |
1338 | delete CHILD_SAs, it MUST send Delete payloads to the other end | |
1339 | notifying it of the deletion. It MAY similarly time out the IKE_SA. | |
d6bd078a MW |
1340 | |
1341 | ||
1342 | ||
1343 | Kaufman, et al. Expires August 28, 2008 [Page 24] | |
1344 | \f | |
1345 | Internet-Draft IKEv2bis February 2008 | |
1346 | ||
1347 | ||
f91513e3 MW |
1348 | {{ Clarified the SHOULD }} Closing the IKE_SA implicitly closes all |
1349 | associated CHILD_SAs. In this case, an IKE endpoint SHOULD send a | |
1350 | Delete payload indicating that it has closed the IKE_SA unless the | |
1351 | other endpoint is no longer responding. | |
1352 | ||
1353 | 2.5. Version Numbers and Forward Compatibility | |
1354 | ||
1355 | This document describes version 2.0 of IKE, meaning the major version | |
1356 | number is 2 and the minor version number is 0. {{ Restated the | |
1357 | relationship to RFC 4306 }} This document is a clarification of | |
1358 | [IKEV2]. It is likely that some implementations will want to support | |
1359 | version 1.0 and version 2.0, and in the future, other versions. | |
1360 | ||
1361 | The major version number should be incremented only if the packet | |
1362 | formats or required actions have changed so dramatically that an | |
1363 | older version node would not be able to interoperate with a newer | |
1364 | version node if it simply ignored the fields it did not understand | |
1365 | and took the actions specified in the older specification. The minor | |
1366 | version number indicates new capabilities, and MUST be ignored by a | |
1367 | node with a smaller minor version number, but used for informational | |
1368 | purposes by the node with the larger minor version number. For | |
1369 | example, it might indicate the ability to process a newly defined | |
1370 | notification message. The node with the larger minor version number | |
1371 | would simply note that its correspondent would not be able to | |
1372 | understand that message and therefore would not send it. | |
1373 | ||
d6bd078a MW |
1374 | {{ 3.10.1-5 }} If an endpoint receives a message with a higher major |
1375 | version number, it MUST drop the message and SHOULD send an | |
1376 | unauthenticated notification message of type INVALID_MAJOR_VERSION | |
1377 | containing the highest (closest) version number it supports. If an | |
1378 | endpoint supports major version n, and major version m, it MUST | |
1379 | support all versions between n and m. If it receives a message with | |
1380 | a major version that it supports, it MUST respond with that version | |
1381 | number. In order to prevent two nodes from being tricked into | |
1382 | corresponding with a lower major version number than the maximum that | |
1383 | they both support, IKE has a flag that indicates that the node is | |
1384 | capable of speaking a higher major version number. | |
f91513e3 MW |
1385 | |
1386 | Thus, the major version number in the IKE header indicates the | |
1387 | version number of the message, not the highest version number that | |
1388 | the transmitter supports. If the initiator is capable of speaking | |
1389 | versions n, n+1, and n+2, and the responder is capable of speaking | |
1390 | versions n and n+1, then they will negotiate speaking n+1, where the | |
d6bd078a | 1391 | initiator will set a flag indicating its ability to speak a higher |
f91513e3 MW |
1392 | version. If they mistakenly (perhaps through an active attacker |
1393 | sending error messages) negotiate to version n, then both will notice | |
1394 | that the other side can support a higher version number, and they | |
1395 | MUST break the connection and reconnect using version n+1. | |
1396 | ||
d6bd078a MW |
1397 | |
1398 | ||
1399 | Kaufman, et al. Expires August 28, 2008 [Page 25] | |
1400 | \f | |
1401 | Internet-Draft IKEv2bis February 2008 | |
1402 | ||
1403 | ||
f91513e3 MW |
1404 | Note that IKEv1 does not follow these rules, because there is no way |
1405 | in v1 of noting that you are capable of speaking a higher version | |
1406 | number. So an active attacker can trick two v2-capable nodes into | |
1407 | speaking v1. {{ Demoted the SHOULD }} When a v2-capable node | |
1408 | negotiates down to v1, it should note that fact in its logs. | |
1409 | ||
1410 | Also for forward compatibility, all fields marked RESERVED MUST be | |
d6bd078a MW |
1411 | set to zero by an implementation running version 2.0, and their |
1412 | content MUST be ignored by an implementation running version 2.0 ("Be | |
1413 | conservative in what you send and liberal in what you receive"). In | |
1414 | this way, future versions of the protocol can use those fields in a | |
1415 | way that is guaranteed to be ignored by implementations that do not | |
1416 | understand them. Similarly, payload types that are not defined are | |
1417 | reserved for future use; implementations of a version where they are | |
1418 | undefined MUST skip over those payloads and ignore their contents. | |
f91513e3 MW |
1419 | |
1420 | IKEv2 adds a "critical" flag to each payload header for further | |
1421 | flexibility for forward compatibility. If the critical flag is set | |
1422 | and the payload type is unrecognized, the message MUST be rejected | |
1423 | and the response to the IKE request containing that payload MUST | |
1424 | include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an | |
d6bd078a MW |
1425 | unsupported critical payload was included. {{ 3.10.1-1 }} In that |
1426 | Notify payload, the notification data contains the one-octet payload | |
1427 | type. If the critical flag is not set and the payload type is | |
1428 | unsupported, that payload MUST be ignored. Payloads sent in IKE | |
1429 | response messages MUST NOT have the critical flag set. Note that the | |
1430 | critical flag applies only to the payload type, not the contents. If | |
1431 | the payload type is recognized, but the payload contains something | |
1432 | which is not (such as an unknown transform inside an SA payload, or | |
1433 | an unknown Notify Message Type inside a Notify payload), the critical | |
1434 | flag is ignored. | |
1435 | ||
1436 | NOTE TO IMPLEMENTERS: Does anyone require that the payloads be in the | |
1437 | order shown in the figures in Section 2? Can we eliminate the | |
1438 | requirement in the following paragraph? If not, we will probably | |
1439 | have to add a new appendix with the order, but there is no reason to | |
1440 | do that if no one actually cares. {{ Remove this paragraph before the | |
1441 | document is finalized, of course. }} | |
f91513e3 MW |
1442 | |
1443 | {{ Demoted the SHOULD in the second clause }}Although new payload | |
f91513e3 MW |
1444 | types may be added in the future and may appear interleaved with the |
1445 | fields defined in this specification, implementations MUST send the | |
1446 | payloads defined in this specification in the order shown in the | |
1447 | figures in Section 2; implementations are explicitly allowed to | |
1448 | reject as invalid a message with those payloads in any other order. | |
1449 | ||
f91513e3 | 1450 | |
d6bd078a MW |
1451 | |
1452 | ||
1453 | ||
1454 | ||
1455 | Kaufman, et al. Expires August 28, 2008 [Page 26] | |
1456 | \f | |
1457 | Internet-Draft IKEv2bis February 2008 | |
1458 | ||
1459 | ||
1460 | 2.6. Cookies | |
1461 | ||
1462 | The term "cookies" originates with Karn and Simpson [PHOTURIS] in | |
1463 | Photuris, an early proposal for key management with IPsec, and it has | |
f91513e3 MW |
1464 | persisted. The Internet Security Association and Key Management |
1465 | Protocol (ISAKMP) [ISAKMP] fixed message header includes two eight- | |
1466 | octet fields titled "cookies", and that syntax is used by both IKEv1 | |
d6bd078a MW |
1467 | and IKEv2, although in IKEv2 they are referred to as the "IKE SPI" |
1468 | and there is a new separate field in a Notify payload holding the | |
1469 | cookie. The initial two eight-octet fields in the header are used as | |
1470 | a connection identifier at the beginning of IKE packets. {{ Demoted | |
1471 | the SHOULD }} Each endpoint chooses one of the two SPIs and needs to | |
f91513e3 MW |
1472 | choose them so as to be unique identifiers of an IKE_SA. An SPI |
1473 | value of zero is special and indicates that the remote SPI value is | |
1474 | not yet known by the sender. | |
1475 | ||
1476 | Unlike ESP and AH where only the recipient's SPI appears in the | |
1477 | header of a message, in IKE the sender's SPI is also sent in every | |
1478 | message. Since the SPI chosen by the original initiator of the | |
1479 | IKE_SA is always sent first, an endpoint with multiple IKE_SAs open | |
1480 | that wants to find the appropriate IKE_SA using the SPI it assigned | |
1481 | must look at the I(nitiator) Flag bit in the header to determine | |
1482 | whether it assigned the first or the second eight octets. | |
1483 | ||
1484 | In the first message of an initial IKE exchange, the initiator will | |
1485 | not know the responder's SPI value and will therefore set that field | |
1486 | to zero. | |
1487 | ||
1488 | An expected attack against IKE is state and CPU exhaustion, where the | |
1489 | target is flooded with session initiation requests from forged IP | |
1490 | addresses. This attack can be made less effective if an | |
1491 | implementation of a responder uses minimal CPU and commits no state | |
1492 | to an SA until it knows the initiator can receive packets at the | |
d6bd078a | 1493 | address from which it claims to be sending them. |
f91513e3 | 1494 | |
d6bd078a MW |
1495 | When a responder detects a large number of half-open IKE_SAs, it |
1496 | SHOULD reply to IKE_SA_INIT requests with a response containing the | |
1497 | COOKIE notification. {{ 3.10.1-16390 }} The data associated with this | |
1498 | notification MUST be between 1 and 64 octets in length (inclusive), | |
1499 | and its generation is described later in this section. If the | |
1500 | IKE_SA_INIT response includes the COOKIE notification, the initiator | |
1501 | MUST then retry the IKE_SA_INIT request, and include the COOKIE | |
1502 | notification containing the received data as the first payload, and | |
1503 | all other payloads unchanged. The initial exchange will then be as | |
1504 | follows: | |
f91513e3 MW |
1505 | |
1506 | ||
f91513e3 MW |
1507 | |
1508 | ||
d6bd078a MW |
1509 | |
1510 | ||
1511 | Kaufman, et al. Expires August 28, 2008 [Page 27] | |
1512 | \f | |
1513 | Internet-Draft IKEv2bis February 2008 | |
1514 | ||
f91513e3 MW |
1515 | |
1516 | Initiator Responder | |
1517 | ------------------------------------------------------------------- | |
1518 | HDR(A,0), SAi1, KEi, Ni --> | |
1519 | <-- HDR(A,0), N(COOKIE) | |
1520 | HDR(A,0), N(COOKIE), SAi1, | |
1521 | KEi, Ni --> | |
1522 | <-- HDR(A,B), SAr1, KEr, | |
1523 | Nr, [CERTREQ] | |
1524 | HDR(A,B), SK {IDi, [CERT,] | |
1525 | [CERTREQ,] [IDr,] AUTH, | |
1526 | SAi2, TSi, TSr} --> | |
1527 | <-- HDR(A,B), SK {IDr, [CERT,] | |
1528 | AUTH, SAr2, TSi, TSr} | |
1529 | ||
1530 | The first two messages do not affect any initiator or responder state | |
1531 | except for communicating the cookie. In particular, the message | |
1532 | sequence numbers in the first four messages will all be zero and the | |
1533 | message sequence numbers in the last two messages will be one. 'A' | |
1534 | is the SPI assigned by the initiator, while 'B' is the SPI assigned | |
1535 | by the responder. | |
1536 | ||
f91513e3 MW |
1537 | {{ Demoted the SHOULD }} An IKE implementation should implement its |
1538 | responder cookie generation in such a way as to not require any saved | |
1539 | state to recognize its valid cookie when the second IKE_SA_INIT | |
1540 | message arrives. The exact algorithms and syntax they use to | |
1541 | generate cookies do not affect interoperability and hence are not | |
1542 | specified here. The following is an example of how an endpoint could | |
1543 | use cookies to implement limited DOS protection. | |
1544 | ||
1545 | A good way to do this is to set the responder cookie to be: | |
1546 | ||
1547 | Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>) | |
1548 | ||
1549 | where <secret> is a randomly generated secret known only to the | |
1550 | responder and periodically changed and | indicates concatenation. | |
1551 | <VersionIDofSecret> should be changed whenever <secret> is | |
1552 | regenerated. The cookie can be recomputed when the IKE_SA_INIT | |
1553 | arrives the second time and compared to the cookie in the received | |
1554 | message. If it matches, the responder knows that the cookie was | |
1555 | generated since the last change to <secret> and that IPi must be the | |
1556 | same as the source address it saw the first time. Incorporating SPIi | |
f91513e3 MW |
1557 | into the calculation ensures that if multiple IKE_SAs are being set |
1558 | up in parallel they will all get different cookies (assuming the | |
1559 | initiator chooses unique SPIi's). Incorporating Ni into the hash | |
1560 | ensures that an attacker who sees only message 2 can't successfully | |
1561 | forge a message 3. | |
1562 | ||
1563 | If a new value for <secret> is chosen while there are connections in | |
d6bd078a MW |
1564 | |
1565 | ||
1566 | ||
1567 | Kaufman, et al. Expires August 28, 2008 [Page 28] | |
1568 | \f | |
1569 | Internet-Draft IKEv2bis February 2008 | |
1570 | ||
1571 | ||
f91513e3 MW |
1572 | the process of being initialized, an IKE_SA_INIT might be returned |
1573 | with other than the current <VersionIDofSecret>. The responder in | |
1574 | that case MAY reject the message by sending another response with a | |
1575 | new cookie or it MAY keep the old value of <secret> around for a | |
1576 | short time and accept cookies computed from either one. {{ Demoted | |
1577 | the SHOULD NOT }} The responder should not accept cookies | |
1578 | indefinitely after <secret> is changed, since that would defeat part | |
1579 | of the denial of service protection. {{ Demoted the SHOULD }} The | |
1580 | responder should change the value of <secret> frequently, especially | |
1581 | if under attack. | |
1582 | ||
1583 | {{ Clarif-2.1 }} In addition to cookies, there are several cases | |
1584 | where the IKE_SA_INIT exchange does not result in the creation of an | |
1585 | IKE_SA (such as INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN). In such a | |
1586 | case, sending a zero value for the Responder's SPI is correct. If | |
1587 | the responder sends a non-zero responder SPI, the initiator should | |
1588 | not reject the response for only that reason. | |
1589 | ||
1590 | {{ Clarif-2.5 }} When one party receives an IKE_SA_INIT request | |
1591 | containing a cookie whose contents do not match the value expected, | |
1592 | that party MUST ignore the cookie and process the message as if no | |
1593 | cookie had been included; usually this means sending a response | |
1594 | containing a new cookie. | |
1595 | ||
1596 | 2.6.1. Interaction of COOKIE and INVALID_KE_PAYLOAD | |
1597 | ||
1598 | {{ This section added by Clarif-2.4 }} | |
1599 | ||
1600 | There are two common reasons why the initiator may have to retry the | |
1601 | IKE_SA_INIT exchange: the responder requests a cookie or wants a | |
1602 | different Diffie-Hellman group than was included in the KEi payload. | |
1603 | If the initiator receives a cookie from the responder, the initiator | |
1604 | needs to decide whether or not to include the cookie in only the next | |
1605 | retry of the IKE_SA_INIT request, or in all subsequent retries as | |
1606 | well. | |
1607 | ||
1608 | If the initiator includes the cookie only in the next retry, one | |
1609 | additional roundtrip may be needed in some cases. An additional | |
1610 | roundtrip is needed also if the initiator includes the cookie in all | |
1611 | retries, but the responder does not support this. For instance, if | |
1612 | the responder includes the SAi1 and KEi payloads in cookie | |
f91513e3 MW |
1613 | calculation, it will reject the request by sending a new cookie. |
1614 | ||
1615 | If both peers support including the cookie in all retries, a slightly | |
1616 | shorter exchange can happen. Implementations SHOULD support this | |
1617 | shorter exchange, but MUST NOT fail if other implementations do not | |
1618 | support this shorter exchange. | |
1619 | ||
d6bd078a MW |
1620 | |
1621 | ||
1622 | ||
1623 | Kaufman, et al. Expires August 28, 2008 [Page 29] | |
1624 | \f | |
1625 | Internet-Draft IKEv2bis February 2008 | |
1626 | ||
1627 | ||
f91513e3 MW |
1628 | 2.7. Cryptographic Algorithm Negotiation |
1629 | ||
1630 | The payload type known as "SA" indicates a proposal for a set of | |
1631 | choices of IPsec protocols (IKE, ESP, and/or AH) for the SA as well | |
1632 | as cryptographic algorithms associated with each protocol. | |
1633 | ||
d6bd078a MW |
1634 | An SA payload consists of one or more proposals. {{ Clarif-7.13 }} |
1635 | Each proposal includes one protocol. Each protocol contains one or | |
1636 | more transforms -- each specifying a cryptographic algorithm. Each | |
1637 | transform contains zero or more attributes (attributes are needed | |
1638 | only if the transform identifier does not completely specify the | |
1639 | cryptographic algorithm). | |
f91513e3 MW |
1640 | |
1641 | This hierarchical structure was designed to efficiently encode | |
1642 | proposals for cryptographic suites when the number of supported | |
1643 | suites is large because multiple values are acceptable for multiple | |
d6bd078a | 1644 | transforms. The responder MUST choose a single suite, which may be |
f91513e3 MW |
1645 | any subset of the SA proposal following the rules below: |
1646 | ||
d6bd078a MW |
1647 | {{ Clarif-7.13 }} Each proposal contains one protocol. If a proposal |
1648 | is accepted, the SA response MUST contain the same protocol. The | |
1649 | responder MUST accept a single proposal or reject them all and return | |
1650 | an error. {{ 3.10.1-14 }} The error is given in a notification of | |
1651 | type NO_PROPOSAL_CHOSEN. | |
f91513e3 MW |
1652 | |
1653 | Each IPsec protocol proposal contains one or more transforms. Each | |
1654 | transform contains a transform type. The accepted cryptographic | |
1655 | suite MUST contain exactly one transform of each type included in the | |
1656 | proposal. For example: if an ESP proposal includes transforms | |
1657 | ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256, | |
1658 | AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one | |
1659 | of the ENCR_ transforms and one of the AUTH_ transforms. Thus, six | |
1660 | combinations are acceptable. | |
1661 | ||
1662 | Since the initiator sends its Diffie-Hellman value in the | |
1663 | IKE_SA_INIT, it must guess the Diffie-Hellman group that the | |
1664 | responder will select from its list of supported groups. If the | |
1665 | initiator guesses wrong, the responder will respond with a Notify | |
1666 | payload of type INVALID_KE_PAYLOAD indicating the selected group. In | |
f91513e3 MW |
1667 | this case, the initiator MUST retry the IKE_SA_INIT with the |
1668 | corrected Diffie-Hellman group. The initiator MUST again propose its | |
1669 | full set of acceptable cryptographic suites because the rejection | |
1670 | message was unauthenticated and otherwise an active attacker could | |
1671 | trick the endpoints into negotiating a weaker suite than a stronger | |
1672 | one that they both prefer. | |
1673 | ||
d6bd078a MW |
1674 | {{ Clarif-2.1 }} When the IKE_SA_INIT exchange does not result in the |
1675 | creation of an IKE_SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN, | |
1676 | ||
1677 | ||
1678 | ||
1679 | Kaufman, et al. Expires August 28, 2008 [Page 30] | |
1680 | \f | |
1681 | Internet-Draft IKEv2bis February 2008 | |
1682 | ||
1683 | ||
1684 | or COOKIE (see Section 2.6), the responder's SPI will be zero. | |
1685 | However, if the responder sends a non-zero responder SPI, the | |
1686 | initiator should not reject the response for only that reason. | |
1687 | ||
f91513e3 MW |
1688 | 2.8. Rekeying |
1689 | ||
1690 | {{ Demoted the SHOULD }} IKE, ESP, and AH security associations use | |
1691 | secret keys that should be used only for a limited amount of time and | |
1692 | to protect a limited amount of data. This limits the lifetime of the | |
1693 | entire security association. When the lifetime of a security | |
1694 | association expires, the security association MUST NOT be used. If | |
1695 | there is demand, new security associations MAY be established. | |
1696 | Reestablishment of security associations to take the place of ones | |
1697 | that expire is referred to as "rekeying". | |
1698 | ||
1699 | To allow for minimal IPsec implementations, the ability to rekey SAs | |
1700 | without restarting the entire IKE_SA is optional. An implementation | |
1701 | MAY refuse all CREATE_CHILD_SA requests within an IKE_SA. If an SA | |
1702 | has expired or is about to expire and rekeying attempts using the | |
1703 | mechanisms described here fail, an implementation MUST close the | |
1704 | IKE_SA and any associated CHILD_SAs and then MAY start new ones. {{ | |
1705 | Demoted the SHOULD }} Implementations may wish to support in-place | |
1706 | rekeying of SAs, since doing so offers better performance and is | |
1707 | likely to reduce the number of packets lost during the transition. | |
1708 | ||
1709 | To rekey a CHILD_SA within an existing IKE_SA, create a new, | |
1710 | equivalent SA (see Section 2.17 below), and when the new one is | |
1711 | established, delete the old one. To rekey an IKE_SA, establish a new | |
1712 | equivalent IKE_SA (see Section 2.18 below) with the peer to whom the | |
1713 | old IKE_SA is shared using a CREATE_CHILD_SA within the existing | |
1714 | IKE_SA. An IKE_SA so created inherits all of the original IKE_SA's | |
d6bd078a MW |
1715 | CHILD_SAs, and the new IKE_SA is used for all control messages needed |
1716 | to maintain those CHILD_SAs. The old IKE_SA is then deleted, and the | |
1717 | Delete payload to delete itself MUST be the last request sent over | |
1718 | the old IKE_SA. | |
f91513e3 MW |
1719 | |
1720 | {{ Demoted the SHOULD }} SAs should be rekeyed proactively, i.e., the | |
1721 | new SA should be established before the old one expires and becomes | |
1722 | unusable. Enough time should elapse between the time the new SA is | |
1723 | established and the old one becomes unusable so that traffic can be | |
1724 | switched over to the new SA. | |
1725 | ||
1726 | A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes | |
1727 | were negotiated. In IKEv2, each end of the SA is responsible for | |
1728 | enforcing its own lifetime policy on the SA and rekeying the SA when | |
d6bd078a MW |
1729 | necessary. If the two ends have different lifetime policies, the end |
1730 | with the shorter lifetime will end up always being the one to request | |
1731 | the rekeying. If an SA has been inactive for a long time and if an | |
f91513e3 MW |
1732 | |
1733 | ||
1734 | ||
d6bd078a | 1735 | Kaufman, et al. Expires August 28, 2008 [Page 31] |
f91513e3 | 1736 | \f |
d6bd078a | 1737 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
1738 | |
1739 | ||
d6bd078a MW |
1740 | endpoint would not initiate the SA in the absence of traffic, the |
1741 | endpoint MAY choose to close the SA instead of rekeying it when its | |
1742 | lifetime expires. {{ Demoted the SHOULD }} It should do so if there | |
1743 | has been no traffic since the last time the SA was rekeyed. | |
f91513e3 MW |
1744 | |
1745 | Note that IKEv2 deliberately allows parallel SAs with the same | |
1746 | traffic selectors between common endpoints. One of the purposes of | |
1747 | this is to support traffic quality of service (QoS) differences among | |
1748 | the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and section 4.1 of | |
1749 | [DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints | |
1750 | and the traffic selectors may not uniquely identify an SA between | |
1751 | those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on | |
1752 | the basis of duplicate traffic selectors SHOULD NOT be used. | |
1753 | ||
1754 | {{ Demoted the SHOULD }} The node that initiated the surviving | |
1755 | rekeyed SA should delete the replaced SA after the new one is | |
1756 | established. | |
1757 | ||
1758 | There are timing windows -- particularly in the presence of lost | |
1759 | packets -- where endpoints may not agree on the state of an SA. The | |
1760 | responder to a CREATE_CHILD_SA MUST be prepared to accept messages on | |
1761 | an SA before sending its response to the creation request, so there | |
1762 | is no ambiguity for the initiator. The initiator MAY begin sending | |
1763 | on an SA as soon as it processes the response. The initiator, | |
1764 | however, cannot receive on a newly created SA until it receives and | |
1765 | processes the response to its CREATE_CHILD_SA request. How, then, is | |
1766 | the responder to know when it is OK to send on the newly created SA? | |
1767 | ||
1768 | From a technical correctness and interoperability perspective, the | |
1769 | responder MAY begin sending on an SA as soon as it sends its response | |
1770 | to the CREATE_CHILD_SA request. In some situations, however, this | |
1771 | could result in packets unnecessarily being dropped, so an | |
d6bd078a | 1772 | implementation MAY defer such sending. |
f91513e3 MW |
1773 | |
1774 | The responder can be assured that the initiator is prepared to | |
1775 | receive messages on an SA if either (1) it has received a | |
1776 | cryptographically valid message on the new SA, or (2) the new SA | |
1777 | rekeys an existing SA and it receives an IKE request to close the | |
1778 | replaced SA. When rekeying an SA, the responder continues to send | |
1779 | traffic on the old SA until one of those events occurs. When | |
1780 | establishing a new SA, the responder MAY defer sending messages on a | |
1781 | new SA until either it receives one or a timeout has occurred. {{ | |
1782 | Demoted the SHOULD }} If an initiator receives a message on an SA for | |
1783 | which it has not received a response to its CREATE_CHILD_SA request, | |
1784 | it interprets that as a likely packet loss and retransmits the | |
d6bd078a MW |
1785 | CREATE_CHILD_SA request. An initiator MAY send a dummy message on a |
1786 | newly created SA if it has no messages queued in order to assure the | |
1787 | responder that the initiator is ready to receive messages. | |
f91513e3 MW |
1788 | |
1789 | ||
1790 | ||
d6bd078a | 1791 | Kaufman, et al. Expires August 28, 2008 [Page 32] |
f91513e3 | 1792 | \f |
d6bd078a | 1793 | Internet-Draft IKEv2bis February 2008 |
f91513e3 | 1794 | |
f91513e3 MW |
1795 | |
1796 | {{ Clarif-5.9 }} Throughout this document, "initiator" refers to the | |
1797 | party who initiated the exchange being described, and "original | |
1798 | initiator" refers to the party who initiated the whole IKE_SA. The | |
1799 | "original initiator" always refers to the party who initiated the | |
1800 | exchange which resulted in the current IKE_SA. In other words, if | |
d6bd078a | 1801 | the "original responder" starts rekeying the IKE_SA, that party |
f91513e3 MW |
1802 | becomes the "original initiator" of the new IKE_SA. |
1803 | ||
1804 | 2.8.1. Simultaneous CHILD_SA rekeying | |
1805 | ||
1806 | {{ The first two paragraphs were moved, and the rest was added, based | |
1807 | on Clarif-5.11 }} | |
1808 | ||
1809 | If the two ends have the same lifetime policies, it is possible that | |
1810 | both will initiate a rekeying at the same time (which will result in | |
1811 | redundant SAs). To reduce the probability of this happening, the | |
1812 | timing of rekeying requests SHOULD be jittered (delayed by a random | |
1813 | amount of time after the need for rekeying is noticed). | |
1814 | ||
1815 | This form of rekeying may temporarily result in multiple similar SAs | |
1816 | between the same pairs of nodes. When there are two SAs eligible to | |
1817 | receive packets, a node MUST accept incoming packets through either | |
1818 | SA. If redundant SAs are created though such a collision, the SA | |
1819 | created with the lowest of the four nonces used in the two exchanges | |
1820 | SHOULD be closed by the endpoint that created it. {{ Clarif-5.10 }} | |
1821 | "Lowest" means an octet-by-octet, lexicographical comparison (instead | |
1822 | of, for instance, comparing the nonces as large integers). In other | |
1823 | words, start by comparing the first octet; if they're equal, move to | |
1824 | the next octet, and so on. If you reach the end of one nonce, that | |
1825 | nonce is the lower one. | |
1826 | ||
1827 | The following is an explanation on the impact this has on | |
1828 | implementations. Assume that hosts A and B have an existing IPsec SA | |
1829 | pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same | |
1830 | time: | |
1831 | ||
1832 | Host A Host B | |
1833 | ------------------------------------------------------------------- | |
1834 | send req1: N(REKEY_SA,SPIa1), | |
1835 | SA(..,SPIa2,..),Ni1,.. --> | |
1836 | <-- send req2: N(REKEY_SA,SPIb1), | |
1837 | SA(..,SPIb2,..),Ni2 | |
1838 | recv req2 <-- | |
1839 | ||
d6bd078a MW |
1840 | At this point, A knows there is a simultaneous rekeying going on. |
1841 | However, it cannot yet know which of the exchanges will have the | |
1842 | lowest nonce, so it will just note the situation and respond as | |
1843 | usual. | |
f91513e3 MW |
1844 | |
1845 | ||
1846 | ||
d6bd078a | 1847 | Kaufman, et al. Expires August 28, 2008 [Page 33] |
f91513e3 | 1848 | \f |
d6bd078a | 1849 | Internet-Draft IKEv2bis February 2008 |
f91513e3 | 1850 | |
f91513e3 MW |
1851 | |
1852 | send resp2: SA(..,SPIa3,..), | |
1853 | Nr1,.. --> | |
1854 | --> recv req1 | |
1855 | ||
1856 | Now B also knows that simultaneous rekeying is going on. It responds | |
1857 | as usual. | |
1858 | ||
1859 | <-- send resp1: SA(..,SPIb3,..), | |
1860 | Nr2,.. | |
1861 | recv resp1 <-- | |
1862 | --> recv resp2 | |
1863 | ||
1864 | At this point, there are three CHILD_SA pairs between A and B (the | |
1865 | old one and two new ones). A and B can now compare the nonces. | |
1866 | Suppose that the lowest nonce was Nr1 in message resp2; in this case, | |
1867 | B (the sender of req2) deletes the redundant new SA, and A (the node | |
1868 | that initiated the surviving rekeyed SA), deletes the old one. | |
1869 | ||
1870 | send req3: D(SPIa1) --> | |
1871 | <-- send req4: D(SPIb2) | |
1872 | --> recv req3 | |
d6bd078a | 1873 | <-- send resp3: D(SPIb1) |
f91513e3 MW |
1874 | recv req4 <-- |
1875 | send resp4: D(SPIa3) --> | |
1876 | ||
1877 | The rekeying is now finished. | |
1878 | ||
1879 | However, there is a second possible sequence of events that can | |
1880 | happen if some packets are lost in the network, resulting in | |
1881 | retransmissions. The rekeying begins as usual, but A's first packet | |
1882 | (req1) is lost. | |
1883 | ||
f91513e3 MW |
1884 | Host A Host B |
1885 | ------------------------------------------------------------------- | |
1886 | send req1: N(REKEY_SA,SPIa1), | |
1887 | SA(..,SPIa2,..), | |
1888 | Ni1,.. --> (lost) | |
1889 | <-- send req2: N(REKEY_SA,SPIb1), | |
1890 | SA(..,SPIb2,..),Ni2 | |
1891 | recv req2 <-- | |
1892 | send resp2: SA(..,SPIa3,..), | |
1893 | Nr1,.. --> | |
1894 | --> recv resp2 | |
1895 | <-- send req3: D(SPIb1) | |
1896 | recv req3 <-- | |
1897 | send resp3: D(SPIa1) --> | |
1898 | --> recv resp3 | |
1899 | ||
d6bd078a MW |
1900 | |
1901 | ||
1902 | ||
1903 | Kaufman, et al. Expires August 28, 2008 [Page 34] | |
1904 | \f | |
1905 | Internet-Draft IKEv2bis February 2008 | |
1906 | ||
1907 | ||
f91513e3 MW |
1908 | From B's point of view, the rekeying is now completed, and since it |
1909 | has not yet received A's req1, it does not even know that there was | |
1910 | simultaneous rekeying. However, A will continue retransmitting the | |
1911 | message, and eventually it will reach B. | |
1912 | ||
1913 | resend req1 --> | |
1914 | --> recv req1 | |
1915 | ||
1916 | To B, it looks like A is trying to rekey an SA that no longer exists; | |
1917 | thus, B responds to the request with something non-fatal such as | |
1918 | NO_PROPOSAL_CHOSEN. | |
1919 | ||
1920 | <-- send resp1: N(NO_PROPOSAL_CHOSEN) | |
1921 | recv resp1 <-- | |
1922 | ||
1923 | When A receives this error, it already knows there was simultaneous | |
1924 | rekeying, so it can ignore the error message. | |
1925 | ||
1926 | 2.8.2. Rekeying the IKE_SA Versus Reauthentication | |
1927 | ||
1928 | {{ Added this section from Clarif-5.2 }} | |
1929 | ||
1930 | Rekeying the IKE_SA and reauthentication are different concepts in | |
1931 | IKEv2. Rekeying the IKE_SA establishes new keys for the IKE_SA and | |
1932 | resets the Message ID counters, but it does not authenticate the | |
1933 | parties again (no AUTH or EAP payloads are involved). | |
1934 | ||
1935 | Although rekeying the IKE_SA may be important in some environments, | |
1936 | reauthentication (the verification that the parties still have access | |
1937 | to the long-term credentials) is often more important. | |
1938 | ||
1939 | IKEv2 does not have any special support for reauthentication. | |
f91513e3 MW |
1940 | Reauthentication is done by creating a new IKE_SA from scratch (using |
1941 | IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify | |
1942 | payloads), creating new CHILD_SAs within the new IKE_SA (without | |
1943 | REKEY_SA notify payloads), and finally deleting the old IKE_SA (which | |
1944 | deletes the old CHILD_SAs as well). | |
1945 | ||
1946 | This means that reauthentication also establishes new keys for the | |
1947 | IKE_SA and CHILD_SAs. Therefore, while rekeying can be performed | |
1948 | more often than reauthentication, the situation where "authentication | |
1949 | lifetime" is shorter than "key lifetime" does not make sense. | |
1950 | ||
1951 | While creation of a new IKE_SA can be initiated by either party | |
1952 | (initiator or responder in the original IKE_SA), the use of EAP | |
1953 | authentication and/or configuration payloads means in practice that | |
1954 | reauthentication has to be initiated by the same party as the | |
1955 | original IKE_SA. IKEv2 does not currently allow the responder to | |
d6bd078a MW |
1956 | |
1957 | ||
1958 | ||
1959 | Kaufman, et al. Expires August 28, 2008 [Page 35] | |
1960 | \f | |
1961 | Internet-Draft IKEv2bis February 2008 | |
1962 | ||
1963 | ||
1964 | request reauthentication in this case; however, there are extensions | |
1965 | that add this functionality such as [REAUTH]. | |
f91513e3 MW |
1966 | |
1967 | 2.9. Traffic Selector Negotiation | |
1968 | ||
1969 | {{ Clarif-7.2 }} When an RFC4301-compliant IPsec subsystem receives | |
1970 | an IP packet and matches a "protect" selector in its Security Policy | |
1971 | Database (SPD), the subsystem protects that packet with IPsec. When | |
1972 | no SA exists yet, it is the task of IKE to create it. Maintenance of | |
1973 | a system's SPD is outside the scope of IKE (see [PFKEY] for an | |
1974 | example protocol), though some implementations might update their SPD | |
1975 | in connection with the running of IKE (for an example scenario, see | |
1976 | Section 1.1.3). | |
1977 | ||
1978 | Traffic Selector (TS) payloads allow endpoints to communicate some of | |
1979 | the information from their SPD to their peers. TS payloads specify | |
1980 | the selection criteria for packets that will be forwarded over the | |
1981 | newly set up SA. This can serve as a consistency check in some | |
1982 | scenarios to assure that the SPDs are consistent. In others, it | |
1983 | guides the dynamic update of the SPD. | |
1984 | ||
1985 | Two TS payloads appear in each of the messages in the exchange that | |
1986 | creates a CHILD_SA pair. Each TS payload contains one or more | |
1987 | Traffic Selectors. Each Traffic Selector consists of an address | |
d6bd078a | 1988 | range (IPv4 or IPv6), a port range, and an IP protocol ID. |
f91513e3 MW |
1989 | |
1990 | The first of the two TS payloads is known as TSi (Traffic Selector- | |
1991 | initiator). The second is known as TSr (Traffic Selector-responder). | |
1992 | TSi specifies the source address of traffic forwarded from (or the | |
1993 | destination address of traffic forwarded to) the initiator of the | |
1994 | CHILD_SA pair. TSr specifies the destination address of the traffic | |
1995 | forwarded to (or the source address of the traffic forwarded from) | |
1996 | the responder of the CHILD_SA pair. For example, if the original | |
d6bd078a | 1997 | initiator requests the creation of a CHILD_SA pair, and wishes to |
f91513e3 MW |
1998 | tunnel all traffic from subnet 192.0.1.* on the initiator's side to |
1999 | subnet 192.0.2.* on the responder's side, the initiator would include | |
2000 | a single traffic selector in each TS payload. TSi would specify the | |
2001 | address range (192.0.1.0 - 192.0.1.255) and TSr would specify the | |
2002 | address range (192.0.2.0 - 192.0.2.255). Assuming that proposal was | |
2003 | acceptable to the responder, it would send identical TS payloads | |
2004 | back. (Note: The IP address range 192.0.2.* has been reserved for | |
2005 | use in examples in RFCs and similar documents. This document needed | |
2006 | two such ranges, and so also used 192.0.1.*. This should not be | |
2007 | confused with any actual address.) | |
2008 | ||
d6bd078a MW |
2009 | IKEv2 allows the responder to choose a subset of the traffic proposed |
2010 | by the initiator. This could happen when the configurations of the | |
2011 | two endpoints are being updated but only one end has received the new | |
f91513e3 MW |
2012 | |
2013 | ||
2014 | ||
d6bd078a | 2015 | Kaufman, et al. Expires August 28, 2008 [Page 36] |
f91513e3 | 2016 | \f |
d6bd078a | 2017 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
2018 | |
2019 | ||
d6bd078a MW |
2020 | information. Since the two endpoints may be configured by different |
2021 | people, the incompatibility may persist for an extended period even | |
2022 | in the absence of errors. It also allows for intentionally different | |
2023 | configurations, as when one end is configured to tunnel all addresses | |
2024 | and depends on the other end to have the up-to-date list. | |
2025 | ||
2026 | When the responder chooses a subset of the traffic proposed by the | |
2027 | initiator, it narrows the traffic selectors to some subset of the | |
2028 | initiator's proposal (provided the set does not become the null set). | |
f91513e3 MW |
2029 | |
2030 | To enable the responder to choose the appropriate range in this case, | |
2031 | if the initiator has requested the SA due to a data packet, the | |
2032 | initiator SHOULD include as the first traffic selector in each of TSi | |
2033 | and TSr a very specific traffic selector including the addresses in | |
2034 | the packet triggering the request. In the example, the initiator | |
2035 | would include in TSi two traffic selectors: the first containing the | |
2036 | address range (192.0.1.43 - 192.0.1.43) and the source port and IP | |
2037 | protocol from the packet and the second containing (192.0.1.0 - | |
2038 | 192.0.1.255) with all ports and IP protocols. The initiator would | |
d6bd078a MW |
2039 | similarly include two traffic selectors in TSr. If the initiator |
2040 | creates the CHILD_SA pair not in response to an arriving packet, but | |
2041 | rather, say, upon startup, then there may be no specific addresses | |
2042 | the initiator prefers for the initial tunnel over any other. In that | |
2043 | case, the first values in TSi and TSr can be ranges rather than | |
2044 | specific values. | |
2045 | ||
2046 | The responder performs the narrowing as follows: {{ Clarif-4.10 }} | |
2047 | ||
2048 | o If the responder's policy does not allow it to accept any part of | |
2049 | the proposed traffic selectors, it responds with TS_UNACCEPTABLE. | |
f91513e3 MW |
2050 | |
2051 | o If the responder's policy allows the entire set of traffic covered | |
d6bd078a MW |
2052 | by TSi and TSr, no narrowing is necessary, and the responder can |
2053 | return the same TSi and TSr values. | |
2054 | ||
2055 | o If the responder's policy allows it to accept the first selector | |
2056 | of TSi and TSr, then the responder MUST narrow the traffic | |
2057 | selectors to a subset that includes the initiator's first choices. | |
2058 | In this example above, the responder might respond with TSi being | |
2059 | (192.0.1.43 - 192.0.1.43) with all ports and IP protocols. | |
2060 | ||
2061 | o If the responder's policy does not allow it to accept the first | |
2062 | selector of TSi and TSr, the responder narrows to an acceptable | |
2063 | subset of TSi and TSr. | |
f91513e3 | 2064 | |
d6bd078a MW |
2065 | When narrowing is done, there may be several subsets that are |
2066 | acceptable but their union is not. In this case, the responder | |
2067 | arbitrarily chooses one of them, and MAY include an | |
f91513e3 MW |
2068 | |
2069 | ||
d6bd078a MW |
2070 | |
2071 | Kaufman, et al. Expires August 28, 2008 [Page 37] | |
f91513e3 | 2072 | \f |
d6bd078a | 2073 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
2074 | |
2075 | ||
d6bd078a MW |
2076 | ADDITIONAL_TS_POSSIBLE notification in the response. {{ 3.10.1-16386 |
2077 | }} The ADDITIONAL_TS_POSSIBLE notification asserts that the responder | |
2078 | narrowed the proposed traffic selectors but that other traffic | |
2079 | selectors would also have been acceptable, though only in a separate | |
2080 | SA. There is no data associated with this Notify type. This case | |
2081 | will occur only when the initiator and responder are configured | |
2082 | differently from one another. If the initiator and responder agree | |
2083 | on the granularity of tunnels, the initiator will never request a | |
2084 | tunnel wider than the responder will accept. {{ Demoted the SHOULD }} | |
2085 | Such misconfigurations should be recorded in error logs. | |
f91513e3 | 2086 | |
d6bd078a MW |
2087 | It is possible for the responder's policy to contain multiple smaller |
2088 | ranges, all encompassed by the initiator's traffic selector, and with | |
2089 | the responder's policy being that each of those ranges should be sent | |
2090 | over a different SA. Continuing the example above, the responder | |
2091 | might have a policy of being willing to tunnel those addresses to and | |
2092 | from the initiator, but might require that each address pair be on a | |
2093 | separately negotiated CHILD_SA. If the initiator generated its | |
2094 | request in response to an incoming packet from 192.0.1.43 to | |
2095 | 192.0.2.123, there would be no way for the responder to determine | |
2096 | which pair of addresses should be included in this tunnel, and it | |
2097 | would have to make a guess or reject the request with a status of | |
2098 | SINGLE_PAIR_REQUIRED. | |
f91513e3 | 2099 | |
d6bd078a MW |
2100 | {{ 3.10.1-34 }} The SINGLE_PAIR_REQUIRED error indicates that a |
2101 | CREATE_CHILD_SA request is unacceptable because its sender is only | |
2102 | willing to accept traffic selectors specifying a single pair of | |
2103 | addresses. The requestor is expected to respond by requesting an SA | |
2104 | for only the specific traffic it is trying to forward. | |
f91513e3 | 2105 | |
d6bd078a MW |
2106 | {{ Clarif-4.11 }} Few implementations will have policies that require |
2107 | separate SAs for each address pair. Because of this, if only some | |
2108 | parts of the TSi and TSr proposed by the initiator are acceptable to | |
2109 | the responder, responders SHOULD narrow the selectors to an | |
2110 | acceptable subset rather than use SINGLE_PAIR_REQUIRED. | |
f91513e3 MW |
2111 | |
2112 | 2.9.1. Traffic Selectors Violating Own Policy | |
2113 | ||
2114 | {{ Clarif-4.12 }} | |
2115 | ||
2116 | When creating a new SA, the initiator needs to avoid proposing | |
2117 | traffic selectors that violate its own policy. If this rule is not | |
2118 | followed, valid traffic may be dropped. | |
2119 | ||
2120 | This is best illustrated by an example. Suppose that host A has a | |
2121 | policy whose effect is that traffic to 192.0.1.66 is sent via host B | |
2122 | encrypted using AES, and traffic to all other hosts in 192.0.1.0/24 | |
2123 | is also sent via B, but must use 3DES. Suppose also that host B | |
d6bd078a MW |
2124 | |
2125 | ||
2126 | ||
2127 | Kaufman, et al. Expires August 28, 2008 [Page 38] | |
2128 | \f | |
2129 | Internet-Draft IKEv2bis February 2008 | |
2130 | ||
2131 | ||
f91513e3 MW |
2132 | accepts any combination of AES and 3DES. |
2133 | ||
2134 | If host A now proposes an SA that uses 3DES, and includes TSr | |
d6bd078a MW |
2135 | containing (192.0.1.0-192.0.1.255), this will be accepted by host B. |
2136 | Now, host B can also use this SA to send traffic from 192.0.1.66, but | |
2137 | those packets will be dropped by A since it requires the use of AES | |
2138 | for those traffic. Even if host A creates a new SA only for | |
f91513e3 MW |
2139 | 192.0.1.66 that uses AES, host B may freely continue to use the first |
2140 | SA for the traffic. In this situation, when proposing the SA, host A | |
2141 | should have followed its own policy, and included a TSr containing | |
2142 | ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead. | |
2143 | ||
2144 | In general, if (1) the initiator makes a proposal "for traffic X | |
2145 | (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator | |
2146 | does not actually accept traffic X' with SA, and (3) the initiator | |
2147 | would be willing to accept traffic X' with some SA' (!=SA), valid | |
2148 | traffic can be unnecessarily dropped since the responder can apply | |
2149 | either SA or SA' to traffic X'. | |
2150 | ||
f91513e3 MW |
2151 | 2.10. Nonces |
2152 | ||
2153 | The IKE_SA_INIT messages each contain a nonce. These nonces are used | |
2154 | as inputs to cryptographic functions. The CREATE_CHILD_SA request | |
2155 | and the CREATE_CHILD_SA response also contain nonces. These nonces | |
2156 | are used to add freshness to the key derivation technique used to | |
2157 | obtain keys for CHILD_SA, and to ensure creation of strong pseudo- | |
2158 | random bits from the Diffie-Hellman key. Nonces used in IKEv2 MUST | |
2159 | be randomly chosen, MUST be at least 128 bits in size, and MUST be at | |
2160 | least half the key size of the negotiated prf. ("prf" refers to | |
2161 | "pseudo-random function", one of the cryptographic algorithms | |
2162 | negotiated in the IKE exchange.) {{ Clarif-7.4 }} However, the | |
2163 | initiator chooses the nonce before the outcome of the negotiation is | |
2164 | known. Because of that, the nonce has to be long enough for all the | |
2165 | PRFs being proposed. If the same random number source is used for | |
2166 | both keys and nonces, care must be taken to ensure that the latter | |
2167 | use does not compromise the former. | |
2168 | ||
2169 | 2.11. Address and Port Agility | |
2170 | ||
2171 | IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and | |
2172 | AH associations for the same IP addresses it runs over. The IP | |
2173 | addresses and ports in the outer header are, however, not themselves | |
2174 | cryptographically protected, and IKE is designed to work even through | |
2175 | Network Address Translation (NAT) boxes. An implementation MUST | |
2176 | accept incoming requests even if the source port is not 500 or 4500, | |
2177 | and MUST respond to the address and port from which the request was | |
2178 | received. It MUST specify the address and port at which the request | |
2179 | was received as the source address and port in the response. IKE | |
d6bd078a MW |
2180 | |
2181 | ||
2182 | ||
2183 | Kaufman, et al. Expires August 28, 2008 [Page 39] | |
2184 | \f | |
2185 | Internet-Draft IKEv2bis February 2008 | |
2186 | ||
2187 | ||
f91513e3 MW |
2188 | functions identically over IPv4 or IPv6. |
2189 | ||
2190 | 2.12. Reuse of Diffie-Hellman Exponentials | |
2191 | ||
2192 | IKE generates keying material using an ephemeral Diffie-Hellman | |
2193 | exchange in order to gain the property of "perfect forward secrecy". | |
2194 | This means that once a connection is closed and its corresponding | |
2195 | keys are forgotten, even someone who has recorded all of the data | |
2196 | from the connection and gets access to all of the long-term keys of | |
2197 | the two endpoints cannot reconstruct the keys used to protect the | |
2198 | conversation without doing a brute force search of the session key | |
2199 | space. | |
2200 | ||
2201 | Achieving perfect forward secrecy requires that when a connection is | |
2202 | closed, each endpoint MUST forget not only the keys used by the | |
2203 | connection but also any information that could be used to recompute | |
2204 | those keys. In particular, it MUST forget the secrets used in the | |
2205 | Diffie-Hellman calculation and any state that may persist in the | |
2206 | state of a pseudo-random number generator that could be used to | |
f91513e3 MW |
2207 | recompute the Diffie-Hellman secrets. |
2208 | ||
2209 | Since the computing of Diffie-Hellman exponentials is computationally | |
2210 | expensive, an endpoint may find it advantageous to reuse those | |
2211 | exponentials for multiple connection setups. There are several | |
2212 | reasonable strategies for doing this. An endpoint could choose a new | |
2213 | exponential only periodically though this could result in less-than- | |
2214 | perfect forward secrecy if some connection lasts for less than the | |
2215 | lifetime of the exponential. Or it could keep track of which | |
2216 | exponential was used for each connection and delete the information | |
2217 | associated with the exponential only when some corresponding | |
2218 | connection was closed. This would allow the exponential to be reused | |
2219 | without losing perfect forward secrecy at the cost of maintaining | |
2220 | more state. | |
2221 | ||
2222 | Decisions as to whether and when to reuse Diffie-Hellman exponentials | |
2223 | is a private decision in the sense that it will not affect | |
2224 | interoperability. An implementation that reuses exponentials MAY | |
2225 | choose to remember the exponential used by the other endpoint on past | |
2226 | exchanges and if one is reused to avoid the second half of the | |
2227 | calculation. | |
2228 | ||
2229 | 2.13. Generating Keying Material | |
2230 | ||
2231 | In the context of the IKE_SA, four cryptographic algorithms are | |
2232 | negotiated: an encryption algorithm, an integrity protection | |
2233 | algorithm, a Diffie-Hellman group, and a pseudo-random function | |
2234 | (prf). The pseudo-random function is used for the construction of | |
2235 | keying material for all of the cryptographic algorithms used in both | |
d6bd078a MW |
2236 | |
2237 | ||
2238 | ||
2239 | Kaufman, et al. Expires August 28, 2008 [Page 40] | |
2240 | \f | |
2241 | Internet-Draft IKEv2bis February 2008 | |
2242 | ||
2243 | ||
f91513e3 MW |
2244 | the IKE_SA and the CHILD_SAs. |
2245 | ||
2246 | We assume that each encryption algorithm and integrity protection | |
2247 | algorithm uses a fixed-size key and that any randomly chosen value of | |
2248 | that fixed size can serve as an appropriate key. For algorithms that | |
2249 | accept a variable length key, a fixed key size MUST be specified as | |
d6bd078a MW |
2250 | part of the cryptographic transform negotiated (see Section 3.3.5 for |
2251 | the defintion of the Key Length transform attribute). For algorithms | |
2252 | for which not all values are valid keys (such as DES or 3DES with key | |
f91513e3 MW |
2253 | parity), the algorithm by which keys are derived from arbitrary |
2254 | values MUST be specified by the cryptographic transform. For | |
2255 | integrity protection functions based on Hashed Message Authentication | |
2256 | Code (HMAC), the fixed key size is the size of the output of the | |
d6bd078a | 2257 | underlying hash function. |
f91513e3 | 2258 | |
d6bd078a MW |
2259 | It is assumed that pseudo-random functions (PRFs) accept keys of any |
2260 | length, but have a preferred key size. The preferred key size is | |
2261 | used as the length of SK_d, SK_pi, and SK_pr (see Section 2.14). For | |
2262 | PRFs based on the HMAC construction, the preferred key size is equal | |
2263 | to the length of the output of the underlying hash function. Other | |
2264 | types of PRFs MUST specify their preferred key size. | |
f91513e3 MW |
2265 | |
2266 | Keying material will always be derived as the output of the | |
2267 | negotiated prf algorithm. Since the amount of keying material needed | |
2268 | may be greater than the size of the output of the prf algorithm, we | |
2269 | will use the prf iteratively. We will use the terminology prf+ to | |
2270 | describe the function that outputs a pseudo-random stream based on | |
2271 | the inputs to a prf as follows: (where | indicates concatenation) | |
2272 | ||
2273 | prf+ (K,S) = T1 | T2 | T3 | T4 | ... | |
2274 | ||
2275 | where: | |
2276 | T1 = prf (K, S | 0x01) | |
2277 | T2 = prf (K, T1 | S | 0x02) | |
2278 | T3 = prf (K, T2 | S | 0x03) | |
2279 | T4 = prf (K, T3 | S | 0x04) | |
2280 | ||
2281 | continuing as needed to compute all required keys. The keys are | |
2282 | taken from the output string without regard to boundaries (e.g., if | |
2283 | the required keys are a 256-bit Advanced Encryption Standard (AES) | |
2284 | key and a 160-bit HMAC key, and the prf function generates 160 bits, | |
2285 | the AES key will come from T1 and the beginning of T2, while the HMAC | |
2286 | key will come from the rest of T2 and the beginning of T3). | |
2287 | ||
2288 | The constant concatenated to the end of each string feeding the prf | |
2289 | is a single octet. prf+ in this document is not defined beyond 255 | |
2290 | times the size of the prf output. | |
2291 | ||
d6bd078a MW |
2292 | |
2293 | ||
2294 | ||
2295 | Kaufman, et al. Expires August 28, 2008 [Page 41] | |
2296 | \f | |
2297 | Internet-Draft IKEv2bis February 2008 | |
2298 | ||
2299 | ||
f91513e3 MW |
2300 | 2.14. Generating Keying Material for the IKE_SA |
2301 | ||
2302 | The shared keys are computed as follows. A quantity called SKEYSEED | |
2303 | is calculated from the nonces exchanged during the IKE_SA_INIT | |
2304 | exchange and the Diffie-Hellman shared secret established during that | |
2305 | exchange. SKEYSEED is used to calculate seven other secrets: SK_d | |
2306 | used for deriving new keys for the CHILD_SAs established with this | |
2307 | IKE_SA; SK_ai and SK_ar used as a key to the integrity protection | |
2308 | algorithm for authenticating the component messages of subsequent | |
2309 | exchanges; SK_ei and SK_er used for encrypting (and of course | |
2310 | decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are | |
d6bd078a MW |
2311 | used when generating an AUTH payload. The lengths of SK_d, SK_pi, |
2312 | and SK_pr are the preferred key length of the agreed-to PRF. | |
f91513e3 MW |
2313 | |
2314 | SKEYSEED and its derivatives are computed as follows: | |
2315 | ||
2316 | SKEYSEED = prf(Ni | Nr, g^ir) | |
2317 | ||
2318 | {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr } | |
2319 | = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) | |
2320 | ||
2321 | (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er, | |
2322 | SK_pi, and SK_pr are taken in order from the generated bits of the | |
f91513e3 MW |
2323 | prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman |
2324 | exchange. g^ir is represented as a string of octets in big endian | |
2325 | order padded with zeros if necessary to make it the length of the | |
d6bd078a MW |
2326 | modulus. Ni and Nr are the nonces, stripped of any headers. For |
2327 | historical backwards-compatibility reasons, there are two PRFs that | |
2328 | are treated specially in this calculation. If the negotiated PRF is | |
2329 | AES-XCBC-PRF-128 [RFC4434] or AES-CMAC-PRF-128 [RFC4615], only the | |
2330 | first 64 bits of Ni and the first 64 bits of Nr are used in the | |
2331 | calculation. | |
f91513e3 MW |
2332 | |
2333 | The two directions of traffic flow use different keys. The keys used | |
2334 | to protect messages from the original initiator are SK_ai and SK_ei. | |
2335 | The keys used to protect messages in the other direction are SK_ar | |
d6bd078a | 2336 | and SK_er. |
f91513e3 MW |
2337 | |
2338 | 2.15. Authentication of the IKE_SA | |
2339 | ||
2340 | When not using extensible authentication (see Section 2.16), the | |
2341 | peers are authenticated by having each sign (or MAC using a shared | |
2342 | secret as the key) a block of data. For the responder, the octets to | |
2343 | be signed start with the first octet of the first SPI in the header | |
d6bd078a MW |
2344 | of the second message (IKE_SA_INIT response) and end with the last |
2345 | octet of the last payload in the second message. Appended to this | |
2346 | (for purposes of computing the signature) are the initiator's nonce | |
2347 | Ni (just the value, not the payload containing it), and the value | |
2348 | ||
2349 | ||
2350 | ||
2351 | Kaufman, et al. Expires August 28, 2008 [Page 42] | |
2352 | \f | |
2353 | Internet-Draft IKEv2bis February 2008 | |
2354 | ||
2355 | ||
2356 | prf(SK_pr,IDr') where IDr' is the responder's ID payload excluding | |
2357 | the fixed header. Note that neither the nonce Ni nor the value | |
2358 | prf(SK_pr,IDr') are transmitted. Similarly, the initiator signs the | |
2359 | first message (IKE_SA_INIT request), starting with the first octet of | |
2360 | the first SPI in the header and ending with the last octet of the | |
2361 | last payload. Appended to this (for purposes of computing the | |
2362 | signature) are the responder's nonce Nr, and the value | |
f91513e3 MW |
2363 | prf(SK_pi,IDi'). In the above calculation, IDi' and IDr' are the |
2364 | entire ID payloads excluding the fixed header. It is critical to the | |
2365 | security of the exchange that each side sign the other side's nonce. | |
2366 | ||
2367 | {{ Clarif-3.1 }} | |
2368 | ||
2369 | The initiator's signed octets can be described as: | |
2370 | ||
2371 | InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI | |
2372 | GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR | |
2373 | RealIKEHDR = SPIi | SPIr | . . . | Length | |
2374 | RealMessage1 = RealIKEHDR | RestOfMessage1 | |
2375 | NonceRPayload = PayloadHeader | NonceRData | |
2376 | InitiatorIDPayload = PayloadHeader | RestOfIDPayload | |
2377 | RestOfInitIDPayload = IDType | RESERVED | InitIDData | |
2378 | MACedIDForI = prf(SK_pi, RestOfInitIDPayload) | |
2379 | ||
f91513e3 MW |
2380 | The responder's signed octets can be described as: |
2381 | ||
2382 | ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR | |
2383 | GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR | |
2384 | RealIKEHDR = SPIi | SPIr | . . . | Length | |
2385 | RealMessage2 = RealIKEHDR | RestOfMessage2 | |
2386 | NonceIPayload = PayloadHeader | NonceIData | |
2387 | ResponderIDPayload = PayloadHeader | RestOfIDPayload | |
2388 | RestOfRespIDPayload = IDType | RESERVED | InitIDData | |
2389 | MACedIDForR = prf(SK_pr, RestOfRespIDPayload) | |
2390 | ||
2391 | Note that all of the payloads are included under the signature, | |
2392 | including any payload types not defined in this document. If the | |
2393 | first message of the exchange is sent twice (the second time with a | |
2394 | responder cookie and/or a different Diffie-Hellman group), it is the | |
2395 | second version of the message that is signed. | |
2396 | ||
2397 | Optionally, messages 3 and 4 MAY include a certificate, or | |
2398 | certificate chain providing evidence that the key used to compute a | |
2399 | digital signature belongs to the name in the ID payload. The | |
2400 | signature or MAC will be computed using algorithms dictated by the | |
2401 | type of key used by the signer, and specified by the Auth Method | |
2402 | field in the Authentication payload. There is no requirement that | |
2403 | the initiator and responder sign with the same cryptographic | |
d6bd078a MW |
2404 | |
2405 | ||
2406 | ||
2407 | Kaufman, et al. Expires August 28, 2008 [Page 43] | |
2408 | \f | |
2409 | Internet-Draft IKEv2bis February 2008 | |
2410 | ||
2411 | ||
f91513e3 MW |
2412 | algorithms. The choice of cryptographic algorithms depends on the |
2413 | type of key each has. In particular, the initiator may be using a | |
2414 | shared key while the responder may have a public signature key and | |
2415 | certificate. It will commonly be the case (but it is not required) | |
2416 | that if a shared secret is used for authentication that the same key | |
d6bd078a MW |
2417 | is used in both directions. |
2418 | ||
2419 | Note that it is a common but typically insecure practice to have a | |
2420 | shared key derived solely from a user-chosen password without | |
2421 | incorporating another source of randomness. This is typically | |
2422 | insecure because user-chosen passwords are unlikely to have | |
2423 | sufficient unpredictability to resist dictionary attacks and these | |
2424 | attacks are not prevented in this authentication method. | |
f91513e3 MW |
2425 | (Applications using password-based authentication for bootstrapping |
2426 | and IKE_SA should use the authentication method in Section 2.16, | |
2427 | which is designed to prevent off-line dictionary attacks.) {{ Demoted | |
2428 | the SHOULD }} The pre-shared key needs to contain as much | |
2429 | unpredictability as the strongest key being negotiated. In the case | |
2430 | of a pre-shared key, the AUTH value is computed as: | |
2431 | ||
2432 | AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), <msg octets>) | |
2433 | ||
2434 | where the string "Key Pad for IKEv2" is 17 ASCII characters without | |
2435 | null termination. The shared secret can be variable length. The pad | |
2436 | string is added so that if the shared secret is derived from a | |
f91513e3 MW |
2437 | password, the IKE implementation need not store the password in |
2438 | cleartext, but rather can store the value prf(Shared Secret,"Key Pad | |
2439 | for IKEv2"), which could not be used as a password equivalent for | |
2440 | protocols other than IKEv2. As noted above, deriving the shared | |
2441 | secret from a password is not secure. This construction is used | |
2442 | because it is anticipated that people will do it anyway. The | |
2443 | management interface by which the Shared Secret is provided MUST | |
2444 | accept ASCII strings of at least 64 octets and MUST NOT add a null | |
2445 | terminator before using them as shared secrets. It MUST also accept | |
2446 | a hex encoding of the Shared Secret. The management interface MAY | |
2447 | accept other encodings if the algorithm for translating the encoding | |
2448 | to a binary string is specified. | |
2449 | ||
f91513e3 MW |
2450 | 2.16. Extensible Authentication Protocol Methods |
2451 | ||
2452 | In addition to authentication using public key signatures and shared | |
2453 | secrets, IKE supports authentication using methods defined in RFC | |
2454 | 3748 [EAP]. Typically, these methods are asymmetric (designed for a | |
2455 | user authenticating to a server), and they may not be mutual. {{ In | |
2456 | the next sentence, changed "public key signature based" to "strong" | |
2457 | }} For this reason, these protocols are typically used to | |
2458 | authenticate the initiator to the responder and MUST be used in | |
2459 | conjunction with a strong authentication of the responder to the | |
d6bd078a MW |
2460 | |
2461 | ||
2462 | ||
2463 | Kaufman, et al. Expires August 28, 2008 [Page 44] | |
2464 | \f | |
2465 | Internet-Draft IKEv2bis February 2008 | |
2466 | ||
2467 | ||
f91513e3 MW |
2468 | initiator. These methods are often associated with mechanisms |
2469 | referred to as "Legacy Authentication" mechanisms. | |
2470 | ||
2471 | While this memo references [EAP] with the intent that new methods can | |
2472 | be added in the future without updating this specification, some | |
2473 | simpler variations are documented here and in Section 3.16. [EAP] | |
2474 | defines an authentication protocol requiring a variable number of | |
2475 | messages. Extensible Authentication is implemented in IKE as | |
2476 | additional IKE_AUTH exchanges that MUST be completed in order to | |
2477 | initialize the IKE_SA. | |
2478 | ||
2479 | An initiator indicates a desire to use extensible authentication by | |
2480 | leaving out the AUTH payload from message 3. By including an IDi | |
f91513e3 MW |
2481 | payload but not an AUTH payload, the initiator has declared an |
2482 | identity but has not proven it. If the responder is willing to use | |
2483 | an extensible authentication method, it will place an Extensible | |
2484 | Authentication Protocol (EAP) payload in message 4 and defer sending | |
2485 | SAr2, TSi, and TSr until initiator authentication is complete in a | |
2486 | subsequent IKE_AUTH exchange. In the case of a minimal extensible | |
2487 | authentication, the initial SA establishment will appear as follows: | |
2488 | ||
2489 | Initiator Responder | |
2490 | ------------------------------------------------------------------- | |
2491 | HDR, SAi1, KEi, Ni --> | |
2492 | <-- HDR, SAr1, KEr, Nr, [CERTREQ] | |
2493 | HDR, SK {IDi, [CERTREQ,] | |
2494 | [IDr,] SAi2, | |
2495 | TSi, TSr} --> | |
2496 | <-- HDR, SK {IDr, [CERT,] AUTH, | |
2497 | EAP } | |
2498 | HDR, SK {EAP} --> | |
2499 | <-- HDR, SK {EAP (success)} | |
2500 | HDR, SK {AUTH} --> | |
2501 | <-- HDR, SK {AUTH, SAr2, TSi, TSr } | |
2502 | ||
2503 | {{ Clarif-3.10 }} As described in Section 2.2, when EAP is used, each | |
2504 | pair of IKE_SA initial setup messages will have their message numbers | |
2505 | incremented; the first pair of AUTH messages will have an ID of 1, | |
2506 | the second will be 2, and so on. | |
2507 | ||
2508 | For EAP methods that create a shared key as a side effect of | |
2509 | authentication, that shared key MUST be used by both the initiator | |
2510 | and responder to generate AUTH payloads in messages 7 and 8 using the | |
2511 | syntax for shared secrets specified in Section 2.15. The shared key | |
2512 | from EAP is the field from the EAP specification named MSK. The | |
2513 | shared key generated during an IKE exchange MUST NOT be used for any | |
2514 | other purpose. | |
2515 | ||
d6bd078a MW |
2516 | |
2517 | ||
2518 | ||
2519 | Kaufman, et al. Expires August 28, 2008 [Page 45] | |
2520 | \f | |
2521 | Internet-Draft IKEv2bis February 2008 | |
2522 | ||
2523 | ||
f91513e3 MW |
2524 | EAP methods that do not establish a shared key SHOULD NOT be used, as |
2525 | they are subject to a number of man-in-the-middle attacks [EAPMITM] | |
2526 | if these EAP methods are used in other protocols that do not use a | |
2527 | server-authenticated tunnel. Please see the Security Considerations | |
2528 | section for more details. If EAP methods that do not generate a | |
2529 | shared key are used, the AUTH payloads in messages 7 and 8 MUST be | |
2530 | generated using SK_pi and SK_pr, respectively. | |
2531 | ||
2532 | {{ Demoted the SHOULD }} The initiator of an IKE_SA using EAP needs | |
2533 | to be capable of extending the initial protocol exchange to at least | |
2534 | ten IKE_AUTH exchanges in the event the responder sends notification | |
2535 | messages and/or retries the authentication prompt. Once the protocol | |
2536 | exchange defined by the chosen EAP authentication method has | |
f91513e3 MW |
2537 | successfully terminated, the responder MUST send an EAP payload |
2538 | containing the Success message. Similarly, if the authentication | |
2539 | method has failed, the responder MUST send an EAP payload containing | |
2540 | the Failure message. The responder MAY at any time terminate the IKE | |
2541 | exchange by sending an EAP payload containing the Failure message. | |
2542 | ||
2543 | Following such an extended exchange, the EAP AUTH payloads MUST be | |
2544 | included in the two messages following the one containing the EAP | |
2545 | Success message. | |
2546 | ||
2547 | {{ Clarif-3.5 }} When the initiator authentication uses EAP, it is | |
2548 | possible that the contents of the IDi payload is used only for AAA | |
2549 | routing purposes and selecting which EAP method to use. This value | |
2550 | may be different from the identity authenticated by the EAP method. | |
2551 | It is important that policy lookups and access control decisions use | |
2552 | the actual authenticated identity. Often the EAP server is | |
2553 | implemented in a separate AAA server that communicates with the IKEv2 | |
2554 | responder. In this case, the authenticated identity has to be sent | |
2555 | from the AAA server to the IKEv2 responder. | |
2556 | ||
f91513e3 MW |
2557 | 2.17. Generating Keying Material for CHILD_SAs |
2558 | ||
2559 | A single CHILD_SA is created by the IKE_AUTH exchange, and additional | |
2560 | CHILD_SAs can optionally be created in CREATE_CHILD_SA exchanges. | |
2561 | Keying material for them is generated as follows: | |
2562 | ||
2563 | KEYMAT = prf+(SK_d, Ni | Nr) | |
2564 | ||
2565 | Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this | |
2566 | request is the first CHILD_SA created or the fresh Ni and Nr from the | |
2567 | CREATE_CHILD_SA exchange if this is a subsequent creation. | |
2568 | ||
2569 | For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman | |
2570 | exchange, the keying material is defined as: | |
2571 | ||
f91513e3 | 2572 | |
f91513e3 | 2573 | |
f91513e3 | 2574 | |
d6bd078a MW |
2575 | Kaufman, et al. Expires August 28, 2008 [Page 46] |
2576 | \f | |
2577 | Internet-Draft IKEv2bis February 2008 | |
f91513e3 MW |
2578 | |
2579 | ||
d6bd078a | 2580 | KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) |
f91513e3 | 2581 | |
d6bd078a MW |
2582 | where g^ir (new) is the shared secret from the ephemeral Diffie- |
2583 | Hellman exchange of this CREATE_CHILD_SA exchange (represented as an | |
2584 | octet string in big endian order padded with zeros in the high-order | |
2585 | bits if necessary to make it the length of the modulus). | |
f91513e3 | 2586 | |
d6bd078a MW |
2587 | For ESP and AH, a single CHILD_SA negotiation results in two security |
2588 | associations (one in each direction). Keying material MUST be taken | |
2589 | from the expanded KEYMAT in the following order: | |
f91513e3 | 2590 | |
d6bd078a MW |
2591 | o The encryption key (if any) for the SA carrying data from the |
2592 | initiator to the responder. | |
f91513e3 | 2593 | |
d6bd078a MW |
2594 | o The authentication key (if any) for the SA carrying data from the |
2595 | initiator to the responder. | |
f91513e3 | 2596 | |
d6bd078a MW |
2597 | o The encryption key (if any) for the SA carrying data from the |
2598 | responder to the initiator. | |
f91513e3 | 2599 | |
d6bd078a MW |
2600 | o The authentication key (if any) for the SA carrying data from the |
2601 | responder to the initiator. | |
f91513e3 MW |
2602 | |
2603 | Each cryptographic algorithm takes a fixed number of bits of keying | |
d6bd078a MW |
2604 | material specified as part of the algorithm, or negotiated in SA |
2605 | payloads (see Section 2.13 for description of key lengths, and | |
2606 | Section 3.3.5 for the definition of the Key Length transform | |
2607 | attribute). | |
f91513e3 MW |
2608 | |
2609 | 2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA Exchange | |
2610 | ||
2611 | The CREATE_CHILD_SA exchange can be used to rekey an existing IKE_SA | |
2612 | (see Section 2.8). {{ Clarif-5.3 }} New initiator and responder SPIs | |
2613 | are supplied in the SPI fields in the Proposal structures inside the | |
2614 | Security Association (SA) payloads (not the SPI fields in the IKE | |
2615 | header). The TS payloads are omitted when rekeying an IKE_SA. | |
2616 | SKEYSEED for the new IKE_SA is computed using SK_d from the existing | |
2617 | IKE_SA as follows: | |
2618 | ||
2619 | SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr) | |
2620 | ||
2621 | where g^ir (new) is the shared secret from the ephemeral Diffie- | |
2622 | Hellman exchange of this CREATE_CHILD_SA exchange (represented as an | |
2623 | octet string in big endian order padded with zeros if necessary to | |
2624 | make it the length of the modulus) and Ni and Nr are the two nonces | |
2625 | stripped of any headers. | |
2626 | ||
2627 | {{ Clarif-5.5 }} The old and new IKE_SA may have selected a different | |
f91513e3 | 2628 | |
f91513e3 | 2629 | |
f91513e3 | 2630 | |
d6bd078a MW |
2631 | Kaufman, et al. Expires August 28, 2008 [Page 47] |
2632 | \f | |
2633 | Internet-Draft IKEv2bis February 2008 | |
f91513e3 MW |
2634 | |
2635 | ||
d6bd078a MW |
2636 | PRF. Because the rekeying exchange belongs to the old IKE_SA, it is |
2637 | the old IKE_SA's PRF that is used. | |
2638 | ||
2639 | {{ Clarif-5.12}} The main purpose of rekeying the IKE_SA is to ensure | |
2640 | that the compromise of old keying material does not provide | |
2641 | information about the current keys, or vice versa. Therefore, | |
2642 | implementations SHOULD perform a new Diffie-Hellman exchange when | |
2643 | rekeying the IKE_SA. In other words, an initiator SHOULD NOT propose | |
2644 | the value "NONE" for the D-H transform, and a responder SHOULD NOT | |
2645 | accept such a proposal. This means that a succesful exchange | |
2646 | rekeying the IKE_SA always includes the KEi/KEr payloads. | |
f91513e3 | 2647 | |
d6bd078a | 2648 | The new IKE_SA MUST reset its message counters to 0. |
f91513e3 | 2649 | |
d6bd078a | 2650 | SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as |
f91513e3 MW |
2651 | specified in Section 2.14. |
2652 | ||
2653 | 2.19. Requesting an Internal Address on a Remote Network | |
2654 | ||
2655 | Most commonly occurring in the endpoint-to-security-gateway scenario, | |
2656 | an endpoint may need an IP address in the network protected by the | |
2657 | security gateway and may need to have that address dynamically | |
2658 | assigned. A request for such a temporary address can be included in | |
2659 | any request to create a CHILD_SA (including the implicit request in | |
2660 | message 3) by including a CP payload. | |
2661 | ||
2662 | This function provides address allocation to an IPsec Remote Access | |
2663 | Client (IRAC) trying to tunnel into a network protected by an IPsec | |
2664 | Remote Access Server (IRAS). Since the IKE_AUTH exchange creates an | |
2665 | IKE_SA and a CHILD_SA, the IRAC MUST request the IRAS-controlled | |
2666 | address (and optionally other information concerning the protected | |
2667 | network) in the IKE_AUTH exchange. The IRAS may procure an address | |
2668 | for the IRAC from any number of sources such as a DHCP/BOOTP server | |
2669 | or its own address pool. | |
2670 | ||
2671 | Initiator Responder | |
2672 | ------------------------------------------------------------------- | |
2673 | HDR, SK {IDi, [CERT,] | |
2674 | [CERTREQ,] [IDr,] AUTH, | |
2675 | CP(CFG_REQUEST), SAi2, | |
2676 | TSi, TSr} --> | |
2677 | <-- HDR, SK {IDr, [CERT,] AUTH, | |
2678 | CP(CFG_REPLY), SAr2, | |
2679 | TSi, TSr} | |
2680 | ||
2681 | In all cases, the CP payload MUST be inserted before the SA payload. | |
2682 | In variations of the protocol where there are multiple IKE_AUTH | |
2683 | exchanges, the CP payloads MUST be inserted in the messages | |
d6bd078a MW |
2684 | |
2685 | ||
2686 | ||
2687 | Kaufman, et al. Expires August 28, 2008 [Page 48] | |
2688 | \f | |
2689 | Internet-Draft IKEv2bis February 2008 | |
2690 | ||
2691 | ||
f91513e3 MW |
2692 | containing the SA payloads. |
2693 | ||
2694 | CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute | |
2695 | (either IPv4 or IPv6) but MAY contain any number of additional | |
2696 | attributes the initiator wants returned in the response. | |
2697 | ||
d6bd078a MW |
2698 | {{ 3.10.1-37 }} The FAILED_CP_REQUIRED notification is sent by |
2699 | responder in the case where CP(CFG_REQUEST) was expected but not | |
2700 | received, and so is a conflict with locally configured policy. There | |
2701 | is no associated data. | |
2702 | ||
f91513e3 MW |
2703 | For example, message from initiator to responder: |
2704 | ||
2705 | CP(CFG_REQUEST)= | |
2706 | INTERNAL_ADDRESS() | |
2707 | TSi = (0, 0-65535,0.0.0.0-255.255.255.255) | |
2708 | TSr = (0, 0-65535,0.0.0.0-255.255.255.255) | |
2709 | ||
2710 | NOTE: Traffic Selectors contain (protocol, port range, address | |
2711 | range). | |
2712 | ||
f91513e3 MW |
2713 | Message from responder to initiator: |
2714 | ||
2715 | CP(CFG_REPLY)= | |
2716 | INTERNAL_ADDRESS(192.0.2.202) | |
2717 | INTERNAL_NETMASK(255.255.255.0) | |
2718 | INTERNAL_SUBNET(192.0.2.0/255.255.255.0) | |
2719 | TSi = (0, 0-65535,192.0.2.202-192.0.2.202) | |
2720 | TSr = (0, 0-65535,192.0.2.0-192.0.2.255) | |
2721 | ||
2722 | All returned values will be implementation dependent. As can be seen | |
2723 | in the above example, the IRAS MAY also send other attributes that | |
2724 | were not included in CP(CFG_REQUEST) and MAY ignore the non- | |
2725 | mandatory attributes that it does not support. | |
2726 | ||
2727 | The responder MUST NOT send a CFG_REPLY without having first received | |
2728 | a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS | |
2729 | to perform an unnecessary configuration lookup if the IRAC cannot | |
2730 | process the REPLY. In the case where the IRAS's configuration | |
2731 | requires that CP be used for a given identity IDi, but IRAC has | |
2732 | failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and | |
2733 | terminate the IKE exchange with a FAILED_CP_REQUIRED error. | |
2734 | ||
d6bd078a MW |
2735 | 2.19.1. Configuration Payloads |
2736 | ||
2737 | Editor's note: some of this sub-section is redundant and will go away | |
2738 | in the next version of the document. | |
2739 | ||
2740 | ||
2741 | ||
2742 | ||
2743 | Kaufman, et al. Expires August 28, 2008 [Page 49] | |
2744 | \f | |
2745 | Internet-Draft IKEv2bis February 2008 | |
2746 | ||
2747 | ||
2748 | In support of the scenario described in Section 1.1.3, an initiator | |
2749 | may request that the responder assign an IP address and tell the | |
2750 | initiator what it is. {{ Clarif-6.1 }} That request is done using | |
2751 | configuration payloads, not traffic selectors. An address in a TSi | |
2752 | payload in a response does not mean that the responder has assigned | |
2753 | that address to the initiator: it only means that if packets matching | |
2754 | these traffic selectors are sent by the initiator, IPsec processing | |
2755 | can be performed as agreed for this SA. | |
2756 | ||
2757 | Configuration payloads are of type CFG_REQUEST/CFG_REPLY or CFG_SET/ | |
2758 | CFG_ACK (see CFG Type in the payload description below). CFG_REQUEST | |
2759 | and CFG_SET payloads may optionally be added to any IKE request. The | |
2760 | IKE response MUST include either a corresponding CFG_REPLY or CFG_ACK | |
2761 | or a Notify payload with an error type indicating why the request | |
2762 | could not be honored. An exception is that a minimal implementation | |
2763 | MAY ignore all CFG_REQUEST and CFG_SET payloads, so a response | |
2764 | message without a corresponding CFG_REPLY or CFG_ACK MUST be accepted | |
2765 | as an indication that the request was not supported. | |
2766 | ||
2767 | "CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information | |
2768 | from its peer. If an attribute in the CFG_REQUEST Configuration | |
2769 | Payload is not zero-length, it is taken as a suggestion for that | |
2770 | attribute. The CFG_REPLY Configuration Payload MAY return that | |
2771 | value, or a new one. It MAY also add new attributes and not include | |
2772 | some requested ones. Requestors MUST ignore returned attributes that | |
2773 | they do not recognize. | |
2774 | ||
2775 | Some attributes MAY be multi-valued, in which case multiple attribute | |
2776 | values of the same type are sent and/or returned. Generally, all | |
2777 | values of an attribute are returned when the attribute is requested. | |
2778 | For some attributes (in this version of the specification only | |
2779 | internal addresses), multiple requests indicates a request that | |
2780 | multiple values be assigned. For these attributes, the number of | |
2781 | values returned SHOULD NOT exceed the number requested. | |
2782 | ||
2783 | If the data type requested in a CFG_REQUEST is not recognized or not | |
2784 | supported, the responder MUST NOT return an error type but rather | |
2785 | MUST either send a CFG_REPLY that MAY be empty or a reply not | |
2786 | containing a CFG_REPLY payload at all. Error returns are reserved | |
2787 | for cases where the request is recognized but cannot be performed as | |
2788 | requested or the request is badly formatted. | |
2789 | ||
2790 | "CFG_SET/CFG_ACK" allows an IKE endpoint to push configuration data | |
2791 | to its peer. In this case, the CFG_SET Configuration Payload | |
2792 | contains attributes the initiator wants its peer to alter. The | |
2793 | responder MUST return a Configuration Payload if it accepted any of | |
2794 | the configuration data and it MUST contain the attributes that the | |
2795 | responder accepted with zero-length data. Those attributes that it | |
2796 | ||
2797 | ||
2798 | ||
2799 | Kaufman, et al. Expires August 28, 2008 [Page 50] | |
2800 | \f | |
2801 | Internet-Draft IKEv2bis February 2008 | |
2802 | ||
2803 | ||
2804 | did not accept MUST NOT be in the CFG_ACK Configuration Payload. If | |
2805 | no attributes were accepted, the responder MUST return either an | |
2806 | empty CFG_ACK payload or a response message without a CFG_ACK | |
2807 | payload. There are currently no defined uses for the CFG_SET/CFG_ACK | |
2808 | exchange, though they may be used in connection with extensions based | |
2809 | on Vendor IDs. An minimal implementation of this specification MAY | |
2810 | ignore CFG_SET payloads. | |
2811 | ||
2812 | {{ Demoted the SHOULD }} Extensions via the CP payload should not be | |
2813 | used for general purpose management. Its main intent is to provide a | |
2814 | bootstrap mechanism to exchange information within IPsec from IRAS to | |
2815 | IRAC. While it MAY be useful to use such a method to exchange | |
2816 | information between some Security Gateways (SGW) or small networks, | |
2817 | existing management protocols such as DHCP [DHCP], RADIUS [RADIUS], | |
2818 | SNMP, or LDAP [LDAP] should be preferred for enterprise management as | |
2819 | well as subsequent information exchanges. | |
2820 | ||
f91513e3 MW |
2821 | 2.20. Requesting the Peer's Version |
2822 | ||
2823 | An IKE peer wishing to inquire about the other peer's IKE software | |
2824 | version information MAY use the method below. This is an example of | |
2825 | a configuration request within an INFORMATIONAL exchange, after the | |
2826 | IKE_SA and first CHILD_SA have been created. | |
2827 | ||
2828 | An IKE implementation MAY decline to give out version information | |
2829 | prior to authentication or even after authentication to prevent | |
2830 | trolling in case some implementation is known to have some security | |
2831 | weakness. In that case, it MUST either return an empty string or no | |
2832 | CP payload if CP is not supported. | |
2833 | ||
2834 | Initiator Responder | |
2835 | ------------------------------------------------------------------- | |
2836 | HDR, SK{CP(CFG_REQUEST)} --> | |
2837 | <-- HDR, SK{CP(CFG_REPLY)} | |
2838 | ||
2839 | CP(CFG_REQUEST)= | |
2840 | APPLICATION_VERSION("") | |
2841 | ||
2842 | CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar | |
2843 | Inc.") | |
2844 | ||
f91513e3 MW |
2845 | 2.21. Error Handling |
2846 | ||
2847 | There are many kinds of errors that can occur during IKE processing. | |
2848 | If a request is received that is badly formatted or unacceptable for | |
2849 | reasons of policy (e.g., no matching cryptographic algorithms), the | |
2850 | response MUST contain a Notify payload indicating the error. If an | |
2851 | error occurs outside the context of an IKE request (e.g., the node is | |
d6bd078a MW |
2852 | |
2853 | ||
2854 | ||
2855 | Kaufman, et al. Expires August 28, 2008 [Page 51] | |
2856 | \f | |
2857 | Internet-Draft IKEv2bis February 2008 | |
2858 | ||
2859 | ||
f91513e3 MW |
2860 | getting ESP messages on a nonexistent SPI), the node SHOULD initiate |
2861 | an INFORMATIONAL exchange with a Notify payload describing the | |
2862 | problem. | |
2863 | ||
2864 | Errors that occur before a cryptographically protected IKE_SA is | |
2865 | established must be handled very carefully. There is a trade-off | |
2866 | between wanting to be helpful in diagnosing a problem and responding | |
2867 | to it and wanting to avoid being a dupe in a denial of service attack | |
2868 | based on forged messages. | |
2869 | ||
2870 | If a node receives a message on UDP port 500 or 4500 outside the | |
2871 | context of an IKE_SA known to it (and not a request to start one), it | |
2872 | may be the result of a recent crash of the node. If the message is | |
2873 | marked as a response, the node MAY audit the suspicious event but | |
2874 | MUST NOT respond. If the message is marked as a request, the node | |
2875 | MAY audit the suspicious event and MAY send a response. If a | |
2876 | response is sent, the response MUST be sent to the IP address and | |
2877 | port from whence it came with the same IKE SPIs and the Message ID | |
2878 | copied. The response MUST NOT be cryptographically protected and | |
d6bd078a MW |
2879 | MUST contain a Notify payload indicating INVALID_IKE_SPI. {{ 3.10.1-4 |
2880 | }} The INVALID_IKE_SPI notification indicates an IKE message was | |
2881 | received with an unrecognized destination SPI; this usually indicates | |
2882 | that the recipient has rebooted and forgotten the existence of an | |
2883 | IKE_SA. | |
f91513e3 MW |
2884 | |
2885 | A node receiving such an unprotected Notify payload MUST NOT respond | |
2886 | and MUST NOT change the state of any existing SAs. The message might | |
2887 | be a forgery or might be a response the genuine correspondent was | |
2888 | tricked into sending. {{ Demoted two SHOULDs }} A node should treat | |
2889 | such a message (and also a network message like ICMP destination | |
2890 | unreachable) as a hint that there might be problems with SAs to that | |
2891 | IP address and should initiate a liveness test for any such IKE_SA. | |
2892 | An implementation SHOULD limit the frequency of such tests to avoid | |
2893 | being tricked into participating in a denial of service attack. | |
2894 | ||
2895 | A node receiving a suspicious message from an IP address with which | |
2896 | it has an IKE_SA MAY send an IKE Notify payload in an IKE | |
2897 | INFORMATIONAL exchange over that SA. {{ Demoted the SHOULD }} The | |
2898 | recipient MUST NOT change the state of any SAs as a result, but may | |
2899 | wish to audit the event to aid in diagnosing malfunctions. A node | |
2900 | MUST limit the rate at which it will send messages in response to | |
2901 | unprotected messages. | |
2902 | ||
d6bd078a | 2903 | 2.22. IPComp |
f91513e3 | 2904 | |
d6bd078a MW |
2905 | Use of IP compression [IPCOMP] can be negotiated as part of the setup |
2906 | of a CHILD_SA. While IP compression involves an extra header in each | |
2907 | packet and a compression parameter index (CPI), the virtual | |
f91513e3 MW |
2908 | |
2909 | ||
2910 | ||
d6bd078a | 2911 | Kaufman, et al. Expires August 28, 2008 [Page 52] |
f91513e3 | 2912 | \f |
d6bd078a | 2913 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
2914 | |
2915 | ||
f91513e3 MW |
2916 | "compression association" has no life outside the ESP or AH SA that |
2917 | contains it. Compression associations disappear when the | |
2918 | corresponding ESP or AH SA goes away. It is not explicitly mentioned | |
2919 | in any DELETE payload. | |
2920 | ||
2921 | Negotiation of IP compression is separate from the negotiation of | |
2922 | cryptographic parameters associated with a CHILD_SA. A node | |
2923 | requesting a CHILD_SA MAY advertise its support for one or more | |
2924 | compression algorithms through one or more Notify payloads of type | |
d6bd078a MW |
2925 | IPCOMP_SUPPORTED. This notification may be included only in a |
2926 | message containing an SA payload negotiating a CHILD_SA and indicates | |
2927 | a willingness by its sender to use IPComp on this SA. The response | |
2928 | MAY indicate acceptance of a single compression algorithm with a | |
2929 | Notify payload of type IPCOMP_SUPPORTED. These payloads MUST NOT | |
2930 | occur in messages that do not contain SA payloads. | |
2931 | ||
2932 | {{ 3.10.1-16387 }}The data associated with this notification includes | |
2933 | a two-octet IPComp CPI followed by a one-octet transform ID | |
2934 | optionally followed by attributes whose length and format are defined | |
2935 | by that transform ID. A message proposing an SA may contain multiple | |
2936 | IPCOMP_SUPPORTED notifications to indicate multiple supported | |
2937 | algorithms. A message accepting an SA may contain at most one. | |
2938 | ||
2939 | The transform IDs currently defined are: | |
2940 | ||
2941 | Name Number Defined In | |
2942 | ------------------------------------- | |
2943 | RESERVED 0 | |
2944 | IPCOMP_OUI 1 | |
2945 | IPCOMP_DEFLATE 2 RFC 2394 | |
2946 | IPCOMP_LZS 3 RFC 2395 | |
2947 | IPCOMP_LZJH 4 RFC 3051 | |
2948 | RESERVED TO IANA 5-240 | |
2949 | PRIVATE USE 241-255 | |
f91513e3 MW |
2950 | |
2951 | Although there has been discussion of allowing multiple compression | |
2952 | algorithms to be accepted and to have different compression | |
2953 | algorithms available for the two directions of a CHILD_SA, | |
2954 | implementations of this specification MUST NOT accept an IPComp | |
2955 | algorithm that was not proposed, MUST NOT accept more than one, and | |
2956 | MUST NOT compress using an algorithm other than one proposed and | |
2957 | accepted in the setup of the CHILD_SA. | |
2958 | ||
2959 | A side effect of separating the negotiation of IPComp from | |
2960 | cryptographic parameters is that it is not possible to propose | |
2961 | multiple cryptographic suites and propose IP compression with some of | |
2962 | them but not others. | |
2963 | ||
d6bd078a MW |
2964 | |
2965 | ||
2966 | ||
2967 | Kaufman, et al. Expires August 28, 2008 [Page 53] | |
2968 | \f | |
2969 | Internet-Draft IKEv2bis February 2008 | |
2970 | ||
2971 | ||
f91513e3 MW |
2972 | 2.23. NAT Traversal |
2973 | ||
2974 | Network Address Translation (NAT) gateways are a controversial | |
2975 | subject. This section briefly describes what they are and how they | |
2976 | are likely to act on IKE traffic. Many people believe that NATs are | |
2977 | evil and that we should not design our protocols so as to make them | |
2978 | work better. IKEv2 does specify some unintuitive processing rules in | |
2979 | order that NATs are more likely to work. | |
2980 | ||
2981 | NATs exist primarily because of the shortage of IPv4 addresses, | |
2982 | though there are other rationales. IP nodes that are "behind" a NAT | |
2983 | have IP addresses that are not globally unique, but rather are | |
2984 | assigned from some space that is unique within the network behind the | |
2985 | NAT but that are likely to be reused by nodes behind other NATs. | |
2986 | Generally, nodes behind NATs can communicate with other nodes behind | |
2987 | the same NAT and with nodes with globally unique addresses, but not | |
f91513e3 MW |
2988 | with nodes behind other NATs. There are exceptions to that rule. |
2989 | When those nodes make connections to nodes on the real Internet, the | |
2990 | NAT gateway "translates" the IP source address to an address that | |
2991 | will be routed back to the gateway. Messages to the gateway from the | |
2992 | Internet have their destination addresses "translated" to the | |
2993 | internal address that will route the packet to the correct endnode. | |
2994 | ||
2995 | NATs are designed to be "transparent" to endnodes. Neither software | |
2996 | on the node behind the NAT nor the node on the Internet requires | |
2997 | modification to communicate through the NAT. Achieving this | |
2998 | transparency is more difficult with some protocols than with others. | |
2999 | Protocols that include IP addresses of the endpoints within the | |
3000 | payloads of the packet will fail unless the NAT gateway understands | |
3001 | the protocol and modifies the internal references as well as those in | |
3002 | the headers. Such knowledge is inherently unreliable, is a network | |
3003 | layer violation, and often results in subtle problems. | |
3004 | ||
3005 | Opening an IPsec connection through a NAT introduces special | |
3006 | problems. If the connection runs in transport mode, changing the IP | |
3007 | addresses on packets will cause the checksums to fail and the NAT | |
3008 | cannot correct the checksums because they are cryptographically | |
3009 | protected. Even in tunnel mode, there are routing problems because | |
3010 | transparently translating the addresses of AH and ESP packets | |
3011 | requires special logic in the NAT and that logic is heuristic and | |
3012 | unreliable in nature. For that reason, IKEv2 can negotiate UDP | |
3013 | encapsulation of IKE and ESP packets. This encoding is slightly less | |
3014 | efficient but is easier for NATs to process. In addition, firewalls | |
3015 | may be configured to pass IPsec traffic over UDP but not ESP/AH or | |
3016 | vice versa. | |
3017 | ||
3018 | It is a common practice of NATs to translate TCP and UDP port numbers | |
3019 | as well as addresses and use the port numbers of inbound packets to | |
d6bd078a MW |
3020 | |
3021 | ||
3022 | ||
3023 | Kaufman, et al. Expires August 28, 2008 [Page 54] | |
3024 | \f | |
3025 | Internet-Draft IKEv2bis February 2008 | |
3026 | ||
3027 | ||
f91513e3 MW |
3028 | decide which internal node should get a given packet. For this |
3029 | reason, even though IKE packets MUST be sent from and to UDP port | |
3030 | 500, they MUST be accepted coming from any port and responses MUST be | |
3031 | sent to the port from whence they came. This is because the ports | |
3032 | may be modified as the packets pass through NATs. Similarly, IP | |
3033 | addresses of the IKE endpoints are generally not included in the IKE | |
3034 | payloads because the payloads are cryptographically protected and | |
3035 | could not be transparently modified by NATs. | |
3036 | ||
3037 | Port 4500 is reserved for UDP-encapsulated ESP and IKE. When working | |
3038 | through a NAT, it is generally better to pass IKE packets over port | |
3039 | 4500 because some older NATs handle IKE traffic on port 500 cleverly | |
3040 | in an attempt to transparently establish IPsec connections between | |
3041 | endpoints that don't handle NAT traversal themselves. Such NATs may | |
3042 | interfere with the straightforward NAT traversal envisioned by this | |
3043 | document. {{ Clarif-7.6 }} An IPsec endpoint that discovers a NAT | |
f91513e3 MW |
3044 | between it and its correspondent MUST send all subsequent traffic |
3045 | from port 4500, which NATs should not treat specially (as they might | |
3046 | with port 500). | |
3047 | ||
3048 | The specific requirements for supporting NAT traversal [NATREQ] are | |
3049 | listed below. Support for NAT traversal is optional. In this | |
3050 | section only, requirements listed as MUST apply only to | |
3051 | implementations supporting NAT traversal. | |
3052 | ||
3053 | o IKE MUST listen on port 4500 as well as port 500. IKE MUST | |
3054 | respond to the IP address and port from which packets arrived. | |
3055 | ||
3056 | o Both IKE initiator and responder MUST include in their IKE_SA_INIT | |
3057 | packets Notify payloads of type NAT_DETECTION_SOURCE_IP and | |
3058 | NAT_DETECTION_DESTINATION_IP. Those payloads can be used to | |
3059 | detect if there is NAT between the hosts, and which end is behind | |
3060 | the NAT. The location of the payloads in the IKE_SA_INIT packets | |
3061 | are just after the Ni and Nr payloads (before the optional CERTREQ | |
3062 | payload). | |
3063 | ||
d6bd078a MW |
3064 | o {{ 3.10.1-16388 }} The data associated with the |
3065 | NAT_DETECTION_SOURCE_IP notification is a SHA-1 digest of the SPIs | |
3066 | (in the order they appear in the header), IP address, and port on | |
3067 | which this packet was sent. There MAY be multiple | |
3068 | NAT_DETECTION_SOURCE_IP payloads in a message if the sender does | |
3069 | not know which of several network attachments will be used to send | |
3070 | the packet. | |
3071 | ||
3072 | o {{ 3.10.1-16389 }} The data associated with the | |
3073 | NAT_DETECTION_DESTINATION_IP notification is a SHA-1 digest of the | |
3074 | SPIs (in the order they appear in the header), IP address, and | |
3075 | port to which this packet was sent. | |
3076 | ||
3077 | ||
3078 | ||
3079 | Kaufman, et al. Expires August 28, 2008 [Page 55] | |
3080 | \f | |
3081 | Internet-Draft IKEv2bis February 2008 | |
3082 | ||
3083 | ||
3084 | o {{ 3.10.1-16388 }} {{ 3.10.1-16389 }} The recipient of either the | |
3085 | NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP | |
3086 | notification MAY compare the supplied value to a SHA-1 hash of the | |
3087 | SPIs, source IP address, and port, and if they don't match it | |
3088 | SHOULD enable NAT traversal. In the case of a mismatching | |
3089 | NAT_DETECTION_SOURCE_IP hash, the recipient MAY reject the | |
3090 | connection attempt if NAT traversal is not supported. In the case | |
3091 | of a mismatching NAT_DETECTION_DESTINATION_IP hash, it means that | |
3092 | the system receiving the NAT_DETECTION_DESTINATION_IP payload is | |
3093 | behind a NAT and that system SHOULD start sending keepalive | |
3094 | packets as defined in [UDPENCAPS]; alternately, it MAY reject the | |
3095 | connection attempt if NAT traversal is not supported. | |
3096 | ||
f91513e3 | 3097 | o If none of the NAT_DETECTION_SOURCE_IP payload(s) received matches |
d6bd078a MW |
3098 | the expected value of the source IP and port found from the IP |
3099 | header of the packet containing the payload, it means that the | |
3100 | system sending those payloads is behind NAT (i.e., someone along | |
3101 | the route changed the source address of the original packet to | |
3102 | match the address of the NAT box). In this case, the system | |
3103 | receiving the payloads should allow dynamic update of the other | |
3104 | systems' IP address, as described later. | |
f91513e3 MW |
3105 | |
3106 | o If the NAT_DETECTION_DESTINATION_IP payload received does not | |
3107 | match the hash of the destination IP and port found from the IP | |
d6bd078a MW |
3108 | header of the packet containing the payload, it means that the |
3109 | system receiving the NAT_DETECTION_DESTINATION_IP payload is | |
3110 | behind a NAT. In this case, that system SHOULD start sending | |
f91513e3 MW |
3111 | keepalive packets as explained in [UDPENCAPS]. |
3112 | ||
3113 | o The IKE initiator MUST check these payloads if present and if they | |
3114 | do not match the addresses in the outer packet MUST tunnel all | |
3115 | future IKE and ESP packets associated with this IKE_SA over UDP | |
3116 | port 4500. | |
3117 | ||
3118 | o To tunnel IKE packets over UDP port 4500, the IKE header has four | |
3119 | octets of zero prepended and the result immediately follows the | |
3120 | UDP header. To tunnel ESP packets over UDP port 4500, the ESP | |
3121 | header immediately follows the UDP header. Since the first four | |
d6bd078a | 3122 | octets of the ESP header contain the SPI, and the SPI cannot |
f91513e3 MW |
3123 | validly be zero, it is always possible to distinguish ESP and IKE |
3124 | messages. | |
3125 | ||
d6bd078a MW |
3126 | o Implementations MUST process received UDP-encapsulated ESP packets |
3127 | even when no NAT was detected. | |
f91513e3 | 3128 | |
d6bd078a MW |
3129 | o The original source and destination IP address required for the |
3130 | transport mode TCP and UDP packet checksum fixup (see [UDPENCAPS]) | |
3131 | are obtained from the Traffic Selectors associated with the | |
f91513e3 MW |
3132 | |
3133 | ||
3134 | ||
d6bd078a | 3135 | Kaufman, et al. Expires August 28, 2008 [Page 56] |
f91513e3 | 3136 | \f |
d6bd078a | 3137 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
3138 | |
3139 | ||
f91513e3 MW |
3140 | exchange. In the case of NAT traversal, the Traffic Selectors |
3141 | MUST contain exactly one IP address, which is then used as the | |
3142 | original IP address. | |
3143 | ||
3144 | o There are cases where a NAT box decides to remove mappings that | |
3145 | are still alive (for example, the keepalive interval is too long, | |
3146 | or the NAT box is rebooted). To recover in these cases, hosts | |
3147 | that are not behind a NAT SHOULD send all packets (including | |
3148 | retransmission packets) to the IP address and port from the last | |
3149 | valid authenticated packet from the other end (i.e., dynamically | |
3150 | update the address). A host behind a NAT SHOULD NOT do this | |
3151 | because it opens a DoS attack possibility. Any authenticated IKE | |
3152 | packet or any authenticated UDP-encapsulated ESP packet can be | |
3153 | used to detect that the IP address or the port has changed. | |
3154 | ||
3155 | Note that similar but probably not identical actions will likely be | |
3156 | needed to make IKE work with Mobile IP, but such processing is not | |
3157 | addressed by this document. | |
3158 | ||
3159 | 2.24. Explicit Congestion Notification (ECN) | |
3160 | ||
3161 | When IPsec tunnels behave as originally specified in [IPSECARCH-OLD], | |
3162 | ECN usage is not appropriate for the outer IP headers because tunnel | |
3163 | decapsulation processing discards ECN congestion indications to the | |
3164 | detriment of the network. ECN support for IPsec tunnels for IKEv1- | |
3165 | based IPsec requires multiple operating modes and negotiation (see | |
3166 | [ECN]). IKEv2 simplifies this situation by requiring that ECN be | |
3167 | usable in the outer IP headers of all tunnel-mode IPsec SAs created | |
3168 | by IKEv2. Specifically, tunnel encapsulators and decapsulators for | |
3169 | all tunnel-mode SAs created by IKEv2 MUST support the ECN full- | |
3170 | functionality option for tunnels specified in [ECN] and MUST | |
3171 | implement the tunnel encapsulation and decapsulation processing | |
3172 | specified in [IPSECARCH] to prevent discarding of ECN congestion | |
3173 | indications. | |
3174 | ||
3175 | ||
3176 | 3. Header and Payload Formats | |
3177 | ||
d6bd078a MW |
3178 | In the tables in this section, some cryptographic primitives and |
3179 | configuation attributes are marked as "UNSPECIFIED". These are items | |
3180 | for which there are no known specifications and therefore | |
3181 | interoperability is currently impossible. A future specification may | |
3182 | describe their use, but until such specification is made, | |
3183 | implementations SHOULD NOT attempt to use items marked as | |
3184 | "UNSPECIFIED" in implementations that are meant to be interoperable. | |
3185 | ||
f91513e3 | 3186 | |
f91513e3 MW |
3187 | |
3188 | ||
3189 | ||
d6bd078a MW |
3190 | |
3191 | Kaufman, et al. Expires August 28, 2008 [Page 57] | |
f91513e3 | 3192 | \f |
d6bd078a MW |
3193 | Internet-Draft IKEv2bis February 2008 |
3194 | ||
f91513e3 | 3195 | |
d6bd078a | 3196 | 3.1. The IKE Header |
f91513e3 | 3197 | |
d6bd078a MW |
3198 | IKE messages use UDP ports 500 and/or 4500, with one IKE message per |
3199 | UDP datagram. Information from the beginning of the packet through | |
3200 | the UDP header is largely ignored except that the IP addresses and | |
3201 | UDP ports from the headers are reversed and used for return packets. | |
3202 | When sent on UDP port 500, IKE messages begin immediately following | |
f91513e3 MW |
3203 | the UDP header. When sent on UDP port 4500, IKE messages have |
3204 | prepended four octets of zero. These four octets of zero are not | |
3205 | part of the IKE message and are not included in any of the length | |
3206 | fields or checksums defined by IKE. Each IKE message begins with the | |
3207 | IKE header, denoted HDR in this memo. Following the header are one | |
3208 | or more IKE payloads each identified by a "Next Payload" field in the | |
3209 | preceding payload. Payloads are processed in the order in which they | |
3210 | appear in an IKE message by invoking the appropriate processing | |
3211 | routine according to the "Next Payload" field in the IKE header and | |
3212 | subsequently according to the "Next Payload" field in the IKE payload | |
3213 | itself until a "Next Payload" field of zero indicates that no | |
3214 | payloads follow. If a payload of type "Encrypted" is found, that | |
3215 | payload is decrypted and its contents parsed as additional payloads. | |
3216 | An Encrypted payload MUST be the last payload in a packet and an | |
3217 | Encrypted payload MUST NOT contain another Encrypted payload. | |
3218 | ||
3219 | The Recipient SPI in the header identifies an instance of an IKE | |
3220 | security association. It is therefore possible for a single instance | |
3221 | of IKE to multiplex distinct sessions with multiple peers. | |
3222 | ||
3223 | All multi-octet fields representing integers are laid out in big | |
d6bd078a MW |
3224 | endian order (also known as "most significant byte first", or |
3225 | "network byte order"). | |
f91513e3 MW |
3226 | |
3227 | The format of the IKE header is shown in Figure 4. | |
3228 | ||
d6bd078a MW |
3229 | |
3230 | ||
3231 | ||
3232 | ||
3233 | ||
3234 | ||
3235 | ||
3236 | ||
3237 | ||
3238 | ||
3239 | ||
3240 | ||
3241 | ||
3242 | ||
3243 | ||
3244 | ||
3245 | ||
3246 | ||
3247 | Kaufman, et al. Expires August 28, 2008 [Page 58] | |
3248 | \f | |
3249 | Internet-Draft IKEv2bis February 2008 | |
3250 | ||
3251 | ||
f91513e3 MW |
3252 | 1 2 3 |
3253 | 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 | |
3254 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
d6bd078a MW |
3255 | | IKE_SA Initiator's SPI | |
3256 | | | | |
f91513e3 | 3257 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a MW |
3258 | | IKE_SA Responder's SPI | |
3259 | | | | |
f91513e3 | 3260 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a | 3261 | | Next Payload | MjVer | MnVer | Exchange Type | Flags | |
f91513e3 | 3262 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a | 3263 | | Message ID | |
f91513e3 | 3264 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a | 3265 | | Length | |
f91513e3 MW |
3266 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
3267 | ||
3268 | Figure 4: IKE Header Format | |
3269 | ||
3270 | o Initiator's SPI (8 octets) - A value chosen by the initiator to | |
3271 | identify a unique IKE security association. This value MUST NOT | |
3272 | be zero. | |
3273 | ||
f91513e3 MW |
3274 | o Responder's SPI (8 octets) - A value chosen by the responder to |
3275 | identify a unique IKE security association. This value MUST be | |
3276 | zero in the first message of an IKE Initial Exchange (including | |
3277 | repeats of that message including a cookie). {{ The phrase "and | |
3278 | MUST NOT be zero in any other message" was removed; Clarif-2.1 }} | |
3279 | ||
3280 | o Next Payload (1 octet) - Indicates the type of payload that | |
3281 | immediately follows the header. The format and value of each | |
3282 | payload are defined below. | |
3283 | ||
3284 | o Major Version (4 bits) - Indicates the major version of the IKE | |
3285 | protocol in use. Implementations based on this version of IKE | |
3286 | MUST set the Major Version to 2. Implementations based on | |
3287 | previous versions of IKE and ISAKMP MUST set the Major Version to | |
3288 | 1. Implementations based on this version of IKE MUST reject or | |
3289 | ignore messages containing a version number greater than 2. | |
3290 | ||
3291 | o Minor Version (4 bits) - Indicates the minor version of the IKE | |
3292 | protocol in use. Implementations based on this version of IKE | |
3293 | MUST set the Minor Version to 0. They MUST ignore the minor | |
3294 | version number of received messages. | |
3295 | ||
3296 | o Exchange Type (1 octet) - Indicates the type of exchange being | |
3297 | used. This constrains the payloads sent in each message and | |
3298 | orderings of messages in an exchange. | |
3299 | ||
d6bd078a MW |
3300 | |
3301 | ||
3302 | ||
3303 | Kaufman, et al. Expires August 28, 2008 [Page 59] | |
3304 | \f | |
3305 | Internet-Draft IKEv2bis February 2008 | |
3306 | ||
3307 | ||
f91513e3 MW |
3308 | Exchange Type Value |
3309 | ---------------------------------- | |
3310 | RESERVED 0-33 | |
3311 | IKE_SA_INIT 34 | |
3312 | IKE_AUTH 35 | |
3313 | CREATE_CHILD_SA 36 | |
3314 | INFORMATIONAL 37 | |
3315 | RESERVED TO IANA 38-239 | |
d6bd078a | 3316 | PRIVATE USE 240-255 |
f91513e3 MW |
3317 | |
3318 | o Flags (1 octet) - Indicates specific options that are set for the | |
3319 | message. Presence of options are indicated by the appropriate bit | |
3320 | in the flags field being set. The bits are defined LSB first, so | |
3321 | bit 0 would be the least significant bit of the Flags octet. In | |
3322 | the description below, a bit being 'set' means its value is '1', | |
3323 | while 'cleared' means its value is '0'. | |
3324 | ||
3325 | * X(reserved) (bits 0-2) - These bits MUST be cleared when | |
3326 | sending and MUST be ignored on receipt. | |
3327 | ||
3328 | * I(nitiator) (bit 3 of Flags) - This bit MUST be set in messages | |
3329 | sent by the original initiator of the IKE_SA and MUST be | |
f91513e3 MW |
3330 | cleared in messages sent by the original responder. It is used |
3331 | by the recipient to determine which eight octets of the SPI | |
3332 | were generated by the recipient. | |
3333 | ||
3334 | * V(ersion) (bit 4 of Flags) - This bit indicates that the | |
3335 | transmitter is capable of speaking a higher major version | |
3336 | number of the protocol than the one indicated in the major | |
3337 | version number field. Implementations of IKEv2 must clear this | |
3338 | bit when sending and MUST ignore it in incoming messages. | |
3339 | ||
3340 | * R(esponse) (bit 5 of Flags) - This bit indicates that this | |
3341 | message is a response to a message containing the same message | |
3342 | ID. This bit MUST be cleared in all request messages and MUST | |
3343 | be set in all responses. An IKE endpoint MUST NOT generate a | |
3344 | response to a message that is marked as being a response. | |
3345 | ||
3346 | * X(reserved) (bits 6-7 of Flags) - These bits MUST be cleared | |
3347 | when sending and MUST be ignored on receipt. | |
3348 | ||
3349 | o Message ID (4 octets) - Message identifier used to control | |
3350 | retransmission of lost packets and matching of requests and | |
3351 | responses. It is essential to the security of the protocol | |
3352 | because it is used to prevent message replay attacks. See | |
3353 | Section 2.1 and Section 2.2. | |
3354 | ||
d6bd078a MW |
3355 | |
3356 | ||
3357 | ||
3358 | ||
3359 | Kaufman, et al. Expires August 28, 2008 [Page 60] | |
3360 | \f | |
3361 | Internet-Draft IKEv2bis February 2008 | |
3362 | ||
3363 | ||
f91513e3 MW |
3364 | o Length (4 octets) - Length of total message (header + payloads) in |
3365 | octets. | |
3366 | ||
3367 | 3.2. Generic Payload Header | |
3368 | ||
3369 | Each IKE payload defined in Section 3.3 through Section 3.16 begins | |
3370 | with a generic payload header, shown in Figure 5. Figures for each | |
3371 | payload below will include the generic payload header, but for | |
3372 | brevity the description of each field will be omitted. | |
3373 | ||
3374 | 1 2 3 | |
3375 | 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 | |
3376 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
d6bd078a | 3377 | | Next Payload |C| RESERVED | Payload Length | |
f91513e3 MW |
3378 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
3379 | ||
3380 | Figure 5: Generic Payload Header | |
3381 | ||
3382 | The Generic Payload Header fields are defined as follows: | |
3383 | ||
3384 | o Next Payload (1 octet) - Identifier for the payload type of the | |
3385 | next payload in the message. If the current payload is the last | |
3386 | in the message, then this field will be 0. This field provides a | |
f91513e3 MW |
3387 | "chaining" capability whereby additional payloads can be added to |
3388 | a message by appending it to the end of the message and setting | |
3389 | the "Next Payload" field of the preceding payload to indicate the | |
3390 | new payload's type. An Encrypted payload, which must always be | |
3391 | the last payload of a message, is an exception. It contains data | |
3392 | structures in the format of additional payloads. In the header of | |
3393 | an Encrypted payload, the Next Payload field is set to the payload | |
3394 | type of the first contained payload (instead of 0). The payload | |
3395 | type values are: | |
3396 | ||
d6bd078a MW |
3397 | |
3398 | ||
3399 | ||
3400 | ||
3401 | ||
3402 | ||
3403 | ||
3404 | ||
3405 | ||
3406 | ||
3407 | ||
3408 | ||
3409 | ||
3410 | ||
3411 | ||
3412 | ||
3413 | ||
3414 | ||
3415 | Kaufman, et al. Expires August 28, 2008 [Page 61] | |
3416 | \f | |
3417 | Internet-Draft IKEv2bis February 2008 | |
3418 | ||
3419 | ||
f91513e3 MW |
3420 | Next Payload Type Notation Value |
3421 | -------------------------------------------------- | |
3422 | No Next Payload 0 | |
3423 | RESERVED 1-32 | |
3424 | Security Association SA 33 | |
3425 | Key Exchange KE 34 | |
3426 | Identification - Initiator IDi 35 | |
3427 | Identification - Responder IDr 36 | |
3428 | Certificate CERT 37 | |
3429 | Certificate Request CERTREQ 38 | |
3430 | Authentication AUTH 39 | |
3431 | Nonce Ni, Nr 40 | |
3432 | Notify N 41 | |
3433 | Delete D 42 | |
3434 | Vendor ID V 43 | |
3435 | Traffic Selector - Initiator TSi 44 | |
3436 | Traffic Selector - Responder TSr 45 | |
3437 | Encrypted E 46 | |
3438 | Configuration CP 47 | |
3439 | Extensible Authentication EAP 48 | |
3440 | RESERVED TO IANA 49-127 | |
3441 | PRIVATE USE 128-255 | |
3442 | ||
3443 | (Payload type values 1-32 should not be assigned in the | |
3444 | future so that there is no overlap with the code assignments | |
3445 | for IKEv1.) | |
3446 | ||
3447 | o Critical (1 bit) - MUST be set to zero if the sender wants the | |
3448 | recipient to skip this payload if it does not understand the | |
3449 | payload type code in the Next Payload field of the previous | |
3450 | payload. MUST be set to one if the sender wants the recipient to | |
3451 | reject this entire message if it does not understand the payload | |
3452 | type. MUST be ignored by the recipient if the recipient | |
3453 | understands the payload type code. MUST be set to zero for | |
3454 | payload types defined in this document. Note that the critical | |
3455 | bit applies to the current payload rather than the "next" payload | |
3456 | whose type code appears in the first octet. The reasoning behind | |
3457 | not setting the critical bit for payloads defined in this document | |
f91513e3 MW |
3458 | is that all implementations MUST understand all payload types |
3459 | defined in this document and therefore must ignore the Critical | |
3460 | bit's value. Skipped payloads are expected to have valid Next | |
3461 | Payload and Payload Length fields. | |
3462 | ||
3463 | o RESERVED (7 bits) - MUST be sent as zero; MUST be ignored on | |
3464 | receipt. | |
3465 | ||
3466 | o Payload Length (2 octets) - Length in octets of the current | |
3467 | payload, including the generic payload header. | |
3468 | ||
d6bd078a MW |
3469 | |
3470 | ||
3471 | Kaufman, et al. Expires August 28, 2008 [Page 62] | |
3472 | \f | |
3473 | Internet-Draft IKEv2bis February 2008 | |
3474 | ||
3475 | ||
3476 | {{ Clarif-7.10 }} Many payloads contain fields marked as "RESERVED". | |
3477 | Some payloads in IKEv2 (and historically in IKEv1) are not aligned to | |
3478 | 4-octet boundaries. | |
3479 | ||
f91513e3 MW |
3480 | 3.3. Security Association Payload |
3481 | ||
3482 | The Security Association Payload, denoted SA in this memo, is used to | |
3483 | negotiate attributes of a security association. Assembly of Security | |
3484 | Association Payloads requires great peace of mind. An SA payload MAY | |
3485 | contain multiple proposals. If there is more than one, they MUST be | |
d6bd078a MW |
3486 | ordered from most preferred to least preferred. Each proposal |
3487 | contains a single IPsec protocol (where a protocol is IKE, ESP, or | |
f91513e3 MW |
3488 | AH), each protocol MAY contain multiple transforms, and each |
3489 | transform MAY contain multiple attributes. When parsing an SA, an | |
3490 | implementation MUST check that the total Payload Length is consistent | |
3491 | with the payload's internal lengths and counts. Proposals, | |
3492 | Transforms, and Attributes each have their own variable length | |
3493 | encodings. They are nested such that the Payload Length of an SA | |
3494 | includes the combined contents of the SA, Proposal, Transform, and | |
3495 | Attribute information. The length of a Proposal includes the lengths | |
3496 | of all Transforms and Attributes it contains. The length of a | |
3497 | Transform includes the lengths of all Attributes it contains. | |
3498 | ||
3499 | The syntax of Security Associations, Proposals, Transforms, and | |
3500 | Attributes is based on ISAKMP; however the semantics are somewhat | |
3501 | different. The reason for the complexity and the hierarchy is to | |
3502 | allow for multiple possible combinations of algorithms to be encoded | |
3503 | in a single SA. Sometimes there is a choice of multiple algorithms, | |
3504 | whereas other times there is a combination of algorithms. For | |
d6bd078a MW |
3505 | example, an initiator might want to propose using ESP with either |
3506 | (3DES and HMAC_MD5) or (AES and HMAC_SHA1). | |
f91513e3 MW |
3507 | |
3508 | One of the reasons the semantics of the SA payload has changed from | |
3509 | ISAKMP and IKEv1 is to make the encodings more compact in common | |
3510 | cases. | |
3511 | ||
3512 | The Proposal structure contains within it a Proposal # and an IPsec | |
d6bd078a MW |
3513 | protocol ID. Each structure MUST have a proposal number one (1) |
3514 | greater than the previous structure. The first Proposal in the | |
3515 | initiator's SA payload MUST have a Proposal # of one (1). A proposal | |
3516 | of AH or ESP would have two proposal structures, one for AH with | |
3517 | Proposal #1 and one for ESP with Proposal #2. | |
f91513e3 | 3518 | |
d6bd078a MW |
3519 | Each Proposal/Protocol structure is followed by one or more transform |
3520 | structures. The number of different transforms is generally | |
3521 | determined by the Protocol. AH generally has two transforms: | |
3522 | Extended Sequence Numbers (ESN) and an integrity check algorithm. | |
3523 | ESP generally has three: ESN, an encryption algorithm and an | |
f91513e3 MW |
3524 | |
3525 | ||
f91513e3 | 3526 | |
d6bd078a MW |
3527 | Kaufman, et al. Expires August 28, 2008 [Page 63] |
3528 | \f | |
3529 | Internet-Draft IKEv2bis February 2008 | |
f91513e3 | 3530 | |
f91513e3 | 3531 | |
d6bd078a MW |
3532 | integrity check algorithm. IKE generally has four transforms: a |
3533 | Diffie-Hellman group, an integrity check algorithm, a prf algorithm, | |
3534 | and an encryption algorithm. If an algorithm that combines | |
3535 | encryption and integrity protection is proposed, it MUST be proposed | |
3536 | as an encryption algorithm and an integrity protection algorithm MUST | |
3537 | NOT be proposed. For each Protocol, the set of permissible | |
3538 | transforms is assigned transform ID numbers, which appear in the | |
3539 | header of each transform. | |
f91513e3 MW |
3540 | |
3541 | If there are multiple transforms with the same Transform Type, the | |
3542 | proposal is an OR of those transforms. If there are multiple | |
3543 | Transforms with different Transform Types, the proposal is an AND of | |
d6bd078a MW |
3544 | the different groups. For example, to propose ESP with (3DES or AES- |
3545 | CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two | |
3546 | Transform Type 1 candidates (one for 3DES and one for AEC-CBC) and | |
3547 | two Transform Type 3 candidates (one for HMAC_MD5 and one for | |
3548 | HMAC_SHA). This effectively proposes four combinations of | |
3549 | algorithms. If the initiator wanted to propose only a subset of | |
3550 | those, for example (3DES and HMAC_MD5) or (IDEA and HMAC_SHA), there | |
3551 | is no way to encode that as multiple transforms within a single | |
3552 | Proposal. Instead, the initiator would have to construct two | |
3553 | different Proposals, each with two transforms. | |
f91513e3 MW |
3554 | |
3555 | A given transform MAY have one or more Attributes. Attributes are | |
3556 | necessary when the transform can be used in more than one way, as | |
3557 | when an encryption algorithm has a variable key size. The transform | |
3558 | would specify the algorithm and the attribute would specify the key | |
3559 | size. Most transforms do not have attributes. A transform MUST NOT | |
3560 | have multiple attributes of the same type. To propose alternate | |
3561 | values for an attribute (for example, multiple key sizes for the AES | |
3562 | encryption algorithm), and implementation MUST include multiple | |
3563 | Transforms with the same Transform Type each with a single Attribute. | |
3564 | ||
3565 | Note that the semantics of Transforms and Attributes are quite | |
3566 | different from those in IKEv1. In IKEv1, a single Transform carried | |
3567 | multiple algorithms for a protocol with one carried in the Transform | |
3568 | and the others carried in the Attributes. | |
3569 | ||
f91513e3 MW |
3570 | 1 2 3 |
3571 | 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 | |
3572 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
d6bd078a | 3573 | | Next Payload |C| RESERVED | Payload Length | |
f91513e3 | 3574 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a | 3575 | | | |
f91513e3 | 3576 | ~ <Proposals> ~ |
d6bd078a | 3577 | | | |
f91513e3 MW |
3578 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
3579 | ||
d6bd078a MW |
3580 | |
3581 | ||
3582 | ||
3583 | Kaufman, et al. Expires August 28, 2008 [Page 64] | |
3584 | \f | |
3585 | Internet-Draft IKEv2bis February 2008 | |
3586 | ||
3587 | ||
f91513e3 MW |
3588 | Figure 6: Security Association Payload |
3589 | ||
3590 | o Proposals (variable) - One or more proposal substructures. | |
3591 | ||
3592 | The payload type for the Security Association Payload is thirty three | |
3593 | (33). | |
3594 | ||
3595 | 3.3.1. Proposal Substructure | |
3596 | ||
3597 | 1 2 3 | |
3598 | 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 | |
3599 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
d6bd078a | 3600 | | 0 (last) or 2 | RESERVED | Proposal Length | |
f91513e3 | 3601 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a | 3602 | | Proposal # | Protocol ID | SPI Size |# of Transforms| |
f91513e3 MW |
3603 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
3604 | ~ SPI (variable) ~ | |
3605 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
d6bd078a | 3606 | | | |
f91513e3 | 3607 | ~ <Transforms> ~ |
d6bd078a | 3608 | | | |
f91513e3 MW |
3609 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
3610 | ||
3611 | Figure 7: Proposal Substructure | |
3612 | ||
3613 | o 0 (last) or 2 (more) (1 octet) - Specifies whether this is the | |
3614 | last Proposal Substructure in the SA. This syntax is inherited | |
3615 | from ISAKMP, but is unnecessary because the last Proposal could be | |
3616 | identified from the length of the SA. The value (2) corresponds | |
3617 | to a Payload Type of Proposal in IKEv1, and the first four octets | |
3618 | of the Proposal structure are designed to look somewhat like the | |
3619 | header of a Payload. | |
3620 | ||
3621 | o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on | |
3622 | receipt. | |
3623 | ||
3624 | o Proposal Length (2 octets) - Length of this proposal, including | |
3625 | all transforms and attributes that follow. | |
3626 | ||
d6bd078a MW |
3627 | o Proposal # (1 octet) - When a proposal is made, the first proposal |
3628 | in an SA payload MUST be #1, and subsequent proposals MUST be one | |
3629 | more than the previous proposal (indicating an OR of the two | |
3630 | proposals). When a proposal is accepted, the proposal number in | |
3631 | the SA payload MUST match the number on the proposal sent that was | |
3632 | accepted. | |
f91513e3 | 3633 | |
d6bd078a MW |
3634 | o Protocol ID (1 octet) - Specifies the IPsec protocol identifier |
3635 | for the current negotiation. The defined values are: | |
f91513e3 | 3636 | |
f91513e3 MW |
3637 | |
3638 | ||
d6bd078a MW |
3639 | Kaufman, et al. Expires August 28, 2008 [Page 65] |
3640 | \f | |
3641 | Internet-Draft IKEv2bis February 2008 | |
f91513e3 | 3642 | |
f91513e3 MW |
3643 | |
3644 | Protocol Protocol ID | |
3645 | ----------------------------------- | |
3646 | RESERVED 0 | |
3647 | IKE 1 | |
3648 | AH 2 | |
3649 | ESP 3 | |
3650 | RESERVED TO IANA 4-200 | |
3651 | PRIVATE USE 201-255 | |
3652 | ||
3653 | o SPI Size (1 octet) - For an initial IKE_SA negotiation, this field | |
3654 | MUST be zero; the SPI is obtained from the outer header. During | |
3655 | subsequent negotiations, it is equal to the size, in octets, of | |
3656 | the SPI of the corresponding protocol (8 for IKE, 4 for ESP and | |
3657 | AH). | |
3658 | ||
3659 | o # of Transforms (1 octet) - Specifies the number of transforms in | |
3660 | this proposal. | |
3661 | ||
3662 | o SPI (variable) - The sending entity's SPI. Even if the SPI Size | |
3663 | is not a multiple of 4 octets, there is no padding applied to the | |
3664 | payload. When the SPI Size field is zero, this field is not | |
3665 | present in the Security Association payload. | |
3666 | ||
3667 | o Transforms (variable) - One or more transform substructures. | |
3668 | ||
f91513e3 MW |
3669 | 3.3.2. Transform Substructure |
3670 | ||
3671 | 1 2 3 | |
3672 | 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 | |
3673 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
d6bd078a | 3674 | | 0 (last) or 3 | RESERVED | Transform Length | |
f91513e3 | 3675 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a | 3676 | |Transform Type | RESERVED | Transform ID | |
f91513e3 | 3677 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a | 3678 | | | |
f91513e3 | 3679 | ~ Transform Attributes ~ |
d6bd078a | 3680 | | | |
f91513e3 MW |
3681 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
3682 | ||
3683 | Figure 8: Transform Substructure | |
3684 | ||
3685 | o 0 (last) or 3 (more) (1 octet) - Specifies whether this is the | |
3686 | last Transform Substructure in the Proposal. This syntax is | |
3687 | inherited from ISAKMP, but is unnecessary because the last | |
3688 | Proposal could be identified from the length of the SA. The value | |
3689 | (3) corresponds to a Payload Type of Transform in IKEv1, and the | |
3690 | first four octets of the Transform structure are designed to look | |
3691 | somewhat like the header of a Payload. | |
3692 | ||
d6bd078a MW |
3693 | |
3694 | ||
3695 | Kaufman, et al. Expires August 28, 2008 [Page 66] | |
3696 | \f | |
3697 | Internet-Draft IKEv2bis February 2008 | |
3698 | ||
3699 | ||
f91513e3 MW |
3700 | o RESERVED - MUST be sent as zero; MUST be ignored on receipt. |
3701 | ||
3702 | o Transform Length - The length (in octets) of the Transform | |
3703 | Substructure including Header and Attributes. | |
3704 | ||
3705 | o Transform Type (1 octet) - The type of transform being specified | |
3706 | in this transform. Different protocols support different | |
3707 | transform types. For some protocols, some of the transforms may | |
3708 | be optional. If a transform is optional and the initiator wishes | |
3709 | to propose that the transform be omitted, no transform of the | |
3710 | given type is included in the proposal. If the initiator wishes | |
3711 | to make use of the transform optional to the responder, it | |
3712 | includes a transform substructure with transform ID = 0 as one of | |
3713 | the options. | |
3714 | ||
3715 | o Transform ID (2 octets) - The specific instance of the transform | |
3716 | type being proposed. | |
3717 | ||
3718 | The tranform type values are: | |
3719 | ||
f91513e3 MW |
3720 | Description Trans. Used In |
3721 | Type | |
3722 | ------------------------------------------------------------------ | |
3723 | RESERVED 0 | |
3724 | Encryption Algorithm (ENCR) 1 IKE and ESP | |
3725 | Pseudo-random Function (PRF) 2 IKE | |
d6bd078a | 3726 | Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP |
f91513e3 MW |
3727 | Diffie-Hellman Group (D-H) 4 IKE, optional in AH & ESP |
3728 | Extended Sequence Numbers (ESN) 5 AH and ESP | |
3729 | RESERVED TO IANA 6-240 | |
3730 | PRIVATE USE 241-255 | |
3731 | ||
d6bd078a MW |
3732 | (*) Negotiating an integrity algorithm is mandatory for the |
3733 | Encrypted payload format specified in this document. Future | |
3734 | documents may specify additional formats based on authenticated | |
3735 | encryption, in which case a separate integrity algorithm is not | |
3736 | negotiated. | |
3737 | ||
f91513e3 MW |
3738 | For Transform Type 1 (Encryption Algorithm), defined Transform IDs |
3739 | are: | |
3740 | ||
d6bd078a MW |
3741 | |
3742 | ||
3743 | ||
3744 | ||
3745 | ||
3746 | ||
3747 | ||
3748 | ||
3749 | ||
3750 | ||
3751 | Kaufman, et al. Expires August 28, 2008 [Page 67] | |
3752 | \f | |
3753 | Internet-Draft IKEv2bis February 2008 | |
3754 | ||
3755 | ||
f91513e3 MW |
3756 | Name Number Defined In |
3757 | --------------------------------------------------- | |
3758 | RESERVED 0 | |
d6bd078a | 3759 | ENCR_DES_IV64 1 (UNSPECIFIED) |
f91513e3 MW |
3760 | ENCR_DES 2 (RFC2405), [DES] |
3761 | ENCR_3DES 3 (RFC2451) | |
3762 | ENCR_RC5 4 (RFC2451) | |
3763 | ENCR_IDEA 5 (RFC2451), [IDEA] | |
3764 | ENCR_CAST 6 (RFC2451) | |
3765 | ENCR_BLOWFISH 7 (RFC2451) | |
d6bd078a MW |
3766 | ENCR_3IDEA 8 (UNSPECIFIED) |
3767 | ENCR_DES_IV32 9 (UNSPECIFIED) | |
f91513e3 MW |
3768 | RESERVED 10 |
3769 | ENCR_NULL 11 (RFC2410) | |
3770 | ENCR_AES_CBC 12 (RFC3602) | |
d6bd078a | 3771 | ENCR_AES_CTR 13 (RFC3686) |
f91513e3 MW |
3772 | RESERVED TO IANA 14-1023 |
3773 | PRIVATE USE 1024-65535 | |
3774 | ||
3775 | For Transform Type 2 (Pseudo-random Function), defined Transform IDs | |
3776 | are: | |
3777 | ||
3778 | Name Number Defined In | |
3779 | ------------------------------------------------------ | |
3780 | RESERVED 0 | |
3781 | PRF_HMAC_MD5 1 (RFC2104), [MD5] | |
3782 | PRF_HMAC_SHA1 2 (RFC2104), [SHA] | |
d6bd078a MW |
3783 | PRF_HMAC_TIGER 3 (UNSPECIFIED) |
3784 | PRF_AES128_XCBC 4 (RFC4434) | |
f91513e3 MW |
3785 | RESERVED TO IANA 5-1023 |
3786 | PRIVATE USE 1024-65535 | |
3787 | ||
3788 | For Transform Type 3 (Integrity Algorithm), defined Transform IDs | |
f91513e3 MW |
3789 | are: |
3790 | ||
3791 | Name Number Defined In | |
3792 | ---------------------------------------- | |
3793 | NONE 0 | |
3794 | AUTH_HMAC_MD5_96 1 (RFC2403) | |
3795 | AUTH_HMAC_SHA1_96 2 (RFC2404) | |
d6bd078a MW |
3796 | AUTH_DES_MAC 3 (UNSPECIFIED) |
3797 | AUTH_KPDK_MD5 4 (UNSPECIFIED) | |
f91513e3 MW |
3798 | AUTH_AES_XCBC_96 5 (RFC3566) |
3799 | RESERVED TO IANA 6-1023 | |
3800 | PRIVATE USE 1024-65535 | |
3801 | ||
3802 | For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs | |
3803 | are: | |
3804 | ||
d6bd078a MW |
3805 | |
3806 | ||
3807 | Kaufman, et al. Expires August 28, 2008 [Page 68] | |
3808 | \f | |
3809 | Internet-Draft IKEv2bis February 2008 | |
3810 | ||
3811 | ||
3812 | Name Number Defined in | |
3813 | ---------------------------------------- | |
3814 | NONE 0 | |
3815 | 768 Bit MODP 1 Appendix B | |
3816 | 1024 Bit MODP 2 Appendix B | |
3817 | RESERVED TO IANA 3-4 | |
3818 | 1536-bit MODP 5 [ADDGROUP] | |
3819 | RESERVED TO IANA 6-13 | |
3820 | 2048-bit MODP 14 [ADDGROUP] | |
3821 | 3072-bit MODP 15 [ADDGROUP] | |
3822 | 4096-bit MODP 16 [ADDGROUP] | |
3823 | 6144-bit MODP 17 [ADDGROUP] | |
3824 | 8192-bit MODP 18 [ADDGROUP] | |
3825 | RESERVED TO IANA 19-1023 | |
3826 | PRIVATE USE 1024-65535 | |
f91513e3 MW |
3827 | |
3828 | For Transform Type 5 (Extended Sequence Numbers), defined Transform | |
3829 | IDs are: | |
3830 | ||
3831 | Name Number | |
3832 | -------------------------------------------- | |
3833 | No Extended Sequence Numbers 0 | |
3834 | Extended Sequence Numbers 1 | |
3835 | RESERVED 2 - 65535 | |
3836 | ||
d6bd078a MW |
3837 | {{ Clarif-4.4 }} Note that an initiator who supports ESNs will |
3838 | usually include two ESN transforms, with values "0" and "1", in its | |
3839 | proposals. A proposal containing a single ESN transform with value | |
3840 | "1" means that using normal (non-extended) sequence numbers is not | |
3841 | acceptable. | |
3842 | ||
f91513e3 MW |
3843 | 3.3.3. Valid Transform Types by Protocol |
3844 | ||
3845 | The number and type of transforms that accompany an SA payload are | |
3846 | dependent on the protocol in the SA itself. An SA payload proposing | |
3847 | the establishment of an SA has the following mandatory and optional | |
3848 | transform types. A compliant implementation MUST understand all | |
3849 | mandatory and optional types for each protocol it supports (though it | |
3850 | need not accept proposals with unacceptable suites). A proposal MAY | |
3851 | omit the optional types if the only value for them it will accept is | |
3852 | NONE. | |
3853 | ||
3854 | ||
3855 | ||
3856 | ||
3857 | ||
d6bd078a MW |
3858 | |
3859 | ||
3860 | ||
3861 | ||
3862 | ||
3863 | Kaufman, et al. Expires August 28, 2008 [Page 69] | |
f91513e3 | 3864 | \f |
d6bd078a | 3865 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
3866 | |
3867 | ||
3868 | Protocol Mandatory Types Optional Types | |
3869 | --------------------------------------------------- | |
d6bd078a | 3870 | IKE ENCR, PRF, INTEG*, D-H |
f91513e3 MW |
3871 | ESP ENCR, ESN INTEG, D-H |
3872 | AH INTEG, ESN D-H | |
3873 | ||
d6bd078a MW |
3874 | (*) Negotiating an integrity algorithm is mandatory for the |
3875 | Encrypted payload format specified in this document. Future | |
3876 | documents may specify additional formats based on authenticated | |
3877 | encryption, in which case a separate integrity algorithm is not | |
3878 | negotiated. | |
3879 | ||
f91513e3 MW |
3880 | 3.3.4. Mandatory Transform IDs |
3881 | ||
3882 | The specification of suites that MUST and SHOULD be supported for | |
3883 | interoperability has been removed from this document because they are | |
3884 | likely to change more rapidly than this document evolves. | |
3885 | ||
3886 | An important lesson learned from IKEv1 is that no system should only | |
3887 | implement the mandatory algorithms and expect them to be the best | |
3888 | choice for all customers. For example, at the time that this | |
3889 | document was written, many IKEv1 implementers were starting to | |
3890 | migrate to AES in Cipher Block Chaining (CBC) mode for Virtual | |
3891 | Private Network (VPN) applications. Many IPsec systems based on | |
3892 | IKEv2 will implement AES, additional Diffie-Hellman groups, and | |
3893 | additional hash algorithms, and some IPsec customers already require | |
3894 | these algorithms in addition to the ones listed above. | |
3895 | ||
3896 | It is likely that IANA will add additional transforms in the future, | |
3897 | and some users may want to use private suites, especially for IKE | |
3898 | where implementations should be capable of supporting different | |
3899 | parameters, up to certain size limits. In support of this goal, all | |
3900 | implementations of IKEv2 SHOULD include a management facility that | |
3901 | allows specification (by a user or system administrator) of Diffie- | |
3902 | Hellman (DH) parameters (the generator, modulus, and exponent lengths | |
3903 | and values) for new DH groups. Implementations SHOULD provide a | |
3904 | management interface through which these parameters and the | |
3905 | associated transform IDs may be entered (by a user or system | |
3906 | administrator), to enable negotiating such groups. | |
3907 | ||
3908 | All implementations of IKEv2 MUST include a management facility that | |
3909 | enables a user or system administrator to specify the suites that are | |
3910 | acceptable for use with IKE. Upon receipt of a payload with a set of | |
3911 | transform IDs, the implementation MUST compare the transmitted | |
3912 | transform IDs against those locally configured via the management | |
3913 | controls, to verify that the proposed suite is acceptable based on | |
3914 | local policy. The implementation MUST reject SA proposals that are | |
3915 | not authorized by these IKE suite controls. Note that cryptographic | |
f91513e3 MW |
3916 | |
3917 | ||
3918 | ||
d6bd078a | 3919 | Kaufman, et al. Expires August 28, 2008 [Page 70] |
f91513e3 | 3920 | \f |
d6bd078a | 3921 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
3922 | |
3923 | ||
d6bd078a MW |
3924 | suites that MUST be implemented need not be configured as acceptable |
3925 | to local policy. | |
3926 | ||
f91513e3 MW |
3927 | 3.3.5. Transform Attributes |
3928 | ||
3929 | Each transform in a Security Association payload may include | |
3930 | attributes that modify or complete the specification of the | |
d6bd078a MW |
3931 | transform. The set of valid attributes depends on the transform. |
3932 | Currently, only a single attribute type is defined: the Key Length | |
3933 | attribute is used by certain encryption transforms with variable- | |
3934 | length keys (see below for details). | |
3935 | ||
3936 | The attributes are type/value pairs and are defined below. | |
3937 | Attributes can have a value with a fixed two-octet length or a | |
f91513e3 MW |
3938 | variable-length value. For the latter, the attribute is encoded as |
3939 | type/length/value. | |
3940 | ||
3941 | 1 2 3 | |
3942 | 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 | |
3943 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
d6bd078a MW |
3944 | |A| Attribute Type | AF=0 Attribute Length | |
3945 | |F| | AF=1 Attribute Value | | |
f91513e3 | 3946 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a MW |
3947 | | AF=0 Attribute Value | |
3948 | | AF=1 Not Transmitted | | |
f91513e3 MW |
3949 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
3950 | ||
3951 | Figure 9: Data Attributes | |
3952 | ||
d6bd078a MW |
3953 | o Attribute Format (AF) (1 bit) - Indicates whether the data |
3954 | attribute follow the Type/Length/Value (TLV) format or a shortened | |
3955 | Type/Value (TV) format. If the AF bit is zero (0), then the | |
3956 | attribute uses TLV format; if the AF bit is one (1), the TV format | |
3957 | (with two-byte value) is used. | |
f91513e3 | 3958 | |
d6bd078a MW |
3959 | o Attribute Type (15 bits) - Unique identifier for each type of |
3960 | attribute (see below). | |
f91513e3 MW |
3961 | |
3962 | o Attribute Value (variable length) - Value of the Attribute | |
3963 | associated with the Attribute Type. If the AF bit is a zero (0), | |
3964 | this field has a variable length defined by the Attribute Length | |
3965 | field. If the AF bit is a one (1), the Attribute Value has a | |
3966 | length of 2 octets. | |
3967 | ||
d6bd078a MW |
3968 | Note that the only currently defined attribute type (Key Length) is |
3969 | fixed length; the variable-length encoding specification is included | |
3970 | only for future extensions. Attributes described as fixed length | |
3971 | MUST NOT be encoded using the variable-length encoding. Variable- | |
f91513e3 MW |
3972 | |
3973 | ||
3974 | ||
d6bd078a | 3975 | Kaufman, et al. Expires August 28, 2008 [Page 71] |
f91513e3 | 3976 | \f |
d6bd078a | 3977 | Internet-Draft IKEv2bis February 2008 |
f91513e3 | 3978 | |
f91513e3 | 3979 | |
d6bd078a MW |
3980 | length attributes MUST NOT be encoded as fixed-length even if their |
3981 | value can fit into two octets. NOTE: This is a change from IKEv1, | |
3982 | where increased flexibility may have simplified the composer of | |
3983 | messages but certainly complicated the parser. | |
f91513e3 MW |
3984 | |
3985 | Attribute Type Value Attribute Format | |
3986 | ------------------------------------------------------------ | |
3987 | RESERVED 0-13 | |
3988 | Key Length (in bits) 14 TV | |
3989 | RESERVED 15-17 | |
3990 | RESERVED TO IANA 18-16383 | |
3991 | PRIVATE USE 16384-32767 | |
d6bd078a MW |
3992 | |
3993 | Values 0-13 and 15-17 were used in a similar context in IKEv1, and | |
3994 | should not be assigned except to matching values. | |
3995 | ||
3996 | The Key Length attribute specifies the key length in bits (MUST use | |
3997 | network byte order) for certain transforms as follows: {{ Clarif-7.11 | |
3998 | }} | |
3999 | ||
4000 | o The Key Length attribute MUST NOT be used with transforms that use | |
4001 | a fixed length key. This includes, e.g., ENCR_DES, ENCR_IDEA, and | |
4002 | all the Type 2 (Pseudo-random function) and Type 3 (Integrity | |
4003 | Algorithm) transforms specified in this document. It is | |
4004 | recommended that future Type 2 or 3 transforms do not use this | |
4005 | attribute. | |
4006 | ||
4007 | o Some transforms specify that the Key Length attribute MUST be | |
4008 | always included (omitting the attribute is not allowed, and | |
4009 | proposals not containing it MUST be rejected). This includes, | |
4010 | e.g., ENCR_AES_CBC and ENCR_AES_CTR. | |
4011 | ||
4012 | o Some transforms allow variable-length keys, but also specify a | |
4013 | default key length if the attribute is not included. These | |
4014 | transforms include, e.g., ENCR_RC5 and ENCR_BLOWFISH. | |
4015 | ||
4016 | Implementation note: To further interoperability and to support | |
4017 | upgrading endpoints independently, implementers of this protocol | |
4018 | SHOULD accept values that they deem to supply greater security. For | |
4019 | instance, if a peer is configured to accept a variable-length cipher | |
4020 | with a key length of X bits and is offered that cipher with a larger | |
4021 | key length, the implementation SHOULD accept the offer if it supports | |
4022 | use of the longer key. | |
4023 | ||
4024 | Support of this capability allows a responder to express a concept of | |
4025 | "at least" a certain level of security -- "a key length of _at least_ | |
4026 | X bits for cipher Y". However, as the attribute is always returned | |
4027 | unchanged (see Section 3.3.6), an initiator willing to accept | |
4028 | ||
4029 | ||
4030 | ||
4031 | Kaufman, et al. Expires August 28, 2008 [Page 72] | |
4032 | \f | |
4033 | Internet-Draft IKEv2bis February 2008 | |
4034 | ||
4035 | ||
4036 | multiple key lengths has to include multiple transforms with the same | |
4037 | Transform Type, each with different Key Length attribute. | |
f91513e3 MW |
4038 | |
4039 | 3.3.6. Attribute Negotiation | |
4040 | ||
4041 | During security association negotiation initiators present offers to | |
4042 | responders. Responders MUST select a single complete set of | |
4043 | parameters from the offers (or reject all offers if none are | |
4044 | acceptable). If there are multiple proposals, the responder MUST | |
d6bd078a | 4045 | choose a single proposal. If the selected proposal has multiple |
f91513e3 MW |
4046 | Transforms with the same type, the responder MUST choose a single |
4047 | one. Any attributes of a selected transform MUST be returned | |
4048 | unmodified. The initiator of an exchange MUST check that the | |
4049 | accepted offer is consistent with one of its proposals, and if not | |
4050 | that response MUST be rejected. | |
4051 | ||
d6bd078a MW |
4052 | If the responder receives a proposal that contains a Transform Type |
4053 | it does not understand, or a proposal that is missing a mandatory | |
4054 | Transform Type, it MUST consider this proposal unacceptable; however, | |
4055 | other proposals in the same SA payload are processed as usual. | |
4056 | Similarly, if the responder receives a transform that contains a | |
4057 | Transform Attribute it does not understand, it MUST consider this | |
4058 | transform unacceptable; other transforms with the same Transform Type | |
4059 | are processed as usual. This allows new Transform Types and | |
4060 | Transform Attributes to be defined in the future. | |
4061 | ||
f91513e3 MW |
4062 | Negotiating Diffie-Hellman groups presents some special challenges. |
4063 | SA offers include proposed attributes and a Diffie-Hellman public | |
4064 | number (KE) in the same message. If in the initial exchange the | |
4065 | initiator offers to use one of several Diffie-Hellman groups, it | |
4066 | SHOULD pick the one the responder is most likely to accept and | |
4067 | include a KE corresponding to that group. If the guess turns out to | |
4068 | be wrong, the responder will indicate the correct group in the | |
4069 | response and the initiator SHOULD pick an element of that group for | |
4070 | its KE value when retrying the first message. It SHOULD, however, | |
4071 | continue to propose its full supported set of groups in order to | |
4072 | prevent a man-in-the-middle downgrade attack. | |
4073 | ||
d6bd078a | 4074 | 3.4. Key Exchange Payload |
f91513e3 | 4075 | |
d6bd078a MW |
4076 | The Key Exchange Payload, denoted KE in this memo, is used to |
4077 | exchange Diffie-Hellman public numbers as part of a Diffie-Hellman | |
4078 | key exchange. The Key Exchange Payload consists of the IKE generic | |
4079 | payload header followed by the Diffie-Hellman public value itself. | |
f91513e3 MW |
4080 | |
4081 | ||
f91513e3 MW |
4082 | |
4083 | ||
f91513e3 | 4084 | |
f91513e3 | 4085 | |
f91513e3 | 4086 | |
d6bd078a MW |
4087 | Kaufman, et al. Expires August 28, 2008 [Page 73] |
4088 | \f | |
4089 | Internet-Draft IKEv2bis February 2008 | |
f91513e3 | 4090 | |
f91513e3 MW |
4091 | |
4092 | 1 2 3 | |
4093 | 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 | |
4094 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
d6bd078a | 4095 | | Next Payload |C| RESERVED | Payload Length | |
f91513e3 | 4096 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a | 4097 | | DH Group # | RESERVED | |
f91513e3 | 4098 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a | 4099 | | | |
f91513e3 | 4100 | ~ Key Exchange Data ~ |
d6bd078a | 4101 | | | |
f91513e3 MW |
4102 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
4103 | ||
4104 | Figure 10: Key Exchange Payload Format | |
4105 | ||
4106 | A key exchange payload is constructed by copying one's Diffie-Hellman | |
4107 | public value into the "Key Exchange Data" portion of the payload. | |
4108 | The length of the Diffie-Hellman public value MUST be equal to the | |
4109 | length of the prime modulus over which the exponentiation was | |
4110 | performed, prepending zero bits to the value if necessary. | |
4111 | ||
4112 | The DH Group # identifies the Diffie-Hellman group in which the Key | |
4113 | Exchange Data was computed (see Section 3.3.2). If the selected | |
d6bd078a MW |
4114 | proposal uses a different Diffie-Hellman group (other than NONE), the |
4115 | message MUST be rejected with a Notify payload of type | |
4116 | INVALID_KE_PAYLOAD. | |
f91513e3 MW |
4117 | |
4118 | The payload type for the Key Exchange payload is thirty four (34). | |
4119 | ||
4120 | 3.5. Identification Payloads | |
4121 | ||
4122 | The Identification Payloads, denoted IDi and IDr in this memo, allow | |
4123 | peers to assert an identity to one another. This identity may be | |
4124 | used for policy lookup, but does not necessarily have to match | |
4125 | anything in the CERT payload; both fields may be used by an | |
4126 | implementation to perform access control decisions. {{ Clarif-7.1 }} | |
4127 | When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr | |
4128 | payloads, IKEv2 does not require this address to match the address in | |
4129 | the IP header of IKEv2 packets, or anything in the TSi/TSr payloads. | |
4130 | The contents of IDi/IDr is used purely to fetch the policy and | |
4131 | authentication data related to the other party. | |
4132 | ||
4133 | NOTE: In IKEv1, two ID payloads were used in each direction to hold | |
4134 | Traffic Selector (TS) information for data passing over the SA. In | |
4135 | IKEv2, this information is carried in TS payloads (see Section 3.13). | |
4136 | ||
4137 | The Identification Payload consists of the IKE generic payload header | |
4138 | followed by identification fields as follows: | |
4139 | ||
d6bd078a MW |
4140 | |
4141 | ||
4142 | ||
4143 | Kaufman, et al. Expires August 28, 2008 [Page 74] | |
4144 | \f | |
4145 | Internet-Draft IKEv2bis February 2008 | |
4146 | ||
4147 | ||
f91513e3 MW |
4148 | 1 2 3 |
4149 | 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 | |
4150 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
d6bd078a | 4151 | | Next Payload |C| RESERVED | Payload Length | |
f91513e3 | 4152 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a | 4153 | | ID Type | RESERVED | |
f91513e3 | 4154 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a | 4155 | | | |
f91513e3 | 4156 | ~ Identification Data ~ |
d6bd078a | 4157 | | | |
f91513e3 MW |
4158 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
4159 | ||
4160 | Figure 11: Identification Payload Format | |
4161 | ||
4162 | o ID Type (1 octet) - Specifies the type of Identification being | |
4163 | used. | |
4164 | ||
4165 | o RESERVED - MUST be sent as zero; MUST be ignored on receipt. | |
4166 | ||
4167 | o Identification Data (variable length) - Value, as indicated by the | |
4168 | Identification Type. The length of the Identification Data is | |
4169 | computed from the size in the ID payload header. | |
4170 | ||
4171 | The payload types for the Identification Payload are thirty five (35) | |
4172 | for IDi and thirty six (36) for IDr. | |
4173 | ||
d6bd078a MW |
4174 | The following table lists the assigned values for the Identification |
4175 | Type field: | |
4176 | ||
4177 | ||
4178 | ||
4179 | ||
4180 | ||
4181 | ||
4182 | ||
4183 | ||
4184 | ||
4185 | ||
f91513e3 MW |
4186 | |
4187 | ||
4188 | ||
f91513e3 MW |
4189 | |
4190 | ||
d6bd078a MW |
4191 | |
4192 | ||
4193 | ||
4194 | ||
4195 | ||
4196 | ||
4197 | ||
4198 | ||
4199 | Kaufman, et al. Expires August 28, 2008 [Page 75] | |
4200 | \f | |
4201 | Internet-Draft IKEv2bis February 2008 | |
4202 | ||
f91513e3 MW |
4203 | |
4204 | ID Type Value | |
4205 | ------------------------------------------------------------------- | |
4206 | RESERVED 0 | |
4207 | ||
4208 | ID_IPV4_ADDR 1 | |
4209 | A single four (4) octet IPv4 address. | |
4210 | ||
4211 | ID_FQDN 2 | |
4212 | A fully-qualified domain name string. An example of a ID_FQDN | |
4213 | is, "example.com". The string MUST not contain any terminators | |
d6bd078a MW |
4214 | (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII; |
4215 | for an "internationalized domain name", the syntax is as defined | |
4216 | in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net". | |
f91513e3 MW |
4217 | |
4218 | ID_RFC822_ADDR 3 | |
4219 | A fully-qualified RFC822 email address string, An example of a | |
4220 | ID_RFC822_ADDR is, "jsmith@example.com". The string MUST not | |
4221 | contain any terminators. | |
4222 | ||
4223 | RESERVED TO IANA 4 | |
4224 | ||
4225 | ID_IPV6_ADDR 5 | |
4226 | A single sixteen (16) octet IPv6 address. | |
4227 | ||
4228 | RESERVED TO IANA 6 - 8 | |
4229 | ||
4230 | ID_DER_ASN1_DN 9 | |
4231 | The binary Distinguished Encoding Rules (DER) encoding of an | |
4232 | ASN.1 X.500 Distinguished Name [X.501]. | |
4233 | ||
4234 | ID_DER_ASN1_GN 10 | |
4235 | The binary DER encoding of an ASN.1 X.500 GeneralName [X.509]. | |
4236 | ||
4237 | ID_KEY_ID 11 | |
4238 | An opaque octet stream which may be used to pass vendor- | |
4239 | specific information necessary to do certain proprietary | |
4240 | types of identification. | |
4241 | ||
4242 | RESERVED TO IANA 12-200 | |
4243 | ||
4244 | PRIVATE USE 201-255 | |
4245 | ||
4246 | Two implementations will interoperate only if each can generate a | |
4247 | type of ID acceptable to the other. To assure maximum | |
4248 | interoperability, implementations MUST be configurable to send at | |
4249 | least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and | |
4250 | MUST be configurable to accept all of these types. Implementations | |
d6bd078a | 4251 | SHOULD be capable of generating and accepting all of these types. |
f91513e3 MW |
4252 | |
4253 | ||
4254 | ||
d6bd078a | 4255 | Kaufman, et al. Expires August 28, 2008 [Page 76] |
f91513e3 | 4256 | \f |
d6bd078a | 4257 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
4258 | |
4259 | ||
f91513e3 MW |
4260 | IPv6-capable implementations MUST additionally be configurable to |
4261 | accept ID_IPV6_ADDR. IPv6-only implementations MAY be configurable | |
4262 | to send only ID_IPV6_ADDR. | |
4263 | ||
4264 | {{ Clarif-3.4 }} EAP [EAP] does not mandate the use of any particular | |
4265 | type of identifier, but often EAP is used with Network Access | |
4266 | Identifiers (NAIs) defined in [NAI]. Although NAIs look a bit like | |
4267 | email addresses (e.g., "joe@example.com"), the syntax is not exactly | |
4268 | the same as the syntax of email address in [MAILFORMAT]. For those | |
4269 | NAIs that include the realm component, the ID_RFC822_ADDR | |
4270 | identification type SHOULD be used. Responder implementations should | |
4271 | not attempt to verify that the contents actually conform to the exact | |
4272 | syntax given in [MAILFORMAT], but instead should accept any | |
4273 | reasonable-looking NAI. For NAIs that do not include the realm | |
4274 | component,the ID_KEY_ID identification type SHOULD be used. | |
4275 | ||
4276 | 3.6. Certificate Payload | |
4277 | ||
4278 | The Certificate Payload, denoted CERT in this memo, provides a means | |
4279 | to transport certificates or other authentication-related information | |
4280 | via IKE. Certificate payloads SHOULD be included in an exchange if | |
4281 | certificates are available to the sender unless the peer has | |
4282 | indicated an ability to retrieve this information from elsewhere | |
4283 | using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note that the | |
4284 | term "Certificate Payload" is somewhat misleading, because not all | |
4285 | authentication mechanisms use certificates and data other than | |
4286 | certificates may be passed in this payload. | |
4287 | ||
4288 | The Certificate Payload is defined as follows: | |
4289 | ||
4290 | 1 2 3 | |
4291 | 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 | |
4292 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
d6bd078a | 4293 | | Next Payload |C| RESERVED | Payload Length | |
f91513e3 | 4294 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a MW |
4295 | | Cert Encoding | | |
4296 | +-+-+-+-+-+-+-+-+ | | |
f91513e3 | 4297 | ~ Certificate Data ~ |
d6bd078a | 4298 | | | |
f91513e3 MW |
4299 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
4300 | ||
4301 | Figure 12: Certificate Payload Format | |
4302 | ||
4303 | o Certificate Encoding (1 octet) - This field indicates the type of | |
4304 | certificate or certificate-related information contained in the | |
4305 | Certificate Data field. | |
4306 | ||
4307 | ||
4308 | ||
4309 | ||
d6bd078a MW |
4310 | |
4311 | Kaufman, et al. Expires August 28, 2008 [Page 77] | |
f91513e3 | 4312 | \f |
d6bd078a | 4313 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
4314 | |
4315 | ||
4316 | Certificate Encoding Value | |
d6bd078a | 4317 | ---------------------------------------------------- |
f91513e3 | 4318 | RESERVED 0 |
d6bd078a MW |
4319 | PKCS #7 wrapped X.509 certificate 1 UNSPECIFIED |
4320 | PGP Certificate 2 UNSPECIFIED | |
4321 | DNS Signed Key 3 UNSPECIFIED | |
f91513e3 | 4322 | X.509 Certificate - Signature 4 |
d6bd078a | 4323 | Kerberos Token 6 UNSPECIFIED |
f91513e3 MW |
4324 | Certificate Revocation List (CRL) 7 |
4325 | Authority Revocation List (ARL) 8 | |
d6bd078a | 4326 | SPKI Certificate 9 UNSPECIFIED |
f91513e3 MW |
4327 | X.509 Certificate - Attribute 10 |
4328 | Raw RSA Key 11 | |
4329 | Hash and URL of X.509 certificate 12 | |
4330 | Hash and URL of X.509 bundle 13 | |
4331 | RESERVED to IANA 14 - 200 | |
4332 | PRIVATE USE 201 - 255 | |
4333 | ||
4334 | o Certificate Data (variable length) - Actual encoding of | |
4335 | certificate data. The type of certificate is indicated by the | |
4336 | Certificate Encoding field. | |
4337 | ||
4338 | The payload type for the Certificate Payload is thirty seven (37). | |
4339 | ||
d6bd078a MW |
4340 | Specific syntax for some of the certificate type codes above is not |
4341 | defined in this document. The types whose syntax is defined in this | |
4342 | document are: | |
f91513e3 MW |
4343 | |
4344 | o X.509 Certificate - Signature (4) contains a DER encoded X.509 | |
4345 | certificate whose public key is used to validate the sender's AUTH | |
4346 | payload. | |
4347 | ||
4348 | o Certificate Revocation List (7) contains a DER encoded X.509 | |
4349 | certificate revocation list. | |
4350 | ||
4351 | o {{ Added "DER-encoded RSAPublicKey structure" from Clarif-3.6 }} | |
4352 | Raw RSA Key (11) contains a PKCS #1 encoded RSA key, that is, a | |
4353 | DER-encoded RSAPublicKey structure (see [RSA] and [PKCS1]). | |
4354 | ||
4355 | o Hash and URL encodings (12-13) allow IKE messages to remain short | |
4356 | by replacing long data structures with a 20 octet SHA-1 hash (see | |
4357 | [SHA]) of the replaced value followed by a variable-length URL | |
4358 | that resolves to the DER encoded data structure itself. This | |
4359 | improves efficiency when the endpoints have certificate data | |
4360 | cached and makes IKE less subject to denial of service attacks | |
4361 | that become easier to mount when IKE messages are large enough to | |
4362 | require IP fragmentation [DOSUDPPROT]. | |
4363 | ||
4364 | ||
4365 | ||
4366 | ||
d6bd078a | 4367 | Kaufman, et al. Expires August 28, 2008 [Page 78] |
f91513e3 | 4368 | \f |
d6bd078a | 4369 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
4370 | |
4371 | ||
4372 | Use the following ASN.1 definition for an X.509 bundle: | |
4373 | ||
4374 | CertBundle | |
4375 | { iso(1) identified-organization(3) dod(6) internet(1) | |
4376 | security(5) mechanisms(5) pkix(7) id-mod(0) | |
4377 | id-mod-cert-bundle(34) } | |
4378 | ||
4379 | DEFINITIONS EXPLICIT TAGS ::= | |
4380 | BEGIN | |
4381 | ||
4382 | IMPORTS | |
4383 | Certificate, CertificateList | |
4384 | FROM PKIX1Explicit88 | |
4385 | { iso(1) identified-organization(3) dod(6) | |
4386 | internet(1) security(5) mechanisms(5) pkix(7) | |
4387 | id-mod(0) id-pkix1-explicit(18) } ; | |
4388 | ||
4389 | CertificateOrCRL ::= CHOICE { | |
4390 | cert [0] Certificate, | |
4391 | crl [1] CertificateList } | |
4392 | ||
4393 | CertificateBundle ::= SEQUENCE OF CertificateOrCRL | |
4394 | ||
4395 | END | |
4396 | ||
4397 | Implementations MUST be capable of being configured to send and | |
4398 | accept up to four X.509 certificates in support of authentication, | |
4399 | and also MUST be capable of being configured to send and accept the | |
d6bd078a MW |
4400 | two Hash and URL formats (with HTTP URLs). Implementations SHOULD be |
4401 | capable of being configured to send and accept Raw RSA keys. If | |
4402 | multiple certificates are sent, the first certificate MUST contain | |
4403 | the public key used to sign the AUTH payload. The other certificates | |
4404 | may be sent in any order. | |
f91513e3 MW |
4405 | |
4406 | 3.7. Certificate Request Payload | |
4407 | ||
4408 | The Certificate Request Payload, denoted CERTREQ in this memo, | |
4409 | provides a means to request preferred certificates via IKE and can | |
4410 | appear in the IKE_INIT_SA response and/or the IKE_AUTH request. | |
4411 | Certificate Request payloads MAY be included in an exchange when the | |
4412 | sender needs to get the certificate of the receiver. If multiple CAs | |
4413 | are trusted and the cert encoding does not allow a list, then | |
4414 | multiple Certificate Request payloads SHOULD be transmitted. | |
4415 | ||
4416 | The Certificate Request Payload is defined as follows: | |
4417 | ||
f91513e3 | 4418 | |
d6bd078a MW |
4419 | |
4420 | ||
4421 | ||
4422 | ||
4423 | Kaufman, et al. Expires August 28, 2008 [Page 79] | |
4424 | \f | |
4425 | Internet-Draft IKEv2bis February 2008 | |
4426 | ||
4427 | ||
4428 | 1 2 3 | |
4429 | 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 | |
4430 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4431 | | Next Payload |C| RESERVED | Payload Length | | |
4432 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4433 | | Cert Encoding | | | |
4434 | +-+-+-+-+-+-+-+-+ | | |
4435 | ~ Certification Authority ~ | |
4436 | | | | |
4437 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
4438 | ||
4439 | Figure 13: Certificate Request Payload Format | |
f91513e3 MW |
4440 | |
4441 | o Certificate Encoding (1 octet) - Contains an encoding of the type | |
4442 | or format of certificate requested. Values are listed in | |
4443 | Section 3.6. | |
4444 | ||
4445 | o Certification Authority (variable length) - Contains an encoding | |
4446 | of an acceptable certification authority for the type of | |
4447 | certificate requested. | |
4448 | ||
4449 | The payload type for the Certificate Request Payload is thirty eight | |
4450 | (38). | |
4451 | ||
4452 | The Certificate Encoding field has the same values as those defined | |
4453 | in Section 3.6. The Certification Authority field contains an | |
4454 | indicator of trusted authorities for this certificate type. The | |
4455 | Certification Authority value is a concatenated list of SHA-1 hashes | |
4456 | of the public keys of trusted Certification Authorities (CAs). Each | |
4457 | is encoded as the SHA-1 hash of the Subject Public Key Info element | |
4458 | (see section 4.1.2.7 of [PKIX]) from each Trust Anchor certificate. | |
4459 | The twenty-octet hashes are concatenated and included with no other | |
4460 | formatting. | |
4461 | ||
4462 | {{ Clarif-3.6 }} The contents of the "Certification Authority" field | |
4463 | are defined only for X.509 certificates, which are types 4, 10, 12, | |
f91513e3 MW |
4464 | and 13. Other values SHOULD NOT be used until standards-track |
4465 | specifications that specify their use are published. | |
4466 | ||
4467 | Note that the term "Certificate Request" is somewhat misleading, in | |
4468 | that values other than certificates are defined in a "Certificate" | |
4469 | payload and requests for those values can be present in a Certificate | |
4470 | Request Payload. The syntax of the Certificate Request payload in | |
4471 | such cases is not defined in this document. | |
4472 | ||
4473 | The Certificate Request Payload is processed by inspecting the "Cert | |
4474 | Encoding" field to determine whether the processor has any | |
4475 | certificates of this type. If so, the "Certification Authority" | |
d6bd078a MW |
4476 | |
4477 | ||
4478 | ||
4479 | Kaufman, et al. Expires August 28, 2008 [Page 80] | |
4480 | \f | |
4481 | Internet-Draft IKEv2bis February 2008 | |
4482 | ||
4483 | ||
f91513e3 MW |
4484 | field is inspected to determine if the processor has any certificates |
4485 | that can be validated up to one of the specified certification | |
4486 | authorities. This can be a chain of certificates. | |
4487 | ||
4488 | If an end-entity certificate exists that satisfies the criteria | |
4489 | specified in the CERTREQ, a certificate or certificate chain SHOULD | |
4490 | be sent back to the certificate requestor if the recipient of the | |
4491 | CERTREQ: | |
4492 | ||
4493 | o is configured to use certificate authentication, | |
4494 | ||
4495 | o is allowed to send a CERT payload, | |
4496 | ||
4497 | o has matching CA trust policy governing the current negotiation, | |
4498 | and | |
4499 | ||
4500 | o has at least one time-wise and usage appropriate end-entity | |
4501 | certificate chaining to a CA provided in the CERTREQ. | |
4502 | ||
4503 | Certificate revocation checking must be considered during the | |
4504 | chaining process used to select a certificate. Note that even if two | |
4505 | peers are configured to use two different CAs, cross-certification | |
4506 | relationships should be supported by appropriate selection logic. | |
4507 | ||
4508 | The intent is not to prevent communication through the strict | |
4509 | adherence of selection of a certificate based on CERTREQ, when an | |
4510 | alternate certificate could be selected by the sender that would | |
4511 | still enable the recipient to successfully validate and trust it | |
4512 | through trust conveyed by cross-certification, CRLs, or other out-of- | |
4513 | band configured means. Thus, the processing of a CERTREQ should be | |
4514 | seen as a suggestion for a certificate to select, not a mandated one. | |
4515 | If no certificates exist, then the CERTREQ is ignored. This is not | |
4516 | an error condition of the protocol. There may be cases where there | |
4517 | is a preferred CA sent in the CERTREQ, but an alternate might be | |
4518 | acceptable (perhaps after prompting a human operator). | |
4519 | ||
d6bd078a MW |
4520 | {{ 3.10.1-16392 }} The HTTP_CERT_LOOKUP_SUPPORTED notification MAY be |
4521 | included in any message that can include a CERTREQ payload and | |
4522 | indicates that the sender is capable of looking up certificates based | |
4523 | on an HTTP-based URL (and hence presumably would prefer to receive | |
4524 | certificate specifications in that format). | |
f91513e3 MW |
4525 | |
4526 | 3.8. Authentication Payload | |
4527 | ||
4528 | The Authentication Payload, denoted AUTH in this memo, contains data | |
4529 | used for authentication purposes. The syntax of the Authentication | |
4530 | data varies according to the Auth Method as specified below. | |
4531 | ||
d6bd078a MW |
4532 | |
4533 | ||
4534 | ||
4535 | Kaufman, et al. Expires August 28, 2008 [Page 81] | |
4536 | \f | |
4537 | Internet-Draft IKEv2bis February 2008 | |
4538 | ||
4539 | ||
f91513e3 MW |
4540 | The Authentication Payload is defined as follows: |
4541 | ||
4542 | 1 2 3 | |
4543 | 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 | |
4544 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
d6bd078a | 4545 | | Next Payload |C| RESERVED | Payload Length | |
f91513e3 | 4546 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a | 4547 | | Auth Method | RESERVED | |
f91513e3 | 4548 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a | 4549 | | | |
f91513e3 | 4550 | ~ Authentication Data ~ |
d6bd078a | 4551 | | | |
f91513e3 MW |
4552 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
4553 | ||
4554 | Figure 14: Authentication Payload Format | |
4555 | ||
4556 | o Auth Method (1 octet) - Specifies the method of authentication | |
4557 | used. Values defined are: | |
4558 | ||
4559 | * RSA Digital Signature (1) - Computed as specified in | |
d6bd078a MW |
4560 | Section 2.15 using an RSA private key with RSASSA-PKCS1-v1_5 |
4561 | signature scheme specified in [PKCS1] (implementors should note | |
4562 | that IKEv1 used a different method for RSA signatures) {{ | |
4563 | Clarif-3.3 }}. {{ Clarif-3.2 }} To promote interoperability, | |
4564 | implementations that support this type SHOULD support | |
4565 | signatures that use SHA-1 as the hash function and SHOULD use | |
4566 | SHA-1 as the default hash function when generating signatures. | |
f91513e3 MW |
4567 | |
4568 | * Shared Key Message Integrity Code (2) - Computed as specified | |
4569 | in Section 2.15 using the shared key associated with the | |
4570 | identity in the ID payload and the negotiated prf function | |
4571 | ||
4572 | * DSS Digital Signature (3) - Computed as specified in | |
4573 | Section 2.15 using a DSS private key (see [DSS]) over a SHA-1 | |
4574 | hash. | |
4575 | ||
4576 | * The values 0 and 4-200 are reserved to IANA. The values 201- | |
4577 | 255 are available for private use. | |
4578 | ||
f91513e3 MW |
4579 | o Authentication Data (variable length) - see Section 2.15. |
4580 | ||
4581 | The payload type for the Authentication Payload is thirty nine (39). | |
4582 | ||
4583 | 3.9. Nonce Payload | |
4584 | ||
4585 | The Nonce Payload, denoted Ni and Nr in this memo for the initiator's | |
4586 | and responder's nonce respectively, contains random data used to | |
4587 | guarantee liveness during an exchange and protect against replay | |
d6bd078a MW |
4588 | |
4589 | ||
4590 | ||
4591 | Kaufman, et al. Expires August 28, 2008 [Page 82] | |
4592 | \f | |
4593 | Internet-Draft IKEv2bis February 2008 | |
4594 | ||
4595 | ||
f91513e3 MW |
4596 | attacks. |
4597 | ||
4598 | The Nonce Payload is defined as follows: | |
4599 | ||
4600 | 1 2 3 | |
4601 | 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 | |
4602 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
d6bd078a | 4603 | | Next Payload |C| RESERVED | Payload Length | |
f91513e3 | 4604 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a | 4605 | | | |
f91513e3 | 4606 | ~ Nonce Data ~ |
d6bd078a | 4607 | | | |
f91513e3 MW |
4608 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
4609 | ||
4610 | Figure 15: Nonce Payload Format | |
4611 | ||
4612 | o Nonce Data (variable length) - Contains the random data generated | |
4613 | by the transmitting entity. | |
4614 | ||
4615 | The payload type for the Nonce Payload is forty (40). | |
4616 | ||
4617 | The size of a Nonce MUST be between 16 and 256 octets inclusive. | |
4618 | Nonce values MUST NOT be reused. | |
4619 | ||
4620 | 3.10. Notify Payload | |
4621 | ||
4622 | The Notify Payload, denoted N in this document, is used to transmit | |
4623 | informational data, such as error conditions and state transitions, | |
4624 | to an IKE peer. A Notify Payload may appear in a response message | |
4625 | (usually specifying why a request was rejected), in an INFORMATIONAL | |
4626 | Exchange (to report an error not in an IKE request), or in any other | |
4627 | message to indicate sender capabilities or to modify the meaning of | |
4628 | the request. | |
4629 | ||
4630 | The Notify Payload is defined as follows: | |
4631 | ||
4632 | ||
4633 | ||
4634 | ||
4635 | ||
4636 | ||
4637 | ||
d6bd078a MW |
4638 | |
4639 | ||
4640 | ||
4641 | ||
4642 | ||
4643 | ||
4644 | ||
4645 | ||
4646 | ||
4647 | Kaufman, et al. Expires August 28, 2008 [Page 83] | |
f91513e3 | 4648 | \f |
d6bd078a | 4649 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
4650 | |
4651 | ||
4652 | 1 2 3 | |
4653 | 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 | |
4654 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
d6bd078a | 4655 | | Next Payload |C| RESERVED | Payload Length | |
f91513e3 | 4656 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a | 4657 | | Protocol ID | SPI Size | Notify Message Type | |
f91513e3 | 4658 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a | 4659 | | | |
f91513e3 | 4660 | ~ Security Parameter Index (SPI) ~ |
d6bd078a | 4661 | | | |
f91513e3 | 4662 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a | 4663 | | | |
f91513e3 | 4664 | ~ Notification Data ~ |
d6bd078a | 4665 | | | |
f91513e3 MW |
4666 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
4667 | ||
4668 | Figure 16: Notify Payload Format | |
4669 | ||
4670 | o Protocol ID (1 octet) - If this notification concerns an existing | |
d6bd078a MW |
4671 | SA whose SPI is given the SPI field, this field indicates the type |
4672 | of that SA. For notifications concerning IPsec SAs this field | |
4673 | MUST contain either (2) to indicate AH or (3) to indicate ESP. {{ | |
4674 | Clarif-7.8 }} Of the notifications defined in this document, the | |
4675 | SPI is included only with INVALID_SELECTORS and REKEY_SA. If the | |
4676 | SPI field is empty, this field MUST be sent as zero and MUST be | |
4677 | ignored on receipt. All other values for this field are reserved | |
4678 | to IANA for future assignment. | |
f91513e3 MW |
4679 | |
4680 | o SPI Size (1 octet) - Length in octets of the SPI as defined by the | |
4681 | IPsec protocol ID or zero if no SPI is applicable. For a | |
4682 | notification concerning the IKE_SA, the SPI Size MUST be zero. | |
4683 | ||
4684 | o Notify Message Type (2 octets) - Specifies the type of | |
4685 | notification message. | |
4686 | ||
4687 | o SPI (variable length) - Security Parameter Index. | |
4688 | ||
4689 | o Notification Data (variable length) - Informational or error data | |
4690 | transmitted in addition to the Notify Message Type. Values for | |
4691 | this field are type specific (see below). | |
4692 | ||
4693 | The payload type for the Notify Payload is forty one (41). | |
4694 | ||
4695 | 3.10.1. Notify Message Types | |
4696 | ||
4697 | Notification information can be error messages specifying why an SA | |
4698 | could not be established. It can also be status data that a process | |
d6bd078a | 4699 | managing an SA database wishes to communicate with a peer process. |
f91513e3 MW |
4700 | |
4701 | ||
4702 | ||
d6bd078a | 4703 | Kaufman, et al. Expires August 28, 2008 [Page 84] |
f91513e3 | 4704 | \f |
d6bd078a | 4705 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
4706 | |
4707 | ||
f91513e3 MW |
4708 | The table below lists the Notification messages and their |
4709 | corresponding values. The number of different error statuses was | |
4710 | greatly reduced from IKEv1 both for simplification and to avoid | |
4711 | giving configuration information to probers. | |
4712 | ||
4713 | Types in the range 0 - 16383 are intended for reporting errors. An | |
4714 | implementation receiving a Notify payload with one of these types | |
4715 | that it does not recognize in a response MUST assume that the | |
4716 | corresponding request has failed entirely. {{ Demoted the SHOULD }} | |
4717 | Unrecognized error types in a request and status types in a request | |
4718 | or response MUST be ignored, and they should be logged. | |
4719 | ||
4720 | Notify payloads with status types MAY be added to any message and | |
4721 | MUST be ignored if not recognized. They are intended to indicate | |
4722 | capabilities, and as part of SA negotiation are used to negotiate | |
4723 | non-cryptographic parameters. | |
4724 | ||
4725 | NOTIFY messages: error types Value | |
4726 | ------------------------------------------------------------------- | |
4727 | ||
4728 | RESERVED 0 | |
4729 | ||
4730 | UNSUPPORTED_CRITICAL_PAYLOAD 1 | |
d6bd078a | 4731 | See Section 2.5. |
f91513e3 MW |
4732 | |
4733 | INVALID_IKE_SPI 4 | |
d6bd078a | 4734 | See Section 2.21. |
f91513e3 MW |
4735 | |
4736 | INVALID_MAJOR_VERSION 5 | |
d6bd078a | 4737 | See Section 2.5. |
f91513e3 MW |
4738 | |
4739 | INVALID_SYNTAX 7 | |
4740 | Indicates the IKE message that was received was invalid because | |
4741 | some type, length, or value was out of range or because the | |
4742 | request was rejected for policy reasons. To avoid a denial of | |
4743 | service attack using forged messages, this status may only be | |
4744 | returned for and in an encrypted packet if the message ID and | |
4745 | cryptographic checksum were valid. To avoid leaking information | |
4746 | to someone probing a node, this status MUST be sent in response | |
4747 | to any error not covered by one of the other status types. | |
4748 | {{ Demoted the SHOULD }} To aid debugging, more detailed error | |
d6bd078a | 4749 | information should be written to a console or log. |
f91513e3 | 4750 | |
d6bd078a MW |
4751 | INVALID_MESSAGE_ID 9 |
4752 | See Section 2.3. | |
f91513e3 | 4753 | |
d6bd078a MW |
4754 | INVALID_SPI 11 |
4755 | See Section 1.5. | |
f91513e3 MW |
4756 | |
4757 | ||
f91513e3 | 4758 | |
d6bd078a MW |
4759 | Kaufman, et al. Expires August 28, 2008 [Page 85] |
4760 | \f | |
4761 | Internet-Draft IKEv2bis February 2008 | |
f91513e3 | 4762 | |
f91513e3 MW |
4763 | |
4764 | NO_PROPOSAL_CHOSEN 14 | |
d6bd078a | 4765 | See Section 2.7. |
f91513e3 MW |
4766 | |
4767 | INVALID_KE_PAYLOAD 17 | |
d6bd078a | 4768 | See Section 1.3. |
f91513e3 MW |
4769 | |
4770 | AUTHENTICATION_FAILED 24 | |
4771 | Sent in the response to an IKE_AUTH message when for some reason | |
4772 | the authentication failed. There is no associated data. | |
4773 | ||
4774 | SINGLE_PAIR_REQUIRED 34 | |
d6bd078a | 4775 | See Section 2.9. |
f91513e3 MW |
4776 | |
4777 | NO_ADDITIONAL_SAS 35 | |
d6bd078a | 4778 | See Section 1.3. |
f91513e3 MW |
4779 | |
4780 | INTERNAL_ADDRESS_FAILURE 36 | |
d6bd078a | 4781 | See Section 3.15.4. |
f91513e3 MW |
4782 | |
4783 | FAILED_CP_REQUIRED 37 | |
d6bd078a | 4784 | See Section 2.19. |
f91513e3 MW |
4785 | |
4786 | TS_UNACCEPTABLE 38 | |
d6bd078a | 4787 | See Section 2.9. |
f91513e3 MW |
4788 | |
4789 | INVALID_SELECTORS 39 | |
4790 | MAY be sent in an IKE INFORMATIONAL exchange when a node receives | |
4791 | an ESP or AH packet whose selectors do not match those of the SA | |
4792 | on which it was delivered (and that caused the packet to be | |
4793 | dropped). The Notification Data contains the start of the | |
4794 | offending packet (as in ICMP messages) and the SPI field of the | |
4795 | notification is set to match the SPI of the IPsec SA. | |
4796 | ||
4797 | RESERVED TO IANA 40-8191 | |
4798 | ||
4799 | PRIVATE USE 8192-16383 | |
4800 | ||
4801 | ||
f91513e3 | 4802 | |
f91513e3 | 4803 | |
f91513e3 MW |
4804 | |
4805 | ||
4806 | ||
f91513e3 MW |
4807 | |
4808 | ||
f91513e3 | 4809 | |
f91513e3 | 4810 | |
f91513e3 | 4811 | |
f91513e3 MW |
4812 | |
4813 | ||
4814 | ||
d6bd078a | 4815 | Kaufman, et al. Expires August 28, 2008 [Page 86] |
f91513e3 | 4816 | \f |
d6bd078a | 4817 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
4818 | |
4819 | ||
d6bd078a MW |
4820 | NOTIFY messages: status types Value |
4821 | ------------------------------------------------------------------- | |
f91513e3 | 4822 | |
d6bd078a MW |
4823 | INITIAL_CONTACT 16384 |
4824 | See Section 2.4. | |
f91513e3 | 4825 | |
d6bd078a MW |
4826 | SET_WINDOW_SIZE 16385 |
4827 | See Section 2.3. | |
f91513e3 | 4828 | |
d6bd078a MW |
4829 | ADDITIONAL_TS_POSSIBLE 16386 |
4830 | See Section 2.9. | |
f91513e3 | 4831 | |
d6bd078a MW |
4832 | IPCOMP_SUPPORTED 16387 |
4833 | See Section 2.22. | |
f91513e3 | 4834 | |
d6bd078a MW |
4835 | NAT_DETECTION_SOURCE_IP 16388 |
4836 | See Section 2.23. | |
f91513e3 | 4837 | |
d6bd078a MW |
4838 | NAT_DETECTION_DESTINATION_IP 16389 |
4839 | See Section 2.23. | |
f91513e3 | 4840 | |
d6bd078a MW |
4841 | COOKIE 16390 |
4842 | See Section 2.6. | |
f91513e3 | 4843 | |
d6bd078a MW |
4844 | USE_TRANSPORT_MODE 16391 |
4845 | See Section 1.3.1. | |
f91513e3 | 4846 | |
d6bd078a MW |
4847 | HTTP_CERT_LOOKUP_SUPPORTED 16392 |
4848 | See Section 3.6. | |
f91513e3 MW |
4849 | |
4850 | REKEY_SA 16393 | |
d6bd078a | 4851 | See Section 1.3.3. |
f91513e3 MW |
4852 | |
4853 | ESP_TFC_PADDING_NOT_SUPPORTED 16394 | |
d6bd078a | 4854 | See Section 1.3.1. |
f91513e3 MW |
4855 | |
4856 | NON_FIRST_FRAGMENTS_ALSO 16395 | |
d6bd078a | 4857 | See Section 1.3.1. |
f91513e3 MW |
4858 | |
4859 | RESERVED TO IANA 16396-40959 | |
4860 | ||
4861 | PRIVATE USE 40960-65535 | |
4862 | ||
4863 | 3.11. Delete Payload | |
4864 | ||
4865 | The Delete Payload, denoted D in this memo, contains a protocol | |
4866 | specific security association identifier that the sender has removed | |
4867 | from its security association database and is, therefore, no longer | |
d6bd078a MW |
4868 | |
4869 | ||
4870 | ||
4871 | Kaufman, et al. Expires August 28, 2008 [Page 87] | |
4872 | \f | |
4873 | Internet-Draft IKEv2bis February 2008 | |
4874 | ||
4875 | ||
f91513e3 MW |
4876 | valid. Figure 17 shows the format of the Delete Payload. It is |
4877 | possible to send multiple SPIs in a Delete payload; however, each SPI | |
4878 | MUST be for the same protocol. Mixing of protocol identifiers MUST | |
4879 | NOT be performed in the Delete payload. It is permitted, however, to | |
4880 | include multiple Delete payloads in a single INFORMATIONAL exchange | |
4881 | where each Delete payload lists SPIs for a different protocol. | |
4882 | ||
4883 | Deletion of the IKE_SA is indicated by a protocol ID of 1 (IKE) but | |
4884 | no SPIs. Deletion of a CHILD_SA, such as ESP or AH, will contain the | |
4885 | IPsec protocol ID of that protocol (2 for AH, 3 for ESP), and the SPI | |
f91513e3 MW |
4886 | is the SPI the sending endpoint would expect in inbound ESP or AH |
4887 | packets. | |
4888 | ||
4889 | The Delete Payload is defined as follows: | |
4890 | ||
4891 | 1 2 3 | |
4892 | 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 | |
4893 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
d6bd078a | 4894 | | Next Payload |C| RESERVED | Payload Length | |
f91513e3 | 4895 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a | 4896 | | Protocol ID | SPI Size | # of SPIs | |
f91513e3 | 4897 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a | 4898 | | | |
f91513e3 | 4899 | ~ Security Parameter Index(es) (SPI) ~ |
d6bd078a | 4900 | | | |
f91513e3 MW |
4901 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
4902 | ||
4903 | Figure 17: Delete Payload Format | |
4904 | ||
4905 | o Protocol ID (1 octet) - Must be 1 for an IKE_SA, 2 for AH, or 3 | |
4906 | for ESP. | |
4907 | ||
4908 | o SPI Size (1 octet) - Length in octets of the SPI as defined by the | |
4909 | protocol ID. It MUST be zero for IKE (SPI is in message header) | |
4910 | or four for AH and ESP. | |
4911 | ||
4912 | o # of SPIs (2 octets) - The number of SPIs contained in the Delete | |
4913 | payload. The size of each SPI is defined by the SPI Size field. | |
4914 | ||
4915 | o Security Parameter Index(es) (variable length) - Identifies the | |
4916 | specific security association(s) to delete. The length of this | |
4917 | field is determined by the SPI Size and # of SPIs fields. | |
4918 | ||
4919 | The payload type for the Delete Payload is forty two (42). | |
4920 | ||
d6bd078a MW |
4921 | |
4922 | ||
4923 | ||
4924 | ||
4925 | ||
4926 | ||
4927 | Kaufman, et al. Expires August 28, 2008 [Page 88] | |
4928 | \f | |
4929 | Internet-Draft IKEv2bis February 2008 | |
4930 | ||
4931 | ||
f91513e3 MW |
4932 | 3.12. Vendor ID Payload |
4933 | ||
4934 | The Vendor ID Payload, denoted V in this memo, contains a vendor | |
4935 | defined constant. The constant is used by vendors to identify and | |
4936 | recognize remote instances of their implementations. This mechanism | |
4937 | allows a vendor to experiment with new features while maintaining | |
4938 | backward compatibility. | |
4939 | ||
d6bd078a | 4940 | A Vendor ID payload MAY announce that the sender is capable of |
f91513e3 MW |
4941 | accepting certain extensions to the protocol, or it MAY simply |
4942 | identify the implementation as an aid in debugging. A Vendor ID | |
4943 | payload MUST NOT change the interpretation of any information defined | |
4944 | in this specification (i.e., the critical bit MUST be set to 0). | |
f91513e3 MW |
4945 | Multiple Vendor ID payloads MAY be sent. An implementation is NOT |
4946 | REQUIRED to send any Vendor ID payload at all. | |
4947 | ||
4948 | A Vendor ID payload may be sent as part of any message. Reception of | |
4949 | a familiar Vendor ID payload allows an implementation to make use of | |
4950 | Private USE numbers described throughout this memo-- private | |
4951 | payloads, private exchanges, private notifications, etc. Unfamiliar | |
4952 | Vendor IDs MUST be ignored. | |
4953 | ||
4954 | Writers of Internet-Drafts who wish to extend this protocol MUST | |
4955 | define a Vendor ID payload to announce the ability to implement the | |
4956 | extension in the Internet-Draft. It is expected that Internet-Drafts | |
4957 | that gain acceptance and are standardized will be given "magic | |
4958 | numbers" out of the Future Use range by IANA, and the requirement to | |
4959 | use a Vendor ID will go away. | |
4960 | ||
4961 | The Vendor ID Payload fields are defined as follows: | |
4962 | ||
4963 | 1 2 3 | |
4964 | 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 | |
4965 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
d6bd078a | 4966 | | Next Payload |C| RESERVED | Payload Length | |
f91513e3 | 4967 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a | 4968 | | | |
f91513e3 | 4969 | ~ Vendor ID (VID) ~ |
d6bd078a | 4970 | | | |
f91513e3 MW |
4971 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
4972 | ||
4973 | Figure 18: Vendor ID Payload Format | |
4974 | ||
4975 | o Vendor ID (variable length) - It is the responsibility of the | |
4976 | person choosing the Vendor ID to assure its uniqueness in spite of | |
4977 | the absence of any central registry for IDs. Good practice is to | |
4978 | include a company name, a person name, or some such. If you want | |
4979 | to show off, you might include the latitude and longitude and time | |
d6bd078a MW |
4980 | |
4981 | ||
4982 | ||
4983 | Kaufman, et al. Expires August 28, 2008 [Page 89] | |
4984 | \f | |
4985 | Internet-Draft IKEv2bis February 2008 | |
4986 | ||
4987 | ||
f91513e3 MW |
4988 | where you were when you chose the ID and some random input. A |
4989 | message digest of a long unique string is preferable to the long | |
4990 | unique string itself. | |
4991 | ||
4992 | The payload type for the Vendor ID Payload is forty three (43). | |
4993 | ||
4994 | 3.13. Traffic Selector Payload | |
4995 | ||
4996 | The Traffic Selector Payload, denoted TS in this memo, allows peers | |
4997 | to identify packet flows for processing by IPsec security services. | |
4998 | The Traffic Selector Payload consists of the IKE generic payload | |
4999 | header followed by individual traffic selectors as follows: | |
5000 | ||
f91513e3 MW |
5001 | 1 2 3 |
5002 | 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 | |
5003 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
d6bd078a | 5004 | | Next Payload |C| RESERVED | Payload Length | |
f91513e3 | 5005 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a | 5006 | | Number of TSs | RESERVED | |
f91513e3 | 5007 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a | 5008 | | | |
f91513e3 | 5009 | ~ <Traffic Selectors> ~ |
d6bd078a | 5010 | | | |
f91513e3 MW |
5011 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
5012 | ||
5013 | Figure 19: Traffic Selectors Payload Format | |
5014 | ||
5015 | o Number of TSs (1 octet) - Number of traffic selectors being | |
5016 | provided. | |
5017 | ||
5018 | o RESERVED - This field MUST be sent as zero and MUST be ignored on | |
5019 | receipt. | |
5020 | ||
5021 | o Traffic Selectors (variable length) - One or more individual | |
5022 | traffic selectors. | |
5023 | ||
5024 | The length of the Traffic Selector payload includes the TS header and | |
5025 | all the traffic selectors. | |
5026 | ||
5027 | The payload type for the Traffic Selector payload is forty four (44) | |
5028 | for addresses at the initiator's end of the SA and forty five (45) | |
5029 | for addresses at the responder's end. | |
5030 | ||
5031 | {{ Clarif-4.7 }} There is no requirement that TSi and TSr contain the | |
5032 | same number of individual traffic selectors. Thus, they are | |
5033 | interpreted as follows: a packet matches a given TSi/TSr if it | |
5034 | matches at least one of the individual selectors in TSi, and at least | |
5035 | one of the individual selectors in TSr. | |
5036 | ||
d6bd078a MW |
5037 | |
5038 | ||
5039 | Kaufman, et al. Expires August 28, 2008 [Page 90] | |
5040 | \f | |
5041 | Internet-Draft IKEv2bis February 2008 | |
5042 | ||
5043 | ||
f91513e3 MW |
5044 | For instance, the following traffic selectors: |
5045 | ||
5046 | TSi = ((17, 100, 192.0.1.66-192.0.1.66), | |
5047 | (17, 200, 192.0.1.66-192.0.1.66)) | |
5048 | TSr = ((17, 300, 0.0.0.0-255.255.255.255), | |
5049 | (17, 400, 0.0.0.0-255.255.255.255)) | |
5050 | ||
5051 | would match UDP packets from 192.0.1.66 to anywhere, with any of the | |
5052 | four combinations of source/destination ports (100,300), (100,400), | |
5053 | (200,300), and (200, 400). | |
5054 | ||
5055 | Thus, some types of policies may require several CHILD_SA pairs. For | |
f91513e3 MW |
5056 | instance, a policy matching only source/destination ports (100,300) |
5057 | and (200,400), but not the other two combinations, cannot be | |
5058 | negotiated as a single CHILD_SA pair. | |
5059 | ||
5060 | 3.13.1. Traffic Selector | |
5061 | ||
5062 | 1 2 3 | |
5063 | 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 | |
5064 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
d6bd078a | 5065 | | TS Type |IP Protocol ID*| Selector Length | |
f91513e3 MW |
5066 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
5067 | | Start Port* | End Port* | | |
5068 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
d6bd078a | 5069 | | | |
f91513e3 | 5070 | ~ Starting Address* ~ |
d6bd078a | 5071 | | | |
f91513e3 | 5072 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a | 5073 | | | |
f91513e3 | 5074 | ~ Ending Address* ~ |
d6bd078a | 5075 | | | |
f91513e3 MW |
5076 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
5077 | ||
5078 | Figure 20: Traffic Selector | |
5079 | ||
5080 | *Note: All fields other than TS Type and Selector Length depend on | |
5081 | the TS Type. The fields shown are for TS Types 7 and 8, the only two | |
5082 | values currently defined. | |
5083 | ||
5084 | o TS Type (one octet) - Specifies the type of traffic selector. | |
5085 | ||
5086 | o IP protocol ID (1 octet) - Value specifying an associated IP | |
5087 | protocol ID (e.g., UDP/TCP/ICMP). A value of zero means that the | |
5088 | protocol ID is not relevant to this traffic selector-- the SA can | |
5089 | carry all protocols. | |
5090 | ||
d6bd078a MW |
5091 | |
5092 | ||
5093 | ||
5094 | ||
5095 | Kaufman, et al. Expires August 28, 2008 [Page 91] | |
5096 | \f | |
5097 | Internet-Draft IKEv2bis February 2008 | |
5098 | ||
5099 | ||
f91513e3 MW |
5100 | o Selector Length - Specifies the length of this Traffic Selector |
5101 | Substructure including the header. | |
5102 | ||
5103 | o Start Port (2 octets) - Value specifying the smallest port number | |
5104 | allowed by this Traffic Selector. For protocols for which port is | |
5105 | undefined, or if all ports are allowed, this field MUST be zero. | |
5106 | For the ICMP protocol, the two one-octet fields Type and Code are | |
5107 | treated as a single 16-bit integer (with Type in the most | |
5108 | significant eight bits and Code in the least significant eight | |
5109 | bits) port number for the purposes of filtering based on this | |
5110 | field. | |
5111 | ||
f91513e3 MW |
5112 | o End Port (2 octets) - Value specifying the largest port number |
5113 | allowed by this Traffic Selector. For protocols for which port is | |
5114 | undefined, or if all ports are allowed, this field MUST be 65535. | |
5115 | For the ICMP protocol, the two one-octet fields Type and Code are | |
5116 | treated as a single 16-bit integer (with Type in the most | |
5117 | significant eight bits and Code in the least significant eight | |
5118 | bits) port number for the purposed of filtering based on this | |
5119 | field. | |
5120 | ||
5121 | o Starting Address - The smallest address included in this Traffic | |
5122 | Selector (length determined by TS type). | |
5123 | ||
5124 | o Ending Address - The largest address included in this Traffic | |
5125 | Selector (length determined by TS type). | |
5126 | ||
5127 | Systems that are complying with [IPSECARCH] that wish to indicate | |
5128 | "ANY" ports MUST set the start port to 0 and the end port to 65535; | |
5129 | note that according to [IPSECARCH], "ANY" includes "OPAQUE". Systems | |
5130 | working with [IPSECARCH] that wish to indicate "OPAQUE" ports, but | |
5131 | not "ANY" ports, MUST set the start port to 65535 and the end port to | |
5132 | 0. | |
5133 | ||
5134 | {{ Added from Clarif-4.8 }} The traffic selector types 7 and 8 can | |
5135 | also refer to ICMP type and code fields. Note, however, that ICMP | |
5136 | packets do not have separate source and destination port fields. The | |
5137 | method for specifying the traffic selectors for ICMP is shown by | |
5138 | example in Section 4.4.1.3 of [IPSECARCH]. | |
5139 | ||
5140 | {{ Added from Clarif-4.9 }} Traffic selectors can use IP Protocol ID | |
5141 | 135 to match the IPv6 mobility header [MIPV6]. This document does | |
5142 | not specify how to represent the "MH Type" field in traffic | |
5143 | selectors, although it is likely that a different document will | |
5144 | specify this in the future. Note that [IPSECARCH] says that the IPv6 | |
5145 | mobility header (MH) message type is placed in the most significant | |
5146 | eight bits of the 16-bit local port selector. The direction | |
5147 | semantics of TSi/TSr port fields are the same as for ICMP. | |
5148 | ||
f91513e3 MW |
5149 | |
5150 | ||
d6bd078a | 5151 | Kaufman, et al. Expires August 28, 2008 [Page 92] |
f91513e3 | 5152 | \f |
d6bd078a | 5153 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
5154 | |
5155 | ||
d6bd078a MW |
5156 | The following table lists the assigned values for the Traffic |
5157 | Selector Type field and the corresponding Address Selector Data. | |
5158 | ||
f91513e3 MW |
5159 | TS Type Value |
5160 | ------------------------------------------------------------------- | |
5161 | RESERVED 0-6 | |
5162 | ||
5163 | TS_IPV4_ADDR_RANGE 7 | |
5164 | ||
5165 | A range of IPv4 addresses, represented by two four-octet | |
5166 | values. The first value is the beginning IPv4 address | |
5167 | (inclusive) and the second value is the ending IPv4 address | |
5168 | (inclusive). All addresses falling between the two specified | |
5169 | addresses are considered to be within the list. | |
5170 | ||
5171 | TS_IPV6_ADDR_RANGE 8 | |
5172 | ||
5173 | A range of IPv6 addresses, represented by two sixteen-octet | |
5174 | values. The first value is the beginning IPv6 address | |
5175 | (inclusive) and the second value is the ending IPv6 address | |
5176 | (inclusive). All addresses falling between the two specified | |
5177 | addresses are considered to be within the list. | |
5178 | ||
5179 | RESERVED TO IANA 9-240 | |
5180 | PRIVATE USE 241-255 | |
5181 | ||
5182 | 3.14. Encrypted Payload | |
5183 | ||
5184 | The Encrypted Payload, denoted SK{...} or E in this memo, contains | |
5185 | other payloads in encrypted form. The Encrypted Payload, if present | |
5186 | in a message, MUST be the last payload in the message. Often, it is | |
5187 | the only payload in the message. | |
5188 | ||
5189 | The algorithms for encryption and integrity protection are negotiated | |
5190 | during IKE_SA setup, and the keys are computed as specified in | |
5191 | Section 2.14 and Section 2.18. | |
5192 | ||
d6bd078a MW |
5193 | This document specifies the cryptographic processing of Encrypted |
5194 | payloads using a block cipher in CBC mode and an integrity check | |
5195 | algorithm that computes a fixed-length checksum over a variable size | |
5196 | message. The design is modeled after the ESP algorithms described in | |
5197 | RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC]. This document | |
5198 | completely specifies the cryptographic processing of IKE data, but | |
5199 | those documents should be consulted for design rationale. Future | |
5200 | documents may specify the processing of Encrypted payloads for other | |
5201 | types of transforms, such as counter mode encryption and | |
5202 | authenticated encryption algorithms. Peers MUST NOT negotiate | |
5203 | transforms for which no such specification exists. | |
f91513e3 MW |
5204 | |
5205 | ||
5206 | ||
d6bd078a | 5207 | Kaufman, et al. Expires August 28, 2008 [Page 93] |
f91513e3 | 5208 | \f |
d6bd078a | 5209 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
5210 | |
5211 | ||
d6bd078a MW |
5212 | The payload type for an Encrypted payload is forty six (46). The |
5213 | Encrypted Payload consists of the IKE generic payload header followed | |
5214 | by individual fields as follows: | |
5215 | ||
f91513e3 MW |
5216 | 1 2 3 |
5217 | 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 | |
5218 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
d6bd078a | 5219 | | Next Payload |C| RESERVED | Payload Length | |
f91513e3 | 5220 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a MW |
5221 | | Initialization Vector | |
5222 | | (length is block size for encryption algorithm) | | |
f91513e3 MW |
5223 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
5224 | ~ Encrypted IKE Payloads ~ | |
5225 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
d6bd078a | 5226 | | | Padding (0-255 octets) | |
f91513e3 | 5227 | +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ |
d6bd078a | 5228 | | | Pad Length | |
f91513e3 MW |
5229 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
5230 | ~ Integrity Checksum Data ~ | |
5231 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5232 | ||
5233 | Figure 21: Encrypted Payload Format | |
5234 | ||
5235 | o Next Payload - The payload type of the first embedded payload. | |
5236 | Note that this is an exception in the standard header format, | |
5237 | since the Encrypted payload is the last payload in the message and | |
5238 | therefore the Next Payload field would normally be zero. But | |
5239 | because the content of this payload is embedded payloads and there | |
5240 | was no natural place to put the type of the first one, that type | |
5241 | is placed here. | |
5242 | ||
5243 | o Payload Length - Includes the lengths of the header, IV, Encrypted | |
5244 | IKE Payloads, Padding, Pad Length, and Integrity Checksum Data. | |
5245 | ||
d6bd078a MW |
5246 | o Initialization Vector - The length of the initialization vector |
5247 | (IV) is equal to the block length of the underlying encryption | |
5248 | algorithm. Senders MUST select a new unpredictable IV for every | |
5249 | message; recipients MUST accept any value. The reader is | |
5250 | encouraged to consult [MODES] for advice on IV generation. In | |
5251 | particular, using the final ciphertext block of the previous | |
5252 | message is not considered unpredictable. | |
f91513e3 MW |
5253 | |
5254 | o IKE Payloads are as specified earlier in this section. This field | |
5255 | is encrypted with the negotiated cipher. | |
5256 | ||
5257 | o Padding MAY contain any value chosen by the sender, and MUST have | |
5258 | a length that makes the combination of the Payloads, the Padding, | |
5259 | and the Pad Length to be a multiple of the encryption block size. | |
f91513e3 MW |
5260 | |
5261 | ||
5262 | ||
d6bd078a | 5263 | Kaufman, et al. Expires August 28, 2008 [Page 94] |
f91513e3 | 5264 | \f |
d6bd078a MW |
5265 | Internet-Draft IKEv2bis February 2008 |
5266 | ||
f91513e3 | 5267 | |
d6bd078a | 5268 | This field is encrypted with the negotiated cipher. |
f91513e3 MW |
5269 | |
5270 | o Pad Length is the length of the Padding field. The sender SHOULD | |
5271 | set the Pad Length to the minimum value that makes the combination | |
5272 | of the Payloads, the Padding, and the Pad Length a multiple of the | |
5273 | block size, but the recipient MUST accept any length that results | |
5274 | in proper alignment. This field is encrypted with the negotiated | |
5275 | cipher. | |
5276 | ||
5277 | o Integrity Checksum Data is the cryptographic checksum of the | |
5278 | entire message starting with the Fixed IKE Header through the Pad | |
5279 | Length. The checksum MUST be computed over the encrypted message. | |
5280 | Its length is determined by the integrity algorithm negotiated. | |
5281 | ||
5282 | 3.15. Configuration Payload | |
5283 | ||
5284 | The Configuration payload, denoted CP in this document, is used to | |
5285 | exchange configuration information between IKE peers. The exchange | |
5286 | is for an IRAC to request an internal IP address from an IRAS and to | |
5287 | exchange other information of the sort that one would acquire with | |
5288 | Dynamic Host Configuration Protocol (DHCP) if the IRAC were directly | |
5289 | connected to a LAN. | |
5290 | ||
d6bd078a | 5291 | The Configuration Payload is defined as follows: |
f91513e3 | 5292 | |
d6bd078a MW |
5293 | 1 2 3 |
5294 | 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 | |
5295 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5296 | | Next Payload |C| RESERVED | Payload Length | | |
5297 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5298 | | CFG Type | RESERVED | | |
5299 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5300 | | | | |
5301 | ~ Configuration Attributes ~ | |
5302 | | | | |
5303 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
f91513e3 | 5304 | |
d6bd078a | 5305 | Figure 22: Configuration Payload Format |
f91513e3 | 5306 | |
d6bd078a | 5307 | The payload type for the Configuration Payload is forty seven (47). |
f91513e3 | 5308 | |
d6bd078a MW |
5309 | o CFG Type (1 octet) - The type of exchange represented by the |
5310 | Configuration Attributes. | |
f91513e3 MW |
5311 | |
5312 | ||
f91513e3 MW |
5313 | |
5314 | ||
f91513e3 | 5315 | |
f91513e3 | 5316 | |
f91513e3 | 5317 | |
f91513e3 | 5318 | |
d6bd078a | 5319 | Kaufman, et al. Expires August 28, 2008 [Page 95] |
f91513e3 | 5320 | \f |
d6bd078a | 5321 | Internet-Draft IKEv2bis February 2008 |
f91513e3 | 5322 | |
f91513e3 MW |
5323 | |
5324 | CFG Type Value | |
5325 | -------------------------- | |
5326 | RESERVED 0 | |
5327 | CFG_REQUEST 1 | |
5328 | CFG_REPLY 2 | |
5329 | CFG_SET 3 | |
5330 | CFG_ACK 4 | |
5331 | RESERVED TO IANA 5-127 | |
5332 | PRIVATE USE 128-255 | |
5333 | ||
5334 | o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on | |
5335 | receipt. | |
5336 | ||
5337 | o Configuration Attributes (variable length) - These are type length | |
5338 | values specific to the Configuration Payload and are defined | |
5339 | below. There may be zero or more Configuration Attributes in this | |
5340 | payload. | |
5341 | ||
5342 | 3.15.1. Configuration Attributes | |
5343 | ||
5344 | 1 2 3 | |
5345 | 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 | |
5346 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
d6bd078a | 5347 | |R| Attribute Type | Length | |
f91513e3 MW |
5348 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
5349 | | | | |
5350 | ~ Value ~ | |
5351 | | | | |
5352 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
5353 | ||
5354 | Figure 23: Configuration Attribute Format | |
5355 | ||
5356 | o Reserved (1 bit) - This bit MUST be set to zero and MUST be | |
5357 | ignored on receipt. | |
5358 | ||
5359 | o Attribute Type (15 bits) - A unique identifier for each of the | |
5360 | Configuration Attribute Types. | |
5361 | ||
5362 | o Length (2 octets) - Length in octets of Value. | |
5363 | ||
5364 | o Value (0 or more octets) - The variable-length value of this | |
5365 | Configuration Attribute. The following attribute types have been | |
5366 | defined: | |
5367 | ||
5368 | ||
5369 | ||
5370 | ||
5371 | ||
d6bd078a MW |
5372 | |
5373 | ||
5374 | ||
5375 | Kaufman, et al. Expires August 28, 2008 [Page 96] | |
f91513e3 | 5376 | \f |
d6bd078a | 5377 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
5378 | |
5379 | ||
5380 | Multi- | |
5381 | Attribute Type Value Valued Length | |
5382 | ------------------------------------------------------- | |
5383 | RESERVED 0 | |
5384 | INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets | |
5385 | INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets | |
5386 | INTERNAL_IP4_DNS 3 YES 0 or 4 octets | |
5387 | INTERNAL_IP4_NBNS 4 YES 0 or 4 octets | |
d6bd078a | 5388 | RESERVED 5 |
f91513e3 MW |
5389 | INTERNAL_IP4_DHCP 6 YES 0 or 4 octets |
5390 | APPLICATION_VERSION 7 NO 0 or more | |
5391 | INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets | |
5392 | RESERVED 9 | |
5393 | INTERNAL_IP6_DNS 10 YES 0 or 16 octets | |
5394 | INTERNAL_IP6_NBNS 11 YES 0 or 16 octets | |
5395 | INTERNAL_IP6_DHCP 12 YES 0 or 16 octets | |
5396 | INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets | |
5397 | SUPPORTED_ATTRIBUTES 14 NO Multiple of 2 | |
5398 | INTERNAL_IP6_SUBNET 15 YES 17 octets | |
5399 | RESERVED TO IANA 16-16383 | |
5400 | PRIVATE USE 16384-32767 | |
5401 | ||
5402 | * These attributes may be multi-valued on return only if | |
5403 | multiple values were requested. | |
5404 | ||
5405 | o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the | |
5406 | internal network, sometimes called a red node address or private | |
5407 | address and MAY be a private address on the Internet. {{ | |
5408 | Clarif-6.2}} In a request message, the address specified is a | |
5409 | requested address (or a zero-length address if no specific address | |
5410 | is requested). If a specific address is requested, it likely | |
5411 | indicates that a previous connection existed with this address and | |
5412 | the requestor would like to reuse that address. With IPv6, a | |
d6bd078a | 5413 | requestor MAY supply the low-order address octets it wants to use. |
f91513e3 MW |
5414 | Multiple internal addresses MAY be requested by requesting |
5415 | multiple internal address attributes. The responder MAY only send | |
5416 | up to the number of addresses requested. The INTERNAL_IP6_ADDRESS | |
5417 | is made up of two fields: the first is a 16-octet IPv6 address, | |
5418 | and the second is a one-octet prefix-length as defined in | |
d6bd078a MW |
5419 | [ADDRIPV6]. The requested address is valid until there are no |
5420 | IKE_SAs between the peers. | |
f91513e3 MW |
5421 | |
5422 | o INTERNAL_IP4_NETMASK - The internal network's netmask. Only one | |
5423 | netmask is allowed in the request and reply messages (e.g., | |
5424 | 255.255.255.0), and it MUST be used only with an | |
d6bd078a MW |
5425 | INTERNAL_IP4_ADDRESS attribute. {{ Clarif-6.4 }} |
5426 | INTERNAL_IP4_NETMASK in a CFG_REPLY means roughly the same thing | |
5427 | as INTERNAL_IP4_SUBNET containing the same information ("send | |
f91513e3 MW |
5428 | |
5429 | ||
5430 | ||
d6bd078a | 5431 | Kaufman, et al. Expires August 28, 2008 [Page 97] |
f91513e3 | 5432 | \f |
d6bd078a | 5433 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
5434 | |
5435 | ||
f91513e3 MW |
5436 | traffic to these addresses through me"), but also implies a link |
5437 | boundary. For instance, the client could use its own address and | |
5438 | the netmask to calculate the broadcast address of the link. An | |
5439 | empty INTERNAL_IP4_NETMASK attribute can be included in a | |
5440 | CFG_REQUEST to request this information (although the gateway can | |
5441 | send the information even when not requested). Non-empty values | |
5442 | for this attribute in a CFG_REQUEST do not make sense and thus | |
5443 | MUST NOT be included. | |
5444 | ||
5445 | o INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a DNS | |
5446 | server within the network. Multiple DNS servers MAY be requested. | |
5447 | The responder MAY respond with zero or more DNS server attributes. | |
5448 | ||
d6bd078a MW |
5449 | o INTERNAL_IP4_NBNS - Specifies an address of a NetBios Name Server |
5450 | (WINS) within the network. Multiple NBNS servers MAY be | |
5451 | requested. The responder MAY respond with zero or more NBNS | |
5452 | server attributes. | |
5453 | ||
5454 | o INTERNAL_IP6_NBNS - {{ Clarif-6.6 }} NetBIOS is not defined for | |
5455 | IPv6; therefore, INTERNAL_IP6_NBNS is also unspecified and is only | |
5456 | retained for compatibility with RFC 4306. | |
f91513e3 MW |
5457 | |
5458 | o INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send | |
5459 | any internal DHCP requests to the address contained within the | |
5460 | attribute. Multiple DHCP servers MAY be requested. The responder | |
5461 | MAY respond with zero or more DHCP server attributes. | |
5462 | ||
5463 | o APPLICATION_VERSION - The version or application information of | |
5464 | the IPsec host. This is a string of printable ASCII characters | |
5465 | that is NOT null terminated. | |
5466 | ||
5467 | o INTERNAL_IP4_SUBNET - The protected sub-networks that this edge- | |
5468 | device protects. This attribute is made up of two fields: the | |
5469 | first being an IP address and the second being a netmask. | |
5470 | Multiple sub-networks MAY be requested. The responder MAY respond | |
5471 | with zero or more sub-network attributes. | |
5472 | ||
f91513e3 MW |
5473 | o SUPPORTED_ATTRIBUTES - When used within a Request, this attribute |
5474 | MUST be zero-length and specifies a query to the responder to | |
5475 | reply back with all of the attributes that it supports. The | |
5476 | response contains an attribute that contains a set of attribute | |
5477 | identifiers each in 2 octets. The length divided by 2 (octets) | |
5478 | would state the number of supported attributes contained in the | |
5479 | response. | |
5480 | ||
5481 | o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge- | |
5482 | device protects. This attribute is made up of two fields: the | |
5483 | first is a 16-octet IPv6 address, and the second is a one-octet | |
d6bd078a MW |
5484 | |
5485 | ||
5486 | ||
5487 | Kaufman, et al. Expires August 28, 2008 [Page 98] | |
5488 | \f | |
5489 | Internet-Draft IKEv2bis February 2008 | |
5490 | ||
5491 | ||
f91513e3 MW |
5492 | prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY |
5493 | be requested. The responder MAY respond with zero or more sub- | |
5494 | network attributes. | |
5495 | ||
5496 | Note that no recommendations are made in this document as to how an | |
5497 | implementation actually figures out what information to send in a | |
5498 | reply. That is, we do not recommend any specific method of an IRAS | |
5499 | determining which DNS server should be returned to a requesting IRAC. | |
5500 | ||
5501 | 3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET | |
5502 | ||
5503 | {{ Section added based on Clarif-6.3 }} | |
5504 | ||
5505 | INTERNAL_IP4/6_SUBNET attributes can indicate additional subnets, | |
5506 | ones that need one or more separate SAs, that can be reached through | |
5507 | the gateway that announces the attributes. INTERNAL_IP4/6_SUBNET | |
5508 | attributes may also express the gateway's policy about what traffic | |
5509 | should be sent through the gateway; the client can choose whether | |
5510 | other traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is | |
5511 | sent through the gateway or directly to the destination. Thus, | |
5512 | traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET | |
5513 | attributes should be sent through the gateway that announces the | |
5514 | attributes. If there are no existing IPsec SAs whose traffic | |
5515 | selectors cover the address in question, new SAs need to be created. | |
5516 | ||
5517 | For instance, if there are two subnets, 192.0.1.0/26 and | |
5518 | 192.0.2.0/24, and the client's request contains the following: | |
5519 | ||
5520 | CP(CFG_REQUEST) = | |
5521 | INTERNAL_IP4_ADDRESS() | |
5522 | TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) | |
5523 | TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) | |
5524 | ||
5525 | then a valid response could be the following (in which TSr and | |
5526 | INTERNAL_IP4_SUBNET contain the same information): | |
5527 | ||
f91513e3 MW |
5528 | CP(CFG_REPLY) = |
5529 | INTERNAL_IP4_ADDRESS(192.0.1.234) | |
5530 | INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) | |
5531 | INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) | |
5532 | TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) | |
5533 | TSr = ((0, 0-65535, 192.0.1.0-192.0.1.63), | |
5534 | (0, 0-65535, 192.0.2.0-192.0.2.255)) | |
5535 | ||
5536 | In these cases, the INTERNAL_IP4_SUBNET does not really carry any | |
5537 | useful information. | |
5538 | ||
5539 | A different possible reply would have been this: | |
5540 | ||
d6bd078a MW |
5541 | |
5542 | ||
5543 | Kaufman, et al. Expires August 28, 2008 [Page 99] | |
5544 | \f | |
5545 | Internet-Draft IKEv2bis February 2008 | |
5546 | ||
5547 | ||
f91513e3 MW |
5548 | CP(CFG_REPLY) = |
5549 | INTERNAL_IP4_ADDRESS(192.0.1.234) | |
5550 | INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) | |
5551 | INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) | |
5552 | TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) | |
5553 | TSr = (0, 0-65535, 0.0.0.0-255.255.255.255) | |
5554 | ||
5555 | That reply would mean that the client can send all its traffic | |
5556 | through the gateway, but the gateway does not mind if the client | |
5557 | sends traffic not included by INTERNAL_IP4_SUBNET directly to the | |
5558 | destination (without going through the gateway). | |
5559 | ||
5560 | A different situation arises if the gateway has a policy that | |
5561 | requires the traffic for the two subnets to be carried in separate | |
5562 | SAs. Then a response like this would indicate to the client that if | |
5563 | it wants access to the second subnet, it needs to create a separate | |
5564 | SA: | |
5565 | ||
5566 | CP(CFG_REPLY) = | |
5567 | INTERNAL_IP4_ADDRESS(192.0.1.234) | |
5568 | INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) | |
5569 | INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) | |
5570 | TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) | |
5571 | TSr = (0, 0-65535, 192.0.1.0-192.0.1.63) | |
5572 | ||
5573 | INTERNAL_IP4_SUBNET can also be useful if the client's TSr included | |
5574 | only part of the address space. For instance, if the client requests | |
5575 | the following: | |
5576 | ||
5577 | CP(CFG_REQUEST) = | |
5578 | INTERNAL_IP4_ADDRESS() | |
5579 | TSi = (0, 0-65535, 0.0.0.0-255.255.255.255) | |
5580 | TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) | |
5581 | ||
5582 | then the gateway's reply might be: | |
5583 | ||
f91513e3 MW |
5584 | CP(CFG_REPLY) = |
5585 | INTERNAL_IP4_ADDRESS(192.0.1.234) | |
5586 | INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) | |
5587 | INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) | |
5588 | TSi = (0, 0-65535, 192.0.1.234-192.0.1.234) | |
5589 | TSr = (0, 0-65535, 192.0.2.155-192.0.2.155) | |
5590 | ||
5591 | Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET is in | |
5592 | CFG_REQUESTs is unclear, they cannot be used reliably in | |
5593 | CFG_REQUESTs. | |
5594 | ||
d6bd078a MW |
5595 | |
5596 | ||
5597 | ||
5598 | ||
5599 | Kaufman, et al. Expires August 28, 2008 [Page 100] | |
5600 | \f | |
5601 | Internet-Draft IKEv2bis February 2008 | |
5602 | ||
5603 | ||
f91513e3 MW |
5604 | 3.15.3. Configuration payloads for IPv6 |
5605 | ||
5606 | {{ Added this section from Clarif-6.5 }} | |
5607 | ||
5608 | The configuration payloads for IPv6 are based on the corresponding | |
5609 | IPv4 payloads, and do not fully follow the "normal IPv6 way of doing | |
5610 | things". In particular, IPv6 stateless autoconfiguration or router | |
5611 | advertisement messages are not used; neither is neighbor discovery. | |
5612 | ||
5613 | A client can be assigned an IPv6 address using the | |
5614 | INTERNAL_IP6_ADDRESS configuration payload. A minimal exchange might | |
5615 | look like this: | |
5616 | ||
5617 | CP(CFG_REQUEST) = | |
5618 | INTERNAL_IP6_ADDRESS() | |
5619 | INTERNAL_IP6_DNS() | |
5620 | TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) | |
5621 | TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) | |
5622 | ||
5623 | CP(CFG_REPLY) = | |
5624 | INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) | |
5625 | INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44) | |
5626 | TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5) | |
5627 | TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) | |
5628 | ||
5629 | The client MAY send a non-empty INTERNAL_IP6_ADDRESS attribute in the | |
5630 | CFG_REQUEST to request a specific address or interface identifier. | |
5631 | The gateway first checks if the specified address is acceptable, and | |
5632 | if it is, returns that one. If the address was not acceptable, the | |
5633 | gateway attempts to use the interface identifier with some other | |
5634 | prefix; if even that fails, the gateway selects another interface | |
5635 | identifier. | |
5636 | ||
5637 | The INTERNAL_IP6_ADDRESS attribute also contains a prefix length | |
5638 | field. When used in a CFG_REPLY, this corresponds to the | |
5639 | INTERNAL_IP4_NETMASK attribute in the IPv4 case. | |
5640 | ||
f91513e3 MW |
5641 | Although this approach to configuring IPv6 addresses is reasonably |
5642 | simple, it has some limitations. IPsec tunnels configured using | |
5643 | IKEv2 are not fully-featured "interfaces" in the IPv6 addressing | |
5644 | architecture sense [IPV6ADDR]. In particular, they do not | |
5645 | necessarily have link-local addresses, and this may complicate the | |
5646 | use of protocols that assume them, such as [MLDV2]. | |
5647 | ||
5648 | 3.15.4. Address Assignment Failures | |
5649 | ||
5650 | {{ Added this section from Clarif-6.8 }} | |
5651 | ||
d6bd078a MW |
5652 | |
5653 | ||
5654 | ||
5655 | Kaufman, et al. Expires August 28, 2008 [Page 101] | |
5656 | \f | |
5657 | Internet-Draft IKEv2bis February 2008 | |
5658 | ||
5659 | ||
f91513e3 | 5660 | If the responder encounters an error while attempting to assign an IP |
d6bd078a MW |
5661 | address to the initiator during the processing of a Configuration |
5662 | Payload, it responds with an INTERNAL_ADDRESS_FAILURE notification. | |
5663 | {{ 3.10.1-36 }} If this error is generated within an IKE_AUTH | |
5664 | exchange, no CHILD_SA will be created. However, there are some more | |
f91513e3 MW |
5665 | complex error cases. |
5666 | ||
5667 | If the responder does not support configuration payloads at all, it | |
5668 | can simply ignore all configuration payloads. This type of | |
5669 | implementation never sends INTERNAL_ADDRESS_FAILURE notifications. | |
5670 | If the initiator requires the assignment of an IP address, it will | |
5671 | treat a response without CFG_REPLY as an error. | |
5672 | ||
5673 | The initiator may request a particular type of address (IPv4 or IPv6) | |
5674 | that the responder does not support, even though the responder | |
5675 | supports configuration payloads. In this case, the responder simply | |
5676 | ignores the type of address it does not support and processes the | |
5677 | rest of the request as usual. | |
5678 | ||
5679 | If the initiator requests multiple addresses of a type that the | |
5680 | responder supports, and some (but not all) of the requests fail, the | |
5681 | responder replies with the successful addresses only. The responder | |
5682 | sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned. | |
5683 | ||
5684 | 3.16. Extensible Authentication Protocol (EAP) Payload | |
5685 | ||
5686 | The Extensible Authentication Protocol Payload, denoted EAP in this | |
5687 | memo, allows IKE_SAs to be authenticated using the protocol defined | |
5688 | in RFC 3748 [EAP] and subsequent extensions to that protocol. The | |
5689 | full set of acceptable values for the payload is defined elsewhere, | |
5690 | but a short summary of RFC 3748 is included here to make this | |
5691 | document stand alone in the common cases. | |
5692 | ||
f91513e3 MW |
5693 | 1 2 3 |
5694 | 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 | |
5695 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
d6bd078a | 5696 | | Next Payload |C| RESERVED | Payload Length | |
f91513e3 | 5697 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a | 5698 | | | |
f91513e3 | 5699 | ~ EAP Message ~ |
d6bd078a | 5700 | | | |
f91513e3 MW |
5701 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
5702 | ||
5703 | Figure 24: EAP Payload Format | |
5704 | ||
5705 | The payload type for an EAP Payload is forty eight (48). | |
5706 | ||
d6bd078a MW |
5707 | |
5708 | ||
5709 | ||
5710 | ||
5711 | Kaufman, et al. Expires August 28, 2008 [Page 102] | |
5712 | \f | |
5713 | Internet-Draft IKEv2bis February 2008 | |
5714 | ||
5715 | ||
f91513e3 MW |
5716 | 1 2 3 |
5717 | 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 | |
5718 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
d6bd078a | 5719 | | Code | Identifier | Length | |
f91513e3 | 5720 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
d6bd078a | 5721 | | Type | Type_Data... |
f91513e3 MW |
5722 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- |
5723 | ||
5724 | Figure 25: EAP Message Format | |
5725 | ||
5726 | o Code (1 octet) indicates whether this message is a Request (1), | |
5727 | Response (2), Success (3), or Failure (4). | |
5728 | ||
5729 | o Identifier (1 octet) is used in PPP to distinguish replayed | |
5730 | messages from repeated ones. Since in IKE, EAP runs over a | |
5731 | reliable protocol, it serves no function here. In a response | |
5732 | message, this octet MUST be set to match the identifier in the | |
5733 | corresponding request. In other messages, this field MAY be set | |
5734 | to any value. | |
5735 | ||
5736 | o Length (2 octets) is the length of the EAP message and MUST be | |
5737 | four less than the Payload Length of the encapsulating payload. | |
5738 | ||
5739 | o Type (1 octet) is present only if the Code field is Request (1) or | |
5740 | Response (2). For other codes, the EAP message length MUST be | |
5741 | four octets and the Type and Type_Data fields MUST NOT be present. | |
5742 | In a Request (1) message, Type indicates the data being requested. | |
5743 | In a Response (2) message, Type MUST either be Nak or match the | |
5744 | type of the data requested. The following types are defined in | |
5745 | RFC 3748: | |
5746 | ||
f91513e3 MW |
5747 | 1 Identity |
5748 | 2 Notification | |
5749 | 3 Nak (Response Only) | |
5750 | 4 MD5-Challenge | |
5751 | 5 One-Time Password (OTP) | |
5752 | 6 Generic Token Card | |
5753 | ||
5754 | o Type_Data (Variable Length) varies with the Type of Request and | |
5755 | the associated Response. For the documentation of the EAP | |
5756 | methods, see [EAP]. | |
5757 | ||
5758 | {{ Demoted the SHOULD NOT and SHOULD }} Note that since IKE passes an | |
5759 | indication of initiator identity in message 3 of the protocol, the | |
5760 | responder should not send EAP Identity requests. The initiator may, | |
5761 | however, respond to such requests if it receives them. | |
5762 | ||
5763 | ||
d6bd078a MW |
5764 | |
5765 | ||
5766 | ||
5767 | Kaufman, et al. Expires August 28, 2008 [Page 103] | |
5768 | \f | |
5769 | Internet-Draft IKEv2bis February 2008 | |
5770 | ||
5771 | ||
f91513e3 MW |
5772 | 4. Conformance Requirements |
5773 | ||
5774 | In order to assure that all implementations of IKEv2 can | |
5775 | interoperate, there are "MUST support" requirements in addition to | |
5776 | those listed elsewhere. Of course, IKEv2 is a security protocol, and | |
5777 | one of its major functions is to allow only authorized parties to | |
5778 | successfully complete establishment of SAs. So a particular | |
5779 | implementation may be configured with any of a number of restrictions | |
5780 | concerning algorithms and trusted authorities that will prevent | |
5781 | universal interoperability. | |
5782 | ||
5783 | IKEv2 is designed to permit minimal implementations that can | |
5784 | interoperate with all compliant implementations. There are a series | |
5785 | of optional features that can easily be ignored by a particular | |
5786 | implementation if it does not support that feature. Those features | |
5787 | include: | |
5788 | ||
5789 | o Ability to negotiate SAs through a NAT and tunnel the resulting | |
5790 | ESP SA over UDP. | |
5791 | ||
5792 | o Ability to request (and respond to a request for) a temporary IP | |
5793 | address on the remote end of a tunnel. | |
5794 | ||
5795 | o Ability to support various types of legacy authentication. | |
5796 | ||
5797 | o Ability to support window sizes greater than one. | |
5798 | ||
5799 | o Ability to establish multiple ESP and/or AH SAs within a single | |
5800 | IKE_SA. | |
5801 | ||
f91513e3 MW |
5802 | o Ability to rekey SAs. |
5803 | ||
5804 | To assure interoperability, all implementations MUST be capable of | |
5805 | parsing all payload types (if only to skip over them) and to ignore | |
5806 | payload types that it does not support unless the critical bit is set | |
5807 | in the payload header. If the critical bit is set in an unsupported | |
5808 | payload header, all implementations MUST reject the messages | |
5809 | containing those payloads. | |
5810 | ||
5811 | Every implementation MUST be capable of doing four-message | |
5812 | IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE, | |
5813 | one for ESP and/or AH). Implementations MAY be initiate-only or | |
5814 | respond-only if appropriate for their platform. Every implementation | |
5815 | MUST be capable of responding to an INFORMATIONAL exchange, but a | |
5816 | minimal implementation MAY respond to any INFORMATIONAL message with | |
5817 | an empty INFORMATIONAL reply (note that within the context of an | |
5818 | IKE_SA, an "empty" message consists of an IKE header followed by an | |
5819 | Encrypted payload with no payloads contained in it). A minimal | |
d6bd078a MW |
5820 | |
5821 | ||
5822 | ||
5823 | Kaufman, et al. Expires August 28, 2008 [Page 104] | |
5824 | \f | |
5825 | Internet-Draft IKEv2bis February 2008 | |
5826 | ||
5827 | ||
f91513e3 MW |
5828 | implementation MAY support the CREATE_CHILD_SA exchange only in so |
5829 | far as to recognize requests and reject them with a Notify payload of | |
5830 | type NO_ADDITIONAL_SAS. A minimal implementation need not be able to | |
5831 | initiate CREATE_CHILD_SA or INFORMATIONAL exchanges. When an SA | |
5832 | expires (based on locally configured values of either lifetime or | |
5833 | octets passed), and implementation MAY either try to renew it with a | |
5834 | CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and | |
5835 | create a new one. If the responder rejects the CREATE_CHILD_SA | |
5836 | request with a NO_ADDITIONAL_SAS notification, the implementation | |
5837 | MUST be capable of instead deleting the old SA and creating a new | |
5838 | one. | |
5839 | ||
5840 | Implementations are not required to support requesting temporary IP | |
5841 | addresses or responding to such requests. If an implementation does | |
5842 | support issuing such requests, it MUST include a CP payload in | |
5843 | message 3 containing at least a field of type INTERNAL_IP4_ADDRESS or | |
5844 | INTERNAL_IP6_ADDRESS. All other fields are optional. If an | |
5845 | implementation supports responding to such requests, it MUST parse | |
5846 | the CP payload of type CFG_REQUEST in message 3 and recognize a field | |
5847 | of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports | |
5848 | leasing an address of the appropriate type, it MUST return a CP | |
5849 | payload of type CFG_REPLY containing an address of the requested | |
5850 | type. {{ Demoted the SHOULD }} The responder may include any other | |
5851 | related attributes. | |
5852 | ||
5853 | A minimal IPv4 responder implementation will ignore the contents of | |
5854 | the CP payload except to determine that it includes an | |
5855 | INTERNAL_IP4_ADDRESS attribute and will respond with the address and | |
5856 | other related attributes regardless of whether the initiator | |
5857 | requested them. | |
5858 | ||
f91513e3 MW |
5859 | A minimal IPv4 initiator will generate a CP payload containing only |
5860 | an INTERNAL_IP4_ADDRESS attribute and will parse the response | |
d6bd078a | 5861 | ignoring attributes it does not know how to use. |
f91513e3 MW |
5862 | |
5863 | For an implementation to be called conforming to this specification, | |
5864 | it MUST be possible to configure it to accept the following: | |
5865 | ||
5866 | o PKIX Certificates containing and signed by RSA keys of size 1024 | |
5867 | or 2048 bits, where the ID passed is any of ID_KEY_ID, ID_FQDN, | |
5868 | ID_RFC822_ADDR, or ID_DER_ASN1_DN. | |
5869 | ||
d6bd078a | 5870 | o Shared key authentication where the ID passed is any of ID_KEY_ID, |
f91513e3 MW |
5871 | ID_FQDN, or ID_RFC822_ADDR. |
5872 | ||
5873 | o Authentication where the responder is authenticated using PKIX | |
5874 | Certificates and the initiator is authenticated using shared key | |
5875 | authentication. | |
5876 | ||
5877 | ||
d6bd078a MW |
5878 | |
5879 | Kaufman, et al. Expires August 28, 2008 [Page 105] | |
5880 | \f | |
5881 | Internet-Draft IKEv2bis February 2008 | |
5882 | ||
5883 | ||
f91513e3 MW |
5884 | 5. Security Considerations |
5885 | ||
5886 | While this protocol is designed to minimize disclosure of | |
5887 | configuration information to unauthenticated peers, some such | |
5888 | disclosure is unavoidable. One peer or the other must identify | |
5889 | itself first and prove its identity first. To avoid probing, the | |
5890 | initiator of an exchange is required to identify itself first, and | |
5891 | usually is required to authenticate itself first. The initiator can, | |
5892 | however, learn that the responder supports IKE and what cryptographic | |
5893 | protocols it supports. The responder (or someone impersonating the | |
5894 | responder) can probe the initiator not only for its identity, but | |
5895 | using CERTREQ payloads may be able to determine what certificates the | |
5896 | initiator is willing to use. | |
5897 | ||
5898 | Use of EAP authentication changes the probing possibilities somewhat. | |
5899 | When EAP authentication is used, the responder proves its identity | |
5900 | before the initiator does, so an initiator that knew the name of a | |
5901 | valid initiator could probe the responder for both its name and | |
5902 | certificates. | |
5903 | ||
5904 | Repeated rekeying using CREATE_CHILD_SA without additional Diffie- | |
5905 | Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a | |
5906 | single key or overrun of either endpoint. Implementers should take | |
5907 | note of this fact and set a limit on CREATE_CHILD_SA exchanges | |
5908 | between exponentiations. This memo does not prescribe such a limit. | |
5909 | ||
f91513e3 MW |
5910 | The strength of a key derived from a Diffie-Hellman exchange using |
5911 | any of the groups defined here depends on the inherent strength of | |
5912 | the group, the size of the exponent used, and the entropy provided by | |
5913 | the random number generator used. Due to these inputs, it is | |
5914 | difficult to determine the strength of a key for any of the defined | |
5915 | groups. Diffie-Hellman group number two, when used with a strong | |
5916 | random number generator and an exponent no less than 200 bits, is | |
5917 | common for use with 3DES. Group five provides greater security than | |
5918 | group two. Group one is for historic purposes only and does not | |
5919 | provide sufficient strength except for use with DES, which is also | |
5920 | for historic use only. Implementations should make note of these | |
5921 | estimates when establishing policy and negotiating security | |
5922 | parameters. | |
5923 | ||
5924 | Note that these limitations are on the Diffie-Hellman groups | |
5925 | themselves. There is nothing in IKE that prohibits using stronger | |
5926 | groups nor is there anything that will dilute the strength obtained | |
5927 | from stronger groups (limited by the strength of the other algorithms | |
5928 | negotiated including the prf function). In fact, the extensible | |
5929 | framework of IKE encourages the definition of more groups; use of | |
5930 | elliptical curve groups may greatly increase strength using much | |
5931 | smaller numbers. | |
5932 | ||
d6bd078a MW |
5933 | |
5934 | ||
5935 | Kaufman, et al. Expires August 28, 2008 [Page 106] | |
5936 | \f | |
5937 | Internet-Draft IKEv2bis February 2008 | |
5938 | ||
5939 | ||
f91513e3 MW |
5940 | It is assumed that all Diffie-Hellman exponents are erased from |
5941 | memory after use. In particular, these exponents MUST NOT be derived | |
5942 | from long-lived secrets like the seed to a pseudo-random generator | |
5943 | that is not erased after use. | |
5944 | ||
5945 | The strength of all keys is limited by the size of the output of the | |
5946 | negotiated prf function. For this reason, a prf function whose | |
5947 | output is less than 128 bits (e.g., 3DES-CBC) MUST NOT be used with | |
5948 | this protocol. | |
5949 | ||
5950 | The security of this protocol is critically dependent on the | |
5951 | randomness of the randomly chosen parameters. These should be | |
5952 | generated by a strong random or properly seeded pseudo-random source | |
5953 | (see [RANDOMNESS]). Implementers should take care to ensure that use | |
5954 | of random numbers for both keys and nonces is engineered in a fashion | |
5955 | that does not undermine the security of the keys. | |
5956 | ||
5957 | For information on the rationale of many of the cryptographic design | |
5958 | choices in this protocol, see [SIGMA] and [SKEME]. Though the | |
5959 | security of negotiated CHILD_SAs does not depend on the strength of | |
5960 | the encryption and integrity protection negotiated in the IKE_SA, | |
5961 | implementations MUST NOT negotiate NONE as the IKE integrity | |
5962 | protection algorithm or ENCR_NULL as the IKE encryption algorithm. | |
5963 | ||
5964 | When using pre-shared keys, a critical consideration is how to assure | |
f91513e3 MW |
5965 | the randomness of these secrets. The strongest practice is to ensure |
5966 | that any pre-shared key contain as much randomness as the strongest | |
5967 | key being negotiated. Deriving a shared secret from a password, | |
5968 | name, or other low-entropy source is not secure. These sources are | |
5969 | subject to dictionary and social engineering attacks, among others. | |
5970 | ||
5971 | The NAT_DETECTION_*_IP notifications contain a hash of the addresses | |
5972 | and ports in an attempt to hide internal IP addresses behind a NAT. | |
5973 | Since the IPv4 address space is only 32 bits, and it is usually very | |
5974 | sparse, it would be possible for an attacker to find out the internal | |
5975 | address used behind the NAT box by trying all possible IP addresses | |
5976 | and trying to find the matching hash. The port numbers are normally | |
5977 | fixed to 500, and the SPIs can be extracted from the packet. This | |
5978 | reduces the number of hash calculations to 2^32. With an educated | |
5979 | guess of the use of private address space, the number of hash | |
5980 | calculations is much smaller. Designers should therefore not assume | |
5981 | that use of IKE will not leak internal address information. | |
5982 | ||
5983 | When using an EAP authentication method that does not generate a | |
5984 | shared key for protecting a subsequent AUTH payload, certain man-in- | |
5985 | the-middle and server impersonation attacks are possible [EAPMITM]. | |
5986 | These vulnerabilities occur when EAP is also used in protocols that | |
5987 | are not protected with a secure tunnel. Since EAP is a general- | |
d6bd078a MW |
5988 | |
5989 | ||
5990 | ||
5991 | Kaufman, et al. Expires August 28, 2008 [Page 107] | |
5992 | \f | |
5993 | Internet-Draft IKEv2bis February 2008 | |
5994 | ||
5995 | ||
f91513e3 MW |
5996 | purpose authentication protocol, which is often used to provide |
5997 | single-signon facilities, a deployed IPsec solution that relies on an | |
5998 | EAP authentication method that does not generate a shared key (also | |
5999 | known as a non-key-generating EAP method) can become compromised due | |
6000 | to the deployment of an entirely unrelated application that also | |
6001 | happens to use the same non-key-generating EAP method, but in an | |
6002 | unprotected fashion. Note that this vulnerability is not limited to | |
6003 | just EAP, but can occur in other scenarios where an authentication | |
6004 | infrastructure is reused. For example, if the EAP mechanism used by | |
6005 | IKEv2 utilizes a token authenticator, a man-in-the-middle attacker | |
6006 | could impersonate the web server, intercept the token authentication | |
6007 | exchange, and use it to initiate an IKEv2 connection. For this | |
6008 | reason, use of non-key-generating EAP methods SHOULD be avoided where | |
6009 | possible. Where they are used, it is extremely important that all | |
6010 | usages of these EAP methods SHOULD utilize a protected tunnel, where | |
6011 | the initiator validates the responder's certificate before initiating | |
6012 | the EAP exchange. {{ Demoted the SHOULD }} Implementers should | |
6013 | describe the vulnerabilities of using non-key-generating EAP methods | |
6014 | in the documentation of their implementations so that the | |
6015 | administrators deploying IPsec solutions are aware of these dangers. | |
6016 | ||
d6bd078a MW |
6017 | An implementation using EAP MUST also use strong authentication of |
6018 | the server to the client before the EAP exchange begins, even if the | |
6019 | EAP method offers mutual authentication. This avoids having | |
6020 | additional IKEv2 protocol variations and protects the EAP data from | |
6021 | active attackers. | |
f91513e3 MW |
6022 | |
6023 | If the messages of IKEv2 are long enough that IP-level fragmentation | |
6024 | is necessary, it is possible that attackers could prevent the | |
6025 | exchange from completing by exhausting the reassembly buffers. The | |
6026 | chances of this can be minimized by using the Hash and URL encodings | |
6027 | instead of sending certificates (see Section 3.6). Additional | |
6028 | mitigations are discussed in [DOSUDPPROT]. | |
6029 | ||
6030 | 5.1. Traffic selector authorization | |
6031 | ||
6032 | {{ Added this section from Clarif-4.13 }} | |
6033 | ||
6034 | IKEv2 relies on information in the Peer Authorization Database (PAD) | |
6035 | when determining what kind of IPsec SAs a peer is allowed to create. | |
6036 | This process is described in [IPSECARCH] Section 4.4.3. When a peer | |
6037 | requests the creation of an IPsec SA with some traffic selectors, the | |
6038 | PAD must contain "Child SA Authorization Data" linking the identity | |
6039 | authenticated by IKEv2 and the addresses permitted for traffic | |
6040 | selectors. | |
6041 | ||
6042 | For example, the PAD might be configured so that authenticated | |
6043 | identity "sgw23.example.com" is allowed to create IPsec SAs for | |
d6bd078a MW |
6044 | |
6045 | ||
6046 | ||
6047 | Kaufman, et al. Expires August 28, 2008 [Page 108] | |
6048 | \f | |
6049 | Internet-Draft IKEv2bis February 2008 | |
6050 | ||
6051 | ||
f91513e3 MW |
6052 | 192.0.2.0/24, meaning this security gateway is a valid |
6053 | "representative" for these addresses. Host-to-host IPsec requires | |
6054 | similar entries, linking, for example, "fooserver4.example.com" with | |
6055 | 192.0.1.66/32, meaning this identity a valid "owner" or | |
6056 | "representative" of the address in question. | |
6057 | ||
6058 | As noted in [IPSECARCH], "It is necessary to impose these constraints | |
6059 | on creation of child SAs to prevent an authenticated peer from | |
6060 | spoofing IDs associated with other, legitimate peers." In the | |
6061 | example given above, a correct configuration of the PAD prevents | |
6062 | sgw23 from creating IPsec SAs with address 192.0.1.66, and prevents | |
6063 | fooserver4 from creating IPsec SAs with addresses from 192.0.2.0/24. | |
6064 | ||
6065 | It is important to note that simply sending IKEv2 packets using some | |
6066 | particular address does not imply a permission to create IPsec SAs | |
6067 | with that address in the traffic selectors. For example, even if | |
6068 | sgw23 would be able to spoof its IP address as 192.0.1.66, it could | |
6069 | not create IPsec SAs matching fooserver4's traffic. | |
6070 | ||
6071 | The IKEv2 specification does not specify how exactly IP address | |
6072 | assignment using configuration payloads interacts with the PAD. Our | |
6073 | interpretation is that when a security gateway assigns an address | |
6074 | using configuration payloads, it also creates a temporary PAD entry | |
6075 | linking the authenticated peer identity and the newly allocated inner | |
6076 | address. | |
6077 | ||
f91513e3 MW |
6078 | It has been recognized that configuring the PAD correctly may be |
6079 | difficult in some environments. For instance, if IPsec is used | |
6080 | between a pair of hosts whose addresses are allocated dynamically | |
6081 | using DHCP, it is extremely difficult to ensure that the PAD | |
6082 | specifies the correct "owner" for each IP address. This would | |
6083 | require a mechanism to securely convey address assignments from the | |
6084 | DHCP server, and link them to identities authenticated using IKEv2. | |
6085 | ||
6086 | Due to this limitation, some vendors have been known to configure | |
6087 | their PADs to allow an authenticated peer to create IPsec SAs with | |
6088 | traffic selectors containing the same address that was used for the | |
6089 | IKEv2 packets. In environments where IP spoofing is possible (i.e., | |
6090 | almost everywhere) this essentially allows any peer to create IPsec | |
6091 | SAs with any traffic selectors. This is not an appropriate or secure | |
6092 | configuration in most circumstances. See [H2HIPSEC] for an extensive | |
6093 | discussion about this issue, and the limitations of host-to-host | |
6094 | IPsec in general. | |
6095 | ||
6096 | ||
6097 | 6. IANA Considerations | |
6098 | ||
6099 | {{ This section was changed to not re-define any new IANA registries. | |
d6bd078a MW |
6100 | |
6101 | ||
6102 | ||
6103 | Kaufman, et al. Expires August 28, 2008 [Page 109] | |
6104 | \f | |
6105 | Internet-Draft IKEv2bis February 2008 | |
6106 | ||
6107 | ||
f91513e3 MW |
6108 | }} |
6109 | ||
6110 | [IKEV2] defined many field types and values. IANA has already | |
6111 | registered those types and values, so the are not listed here again. | |
d6bd078a MW |
6112 | No new types or values are registered in this document. However, |
6113 | IANA should update all references to RFC 4306 to point to this | |
6114 | document. | |
f91513e3 MW |
6115 | |
6116 | ||
6117 | 7. Acknowledgements | |
6118 | ||
d6bd078a MW |
6119 | The individuals on the IPsec mailing list was very helpful in both |
6120 | pointing out where clarifications and changes were needed, as well as | |
6121 | in reviewing the clarifications suggested by others. | |
6122 | ||
f91513e3 MW |
6123 | The acknowledgements from the IKEv2 document were: |
6124 | ||
6125 | This document is a collaborative effort of the entire IPsec WG. If | |
6126 | there were no limit to the number of authors that could appear on an | |
6127 | RFC, the following, in alphabetical order, would have been listed: | |
6128 | Bill Aiello, Stephane Beaulieu, Steve Bellovin, Sara Bitan, Matt | |
6129 | Blaze, Ran Canetti, Darren Dukes, Dan Harkins, Paul Hoffman, John | |
6130 | Ioannidis, Charlie Kaufman, Steve Kent, Angelos Keromytis, Tero | |
6131 | Kivinen, Hugo Krawczyk, Andrew Krywaniuk, Radia Perlman, Omer | |
6132 | Reingold, and Michael Richardson. Many other people contributed to | |
6133 | the design. It is an evolution of IKEv1, ISAKMP, and the IPsec DOI, | |
6134 | each of which has its own list of authors. Hugh Daniel suggested the | |
6135 | feature of having the initiator, in message 3, specify a name for the | |
6136 | responder, and gave the feature the cute name "You Tarzan, Me Jane". | |
6137 | David Faucher and Valery Smyzlov helped refine the design of the | |
6138 | traffic selector negotiation. | |
6139 | ||
f91513e3 | 6140 | This paragraph lists references that appear only in figures. The |
d6bd078a MW |
6141 | section is only here to keep the 'xml2rfc' program happy, and needs |
6142 | to be removed when the document is published. Feel free to ignore | |
6143 | it. [DES] [IDEA] [MD5] [X.501] [X.509] | |
f91513e3 MW |
6144 | |
6145 | ||
6146 | 8. References | |
6147 | ||
6148 | 8.1. Normative References | |
6149 | ||
6150 | [ADDGROUP] | |
6151 | Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) | |
6152 | Diffie-Hellman groups for Internet Key Exchange (IKE)", | |
6153 | RFC 3526, May 2003. | |
6154 | ||
6155 | [ADDRIPV6] | |
f91513e3 | 6156 | |
d6bd078a MW |
6157 | |
6158 | ||
6159 | Kaufman, et al. Expires August 28, 2008 [Page 110] | |
6160 | \f | |
6161 | Internet-Draft IKEv2bis February 2008 | |
6162 | ||
6163 | ||
6164 | Hinden, R. and S. Deering, "Internet Protocol Version 6 | |
6165 | (IPv6) Addressing Architecture", RFC 4291, February 2006. | |
f91513e3 MW |
6166 | |
6167 | [EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. | |
6168 | Levkowetz, "Extensible Authentication Protocol (EAP)", | |
6169 | RFC 3748, June 2004. | |
6170 | ||
6171 | [ECN] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition | |
6172 | of Explicit Congestion Notification (ECN) to IP", | |
6173 | RFC 3168, September 2001. | |
6174 | ||
6175 | [ESPCBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher | |
6176 | Algorithms", RFC 2451, November 1998. | |
6177 | ||
f91513e3 MW |
6178 | [IPSECARCH] |
6179 | Kent, S. and K. Seo, "Security Architecture for the | |
6180 | Internet Protocol", RFC 4301, December 2005. | |
6181 | ||
6182 | [MUSTSHOULD] | |
6183 | Bradner, S., "Key Words for use in RFCs to indicate | |
6184 | Requirement Levels", BCP 14, RFC 2119, March 1997. | |
6185 | ||
d6bd078a MW |
6186 | [PKCS1] Jonsson, J. and B. Kaliski, "Public-Key Cryptography |
6187 | Standards (PKCS) #1: RSA Cryptography Specifications | |
6188 | Version 2.1", RFC 3447, February 2003. | |
f91513e3 MW |
6189 | |
6190 | [PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet | |
6191 | X.509 Public Key Infrastructure Certificate and | |
6192 | Certificate Revocation List (CRL) Profile", RFC 3280, | |
6193 | April 2002. | |
6194 | ||
d6bd078a MW |
6195 | [RFC4434] Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the |
6196 | Internet Key Exchange Protocol (IKE)", RFC 4434, | |
6197 | February 2006. | |
6198 | ||
6199 | [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The | |
6200 | Advanced Encryption Standard-Cipher-based Message | |
6201 | Authentication Code-Pseudo-Random Function-128 (AES-CMAC- | |
6202 | PRF-128) Algorithm for the Internet Key Exchange Protocol | |
6203 | (IKE)", RFC 4615, August 2006. | |
6204 | ||
f91513e3 MW |
6205 | [UDPENCAPS] |
6206 | Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. | |
6207 | Stenberg, "UDP Encapsulation of IPsec ESP Packets", | |
6208 | RFC 3948, January 2005. | |
6209 | ||
d6bd078a MW |
6210 | |
6211 | ||
6212 | ||
6213 | ||
6214 | ||
6215 | Kaufman, et al. Expires August 28, 2008 [Page 111] | |
6216 | \f | |
6217 | Internet-Draft IKEv2bis February 2008 | |
6218 | ||
6219 | ||
f91513e3 MW |
6220 | 8.2. Informative References |
6221 | ||
6222 | [AH] Kent, S., "IP Authentication Header", RFC 4302, | |
6223 | December 2005. | |
6224 | ||
6225 | [ARCHGUIDEPHIL] | |
6226 | Bush, R. and D. Meyer, "Some Internet Architectural | |
6227 | Guidelines and Philosophy", RFC 3439, December 2002. | |
6228 | ||
6229 | [ARCHPRINC] | |
6230 | Carpenter, B., "Architectural Principles of the Internet", | |
6231 | RFC 1958, June 1996. | |
6232 | ||
d6bd078a MW |
6233 | [Clarif] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and |
6234 | Implementation Guidelines", RFC 4718, October 2006. | |
6235 | ||
f91513e3 MW |
6236 | [DES] American National Standards Institute, "American National |
6237 | Standard for Information Systems-Data Link Encryption", | |
6238 | ANSI X3.106, 1983. | |
6239 | ||
6240 | [DH] Diffie, W. and M. Hellman, "New Directions in | |
6241 | Cryptography", IEEE Transactions on Information Theory, | |
6242 | V.IT-22 n. 6, June 1977. | |
6243 | ||
6244 | [DHCP] Droms, R., "Dynamic Host Configuration Protocol", | |
6245 | RFC 2131, March 1997. | |
6246 | ||
6247 | [DIFFSERVARCH] | |
6248 | Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., | |
6249 | and W. Weiss, "An Architecture for Differentiated | |
6250 | Services", RFC 2475. | |
6251 | ||
6252 | [DIFFSERVFIELD] | |
6253 | Nichols, K., Blake, S., Baker, F., and D. Black, | |
6254 | "Definition of the Differentiated Services Field (DS | |
6255 | Field) in the IPv4 and IPv6 Headers", RFC 2474, | |
6256 | December 1998. | |
6257 | ||
6258 | [DIFFTUNNEL] | |
6259 | Black, D., "Differentiated Services and Tunnels", | |
6260 | RFC 2983, October 2000. | |
6261 | ||
f91513e3 MW |
6262 | [DOI] Piper, D., "The Internet IP Security Domain of |
6263 | Interpretation for ISAKMP", RFC 2407, November 1998. | |
6264 | ||
6265 | [DOSUDPPROT] | |
6266 | C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection | |
6267 | for UDP-based protocols", ACM Conference on Computer and | |
d6bd078a MW |
6268 | |
6269 | ||
6270 | ||
6271 | Kaufman, et al. Expires August 28, 2008 [Page 112] | |
6272 | \f | |
6273 | Internet-Draft IKEv2bis February 2008 | |
6274 | ||
6275 | ||
f91513e3 MW |
6276 | Communications Security , October 2003. |
6277 | ||
6278 | [DSS] National Institute of Standards and Technology, U.S. | |
6279 | Department of Commerce, "Digital Signature Standard", | |
6280 | FIPS 186, May 1994. | |
6281 | ||
6282 | [EAPMITM] N. Asokan, V. Nierni, and K. Nyberg, "Man-in-the-Middle in | |
6283 | Tunneled Authentication Protocols", November 2002, | |
6284 | <http://eprint.iacr.org/2002/163>. | |
6285 | ||
6286 | [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", | |
6287 | RFC 4303, December 2005. | |
6288 | ||
6289 | [EXCHANGEANALYSIS] | |
6290 | R. Perlman and C. Kaufman, "Analysis of the IPsec key | |
6291 | exchange Standard", WET-ICE Security Conference, MIT , | |
6292 | 2001, | |
6293 | <http://sec.femto.org/wetice-2001/papers/radia-paper.pdf>. | |
6294 | ||
6295 | [H2HIPSEC] | |
6296 | Aura, T., Roe, M., and A. Mohammed, "Experiences with | |
6297 | Host-to-Host IPsec", 13th International Workshop on | |
6298 | Security Protocols, Cambridge, UK, April 2005. | |
6299 | ||
6300 | [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- | |
6301 | Hashing for Message Authentication", RFC 2104, | |
6302 | February 1997. | |
6303 | ||
6304 | [IDEA] X. Lai, "On the Design and Security of Block Ciphers", ETH | |
6305 | Series in Information Processing, v. 1, Konstanz: Hartung- | |
6306 | Gorre Verlag, 1992. | |
6307 | ||
d6bd078a MW |
6308 | [IDNA] Faltstrom, P., Hoffman, P., and A. Costello, |
6309 | "Internationalizing Domain Names in Applications (IDNA)", | |
6310 | RFC 3490, March 2003. | |
6311 | ||
f91513e3 MW |
6312 | [IKEV1] Harkins, D. and D. Carrel, "The Internet Key Exchange |
6313 | (IKE)", RFC 2409, November 1998. | |
6314 | ||
d6bd078a MW |
6315 | [IKEV2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", |
6316 | RFC 4306, December 2005. | |
6317 | ||
f91513e3 MW |
6318 | [IPCOMP] Shacham, A., Monsour, B., Pereira, R., and M. Thomas, "IP |
6319 | Payload Compression Protocol (IPComp)", RFC 3173, | |
6320 | September 2001. | |
6321 | ||
6322 | [IPSECARCH-OLD] | |
6323 | Kent, S. and R. Atkinson, "Security Architecture for the | |
f91513e3 MW |
6324 | |
6325 | ||
6326 | ||
d6bd078a | 6327 | Kaufman, et al. Expires August 28, 2008 [Page 113] |
f91513e3 | 6328 | \f |
d6bd078a | 6329 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
6330 | |
6331 | ||
d6bd078a MW |
6332 | Internet Protocol", RFC 2401, November 1998. |
6333 | ||
f91513e3 MW |
6334 | [IPV6ADDR] |
6335 | Hinden, R. and S. Deering, "Internet Protocol Version 6 | |
6336 | (IPv6) Addressing Architecture", RFC 3513, April 2003. | |
6337 | ||
6338 | [ISAKMP] Maughan, D., Schneider, M., and M. Schertler, "Internet | |
6339 | Security Association and Key Management Protocol | |
6340 | (ISAKMP)", RFC 2408, November 1998. | |
6341 | ||
6342 | [LDAP] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory | |
6343 | Access Protocol (v3)", RFC 2251, December 1997. | |
6344 | ||
6345 | [MAILFORMAT] | |
6346 | Resnick, P., "Internet Message Format", RFC 2822, | |
6347 | April 2001. | |
6348 | ||
6349 | [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, | |
6350 | April 1992. | |
6351 | ||
6352 | [MIPV6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support | |
6353 | in IPv6", RFC 3775, June 2004. | |
6354 | ||
6355 | [MLDV2] Vida, R. and L. Costa, "Multicast Listener Discovery | |
6356 | Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. | |
6357 | ||
d6bd078a MW |
6358 | [MODES] National Institute of Standards and Technology, U.S. |
6359 | Department of Commerce, "Recommendation for Block Cipher | |
6360 | Modes of Operation", SP 800-38A, 2001. | |
6361 | ||
f91513e3 MW |
6362 | [NAI] Aboba, B. and M. Beadles, "The Network Access Identifier", |
6363 | RFC 2486, January 1999. | |
6364 | ||
6365 | [NATREQ] Aboba, B. and W. Dixon, "IPsec-Network Address Translation | |
6366 | (NAT) Compatibility Requirements", RFC 3715, March 2004. | |
6367 | ||
6368 | [OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", | |
6369 | RFC 2412, November 1998. | |
6370 | ||
6371 | [PFKEY] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key | |
6372 | Management API, Version 2", RFC 2367, July 1998. | |
6373 | ||
6374 | [PHOTURIS] | |
6375 | Karn, P. and W. Simpson, "Photuris: Session-Key Management | |
6376 | Protocol", RFC 2522, March 1999. | |
6377 | ||
d6bd078a MW |
6378 | [RADIUS] Rigney, C., Rubens, A., Simpson, W., and S. Willens, |
6379 | "Remote Authentication Dial In User Service (RADIUS)", | |
f91513e3 MW |
6380 | |
6381 | ||
6382 | ||
d6bd078a | 6383 | Kaufman, et al. Expires August 28, 2008 [Page 114] |
f91513e3 | 6384 | \f |
d6bd078a | 6385 | Internet-Draft IKEv2bis February 2008 |
f91513e3 | 6386 | |
f91513e3 | 6387 | |
f91513e3 MW |
6388 | RFC 2138, April 1997. |
6389 | ||
6390 | [RANDOMNESS] | |
6391 | Eastlake, D., Schiller, J., and S. Crocker, "Randomness | |
6392 | Requirements for Security", BCP 106, RFC 4086, June 2005. | |
6393 | ||
d6bd078a MW |
6394 | [REAUTH] Nir, Y., "Repeated Authentication in Internet Key Exchange |
6395 | (IKEv2) Protocol", RFC 4478, April 2006. | |
f91513e3 MW |
6396 | |
6397 | [RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for | |
6398 | Obtaining Digital Signatures and Public-Key | |
6399 | Cryptosystems", February 1978. | |
6400 | ||
6401 | [SHA] National Institute of Standards and Technology, U.S. | |
6402 | Department of Commerce, "Secure Hash Standard", | |
6403 | FIPS 180-1, May 1994. | |
6404 | ||
6405 | [SIGMA] H. Krawczyk, "SIGMA: the `SIGn-and-MAc' Approach to | |
6406 | Authenticated Diffie-Hellman and its Use in the IKE | |
6407 | Protocols", Advances in Cryptography - CRYPTO 2003 | |
6408 | Proceedings LNCS 2729, 2003, <http:// | |
6409 | www.informatik.uni-trier.de/~ley/db/conf/crypto/ | |
6410 | crypto2003.html>. | |
6411 | ||
6412 | [SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange | |
6413 | Mechanism for Internet", IEEE Proceedings of the 1996 | |
6414 | Symposium on Network and Distributed Systems Security , | |
6415 | 1996. | |
6416 | ||
6417 | [TRANSPARENCY] | |
6418 | Carpenter, B., "Internet Transparency", RFC 2775, | |
6419 | February 2000. | |
6420 | ||
6421 | [X.501] ITU-T, "Recommendation X.501: Information Technology - | |
6422 | Open Systems Interconnection - The Directory: Models", | |
6423 | 1993. | |
6424 | ||
6425 | [X.509] ITU-T, "Recommendation X.509 (1997 E): Information | |
6426 | Technology - Open Systems Interconnection - The Directory: | |
6427 | Authentication Framework", 1997. | |
6428 | ||
6429 | ||
d6bd078a MW |
6430 | Appendix A. Summary of changes from IKEv1 |
6431 | ||
6432 | The goals of this revision to IKE are: | |
f91513e3 MW |
6433 | |
6434 | ||
f91513e3 MW |
6435 | |
6436 | ||
f91513e3 | 6437 | |
d6bd078a MW |
6438 | |
6439 | Kaufman, et al. Expires August 28, 2008 [Page 115] | |
6440 | \f | |
6441 | Internet-Draft IKEv2bis February 2008 | |
6442 | ||
f91513e3 MW |
6443 | |
6444 | 1. To define the entire IKE protocol in a single document, | |
6445 | replacing RFCs 2407, 2408, and 2409 and incorporating subsequent | |
6446 | changes to support NAT Traversal, Extensible Authentication, and | |
6447 | Remote Address acquisition; | |
6448 | ||
6449 | 2. To simplify IKE by replacing the eight different initial | |
6450 | exchanges with a single four-message exchange (with changes in | |
6451 | authentication mechanisms affecting only a single AUTH payload | |
6452 | rather than restructuring the entire exchange) see | |
6453 | [EXCHANGEANALYSIS]; | |
6454 | ||
6455 | 3. To remove the Domain of Interpretation (DOI), Situation (SIT), | |
6456 | and Labeled Domain Identifier fields, and the Commit and | |
6457 | Authentication only bits; | |
6458 | ||
6459 | 4. To decrease IKE's latency in the common case by making the | |
6460 | initial exchange be 2 round trips (4 messages), and allowing the | |
6461 | ability to piggyback setup of a CHILD_SA on that exchange; | |
6462 | ||
6463 | 5. To replace the cryptographic syntax for protecting the IKE | |
6464 | messages themselves with one based closely on ESP to simplify | |
6465 | implementation and security analysis; | |
6466 | ||
6467 | 6. To reduce the number of possible error states by making the | |
6468 | protocol reliable (all messages are acknowledged) and sequenced. | |
6469 | This allows shortening CREATE_CHILD_SA exchanges from 3 messages | |
6470 | to 2; | |
6471 | ||
6472 | 7. To increase robustness by allowing the responder to not do | |
6473 | significant processing until it receives a message proving that | |
d6bd078a | 6474 | the initiator can receive messages at its claimed IP address; |
f91513e3 MW |
6475 | |
6476 | 8. To fix cryptographic weaknesses such as the problem with | |
6477 | symmetries in hashes used for authentication documented by Tero | |
6478 | Kivinen; | |
6479 | ||
6480 | 9. To specify Traffic Selectors in their own payloads type rather | |
6481 | than overloading ID payloads, and making more flexible the | |
6482 | Traffic Selectors that may be specified; | |
6483 | ||
6484 | 10. To specify required behavior under certain error conditions or | |
6485 | when data that is not understood is received in order to make it | |
d6bd078a MW |
6486 | easier to make future revisions in a way that does not break |
6487 | backwards compatibility; | |
f91513e3 | 6488 | |
d6bd078a MW |
6489 | 11. To simplify and clarify how shared state is maintained in the |
6490 | presence of network failures and Denial of Service attacks; and | |
f91513e3 MW |
6491 | |
6492 | ||
f91513e3 MW |
6493 | |
6494 | ||
d6bd078a MW |
6495 | Kaufman, et al. Expires August 28, 2008 [Page 116] |
6496 | \f | |
6497 | Internet-Draft IKEv2bis February 2008 | |
f91513e3 | 6498 | |
f91513e3 MW |
6499 | |
6500 | 12. To maintain existing syntax and magic numbers to the extent | |
6501 | possible to make it likely that implementations of IKEv1 can be | |
6502 | enhanced to support IKEv2 with minimum effort. | |
6503 | ||
6504 | ||
6505 | Appendix B. Diffie-Hellman Groups | |
6506 | ||
6507 | There are two Diffie-Hellman groups defined here for use in IKE. | |
6508 | These groups were generated by Richard Schroeppel at the University | |
6509 | of Arizona. Properties of these primes are described in [OAKLEY]. | |
6510 | ||
6511 | The strength supplied by group one may not be sufficient for the | |
6512 | mandatory-to-implement encryption algorithm and is here for historic | |
6513 | reasons. | |
6514 | ||
6515 | Additional Diffie-Hellman groups have been defined in [ADDGROUP]. | |
6516 | ||
6517 | B.1. Group 1 - 768 Bit MODP | |
6518 | ||
6519 | This group is assigned id 1 (one). | |
6520 | ||
6521 | The prime is: 2^768 - 2 ^704 - 1 + 2^64 * { [2^638 pi] + 149686 } | |
6522 | Its hexadecimal value is: | |
6523 | ||
6524 | FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 | |
6525 | 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD | |
6526 | EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 | |
6527 | E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF | |
6528 | ||
6529 | The generator is 2. | |
6530 | ||
6531 | B.2. Group 2 - 1024 Bit MODP | |
6532 | ||
6533 | This group is assigned id 2 (two). | |
6534 | ||
f91513e3 MW |
6535 | The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }. |
6536 | Its hexadecimal value is: | |
6537 | ||
6538 | FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1 | |
6539 | 29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD | |
6540 | EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245 | |
6541 | E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED | |
6542 | EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381 | |
6543 | FFFFFFFF FFFFFFFF | |
6544 | ||
6545 | The generator is 2. | |
6546 | ||
6547 | ||
d6bd078a MW |
6548 | |
6549 | ||
6550 | ||
6551 | Kaufman, et al. Expires August 28, 2008 [Page 117] | |
6552 | \f | |
6553 | Internet-Draft IKEv2bis February 2008 | |
6554 | ||
6555 | ||
f91513e3 MW |
6556 | Appendix C. Exchanges and Payloads |
6557 | ||
6558 | {{ Clarif-AppA }} | |
6559 | ||
6560 | This appendix contains a short summary of the IKEv2 exchanges, and | |
6561 | what payloads can appear in which message. This appendix is purely | |
6562 | informative; if it disagrees with the body of this document, the | |
6563 | other text is considered correct. | |
6564 | ||
6565 | Vendor-ID (V) payloads may be included in any place in any message. | |
6566 | This sequence here shows what are the most logical places for them. | |
6567 | ||
6568 | C.1. IKE_SA_INIT Exchange | |
6569 | ||
6570 | request --> [N(COOKIE)], | |
6571 | SA, KE, Ni, | |
6572 | [N(NAT_DETECTION_SOURCE_IP)+, | |
6573 | N(NAT_DETECTION_DESTINATION_IP)], | |
6574 | [V+] | |
6575 | ||
6576 | normal response <-- SA, KE, Nr, | |
6577 | (no cookie) [N(NAT_DETECTION_SOURCE_IP), | |
6578 | N(NAT_DETECTION_DESTINATION_IP)], | |
6579 | [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], | |
6580 | [V+] | |
6581 | ||
6582 | ||
6583 | ||
6584 | ||
6585 | ||
6586 | ||
6587 | ||
6588 | ||
6589 | ||
6590 | ||
6591 | ||
6592 | ||
6593 | ||
d6bd078a MW |
6594 | |
6595 | ||
6596 | ||
6597 | ||
6598 | ||
6599 | ||
6600 | ||
6601 | ||
6602 | ||
6603 | ||
6604 | ||
6605 | ||
6606 | ||
6607 | Kaufman, et al. Expires August 28, 2008 [Page 118] | |
f91513e3 | 6608 | \f |
d6bd078a | 6609 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
6610 | |
6611 | ||
6612 | C.2. IKE_AUTH Exchange without EAP | |
6613 | ||
6614 | request --> IDi, [CERT+], | |
6615 | [N(INITIAL_CONTACT)], | |
6616 | [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], | |
6617 | [IDr], | |
6618 | AUTH, | |
6619 | [CP(CFG_REQUEST)], | |
6620 | [N(IPCOMP_SUPPORTED)+], | |
6621 | [N(USE_TRANSPORT_MODE)], | |
6622 | [N(ESP_TFC_PADDING_NOT_SUPPORTED)], | |
6623 | [N(NON_FIRST_FRAGMENTS_ALSO)], | |
6624 | SA, TSi, TSr, | |
6625 | [V+] | |
6626 | ||
6627 | response <-- IDr, [CERT+], | |
6628 | AUTH, | |
6629 | [CP(CFG_REPLY)], | |
6630 | [N(IPCOMP_SUPPORTED)], | |
6631 | [N(USE_TRANSPORT_MODE)], | |
6632 | [N(ESP_TFC_PADDING_NOT_SUPPORTED)], | |
6633 | [N(NON_FIRST_FRAGMENTS_ALSO)], | |
6634 | SA, TSi, TSr, | |
6635 | [N(ADDITIONAL_TS_POSSIBLE)], | |
6636 | [V+] | |
6637 | ||
6638 | ||
6639 | ||
6640 | ||
6641 | ||
6642 | ||
6643 | ||
6644 | ||
6645 | ||
6646 | ||
6647 | ||
6648 | ||
6649 | ||
6650 | ||
6651 | ||
6652 | ||
6653 | ||
6654 | ||
6655 | ||
6656 | ||
6657 | ||
6658 | ||
6659 | ||
6660 | ||
6661 | ||
6662 | ||
d6bd078a | 6663 | Kaufman, et al. Expires August 28, 2008 [Page 119] |
f91513e3 | 6664 | \f |
d6bd078a | 6665 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
6666 | |
6667 | ||
6668 | C.3. IKE_AUTH Exchange with EAP | |
6669 | ||
6670 | first request --> IDi, | |
6671 | [N(INITIAL_CONTACT)], | |
6672 | [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], | |
6673 | [IDr], | |
6674 | [CP(CFG_REQUEST)], | |
6675 | [N(IPCOMP_SUPPORTED)+], | |
6676 | [N(USE_TRANSPORT_MODE)], | |
6677 | [N(ESP_TFC_PADDING_NOT_SUPPORTED)], | |
6678 | [N(NON_FIRST_FRAGMENTS_ALSO)], | |
6679 | SA, TSi, TSr, | |
6680 | [V+] | |
6681 | ||
6682 | first response <-- IDr, [CERT+], AUTH, | |
6683 | EAP, | |
6684 | [V+] | |
6685 | ||
6686 | / --> EAP | |
6687 | repeat 1..N times | | |
6688 | \ <-- EAP | |
6689 | ||
6690 | last request --> AUTH | |
6691 | ||
6692 | last response <-- AUTH, | |
6693 | [CP(CFG_REPLY)], | |
6694 | [N(IPCOMP_SUPPORTED)], | |
6695 | [N(USE_TRANSPORT_MODE)], | |
6696 | [N(ESP_TFC_PADDING_NOT_SUPPORTED)], | |
6697 | [N(NON_FIRST_FRAGMENTS_ALSO)], | |
6698 | SA, TSi, TSr, | |
6699 | [N(ADDITIONAL_TS_POSSIBLE)], | |
6700 | [V+] | |
6701 | ||
6702 | ||
6703 | ||
6704 | ||
6705 | ||
6706 | ||
6707 | ||
6708 | ||
6709 | ||
6710 | ||
6711 | ||
6712 | ||
6713 | ||
6714 | ||
6715 | ||
6716 | ||
6717 | ||
6718 | ||
d6bd078a | 6719 | Kaufman, et al. Expires August 28, 2008 [Page 120] |
f91513e3 | 6720 | \f |
d6bd078a | 6721 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
6722 | |
6723 | ||
6724 | C.4. CREATE_CHILD_SA Exchange for Creating or Rekeying CHILD_SAs | |
6725 | ||
6726 | request --> [N(REKEY_SA)], | |
d6bd078a | 6727 | [CP(CFG_REQUEST)], |
f91513e3 MW |
6728 | [N(IPCOMP_SUPPORTED)+], |
6729 | [N(USE_TRANSPORT_MODE)], | |
6730 | [N(ESP_TFC_PADDING_NOT_SUPPORTED)], | |
6731 | [N(NON_FIRST_FRAGMENTS_ALSO)], | |
6732 | SA, Ni, [KEi], TSi, TSr | |
6733 | ||
d6bd078a MW |
6734 | response <-- [CP(CFG_REPLY)], |
6735 | [N(IPCOMP_SUPPORTED)], | |
f91513e3 MW |
6736 | [N(USE_TRANSPORT_MODE)], |
6737 | [N(ESP_TFC_PADDING_NOT_SUPPORTED)], | |
6738 | [N(NON_FIRST_FRAGMENTS_ALSO)], | |
6739 | SA, Nr, [KEr], TSi, TSr, | |
6740 | [N(ADDITIONAL_TS_POSSIBLE)] | |
6741 | ||
6742 | C.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA | |
6743 | ||
6744 | request --> SA, Ni, [KEi] | |
6745 | ||
6746 | response <-- SA, Nr, [KEr] | |
6747 | ||
6748 | C.6. INFORMATIONAL Exchange | |
6749 | ||
6750 | request --> [N+], | |
6751 | [D+], | |
6752 | [CP(CFG_REQUEST)] | |
6753 | ||
6754 | response <-- [N+], | |
6755 | [D+], | |
6756 | [CP(CFG_REPLY)] | |
6757 | ||
6758 | ||
6759 | Appendix D. Changes Between Internet Draft Versions | |
6760 | ||
d6bd078a MW |
6761 | This section will be removed before publication as an RFC, but should |
6762 | be left intact until then so that reviewers can follow what has | |
6763 | changed. | |
f91513e3 MW |
6764 | |
6765 | D.1. Changes from IKEv2 to draft -00 | |
6766 | ||
d6bd078a MW |
6767 | There were a zillion additions from RFC 4718. These are noted with |
6768 | "{{ Clarif-nn }}". | |
f91513e3 MW |
6769 | |
6770 | Cleaned up many of the figures. Made the table headings consistent. | |
6771 | Made some tables easier to read by removing blank spaces. Removed | |
f91513e3 MW |
6772 | |
6773 | ||
6774 | ||
d6bd078a | 6775 | Kaufman, et al. Expires August 28, 2008 [Page 121] |
f91513e3 | 6776 | \f |
d6bd078a | 6777 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
6778 | |
6779 | ||
d6bd078a | 6780 | the "reserved to IANA" and "private use" text wording and moved it |
f91513e3 MW |
6781 | into the tables. |
6782 | ||
6783 | Changed many SHOULD requirements to better match RFC 2119. These are | |
6784 | also marked with comments such as "{{ Demoted the SHOULD }}". | |
6785 | ||
6786 | In Section 2.16, changed the MUST requirement of authenticating the | |
6787 | responder from "public key signature based" to "strong" because that | |
6788 | is what most current IKEv2 implementations do, and it better matches | |
6789 | the actual security requirement. | |
6790 | ||
d6bd078a MW |
6791 | D.2. Changes from draft -00 to draft -01 |
6792 | ||
6793 | The most significant technical change was to make KE optional but | |
6794 | strongly recommended in Section 1.3.2. | |
6795 | ||
6796 | Updated all references to the IKEv2 Clarifications document to RFC | |
6797 | 4718. | |
6798 | ||
6799 | Moved a lot of the protocol description out of the long tables in | |
6800 | Section 3.10.1 into the body of the document. These are noted with | |
6801 | "{{ 3.10.1-nnnn }}", where "nnnn" is the notification type number. | |
6802 | ||
6803 | Made some table changes based on suggestions from Alfred Hoenes. | |
6804 | ||
6805 | Changed "byte" to "octet" in many places. | |
6806 | ||
6807 | Removed discussion of ESP+AH bundles in many places, and added a | |
6808 | paragraph about it in Section 1.7. | |
6809 | ||
6810 | Removed the discussion of INTERNAL_ADDRESS_EXPIRY in many places, and | |
6811 | added a paragraph about it in Section 1.7. | |
6812 | ||
6813 | Moved Clarif-7.10 from Section 1.2 to Section 3.2. | |
6814 | ||
6815 | In the figure in Section 1.3.2, made KEi optional, and added text | |
6816 | saying "The KEi payload SHOULD be included." | |
6817 | ||
6818 | In the figure in Section 1.3.2, maked KEr optional, and removed text | |
6819 | saying "KEi and KEr are required for rekeying an IKE_SA." | |
6820 | ||
6821 | In Section 1.4, clarified that the half-closed connections being | |
6822 | discussed are AH and ESP. | |
6823 | ||
6824 | Rearranged the end of Section 1.7, and added the new notation for | |
6825 | moving text out of 3.10.1. | |
6826 | ||
6827 | Clarified the wording in the second paragraph of Section 2.2. This | |
6828 | ||
6829 | ||
6830 | ||
6831 | Kaufman, et al. Expires August 28, 2008 [Page 122] | |
6832 | \f | |
6833 | Internet-Draft IKEv2bis February 2008 | |
6834 | ||
6835 | ||
6836 | allowd the removal of the fourth paragraph, which previously had | |
6837 | Clarif-2.2 in it. | |
6838 | ||
6839 | In section 2.5, removed "or later" from "version 2.0". | |
6840 | ||
6841 | Added the question for implementers about payload order at the end of | |
6842 | Section 2.5. | |
6843 | ||
6844 | Corrected Section 2.7 based on Clarif-7-13 to say that you can't do | |
6845 | ESP and AH at one time. | |
6846 | ||
6847 | In Section 2.8, clarified the wording about how to replace an IKE_SA. | |
6848 | ||
6849 | Clarified the text in the last many paragraphs in Section 2.9. Also | |
6850 | moved some text from near the beginning of 2.9 to the beginning of | |
6851 | 2.9.1. | |
6852 | ||
6853 | Removed some redundant text in Section 2.9 concerning creating a | |
6854 | CHILD_SA pair not in response to an arriving packet. | |
6855 | ||
6856 | Added the following to the end of the first paragraph of Section | |
6857 | 2.14: "The lengths of SK_d, SK_pi, and SK_pr are the key length of | |
6858 | the agreed-to PRF." | |
6859 | ||
6860 | Added the restriction in Section 2.15 that all PRFs used with IKEv2 | |
6861 | MUST take variable-sized keys. | |
6862 | ||
6863 | In Section 2.17, removed "If multiple IPsec protocols are negotiated, | |
6864 | keying material is taken in the order in which the protocol headers | |
6865 | will appear in the encapsulated packet" because multiple IPsec | |
6866 | protocols cannot be negotiated at one time. | |
6867 | ||
6868 | Added the material from Clarif-5.12 to Section 2.18. | |
6869 | ||
6870 | Changed "hash of" to "expected value of" in Section 2.23. | |
6871 | ||
6872 | In the bulleted list in Section 2.23, replaced "this end" with a | |
6873 | clearer description of which system is being discussed. | |
6874 | ||
6875 | Added the paragraph at the beginning of Section 3 about | |
6876 | interoperability and UNSPECIFIED values ("In the tables in this | |
6877 | section..."). | |
6878 | ||
6879 | Fixed Section 3.3 to not include proposal that include both AH and | |
6880 | ESP. Ditto for the "Proposal #" bullet in Section 3.3.1. | |
6881 | ||
6882 | In the description of ID_FQDN in Section 3.5, added "All characters | |
6883 | in the ID_FQDN are ASCII; this follows that for an "internationalized | |
6884 | ||
6885 | ||
6886 | ||
6887 | Kaufman, et al. Expires August 28, 2008 [Page 123] | |
6888 | \f | |
6889 | Internet-Draft IKEv2bis February 2008 | |
6890 | ||
6891 | ||
6892 | domain name" as defined in [IDNA]." | |
6893 | ||
6894 | In Section 3.8, shortened and clarified the description of "RSA | |
6895 | Digital Signature". | |
6896 | ||
6897 | In Section 3.10, shortened and clarified the description of "Protocol | |
6898 | ID". | |
6899 | ||
6900 | In Section 3.15, "The requested address is valid until the expiry | |
6901 | time defined with the INTERNAL_ADDRESS_EXPIRY attribute or there are | |
6902 | no IKE_SAs between the peers" is shortened to just "The requested | |
6903 | address is valid until there are no IKE_SAs between the peers." | |
6904 | ||
6905 | In Section 3.15.1, changed "INTERNAL_IP6_NBNS" to unspecified. | |
6906 | ||
6907 | Made [ADDRIPV6] an informative reference instead of a normative | |
6908 | reference and updated it. | |
6909 | ||
6910 | Made [PKCS1] a normative reference instead of an informative | |
6911 | reference and changed the pointer to RFC 3447. | |
6912 | ||
6913 | D.3. Changes from draft -00 to draft -01 | |
6914 | ||
6915 | In Section 1.5, added "request" to first sentence to make it "If an | |
6916 | encrypted IKE request packet arrives on port 500 or 4500 with an | |
6917 | unrecognized SPI...". | |
6918 | ||
6919 | In Section 3.3, fifth paragraph, upped the number of transforms for | |
6920 | AH and ESP by one each to account for ESN, which is now mandatory. | |
6921 | ||
6922 | In Section 2.1, added "or equal to" in "The responder MUST remember | |
6923 | each response until it receives a request whose sequence number is | |
6924 | larger than or equal to the sequence number in the response plus its | |
6925 | window size." | |
6926 | ||
6927 | In Section 2.18, removed " Note that this may not work if the new | |
6928 | IKE_SA's PRF has a fixed key size because the output of the PRF may | |
6929 | not be of the correct size." because it is no longer relevant. | |
6930 | ||
6931 | D.4. Changes from draft -01 to draft -02 | |
6932 | ||
6933 | Many grammatical fixes. | |
6934 | ||
6935 | In Section 1.2, reworded Clarif-4.3 to be clearer. | |
6936 | ||
6937 | In Section 1.3.3, reworded 3.10.1-16393 and Clarif-5.4 to remove | |
6938 | redundant text. | |
6939 | ||
6940 | ||
6941 | ||
6942 | ||
6943 | Kaufman, et al. Expires August 28, 2008 [Page 124] | |
6944 | \f | |
6945 | Internet-Draft IKEv2bis February 2008 | |
6946 | ||
6947 | ||
6948 | In Section 2.13, replaced text about variable length keys with | |
6949 | clearer explanation and requirement on non-HMAC PRFs. Also added | |
6950 | "preferred" to Section 2.14 for the key length, and removed redundant | |
6951 | text. | |
6952 | ||
6953 | In Section 2.14, removed the "half and half" description and replaced | |
6954 | it with exceptions for RFC4434 and RFC4615. | |
6955 | ||
6956 | Removed the now-redundant "All PRFs used with IKEv2 MUST take | |
6957 | variable-sized keys" from Section 2.15. | |
6958 | ||
6959 | In Section 2.15, added "(IKE_SA_INIT response)" after "of the second | |
6960 | message" and "(IKE_SA_INIT request)" after "the first message". | |
6961 | ||
6962 | In Section 2.17, simplified because there are no more bundles. "A | |
6963 | single CHILD_SA negotiation may result in multiple security | |
6964 | associations. ESP and AH SAs exist in pairs (one in each | |
6965 | direction)." becomes "For ESP and AH, a single CHILD_SA negotiation | |
6966 | results in two security associations (one in each direction)." | |
6967 | ||
6968 | In section 3.3, made the example of combinations of algorithms and | |
6969 | the contents of the first proposal clearer. | |
6970 | ||
6971 | Added Clarif-4.4 to the ned of Section 3.3.2. | |
6972 | ||
6973 | Reordered Section 3.3.5 and added Clarif-7.11. | |
6974 | ||
6975 | Clarified Section 3.3.6 about choosing a single proposal. Also added | |
6976 | second paragraph about transforms not understood, and clarified third | |
6977 | paragraph about picking D-H groups. | |
6978 | ||
6979 | Moved 3.10.1-16392 from Section 3.6 to 3.7. | |
6980 | ||
6981 | In Section 3.10, clarified 3.10.1-16394. | |
6982 | ||
6983 | Updated Section 6 to indicate that there is nothing new for IANA in | |
6984 | this spec. Also removed the definition of "Expert Review" from | |
6985 | Section 1.6 for the same reason. | |
6986 | ||
6987 | In Appendix A, removed "and not commit any state to an exchange until | |
6988 | the initiator can be cryptographically authenticated" because that | |
6989 | was only true in an earlier version of IKEv2. | |
6990 | ||
6991 | D.5. Changes from draft -02 to draft -03 | |
6992 | ||
6993 | In Section 1.3, changed "If the responder rejects the Diffie-Hellman | |
6994 | group of the KEi payload, the responder MUST reject the request and | |
6995 | indicate its preferred Diffie-Hellman group in the INVALID_KE_PAYLOAD | |
6996 | ||
6997 | ||
6998 | ||
6999 | Kaufman, et al. Expires August 28, 2008 [Page 125] | |
7000 | \f | |
7001 | Internet-Draft IKEv2bis February 2008 | |
7002 | ||
7003 | ||
7004 | Notification payload." to "If the responder selects a proposal using | |
7005 | a different Diffie-Hellman group (other than NONE), the responder | |
7006 | MUST reject the request and indicate its preferred Diffie-Hellman | |
7007 | group in the INVALID_KE_PAYLOAD Notification payload. | |
7008 | ||
7009 | In Section 2.3, added the last two paragraphs covering why you | |
7010 | initiator's SPI and/or IP to differentiate if this is a "half-open" | |
7011 | IKE_SA or a new request. Also removed similar text from Section 2.2. | |
7012 | ||
7013 | In Section 2.5, added "Payloads sent in IKE response messages MUST | |
7014 | NOT have the critical flag set. Note that the critical flag applies | |
7015 | only to the payload type, not the contents. If the payload type is | |
7016 | recognized, but the payload contains something which is not (such as | |
7017 | an unknown transform inside an SA payload, or an unknown Notify | |
7018 | Message Type inside a Notify payload), the critical flag is ignored." | |
7019 | ||
7020 | In Section 2.6, moved the text about {{ 3.10.1-16390 }} later in the | |
7021 | section. Also reworded the text to make it clearer what the COOKIE | |
7022 | is for. | |
7023 | ||
7024 | Moved text from {{ Clarif-2.1 }} from Section 2.6 to Section 2.7. | |
7025 | ||
7026 | In Section 2.13, added "(see Section 3.3.5 for the defintion of the | |
7027 | Key Length transform attribute)". | |
7028 | ||
7029 | In Section 2.17, change the description of the keying material from | |
7030 | the list with two bullets to a clearer list. | |
7031 | ||
7032 | In Section 2.23, added "Implementations MUST process received UDP- | |
7033 | encapsulated ESP packets even when no NAT was detected." | |
7034 | ||
7035 | In Section 3.3, changed "Each proposal may contain a" to "Each | |
7036 | proposal contains a". | |
7037 | ||
7038 | Added the asterisks to the tranform type table in Section 3.3.2 and | |
7039 | the types table in 3.3.3 to foreshadow future developments. | |
7040 | ||
7041 | In Section 3.3.2, changed the following algorithms to (UNSPECIFIED) | |
7042 | because the RFCs listed didn't really specify how to implement them | |
7043 | in an interoperable fashion: | |
7044 | ||
7045 | ||
7046 | ||
7047 | ||
7048 | ||
7049 | ||
7050 | ||
7051 | ||
7052 | ||
7053 | ||
7054 | ||
7055 | Kaufman, et al. Expires August 28, 2008 [Page 126] | |
7056 | \f | |
7057 | Internet-Draft IKEv2bis February 2008 | |
7058 | ||
7059 | ||
7060 | Encryption Algorithms | |
7061 | ENCR_DES_IV64 1 (RFC1827) | |
7062 | ENCR_3IDEA 8 (RFC2451) | |
7063 | ENCR_DES_IV32 9 | |
7064 | Pseudo-random Functions | |
7065 | PRF_HMAC_TIGER 3 (RFC2104) | |
7066 | Integrity Algorithms | |
7067 | AUTH_DES_MAC 3 | |
7068 | AUTH_KPDK_MD5 4 (RFC1826) | |
7069 | ||
7070 | In Section 3.4, added "(other than NONE)" to the second-to-last | |
7071 | paragraph. | |
7072 | ||
7073 | Rewrote the third paragraph of Section 3.14 to talk about other | |
7074 | modes, and to clarify which encryption and integrity protection we | |
7075 | are talking about. | |
7076 | ||
7077 | Changed the "Initialization Vector" bullet in Section 3.14 to specify | |
7078 | better what is needed for the IV. Upgraded the SHOULDs to MUSTs. | |
7079 | Also added the reference for [MODES]. | |
7080 | ||
7081 | In Section 5, in the second-to-last paragraph, changed "a public-key- | |
7082 | based" to "strong" to match the wording in Section 2.16. | |
7083 | ||
f91513e3 MW |
7084 | |
7085 | Authors' Addresses | |
7086 | ||
7087 | Charlie Kaufman | |
7088 | Microsoft | |
7089 | 1 Microsoft Way | |
7090 | Redmond, WA 98052 | |
7091 | US | |
7092 | ||
7093 | Phone: 1-425-707-3335 | |
7094 | Email: charliek@microsoft.com | |
7095 | ||
7096 | ||
7097 | Paul Hoffman | |
7098 | VPN Consortium | |
7099 | 127 Segre Place | |
7100 | Santa Cruz, CA 95060 | |
7101 | US | |
7102 | ||
7103 | Phone: 1-831-426-9827 | |
7104 | Email: paul.hoffman@vpnc.org | |
7105 | ||
7106 | ||
d6bd078a MW |
7107 | |
7108 | ||
7109 | ||
7110 | ||
7111 | Kaufman, et al. Expires August 28, 2008 [Page 127] | |
7112 | \f | |
7113 | Internet-Draft IKEv2bis February 2008 | |
7114 | ||
7115 | ||
f91513e3 MW |
7116 | Pasi Eronen |
7117 | Nokia Research Center | |
7118 | P.O. Box 407 | |
7119 | FIN-00045 Nokia Group | |
7120 | Finland | |
7121 | ||
7122 | Email: pasi.eronen@nokia.com | |
7123 | ||
7124 | ||
f91513e3 | 7125 | |
f91513e3 | 7126 | |
f91513e3 MW |
7127 | |
7128 | ||
7129 | ||
d6bd078a MW |
7130 | |
7131 | ||
7132 | ||
7133 | ||
7134 | ||
7135 | ||
7136 | ||
7137 | ||
7138 | ||
7139 | ||
7140 | ||
7141 | ||
7142 | ||
7143 | ||
7144 | ||
7145 | ||
7146 | ||
7147 | ||
7148 | ||
7149 | ||
7150 | ||
7151 | ||
7152 | ||
7153 | ||
7154 | ||
7155 | ||
7156 | ||
7157 | ||
7158 | ||
7159 | ||
7160 | ||
7161 | ||
7162 | ||
7163 | ||
7164 | ||
7165 | ||
7166 | ||
7167 | Kaufman, et al. Expires August 28, 2008 [Page 128] | |
f91513e3 | 7168 | \f |
d6bd078a | 7169 | Internet-Draft IKEv2bis February 2008 |
f91513e3 MW |
7170 | |
7171 | ||
d6bd078a MW |
7172 | Full Copyright Statement |
7173 | ||
7174 | Copyright (C) The IETF Trust (2008). | |
7175 | ||
7176 | This document is subject to the rights, licenses and restrictions | |
7177 | contained in BCP 78, and except as set forth therein, the authors | |
f91513e3 MW |
7178 | retain all their rights. |
7179 | ||
7180 | This document and the information contained herein are provided on an | |
7181 | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |
d6bd078a MW |
7182 | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND |
7183 | THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS | |
7184 | OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF | |
7185 | THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | |
f91513e3 MW |
7186 | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. |
7187 | ||
7188 | ||
7189 | Intellectual Property | |
7190 | ||
7191 | The IETF takes no position regarding the validity or scope of any | |
7192 | Intellectual Property Rights or other rights that might be claimed to | |
7193 | pertain to the implementation or use of the technology described in | |
7194 | this document or the extent to which any license under such rights | |
7195 | might or might not be available; nor does it represent that it has | |
7196 | made any independent effort to identify any such rights. Information | |
7197 | on the procedures with respect to rights in RFC documents can be | |
7198 | found in BCP 78 and BCP 79. | |
7199 | ||
7200 | Copies of IPR disclosures made to the IETF Secretariat and any | |
7201 | assurances of licenses to be made available, or the result of an | |
7202 | attempt made to obtain a general license or permission for the use of | |
7203 | such proprietary rights by implementers or users of this | |
7204 | specification can be obtained from the IETF on-line IPR repository at | |
7205 | http://www.ietf.org/ipr. | |
7206 | ||
7207 | The IETF invites any interested party to bring to its attention any | |
7208 | copyrights, patents or patent applications, or other proprietary | |
7209 | rights that may cover technology that may be required to implement | |
7210 | this standard. Please address the information to the IETF at | |
7211 | ietf-ipr@ietf.org. | |
7212 | ||
7213 | ||
7214 | Acknowledgment | |
7215 | ||
d6bd078a MW |
7216 | Funding for the RFC Editor function is provided by the IETF |
7217 | Administrative Support Activity (IASA). | |
f91513e3 MW |
7218 | |
7219 | ||
7220 | ||
7221 | ||
7222 | ||
d6bd078a | 7223 | Kaufman, et al. Expires August 28, 2008 [Page 129] |
f91513e3 | 7224 | \f |