← Back to branch summary

~ubuntu-branches/ubuntu/utopic/strongswan/utopic

« back to all changes in this revision

Viewing changes to doc/standards/rfc5996.txt

  • Committer: Package Import Robot
  • Author(s): Jonathan Davies
  • Date: 2014-01-20 19:00:59 UTC
  • mfrom: (1.2.6)
  • Revision ID: package-import@ubuntu.com-20140120190059-z8e4dl3g8cd09yi5
Tags: 5.1.2~dr3+git20130120-0ubuntu1
* Upstream Git snapshot for build fixes with regards to entropy.
* debian/rules:
  - Enforcing DEB_BUILD_OPTIONS=nostrip for library integrity checking.
  - Set TESTS_REDUCED_KEYLENGTHS to one generate smallest key-lengths in
    tests.

Show diffs side-by-side

added added

removed removed

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