added actual ikev2bis draft
[strongswan.git] / doc / standards / draft-ietf-ipsecme-ikev2bis-01.txt
1
2
3
4 Network Working Group                                         C. Kaufman
5 Internet-Draft                                                 Microsoft
6 Obsoletes: 4306, 4718                                         P. Hoffman
7 (if approved)                                             VPN Consortium
8 Intended status: Standards Track                                  Y. Nir
9 Expires: May 3, 2009                                         Check Point
10                                                                P. Eronen
11                                                                    Nokia
12                                                         October 30, 2008
13
14
15                  Internet Key Exchange Protocol: IKEv2
16                      draft-ietf-ipsecme-ikev2bis-01
17
18 Status of this Memo
19
20    By submitting this Internet-Draft, each author represents that any
21    applicable patent or other IPR claims of which he or she is aware
22    have been or will be disclosed, and any of which he or she becomes
23    aware will be disclosed, in accordance with Section 6 of BCP 79.
24
25    Internet-Drafts are working documents of the Internet Engineering
26    Task Force (IETF), its areas, and its working groups.  Note that
27    other groups may also distribute working documents as Internet-
28    Drafts.
29
30    Internet-Drafts are draft documents valid for a maximum of six months
31    and may be updated, replaced, or obsoleted by other documents at any
32    time.  It is inappropriate to use Internet-Drafts as reference
33    material or to cite them other than as "work in progress."
34
35    The list of current Internet-Drafts can be accessed at
36    http://www.ietf.org/ietf/1id-abstracts.txt.
37
38    The list of Internet-Draft Shadow Directories can be accessed at
39    http://www.ietf.org/shadow.html.
40
41    This Internet-Draft will expire on May 3, 2009.
42
43 Copyright Notice
44
45    Copyright (C) The IETF Trust (2008).
46
47 Abstract
48
49    This document describes version 2 of the Internet Key Exchange (IKE)
50    protocol.  IKE is a component of IPsec used for performing mutual
51    authentication and establishing and maintaining security associations
52
53
54
55 Kaufman, et al.            Expires May 3, 2009                  [Page 1]
56 \f
57 Internet-Draft                  IKEv2bis                    October 2008
58
59
60    (SAs).  It replaces and updates RFC 4306, and includes all of the
61    clarifications from RFC 4718.
62
63
64 Table of Contents
65
66    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   5
67      1.1.  Usage Scenarios . . . . . . . . . . . . . . . . . . . . .   6
68        1.1.1.  Security Gateway to Security Gateway Tunnel Mode  . .   6
69        1.1.2.  Endpoint-to-Endpoint Transport Mode . . . . . . . . .   7
70        1.1.3.  Endpoint to Security Gateway Tunnel Mode  . . . . . .   8
71        1.1.4.  Other Scenarios . . . . . . . . . . . . . . . . . . .   8
72      1.2.  The Initial Exchanges . . . . . . . . . . . . . . . . . .   9
73      1.3.  The CREATE_CHILD_SA Exchange  . . . . . . . . . . . . . .  12
74        1.3.1.  Creating New Child SAs with the CREATE_CHILD_SA
75                Exchange  . . . . . . . . . . . . . . . . . . . . . .  13
76        1.3.2.  Rekeying IKE SAs with the CREATE_CHILD_SA Exchange  .  14
77        1.3.3.  Rekeying Child SAs with the CREATE_CHILD_SA
78                Exchange  . . . . . . . . . . . . . . . . . . . . . .  15
79      1.4.  The INFORMATIONAL Exchange  . . . . . . . . . . . . . . .  16
80        1.4.1.  Deleting an SA with INFORMATIONAL Exchanges . . . . .  16
81      1.5.  Informational Messages outside of an IKE SA . . . . . . .  17
82      1.6.  Requirements Terminology  . . . . . . . . . . . . . . . .  18
83      1.7.  Differences Between RFC 4306 and This Document  . . . . .  18
84    2.  IKE Protocol Details and Variations . . . . . . . . . . . . .  20
85      2.1.  Use of Retransmission Timers  . . . . . . . . . . . . . .  21
86      2.2.  Use of Sequence Numbers for Message ID  . . . . . . . . .  22
87      2.3.  Window Size for Overlapping Requests  . . . . . . . . . .  22
88      2.4.  State Synchronization and Connection Timeouts . . . . . .  24
89      2.5.  Version Numbers and Forward Compatibility . . . . . . . .  26
90      2.6.  IKE SA SPIs and Cookies . . . . . . . . . . . . . . . . .  28
91        2.6.1.  Interaction of COOKIE and INVALID_KE_PAYLOAD  . . . .  30
92      2.7.  Cryptographic Algorithm Negotiation . . . . . . . . . . .  31
93      2.8.  Rekeying  . . . . . . . . . . . . . . . . . . . . . . . .  32
94        2.8.1.  Simultaneous Child SA rekeying  . . . . . . . . . . .  34
95        2.8.2.  Rekeying the IKE SA Versus Reauthentication . . . . .  36
96      2.9.  Traffic Selector Negotiation  . . . . . . . . . . . . . .  37
97        2.9.1.  Traffic Selectors Violating Own Policy  . . . . . . .  40
98      2.10. Nonces  . . . . . . . . . . . . . . . . . . . . . . . . .  40
99      2.11. Address and Port Agility  . . . . . . . . . . . . . . . .  41
100      2.12. Reuse of Diffie-Hellman Exponentials  . . . . . . . . . .  41
101      2.13. Generating Keying Material  . . . . . . . . . . . . . . .  42
102      2.14. Generating Keying Material for the IKE SA . . . . . . . .  43
103      2.15. Authentication of the IKE SA  . . . . . . . . . . . . . .  44
104      2.16. Extensible Authentication Protocol Methods  . . . . . . .  46
105      2.17. Generating Keying Material for Child SAs  . . . . . . . .  48
106      2.18. Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange . . . .  49
107      2.19. Requesting an Internal Address on a Remote Network  . . .  50
108
109
110
111 Kaufman, et al.            Expires May 3, 2009                  [Page 2]
112 \f
113 Internet-Draft                  IKEv2bis                    October 2008
114
115
116        2.19.1. Configuration Payloads  . . . . . . . . . . . . . . .  51
117      2.20. Requesting the Peer's Version . . . . . . . . . . . . . .  53
118      2.21. Error Handling  . . . . . . . . . . . . . . . . . . . . .  53
119      2.22. IPComp  . . . . . . . . . . . . . . . . . . . . . . . . .  54
120      2.23. NAT Traversal . . . . . . . . . . . . . . . . . . . . . .  55
121      2.24. Explicit Congestion Notification (ECN)  . . . . . . . . .  59
122    3.  Header and Payload Formats  . . . . . . . . . . . . . . . . .  59
123      3.1.  The IKE Header  . . . . . . . . . . . . . . . . . . . . .  59
124      3.2.  Generic Payload Header  . . . . . . . . . . . . . . . . .  62
125      3.3.  Security Association Payload  . . . . . . . . . . . . . .  64
126        3.3.1.  Proposal Substructure . . . . . . . . . . . . . . . .  66
127        3.3.2.  Transform Substructure  . . . . . . . . . . . . . . .  68
128        3.3.3.  Valid Transform Types by Protocol . . . . . . . . . .  71
129        3.3.4.  Mandatory Transform IDs . . . . . . . . . . . . . . .  71
130        3.3.5.  Transform Attributes  . . . . . . . . . . . . . . . .  72
131        3.3.6.  Attribute Negotiation . . . . . . . . . . . . . . . .  74
132      3.4.  Key Exchange Payload  . . . . . . . . . . . . . . . . . .  75
133      3.5.  Identification Payloads . . . . . . . . . . . . . . . . .  75
134      3.6.  Certificate Payload . . . . . . . . . . . . . . . . . . .  78
135      3.7.  Certificate Request Payload . . . . . . . . . . . . . . .  80
136      3.8.  Authentication Payload  . . . . . . . . . . . . . . . . .  82
137      3.9.  Nonce Payload . . . . . . . . . . . . . . . . . . . . . .  83
138      3.10. Notify Payload  . . . . . . . . . . . . . . . . . . . . .  84
139        3.10.1. Notify Message Types  . . . . . . . . . . . . . . . .  85
140      3.11. Delete Payload  . . . . . . . . . . . . . . . . . . . . .  88
141      3.12. Vendor ID Payload . . . . . . . . . . . . . . . . . . . .  90
142      3.13. Traffic Selector Payload  . . . . . . . . . . . . . . . .  91
143        3.13.1. Traffic Selector  . . . . . . . . . . . . . . . . . .  92
144      3.14. Encrypted Payload . . . . . . . . . . . . . . . . . . . .  94
145      3.15. Configuration Payload . . . . . . . . . . . . . . . . . .  96
146        3.15.1. Configuration Attributes  . . . . . . . . . . . . . .  97
147        3.15.2. Meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET  . 100
148        3.15.3. Configuration payloads for IPv6 . . . . . . . . . . . 102
149        3.15.4. Address Assignment Failures . . . . . . . . . . . . . 103
150      3.16. Extensible Authentication Protocol (EAP) Payload  . . . . 103
151    4.  Conformance Requirements  . . . . . . . . . . . . . . . . . . 105
152    5.  Security Considerations . . . . . . . . . . . . . . . . . . . 107
153      5.1.  Traffic selector authorization  . . . . . . . . . . . . . 109
154    6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 111
155    7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . 111
156    8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . 111
157      8.1.  Normative References  . . . . . . . . . . . . . . . . . . 111
158      8.2.  Informative References  . . . . . . . . . . . . . . . . . 113
159    Appendix A.  Summary of changes from IKEv1  . . . . . . . . . . . 117
160    Appendix B.  Diffie-Hellman Groups  . . . . . . . . . . . . . . . 118
161      B.1.  Group 1 - 768 Bit MODP  . . . . . . . . . . . . . . . . . 118
162      B.2.  Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 118
163    Appendix C.  Exchanges and Payloads . . . . . . . . . . . . . . . 119
164
165
166
167 Kaufman, et al.            Expires May 3, 2009                  [Page 3]
168 \f
169 Internet-Draft                  IKEv2bis                    October 2008
170
171
172      C.1.  IKE_SA_INIT Exchange  . . . . . . . . . . . . . . . . . . 119
173      C.2.  IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 120
174      C.3.  IKE_AUTH Exchange with EAP  . . . . . . . . . . . . . . . 121
175      C.4.  CREATE_CHILD_SA Exchange for Creating or Rekeying
176            Child SAs . . . . . . . . . . . . . . . . . . . . . . . . 122
177      C.5.  CREATE_CHILD_SA Exchange for Rekeying the IKE SA  . . . . 122
178      C.6.  INFORMATIONAL Exchange  . . . . . . . . . . . . . . . . . 122
179    Appendix D.  Changes Between Internet Draft Versions  . . . . . . 122
180      D.1.  Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 123
181      D.2.  Changes from draft -00 to draft -01 . . . . . . . . . . . 123
182      D.3.  Changes from draft -00 to draft -01 . . . . . . . . . . . 125
183      D.4.  Changes from draft -01 to draft -02 . . . . . . . . . . . 126
184      D.5.  Changes from draft -02 to draft -03 . . . . . . . . . . . 127
185      D.6.  Changes from draft -03 to
186            draft-ietf-ipsecme-ikev2bis-00  . . . . . . . . . . . . . 128
187      D.7.  Changes from draft-ietf-ipsecme-ikev2bis-00 to
188            draft-ietf-ipsecme-ikev2bis-01  . . . . . . . . . . . . . 129
189    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 133
190    Intellectual Property and Copyright Statements  . . . . . . . . . 134
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223 Kaufman, et al.            Expires May 3, 2009                  [Page 4]
224 \f
225 Internet-Draft                  IKEv2bis                    October 2008
226
227
228 1.  Introduction
229
230    {{ An introduction to the differences between RFC 4306 [IKEV2] and
231    this document is given at the end of Section 1.  It is put there
232    (instead of here) to preserve the section numbering of RFC 4306. }}
233
234    IP Security (IPsec) provides confidentiality, data integrity, access
235    control, and data source authentication to IP datagrams.  These
236    services are provided by maintaining shared state between the source
237    and the sink of an IP datagram.  This state defines, among other
238    things, the specific services provided to the datagram, which
239    cryptographic algorithms will be used to provide the services, and
240    the keys used as input to the cryptographic algorithms.
241
242    Establishing this shared state in a manual fashion does not scale
243    well.  Therefore, a protocol to establish this state dynamically is
244    needed.  This memo describes such a protocol -- the Internet Key
245    Exchange (IKE).  Version 1 of IKE was defined in RFCs 2407 [DOI],
246    2408 [ISAKMP], and 2409 [IKEV1].  IKEv2 replaced all of those RFCs.
247    IKEv2 was defined in [IKEV2] (RFC 4306) and was clarified in [Clarif]
248    (RFC 4718).  This document replaces and updates RFC 4306 and RFC
249    4718.
250
251    IKE performs mutual authentication between two parties and
252    establishes an IKE security association (SA) that includes shared
253    secret information that can be used to efficiently establish SAs for
254    Encapsulating Security Payload (ESP) [ESP] or Authentication Header
255    (AH) [AH] and a set of cryptographic algorithms to be used by the SAs
256    to protect the traffic that they carry.  In this document, the term
257    "suite" or "cryptographic suite" refers to a complete set of
258    algorithms used to protect an SA.  An initiator proposes one or more
259    suites by listing supported algorithms that can be combined into
260    suites in a mix-and-match fashion.  IKE can also negotiate use of IP
261    Compression (IPComp) [IP-COMP] in connection with an ESP or AH SA.
262    The SAs for ESP or AH that get set up through that IKE SA we call
263    "Child SAs".
264
265    All IKE communications consist of pairs of messages: a request and a
266    response.  The pair is called an "exchange".  We call the first
267    messages establishing an IKE SA IKE_SA_INIT and IKE_AUTH exchanges
268    and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL
269    exchanges.  In the common case, there is a single IKE_SA_INIT
270    exchange and a single IKE_AUTH exchange (a total of four messages) to
271    establish the IKE SA and the first Child SA.  In exceptional cases,
272    there may be more than one of each of these exchanges.  In all cases,
273    all IKE_SA_INIT exchanges MUST complete before any other exchange
274    type, then all IKE_AUTH exchanges MUST complete, and following that
275    any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur
276
277
278
279 Kaufman, et al.            Expires May 3, 2009                  [Page 5]
280 \f
281 Internet-Draft                  IKEv2bis                    October 2008
282
283
284    in any order.  In some scenarios, only a single Child SA is needed
285    between the IPsec endpoints, and therefore there would be no
286    additional exchanges.  Subsequent exchanges MAY be used to establish
287    additional Child SAs between the same authenticated pair of endpoints
288    and to perform housekeeping functions.
289
290    IKE message flow always consists of a request followed by a response.
291    It is the responsibility of the requester to ensure reliability.  If
292    the response is not received within a timeout interval, the requester
293    needs to retransmit the request (or abandon the connection).
294
295    The first request/response of an IKE session (IKE_SA_INIT) negotiates
296    security parameters for the IKE SA, sends nonces, and sends Diffie-
297    Hellman values.
298
299    The second request/response (IKE_AUTH) transmits identities, proves
300    knowledge of the secrets corresponding to the two identities, and
301    sets up an SA for the first (and often only) AH or ESP Child SA
302    (unless there is failure setting up the AH or ESP Child SA, in which
303    case the IKE SA is still established without IPsec SA).
304
305    The types of subsequent exchanges are CREATE_CHILD_SA (which creates
306    a Child SA) and INFORMATIONAL (which deletes an SA, reports error
307    conditions, or does other housekeeping).  Every request requires a
308    response.  An INFORMATIONAL request with no payloads (other than the
309    empty Encrypted payload required by the syntax) is commonly used as a
310    check for liveness.  These subsequent exchanges cannot be used until
311    the initial exchanges have completed.
312
313    In the description that follows, we assume that no errors occur.
314    Modifications to the flow should errors occur are described in
315    Section 2.21.
316
317 1.1.  Usage Scenarios
318
319    IKE is expected to be used to negotiate ESP or AH SAs in a number of
320    different scenarios, each with its own special requirements.
321
322 1.1.1.  Security Gateway to Security Gateway Tunnel Mode
323
324                 +-+-+-+-+-+            +-+-+-+-+-+
325                 |         | IPsec      |         |
326    Protected    |Tunnel   | tunnel     |Tunnel   |     Protected
327    Subnet   <-->|Endpoint |<---------->|Endpoint |<--> Subnet
328                 |         |            |         |
329                 +-+-+-+-+-+            +-+-+-+-+-+
330
331           Figure 1:  Security Gateway to Security Gateway Tunnel
332
333
334
335 Kaufman, et al.            Expires May 3, 2009                  [Page 6]
336 \f
337 Internet-Draft                  IKEv2bis                    October 2008
338
339
340    In this scenario, neither endpoint of the IP connection implements
341    IPsec, but network nodes between them protect traffic for part of the
342    way.  Protection is transparent to the endpoints, and depends on
343    ordinary routing to send packets through the tunnel endpoints for
344    processing.  Each endpoint would announce the set of addresses
345    "behind" it, and packets would be sent in tunnel mode where the inner
346    IP header would contain the IP addresses of the actual endpoints.
347
348 1.1.2.  Endpoint-to-Endpoint Transport Mode
349
350    +-+-+-+-+-+                                          +-+-+-+-+-+
351    |         |                 IPsec transport          |         |
352    |Protected|                or tunnel mode SA         |Protected|
353    |Endpoint |<---------------------------------------->|Endpoint |
354    |         |                                          |         |
355    +-+-+-+-+-+                                          +-+-+-+-+-+
356
357                     Figure 2:  Endpoint to Endpoint
358
359    In this scenario, both endpoints of the IP connection implement
360    IPsec, as required of hosts in [IPSECARCH].  Transport mode will
361    commonly be used with no inner IP header.  A single pair of addresses
362    will be negotiated for packets to be protected by this SA.  These
363    endpoints MAY implement application layer access controls based on
364    the IPsec authenticated identities of the participants.  This
365    scenario enables the end-to-end security that has been a guiding
366    principle for the Internet since [ARCHPRINC], [TRANSPARENCY], and a
367    method of limiting the inherent problems with complexity in networks
368    noted by [ARCHGUIDEPHIL].  Although this scenario may not be fully
369    applicable to the IPv4 Internet, it has been deployed successfully in
370    specific scenarios within intranets using IKEv1.  It should be more
371    broadly enabled during the transition to IPv6 and with the adoption
372    of IKEv2.
373
374    It is possible in this scenario that one or both of the protected
375    endpoints will be behind a network address translation (NAT) node, in
376    which case the tunneled packets will have to be UDP encapsulated so
377    that port numbers in the UDP headers can be used to identify
378    individual endpoints "behind" the NAT (see Section 2.23).
379
380
381
382
383
384
385
386
387
388
389
390
391 Kaufman, et al.            Expires May 3, 2009                  [Page 7]
392 \f
393 Internet-Draft                  IKEv2bis                    October 2008
394
395
396 1.1.3.  Endpoint to Security Gateway Tunnel Mode
397
398    +-+-+-+-+-+                          +-+-+-+-+-+
399    |         |         IPsec            |         |     Protected
400    |Protected|         tunnel           |Tunnel   |     Subnet
401    |Endpoint |<------------------------>|Endpoint |<--- and/or
402    |         |                          |         |     Internet
403    +-+-+-+-+-+                          +-+-+-+-+-+
404
405               Figure 3:  Endpoint to Security Gateway Tunnel
406
407    In this scenario, a protected endpoint (typically a portable roaming
408    computer) connects back to its corporate network through an IPsec-
409    protected tunnel.  It might use this tunnel only to access
410    information on the corporate network, or it might tunnel all of its
411    traffic back through the corporate network in order to take advantage
412    of protection provided by a corporate firewall against Internet-based
413    attacks.  In either case, the protected endpoint will want an IP
414    address associated with the security gateway so that packets returned
415    to it will go to the security gateway and be tunneled back.  This IP
416    address may be static or may be dynamically allocated by the security
417    gateway. {{ Clarif-6.1 }} In support of the latter case, IKEv2
418    includes a mechanism (namely, configuration payloads) for the
419    initiator to request an IP address owned by the security gateway for
420    use for the duration of its SA.
421
422    In this scenario, packets will use tunnel mode.  On each packet from
423    the protected endpoint, the outer IP header will contain the source
424    IP address associated with its current location (i.e., the address
425    that will get traffic routed to the endpoint directly), while the
426    inner IP header will contain the source IP address assigned by the
427    security gateway (i.e., the address that will get traffic routed to
428    the security gateway for forwarding to the endpoint).  The outer
429    destination address will always be that of the security gateway,
430    while the inner destination address will be the ultimate destination
431    for the packet.
432
433    In this scenario, it is possible that the protected endpoint will be
434    behind a NAT.  In that case, the IP address as seen by the security
435    gateway will not be the same as the IP address sent by the protected
436    endpoint, and packets will have to be UDP encapsulated in order to be
437    routed properly.
438
439 1.1.4.  Other Scenarios
440
441    Other scenarios are possible, as are nested combinations of the
442    above.  One notable example combines aspects of 1.1.1 and 1.1.3.  A
443    subnet may make all external accesses through a remote security
444
445
446
447 Kaufman, et al.            Expires May 3, 2009                  [Page 8]
448 \f
449 Internet-Draft                  IKEv2bis                    October 2008
450
451
452    gateway using an IPsec tunnel, where the addresses on the subnet are
453    routed to the security gateway by the rest of the Internet.  An
454    example would be someone's home network being virtually on the
455    Internet with static IP addresses even though connectivity is
456    provided by an ISP that assigns a single dynamically assigned IP
457    address to the user's security gateway (where the static IP addresses
458    and an IPsec relay are provided by a third party located elsewhere).
459
460 1.2.  The Initial Exchanges
461
462    Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH
463    exchanges (known in IKEv1 as Phase 1).  These initial exchanges
464    normally consist of four messages, though in some scenarios that
465    number can grow.  All communications using IKE consist of request/
466    response pairs.  We'll describe the base exchange first, followed by
467    variations.  The first pair of messages (IKE_SA_INIT) negotiate
468    cryptographic algorithms, exchange nonces, and do a Diffie-Hellman
469    exchange [DH].
470
471    The second pair of messages (IKE_AUTH) authenticate the previous
472    messages, exchange identities and certificates, and establish the
473    first Child SA.  Parts of these messages are encrypted and integrity
474    protected with keys established through the IKE_SA_INIT exchange, so
475    the identities are hidden from eavesdroppers and all fields in all
476    the messages are authenticated.  (See Section 2.14 for information on
477    how the encyrption keys are generated.)
478
479    All messages following the initial exchange are cryptographically
480    protected using the cryptographic algorithms and keys negotiated in
481    the the IKE_SA_INIT exchange.  These subsequent messages use the
482    syntax of the Encrypted Payload described in Section 3.14, encrypted
483    with keys that are derived as described in Section 2.14.  All
484    subsequent messages include an Encrypted Payload, even if they are
485    referred to in the text as "empty".  For the CREATE_CHILD_SA,
486    IKE_AUTH, or IKE_INFORMATIONAL exchanges, the message following the
487    header is encrypted and the message including the header is integrity
488    protected using the cryptographic algorithms negotiated for the IKE
489    SA.
490
491    In the following descriptions, the payloads contained in the message
492    are indicated by names as listed below.
493
494
495
496
497
498
499
500
501
502
503 Kaufman, et al.            Expires May 3, 2009                  [Page 9]
504 \f
505 Internet-Draft                  IKEv2bis                    October 2008
506
507
508    Notation    Payload
509    -----------------------------------------
510    AUTH        Authentication
511    CERT        Certificate
512    CERTREQ     Certificate Request
513    CP          Configuration
514    D           Delete
515    E           Encrypted
516    EAP         Extensible Authentication
517    HDR         IKE Header
518    IDi         Identification - Initiator
519    IDr         Identification - Responder
520    KE          Key Exchange
521    Ni, Nr      Nonce
522    N           Notify
523    SA          Security Association
524    TSi         Traffic Selector - Initiator
525    TSr         Traffic Selector - Responder
526    V           Vendor ID
527
528    The details of the contents of each payload are described in section
529    3.  Payloads that may optionally appear will be shown in brackets,
530    such as [CERTREQ], indicate that optionally a certificate request
531    payload can be included.
532
533    The initial exchanges are as follows:
534
535    Initiator                         Responder
536    -------------------------------------------------------------------
537    HDR, SAi1, KEi, Ni  -->
538
539    HDR contains the Security Parameter Indexes (SPIs), version numbers,
540    and flags of various sorts.  The SAi1 payload states the
541    cryptographic algorithms the initiator supports for the IKE SA.  The
542    KE payload sends the initiator's Diffie-Hellman value.  Ni is the
543    initiator's nonce.
544
545                                 <--  HDR, SAr1, KEr, Nr, [CERTREQ]
546
547    The responder chooses a cryptographic suite from the initiator's
548    offered choices and expresses that choice in the SAr1 payload,
549    completes the Diffie-Hellman exchange with the KEr payload, and sends
550    its nonce in the Nr payload.
551
552    At this point in the negotiation, each party can generate SKEYSEED,
553    from which all keys are derived for that IKE SA.  The messages that
554    follow are encrypted and integrity protected in their entirety, with
555    the exception of the message headers.  The keys used for the
556
557
558
559 Kaufman, et al.            Expires May 3, 2009                 [Page 10]
560 \f
561 Internet-Draft                  IKEv2bis                    October 2008
562
563
564    encryption and integrity protection are derived from SKEYSEED and are
565    known as SK_e (encryption) and SK_a (authentication, a.k.a. integrity
566    protection).  A separate SK_e and SK_a is computed for each
567    direction.  In addition to the keys SK_e and SK_a derived from the DH
568    value for protection of the IKE SA, another quantity SK_d is derived
569    and used for derivation of further keying material for Child SAs.
570    The notation SK { ... } indicates that these payloads are encrypted
571    and integrity protected using that direction's SK_e and SK_a.
572
573    HDR, SK {IDi, [CERT,] [CERTREQ,]
574        [IDr,] AUTH, SAi2,
575        TSi, TSr}  -->
576
577    The initiator asserts its identity with the IDi payload, proves
578    knowledge of the secret corresponding to IDi and integrity protects
579    the contents of the first message using the AUTH payload (see
580    Section 2.15).  It might also send its certificate(s) in CERT
581    payload(s) and a list of its trust anchors in CERTREQ payload(s).  If
582    any CERT payloads are included, the first certificate provided MUST
583    contain the public key used to verify the AUTH field.
584
585    The optional payload IDr enables the initiator to specify which of
586    the responder's identities it wants to talk to.  This is useful when
587    the machine on which the responder is running is hosting multiple
588    identities at the same IP address.  If the IDr proposed by the
589    initiator is not acceptable to the responder, the responder might use
590    some other IDr to finish the exchange.  If the initiator then does
591    not accept that fact that responder used different IDr than the one
592    that was requested, the initiator can close the SA after noticing the
593    fact.
594
595    The initiator begins negotiation of a Child SA using the SAi2
596    payload.  The final fields (starting with SAi2) are described in the
597    description of the CREATE_CHILD_SA exchange.
598
599                                 <--  HDR, SK {IDr, [CERT,] AUTH,
600                                          SAr2, TSi, TSr}
601
602    The responder asserts its identity with the IDr payload, optionally
603    sends one or more certificates (again with the certificate containing
604    the public key used to verify AUTH listed first), authenticates its
605    identity and protects the integrity of the second message with the
606    AUTH payload, and completes negotiation of a Child SA with the
607    additional fields described below in the CREATE_CHILD_SA exchange.
608
609    The recipients of messages 3 and 4 MUST verify that all signatures
610    and MACs are computed correctly and that the names in the ID payloads
611    correspond to the keys used to generate the AUTH payload.
612
613
614
615 Kaufman, et al.            Expires May 3, 2009                 [Page 11]
616 \f
617 Internet-Draft                  IKEv2bis                    October 2008
618
619
620    {{ Clarif-4.2}} If creating the Child SA during the IKE_AUTH exchange
621    fails for some reason, the IKE SA is still created as usual.  The
622    list of responses in the IKE_AUTH exchange that do not prevent an IKE
623    SA from being set up include at least the following:
624    NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,
625    INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED.
626
627    {{ Clarif-4.3 }} Note that IKE_AUTH messages do not contain KEi/KEr
628    or Ni/Nr payloads.  Thus, the SA payloads in the IKE_AUTH exchange
629    cannot contain Transform Type 4 (Diffie-Hellman Group) with any value
630    other than NONE.  Implementations SHOULD omit the whole transform
631    substructure instead of sending value NONE.
632
633 1.3.  The CREATE_CHILD_SA Exchange
634
635    {{ This is a heavy rewrite of most of this section.  The major
636    organization changes are described in Clarif-4.1 and Clarif-5.1. }}
637
638    The CREATE_CHILD_SA exchange is used to create new Child SAs and to
639    rekey both IKE SAs and Child SAs.  This exchange consists of a single
640    request/response pair, and some of its function was referred to as a
641    phase 2 exchange in IKEv1.  It MAY be initiated by either end of the
642    IKE SA after the initial exchanges are completed.
643
644    All messages following the initial exchange are cryptographically
645    protected using the cryptographic algorithms and keys negotiated in
646    the first two messages of the IKE exchange.  These subsequent
647    messages use the syntax of the Encrypted Payload described in
648    Section 3.14, encrypted with keys that are derived as described in
649    Section 2.14.  All subsequent messages include an Encrypted Payload,
650    even if they are referred to in the text as "empty".  For both
651    messages in the CREATE_CHILD_SA, the message following the header is
652    encrypted and the message including the header is integrity protected
653    using the cryptographic algorithms negotiated for the IKE SA.
654
655    The CREATE_CHILD_SA is also used for rekeying IKE SAs and Child SAs.
656    An SA is rekeyed by creating a new SA and then deleting the old one.
657    This section describes the first part of rekeying, the creation of
658    new SAs; Section 2.8 covers the mechanics of rekeying, including
659    moving traffic from old to new SAs and the deletion of the old SAs.
660    The two sections must be read together to understand the entire
661    process of rekeying.
662
663    Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this
664    section the term initiator refers to the endpoint initiating this
665    exchange.  An implementation MAY refuse all CREATE_CHILD_SA requests
666    within an IKE SA.
667
668
669
670
671 Kaufman, et al.            Expires May 3, 2009                 [Page 12]
672 \f
673 Internet-Draft                  IKEv2bis                    October 2008
674
675
676    The CREATE_CHILD_SA request MAY optionally contain a KE payload for
677    an additional Diffie-Hellman exchange to enable stronger guarantees
678    of forward secrecy for the Child SA.  The keying material for the
679    Child SA is a function of SK_d established during the establishment
680    of the IKE SA, the nonces exchanged during the CREATE_CHILD_SA
681    exchange, and the Diffie-Hellman value (if KE payloads are included
682    in the CREATE_CHILD_SA exchange).
683
684    If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of
685    the SA offers MUST include the Diffie-Hellman group of the KEi.  The
686    Diffie-Hellman group of the KEi MUST be an element of the group the
687    initiator expects the responder to accept (additional Diffie-Hellman
688    groups can be proposed).  If the responder selects a proposal using a
689    different Diffie-Hellman group (other than NONE), the responder MUST
690    reject the request and indicate its preferred Diffie-Hellman group in
691    the INVALID_KE_PAYLOAD Notification payload. {{ 3.10.1-17 }} There
692    are two octets of data associated with this notification: the
693    accepted D-H Group number in big endian order.  In the case of such a
694    rejection, the CREATE_CHILD_SA exchange fails, and the initiator will
695    probably retry the exchange with a Diffie-Hellman proposal and KEi in
696    the group that the responder gave in the INVALID_KE_PAYLOAD.
697
698    {{ 3.10.1-35 }} The responder sends a NO_ADDITIONAL_SAS notification
699    to indicate that a CREATE_CHILD_SA request is unacceptable because
700    the responder is unwilling to accept any more Child SAs on this IKE
701    SA.  Some minimal implementations may only accept a single Child SA
702    setup in the context of an initial IKE exchange and reject any
703    subsequent attempts to add more.
704
705 1.3.1.  Creating New Child SAs with the CREATE_CHILD_SA Exchange
706
707    A Child SA may be created by sending a CREATE_CHILD_SA request.  The
708    CREATE_CHILD_SA request for creating a new Child SA is:
709
710    Initiator                         Responder
711    -------------------------------------------------------------------
712    HDR, SK {SA, Ni, [KEi],
713               TSi, TSr}  -->
714
715    The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
716    payload, optionally a Diffie-Hellman value in the KEi payload, and
717    the proposed traffic selectors for the proposed Child SA in the TSi
718    and TSr payloads.
719
720    The CREATE_CHILD_SA response for creating a new Child SA is:
721
722                                 <--  HDR, SK {SA, Nr, [KEr],
723                                          TSi, TSr}
724
725
726
727 Kaufman, et al.            Expires May 3, 2009                 [Page 13]
728 \f
729 Internet-Draft                  IKEv2bis                    October 2008
730
731
732    The responder replies (using the same Message ID to respond) with the
733    accepted offer in an SA payload, and a Diffie-Hellman value in the
734    KEr payload if KEi was included in the request and the selected
735    cryptographic suite includes that group.
736
737    The traffic selectors for traffic to be sent on that SA are specified
738    in the TS payloads in the response, which may be a subset of what the
739    initiator of the Child SA proposed.
740
741    {{ 3.10.1-16391 }} The USE_TRANSPORT_MODE notification MAY be
742    included in a request message that also includes an SA payload
743    requesting a Child SA.  It requests that the Child SA use transport
744    mode rather than tunnel mode for the SA created.  If the request is
745    accepted, the response MUST also include a notification of type
746    USE_TRANSPORT_MODE.  If the responder declines the request, the Child
747    SA will be established in tunnel mode.  If this is unacceptable to
748    the initiator, the initiator MUST delete the SA.  Note: Except when
749    using this option to negotiate transport mode, all Child SAs will use
750    tunnel mode.
751
752    {{ 3.10.1-16394 }} The ESP_TFC_PADDING_NOT_SUPPORTED notification
753    asserts that the sending endpoint will NOT accept packets that
754    contain Traffic Flow Confidentiality (TFC) padding over the Child SA
755    being negotiated. {{ Clarif-4.5 }} If neither endpoint accepts TFC
756    padding, this notification is included in both the request and the
757    response.  If this notification is included in only one of the
758    messages, TFC padding can still be sent in the other direction.
759
760    {{ 3.10.1-16395 }} The NON_FIRST_FRAGMENTS_ALSO notification is used
761    for fragmentation control.  See [IPSECARCH] for a fuller explanation.
762    {{ Clarif-4.6 }} Both parties need to agree to sending non-first
763    fragments before either party does so.  It is enabled only if
764    NON_FIRST_FRAGMENTS_ALSO notification is included in both the request
765    proposing an SA and the response accepting it.  If the responder does
766    not want to send or receive non-first fragments, it only omits
767    NON_FIRST_FRAGMENTS_ALSO notification from its response, but does not
768    reject the whole Child SA creation.
769
770 1.3.2.  Rekeying IKE SAs with the CREATE_CHILD_SA Exchange
771
772    The CREATE_CHILD_SA request for rekeying an IKE SA is:
773
774    Initiator                         Responder
775    -------------------------------------------------------------------
776    HDR, SK {SA, Ni, [KEi]} -->
777
778    The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
779    payload, and a Diffie-Hellman value in the KEi payload.  The KEi
780
781
782
783 Kaufman, et al.            Expires May 3, 2009                 [Page 14]
784 \f
785 Internet-Draft                  IKEv2bis                    October 2008
786
787
788    payload SHOULD be included.  New initiator and responder SPIs are
789    supplied in the SPI fields of the SA payload.
790
791    The CREATE_CHILD_SA response for rekeying an IKE SA is:
792
793                                 <--  HDR, SK {SA, Nr,[KEr]}
794
795    The responder replies (using the same Message ID to respond) with the
796    accepted offer in an SA payload, and a Diffie-Hellman value in the
797    KEr payload if the selected cryptographic suite includes that group.
798
799    The new IKE SA has its message counters set to 0, regardless of what
800    they were in the earlier IKE SA.  The window size starts at 1 for any
801    new IKE SA.
802
803 1.3.3.  Rekeying Child SAs with the CREATE_CHILD_SA Exchange
804
805    The CREATE_CHILD_SA request for rekeying a Child SA is:
806
807    Initiator                         Responder
808    -------------------------------------------------------------------
809    HDR, SK {N, SA, Ni, [KEi],
810        TSi, TSr}   -->
811
812    The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
813    payload, optionally a Diffie-Hellman value in the KEi payload, and
814    the proposed traffic selectors for the proposed Child SA in the TSi
815    and TSr payloads.
816
817    {{ 3.10.1-16393 }} The REKEY_SA notification MUST be included in a
818    CREATE_CHILD_SA exchange if the purpose of the exchange is to replace
819    an existing ESP or AH SA. {{ Clarif-5.4 }} The SA being rekeyed is
820    identified by the SPI field in the Notify payload; this is the SPI
821    the exchange initiator would expect in inbound ESP or AH packets.
822    There is no data associated with this Notify type.  The Protocol ID
823    field of the REKEY_SA notification is set to match the protocol of
824    the SA we are rekeying, for example, 3 for ESP and 2 for AH.
825
826    The CREATE_CHILD_SA response for rekeying a Child SA is:
827
828                                 <--  HDR, SK {SA, Nr, [KEr],
829                                          TSi, TSr}
830
831    The responder replies (using the same Message ID to respond) with the
832    accepted offer in an SA payload, and a Diffie-Hellman value in the
833    KEr payload if KEi was included in the request and the selected
834    cryptographic suite includes that group.
835
836
837
838
839 Kaufman, et al.            Expires May 3, 2009                 [Page 15]
840 \f
841 Internet-Draft                  IKEv2bis                    October 2008
842
843
844    The traffic selectors for traffic to be sent on that SA are specified
845    in the TS payloads in the response, which may be a subset of what the
846    initiator of the Child SA proposed.
847
848 1.4.  The INFORMATIONAL Exchange
849
850    At various points during the operation of an IKE SA, peers may desire
851    to convey control messages to each other regarding errors or
852    notifications of certain events.  To accomplish this, IKE defines an
853    INFORMATIONAL exchange.  INFORMATIONAL exchanges MUST ONLY occur
854    after the initial exchanges and are cryptographically protected with
855    the negotiated keys.
856
857    Control messages that pertain to an IKE SA MUST be sent under that
858    IKE SA.  Control messages that pertain to Child SAs MUST be sent
859    under the protection of the IKE SA which generated them (or its
860    successor if the IKE SA was rekeyed).
861
862    Messages in an INFORMATIONAL exchange contain zero or more
863    Notification, Delete, and Configuration payloads.  The Recipient of
864    an INFORMATIONAL exchange request MUST send some response (else the
865    Sender will assume the message was lost in the network and will
866    retransmit it).  That response MAY be a message with no payloads.
867    The request message in an INFORMATIONAL exchange MAY also contain no
868    payloads.  This is the expected way an endpoint can ask the other
869    endpoint to verify that it is alive.
870
871    The INFORMATIONAL exchange is defined as:
872
873    Initiator                         Responder
874    -------------------------------------------------------------------
875    HDR, SK {[N,] [D,]
876        [CP,] ...}  -->
877                                 <--  HDR, SK {[N,] [D,]
878                                          [CP], ...}
879
880    The processing of an INFORMATIONAL exchange is determined by its
881    component payloads.
882
883 1.4.1.  Deleting an SA with INFORMATIONAL Exchanges
884
885    {{ Clarif-5.6 }} ESP and AH SAs always exist in pairs, with one SA in
886    each direction.  When an SA is closed, both members of the pair MUST
887    be closed (that is, deleted).  Each endpoint MUST close its incoming
888    SAs and allow the other endpoint to close the other SA in each pair.
889    To delete an SA, an INFORMATIONAL exchange with one or more delete
890    payloads is sent listing the SPIs (as they would be expected in the
891    headers of inbound packets) of the SAs to be deleted.  The recipient
892
893
894
895 Kaufman, et al.            Expires May 3, 2009                 [Page 16]
896 \f
897 Internet-Draft                  IKEv2bis                    October 2008
898
899
900    MUST close the designated SAs. {{ Clarif-5.7 }} Note that one never
901    sends delete payloads for the two sides of an SA in a single message.
902    If there are many SAs to delete at the same time, one includes delete
903    payloads for the inbound half of each SA pair in your Informational
904    exchange.
905
906    Normally, the reply in the INFORMATIONAL exchange will contain delete
907    payloads for the paired SAs going in the other direction.  There is
908    one exception.  If by chance both ends of a set of SAs independently
909    decide to close them, each may send a delete payload and the two
910    requests may cross in the network.  If a node receives a delete
911    request for SAs for which it has already issued a delete request, it
912    MUST delete the outgoing SAs while processing the request and the
913    incoming SAs while processing the response.  In that case, the
914    responses MUST NOT include delete payloads for the deleted SAs, since
915    that would result in duplicate deletion and could in theory delete
916    the wrong SA.
917
918    {{ Demoted the SHOULD }} Half-closed ESP or AH connections are
919    anomalous, and a node with auditing capability should probably audit
920    their existence if they persist.  Note that this specification
921    nowhere specifies time periods, so it is up to individual endpoints
922    to decide how long to wait.  A node MAY refuse to accept incoming
923    data on half-closed connections but MUST NOT unilaterally close them
924    and reuse the SPIs.  If connection state becomes sufficiently messed
925    up, a node MAY close the IKE SA; doing so will implicitly close all
926    SAs negotiated under it.  It can then rebuild the SAs it needs on a
927    clean base under a new IKE SA. {{ Clarif-5.8 }} The response to a
928    request that deletes the IKE SA is an empty Informational response.
929
930 1.5.  Informational Messages outside of an IKE SA
931
932    If an encrypted IKE request packet arrives on port 500 or 4500 with
933    an unrecognized SPI, it could be because the receiving node has
934    recently crashed and lost state or because of some other system
935    malfunction or attack.  If the receiving node has an active IKE SA to
936    the IP address from whence the packet came, it MAY send a
937    notification of the wayward packet over that IKE SA in an
938    INFORMATIONAL exchange.  If it does not have such an IKE SA, it MAY
939    send an Informational message without cryptographic protection to the
940    source IP address.  Such a message is not part of an informational
941    exchange, and the receiving node MUST NOT respond to it.  Doing so
942    could cause a message loop.
943
944    {{ 3.10.1-11 }} The INVALID_SPI notification MAY be sent in an IKE
945    INFORMATIONAL exchange when a node receives an ESP or AH packet with
946    an invalid SPI.  The Notification Data contains the SPI of the
947    invalid packet.  This usually indicates a node has rebooted and
948
949
950
951 Kaufman, et al.            Expires May 3, 2009                 [Page 17]
952 \f
953 Internet-Draft                  IKEv2bis                    October 2008
954
955
956    forgotten an SA.  If this Informational Message is sent outside the
957    context of an IKE SA, it should only be used by the recipient as a
958    "hint" that something might be wrong (because it could easily be
959    forged).
960
961    {{ Clarif-7.7 }} There are two cases when such a one-way notification
962    is sent: INVALID_IKE_SPI and INVALID_SPI.  These notifications are
963    sent outside of an IKE SA.  Note that such notifications are
964    explicitly not Informational exchanges; these are one-way messages
965    that must not be responded to.
966
967    In case of INVALID_IKE_SPI, the message sent is a response message,
968    and thus it is sent to the IP address and port from whence it came
969    with the same IKE SPIs and the Message ID is copied.  The Response
970    bit is set to 1, and the version flags are set in the normal fashion.
971
972    In case of INVALID_SPI, however, there are no IKE SPI values that
973    would be meaningful to the recipient of such a notification.  Using
974    zero values or random values are both acceptable.  The Initiator flag
975    is set, the Response bit is set to 0, and the version flags are set
976    in the normal fashion.
977
978 1.6.  Requirements Terminology
979
980    Definitions of the primitive terms in this document (such as Security
981    Association or SA) can be found in [IPSECARCH]. {{ Clarif-7.2 }} It
982    should be noted that parts of IKEv2 rely on some of the processing
983    rules in [IPSECARCH], as described in various sections of this
984    document.
985
986    Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
987    "MAY" that appear in this document are to be interpreted as described
988    in [MUSTSHOULD].
989
990 1.7.  Differences Between RFC 4306 and This Document
991
992    {{ Added this entire section, including this recursive remark. }}
993
994    This document contains clarifications and amplifications to IKEv2
995    [IKEV2].  The clarifications are mostly based on [Clarif].  The
996    changes listed in that document were discussed in the IPsec Working
997    Group and, after the Working Group was disbanded, on the IPsec
998    mailing list.  That document contains detailed explanations of areas
999    that were unclear in IKEv2, and is thus useful to implementers of
1000    IKEv2.
1001
1002    The protocol described in this document retains the same major
1003    version number (2) and minor version number (0) as was used in RFC
1004
1005
1006
1007 Kaufman, et al.            Expires May 3, 2009                 [Page 18]
1008 \f
1009 Internet-Draft                  IKEv2bis                    October 2008
1010
1011
1012    4306.  That is, the version number is *not* changed from RFC 4306.
1013
1014    This document makes the figures and references a bit more regular
1015    than in [IKEV2].
1016
1017    IKEv2 developers have noted that the SHOULD-level requirements are
1018    often unclear in that they don't say when it is OK to not obey the
1019    requirements.  They also have noted that there are MUST-level
1020    requirements that are not related to interoperability.  This document
1021    has more explanation of some of these requirements.  All non-
1022    capitalized uses of the words SHOULD and MUST now mean their normal
1023    English sense, not the interoperability sense of [MUSTSHOULD].
1024
1025    IKEv2 (and IKEv1) developers have noted that there is a great deal of
1026    material in the tables of codes in Section 3.10.1.  This leads to
1027    implementers not having all the needed information in the main body
1028    of the document.  Much of the material from those tables has been
1029    moved into the associated parts of the main body of the document.
1030
1031    In the body of this document, notes that are enclosed in double curly
1032    braces {{ such as this }} point out changes from IKEv2.  Changes that
1033    come from [Clarif] are marked with the section from that document,
1034    such as "{{ Clarif-2.10 }}".  Changes that come from moving
1035    descriptive text out of the tables in Section 3.10.1 are marked with
1036    that number and the message type that contained the text, such as "{{
1037    3.10.1-16384 }}".
1038
1039    This document removes discussion of nesting AH and ESP.  This was a
1040    mistake in RFC 4306 caused by the lag between finishing RFC 4306 and
1041    RFC 4301.  Basically, IKEv2 is based on RFC 4301, which does not
1042    include "SA bundles" that were part of RFC 2401.  While a single
1043    packet can go through IPsec processing multiple times, each of these
1044    passes uses a separate SA, and the passes are coordinated by the
1045    forwarding tables.  In IKEv2, each of these SAs has to be created
1046    using a separate CREATE_CHILD_SA exchange.
1047
1048    This document removes discussion of the INTERNAL_ADDRESS_EXPIRY
1049    configuration attribute because its implementation was very
1050    problematic.  Implementations that conform to this document MUST
1051    ignore proposals that have configuration attribute type 5, the old
1052    value for INTERNAL_ADDRESS_EXPIRY.
1053
1054    This document adds the restriction in Section 2.13 that all PRFs used
1055    with IKEv2 MUST take variable-sized keys.  This should not affect any
1056    implementations because there were no standardized PRFs that have
1057    fixed-size keys.
1058
1059    A later version of this document may have all the {{ }} comments
1060
1061
1062
1063 Kaufman, et al.            Expires May 3, 2009                 [Page 19]
1064 \f
1065 Internet-Draft                  IKEv2bis                    October 2008
1066
1067
1068    removed from the body of the document and instead appear in an
1069    appendix.
1070
1071
1072 2.  IKE Protocol Details and Variations
1073
1074    IKE normally listens and sends on UDP port 500, though IKE messages
1075    may also be received on UDP port 4500 with a slightly different
1076    format (see Section 2.23).  Since UDP is a datagram (unreliable)
1077    protocol, IKE includes in its definition recovery from transmission
1078    errors, including packet loss, packet replay, and packet forgery.
1079    IKE is designed to function so long as (1) at least one of a series
1080    of retransmitted packets reaches its destination before timing out;
1081    and (2) the channel is not so full of forged and replayed packets so
1082    as to exhaust the network or CPU capacities of either endpoint.  Even
1083    in the absence of those minimum performance requirements, IKE is
1084    designed to fail cleanly (as though the network were broken).
1085
1086    Although IKEv2 messages are intended to be short, they contain
1087    structures with no hard upper bound on size (in particular, X.509
1088    certificates), and IKEv2 itself does not have a mechanism for
1089    fragmenting large messages.  IP defines a mechanism for fragmentation
1090    of oversize UDP messages, but implementations vary in the maximum
1091    message size supported.  Furthermore, use of IP fragmentation opens
1092    an implementation to denial of service attacks [DOSUDPPROT].
1093    Finally, some NAT and/or firewall implementations may block IP
1094    fragments.
1095
1096    All IKEv2 implementations MUST be able to send, receive, and process
1097    IKE messages that are up to 1280 octets long, and they SHOULD be able
1098    to send, receive, and process messages that are up to 3000 octets
1099    long. {{ Demoted the SHOULD }} IKEv2 implementations need to be aware
1100    of the maximum UDP message size supported and MAY shorten messages by
1101    leaving out some certificates or cryptographic suite proposals if
1102    that will keep messages below the maximum.  Use of the "Hash and URL"
1103    formats rather than including certificates in exchanges where
1104    possible can avoid most problems. {{ Demoted the SHOULD }}
1105    Implementations and configuration need to keep in mind, however, that
1106    if the URL lookups are possible only after the IPsec SA is
1107    established, recursion issues could prevent this technique from
1108    working.
1109
1110    {{ Clarif-7.5 }} The UDP payload of all packets containing IKE
1111    messages sent on port 4500 MUST begin with the prefix of four zeros;
1112    otherwise, the receiver won't know how to handle them.
1113
1114
1115
1116
1117
1118
1119 Kaufman, et al.            Expires May 3, 2009                 [Page 20]
1120 \f
1121 Internet-Draft                  IKEv2bis                    October 2008
1122
1123
1124 2.1.  Use of Retransmission Timers
1125
1126    All messages in IKE exist in pairs: a request and a response.  The
1127    setup of an IKE SA normally consists of two request/response pairs.
1128    Once the IKE SA is set up, either end of the security association may
1129    initiate requests at any time, and there can be many requests and
1130    responses "in flight" at any given moment.  But each message is
1131    labeled as either a request or a response, and for each request/
1132    response pair one end of the security association is the initiator
1133    and the other is the responder.
1134
1135    For every pair of IKE messages, the initiator is responsible for
1136    retransmission in the event of a timeout.  The responder MUST never
1137    retransmit a response unless it receives a retransmission of the
1138    request.  In that event, the responder MUST ignore the retransmitted
1139    request except insofar as it triggers a retransmission of the
1140    response.  The initiator MUST remember each request until it receives
1141    the corresponding response.  The responder MUST remember each
1142    response until it receives a request whose sequence number is larger
1143    than or equal to the sequence number in the response plus its window
1144    size (see Section 2.3).
1145
1146    IKE is a reliable protocol, in the sense that the initiator MUST
1147    retransmit a request until either it receives a corresponding reply
1148    OR it deems the IKE security association to have failed and it
1149    discards all state associated with the IKE SA and any Child SAs
1150    negotiated using that IKE SA.  A retransmission from the initiator
1151    MUST be bitwise identical to the original request.  That is,
1152    everything starting from the IKE Header (the IKE SA Initiator's SPI
1153    onwards) must be bitwise identical; items before it (such as the IP
1154    and UDP headers, and the zero non-ESP marker) do not have to be
1155    identical.
1156
1157    {{ Clarif-2.3 }} Retransmissions of the IKE_SA_INIT request require
1158    some special handling.  When a responder receives an IKE_SA_INIT
1159    request, it has to determine whether the packet is retransmission
1160    belonging to an existing "half-open" IKE SA (in which case the
1161    responder retransmits the same response), or a new request (in which
1162    case the responder creates a new IKE SA and sends a fresh response),
1163    or it belongs to an existing IKE SA where the IKE_AUTH request has
1164    been already received (in which case the responder ignores it).
1165
1166    It is not sufficient to use the initiator's SPI and/or IP address to
1167    differentiate between these three cases because two different peers
1168    behind a single NAT could choose the same initiator SPI.  Instead, a
1169    robust responder will do the IKE SA lookup using the whole packet,
1170    its hash, or the Ni payload.
1171
1172
1173
1174
1175 Kaufman, et al.            Expires May 3, 2009                 [Page 21]
1176 \f
1177 Internet-Draft                  IKEv2bis                    October 2008
1178
1179
1180 2.2.  Use of Sequence Numbers for Message ID
1181
1182    Every IKE message contains a Message ID as part of its fixed header.
1183    This Message ID is used to match up requests and responses, and to
1184    identify retransmissions of messages.
1185
1186    The Message ID is a 32-bit quantity, which is zero for the
1187    IKE_SA_INIT messages (including retries of the message due to
1188    responses such as COOKIE and INVALID_KE_PAYLOAD {{ Clarif-2.2 }}),
1189    and incremented for each subsequent exchange.  Rekeying an IKE SA
1190    resets the sequence numbers.  Thus, the first pair of IKE_AUTH
1191    messages will have ID of 1, the second (when EAP is used) will be 2,
1192    and so on. {{ Clarif-3.10 }}
1193
1194    Each endpoint in the IKE Security Association maintains two "current"
1195    Message IDs: the next one to be used for a request it initiates and
1196    the next one it expects to see in a request from the other end.
1197    These counters increment as requests are generated and received.
1198    Responses always contain the same message ID as the corresponding
1199    request.  That means that after the initial exchange, each integer n
1200    may appear as the message ID in four distinct messages: the nth
1201    request from the original IKE initiator, the corresponding response,
1202    the nth request from the original IKE responder, and the
1203    corresponding response.  If the two ends make very different numbers
1204    of requests, the Message IDs in the two directions can be very
1205    different.  There is no ambiguity in the messages, however, because
1206    the (I)nitiator and (R)esponse bits in the message header specify
1207    which of the four messages a particular one is.
1208
1209    {{ Clarif-5.9 }} Throughout this document, "initiator" refers to the
1210    party who initiated the exchange being described, and "original
1211    initiator" refers to the party who initiated the whole IKE SA.  The
1212    "original initiator" always refers to the party who initiated the
1213    exchange which resulted in the current IKE SA.  In other words, if
1214    the "original responder" starts rekeying the IKE SA, that party
1215    becomes the "original initiator" of the new IKE SA.
1216
1217    Note that Message IDs are cryptographically protected and provide
1218    protection against message replays.  In the unlikely event that
1219    Message IDs grow too large to fit in 32 bits, the IKE SA MUST be
1220    closed or rekeyed.
1221
1222 2.3.  Window Size for Overlapping Requests
1223
1224    In order to maximize IKE throughput, an IKE endpoint MAY issue
1225    multiple requests before getting a response to any of them if the
1226    other endpoint has indicated its ability to handle such requests.
1227    For simplicity, an IKE implementation MAY choose to process requests
1228
1229
1230
1231 Kaufman, et al.            Expires May 3, 2009                 [Page 22]
1232 \f
1233 Internet-Draft                  IKEv2bis                    October 2008
1234
1235
1236    strictly in order and/or wait for a response to one request before
1237    issuing another.  Certain rules must be followed to ensure
1238    interoperability between implementations using different strategies.
1239
1240    After an IKE SA is set up, either end can initiate one or more
1241    requests.  These requests may pass one another over the network.  An
1242    IKE endpoint MUST be prepared to accept and process a request while
1243    it has a request outstanding in order to avoid a deadlock in this
1244    situation. {{ Downgraded the SHOULD }} An IKE endpoint may also
1245    accept and process multiple requests while it has a request
1246    outstanding.
1247
1248    {{ 3.10.1-16385 }} The SET_WINDOW_SIZE notification asserts that the
1249    sending endpoint is capable of keeping state for multiple outstanding
1250    exchanges, permitting the recipient to send multiple requests before
1251    getting a response to the first.  The data associated with a
1252    SET_WINDOW_SIZE notification MUST be 4 octets long and contain the
1253    big endian representation of the number of messages the sender
1254    promises to keep.  The window size is always one until the initial
1255    exchanges complete.
1256
1257    An IKE endpoint MUST wait for a response to each of its messages
1258    before sending a subsequent message unless it has received a
1259    SET_WINDOW_SIZE Notify message from its peer informing it that the
1260    peer is prepared to maintain state for multiple outstanding messages
1261    in order to allow greater throughput.
1262
1263    An IKE endpoint MUST NOT exceed the peer's stated window size for
1264    transmitted IKE requests.  In other words, if the responder stated
1265    its window size is N, then when the initiator needs to make a request
1266    X, it MUST wait until it has received responses to all requests up
1267    through request X-N.  An IKE endpoint MUST keep a copy of (or be able
1268    to regenerate exactly) each request it has sent until it receives the
1269    corresponding response.  An IKE endpoint MUST keep a copy of (or be
1270    able to regenerate exactly) the number of previous responses equal to
1271    its declared window size in case its response was lost and the
1272    initiator requests its retransmission by retransmitting the request.
1273
1274    An IKE endpoint supporting a window size greater than one ought to be
1275    capable of processing incoming requests out of order to maximize
1276    performance in the event of network failures or packet reordering.
1277
1278    {{ Clarif-7.3 }} The window size is normally a (possibly
1279    configurable) property of a particular implementation, and is not
1280    related to congestion control (unlike the window size in TCP, for
1281    example).  In particular, it is not defined what the responder should
1282    do when it receives a SET_WINDOW_SIZE notification containing a
1283    smaller value than is currently in effect.  Thus, there is currently
1284
1285
1286
1287 Kaufman, et al.            Expires May 3, 2009                 [Page 23]
1288 \f
1289 Internet-Draft                  IKEv2bis                    October 2008
1290
1291
1292    no way to reduce the window size of an existing IKE SA; you can only
1293    increase it.  When rekeying an IKE SA, the new IKE SA starts with
1294    window size 1 until it is explicitly increased by sending a new
1295    SET_WINDOW_SIZE notification.
1296
1297    {{ 3.10.1-9 }}The INVALID_MESSAGE_ID notification is sent when an IKE
1298    message ID outside the supported window is received.  This Notify
1299    MUST NOT be sent in a response; the invalid request MUST NOT be
1300    acknowledged.  Instead, inform the other side by initiating an
1301    INFORMATIONAL exchange with Notification data containing the four
1302    octet invalid message ID.  Sending this notification is optional, and
1303    notifications of this type MUST be rate limited.
1304
1305 2.4.  State Synchronization and Connection Timeouts
1306
1307    An IKE endpoint is allowed to forget all of its state associated with
1308    an IKE SA and the collection of corresponding Child SAs at any time.
1309    This is the anticipated behavior in the event of an endpoint crash
1310    and restart.  It is important when an endpoint either fails or
1311    reinitializes its state that the other endpoint detect those
1312    conditions and not continue to waste network bandwidth by sending
1313    packets over discarded SAs and having them fall into a black hole.
1314
1315    {{ 3.10.1-16384 }} The INITIAL_CONTACT notification asserts that this
1316    IKE SA is the only IKE SA currently active between the authenticated
1317    identities.  It MAY be sent when an IKE SA is established after a
1318    crash, and the recipient MAY use this information to delete any other
1319    IKE SAs it has to the same authenticated identity without waiting for
1320    a timeout.  This notification MUST NOT be sent by an entity that may
1321    be replicated (e.g., a roaming user's credentials where the user is
1322    allowed to connect to the corporate firewall from two remote systems
1323    at the same time). {{ Clarif-7.9 }} The INITIAL_CONTACT notification,
1324    if sent, MUST be in the first IKE_AUTH request, not as a separate
1325    exchange afterwards; however, receiving parties need to deal with it
1326    in other requests.
1327
1328    Since IKE is designed to operate in spite of Denial of Service (DoS)
1329    attacks from the network, an endpoint MUST NOT conclude that the
1330    other endpoint has failed based on any routing information (e.g.,
1331    ICMP messages) or IKE messages that arrive without cryptographic
1332    protection (e.g., Notify messages complaining about unknown SPIs).
1333    An endpoint MUST conclude that the other endpoint has failed only
1334    when repeated attempts to contact it have gone unanswered for a
1335    timeout period or when a cryptographically protected INITIAL_CONTACT
1336    notification is received on a different IKE SA to the same
1337    authenticated identity. {{ Demoted the SHOULD }} An endpoint should
1338    suspect that the other endpoint has failed based on routing
1339    information and initiate a request to see whether the other endpoint
1340
1341
1342
1343 Kaufman, et al.            Expires May 3, 2009                 [Page 24]
1344 \f
1345 Internet-Draft                  IKEv2bis                    October 2008
1346
1347
1348    is alive.  To check whether the other side is alive, IKE specifies an
1349    empty INFORMATIONAL message that (like all IKE requests) requires an
1350    acknowledgement (note that within the context of an IKE SA, an
1351    "empty" message consists of an IKE header followed by an Encrypted
1352    payload that contains no payloads).  If a cryptographically protected
1353    (fresh, i.e. not retransmitted) message has been received from the
1354    other side recently, unprotected notifications MAY be ignored.
1355    Implementations MUST limit the rate at which they take actions based
1356    on unprotected messages.
1357
1358    Numbers of retries and lengths of timeouts are not covered in this
1359    specification because they do not affect interoperability.  It is
1360    suggested that messages be retransmitted at least a dozen times over
1361    a period of at least several minutes before giving up on an SA, but
1362    different environments may require different rules.  To be a good
1363    network citizen, retranmission times MUST increase exponentially to
1364    avoid flooding the network and making an existing congestion
1365    situation worse.  If there has only been outgoing traffic on all of
1366    the SAs associated with an IKE SA, it is essential to confirm
1367    liveness of the other endpoint to avoid black holes.  If no
1368    cryptographically protected messages have been received on an IKE SA
1369    or any of its Child SAs recently, the system needs to perform a
1370    liveness check in order to prevent sending messages to a dead peer.
1371    (This is sometimes called "dead peer detection" or "DPD", although it
1372    is really detecting live peers, not dead ones.)  Receipt of a fresh
1373    cryptographically protected message on an IKE SA or any of its Child
1374    SAs ensures liveness of the IKE SA and all of its Child SAs.  Note
1375    that this places requirements on the failure modes of an IKE
1376    endpoint.  An implementation MUST NOT continue sending on any SA if
1377    some failure prevents it from receiving on all of the associated SAs.
1378    If Child SAs can fail independently from one another without the
1379    associated IKE SA being able to send a delete message, then they MUST
1380    be negotiated by separate IKE SAs.
1381
1382    There is a Denial of Service attack on the initiator of an IKE SA
1383    that can be avoided if the initiator takes the proper care.  Since
1384    the first two messages of an SA setup are not cryptographically
1385    protected, an attacker could respond to the initiator's message
1386    before the genuine responder and poison the connection setup attempt.
1387    To prevent this, the initiator MAY be willing to accept multiple
1388    responses to its first message, treat each as potentially legitimate,
1389    respond to it, and then discard all the invalid half-open connections
1390    when it receives a valid cryptographically protected response to any
1391    one of its requests.  Once a cryptographically valid response is
1392    received, all subsequent responses should be ignored whether or not
1393    they are cryptographically valid.
1394
1395    Note that with these rules, there is no reason to negotiate and agree
1396
1397
1398
1399 Kaufman, et al.            Expires May 3, 2009                 [Page 25]
1400 \f
1401 Internet-Draft                  IKEv2bis                    October 2008
1402
1403
1404    upon an SA lifetime.  If IKE presumes the partner is dead, based on
1405    repeated lack of acknowledgement to an IKE message, then the IKE SA
1406    and all Child SAs set up through that IKE SA are deleted.
1407
1408    An IKE endpoint may at any time delete inactive Child SAs to recover
1409    resources used to hold their state.  If an IKE endpoint chooses to
1410    delete Child SAs, it MUST send Delete payloads to the other end
1411    notifying it of the deletion.  It MAY similarly time out the IKE SA.
1412    {{ Clarified the SHOULD }} Closing the IKE SA implicitly closes all
1413    associated Child SAs.  In this case, an IKE endpoint SHOULD send a
1414    Delete payload indicating that it has closed the IKE SA unless the
1415    other endpoint is no longer responding.
1416
1417 2.5.  Version Numbers and Forward Compatibility
1418
1419    This document describes version 2.0 of IKE, meaning the major version
1420    number is 2 and the minor version number is 0. {{ Restated the
1421    relationship to RFC 4306 }} This document is a replacement for
1422    [IKEV2].  It is likely that some implementations will want to support
1423    version 1.0 and version 2.0, and in the future, other versions.
1424
1425    The major version number should be incremented only if the packet
1426    formats or required actions have changed so dramatically that an
1427    older version node would not be able to interoperate with a newer
1428    version node if it simply ignored the fields it did not understand
1429    and took the actions specified in the older specification.  The minor
1430    version number indicates new capabilities, and MUST be ignored by a
1431    node with a smaller minor version number, but used for informational
1432    purposes by the node with the larger minor version number.  For
1433    example, it might indicate the ability to process a newly defined
1434    notification message.  The node with the larger minor version number
1435    would simply note that its correspondent would not be able to
1436    understand that message and therefore would not send it.
1437
1438    {{ 3.10.1-5 }} If an endpoint receives a message with a higher major
1439    version number, it MUST drop the message and SHOULD send an
1440    unauthenticated notification message of type INVALID_MAJOR_VERSION
1441    containing the highest (closest) version number it supports.  If an
1442    endpoint supports major version n, and major version m, it MUST
1443    support all versions between n and m.  If it receives a message with
1444    a major version that it supports, it MUST respond with that version
1445    number.  In order to prevent two nodes from being tricked into
1446    corresponding with a lower major version number than the maximum that
1447    they both support, IKE has a flag that indicates that the node is
1448    capable of speaking a higher major version number.
1449
1450    Thus, the major version number in the IKE header indicates the
1451    version number of the message, not the highest version number that
1452
1453
1454
1455 Kaufman, et al.            Expires May 3, 2009                 [Page 26]
1456 \f
1457 Internet-Draft                  IKEv2bis                    October 2008
1458
1459
1460    the transmitter supports.  If the initiator is capable of speaking
1461    versions n, n+1, and n+2, and the responder is capable of speaking
1462    versions n and n+1, then they will negotiate speaking n+1, where the
1463    initiator will set a flag indicating its ability to speak a higher
1464    version.  If they mistakenly (perhaps through an active attacker
1465    sending error messages) negotiate to version n, then both will notice
1466    that the other side can support a higher version number, and they
1467    MUST break the connection and reconnect using version n+1.
1468
1469    Note that IKEv1 does not follow these rules, because there is no way
1470    in v1 of noting that you are capable of speaking a higher version
1471    number.  So an active attacker can trick two v2-capable nodes into
1472    speaking v1. {{ Demoted the SHOULD }} When a v2-capable node
1473    negotiates down to v1, it should note that fact in its logs.
1474
1475    Also for forward compatibility, all fields marked RESERVED MUST be
1476    set to zero by an implementation running version 2.0, and their
1477    content MUST be ignored by an implementation running version 2.0 ("Be
1478    conservative in what you send and liberal in what you receive").  In
1479    this way, future versions of the protocol can use those fields in a
1480    way that is guaranteed to be ignored by implementations that do not
1481    understand them.  Similarly, payload types that are not defined are
1482    reserved for future use; implementations of a version where they are
1483    undefined MUST skip over those payloads and ignore their contents.
1484
1485    IKEv2 adds a "critical" flag to each payload header for further
1486    flexibility for forward compatibility.  If the critical flag is set
1487    and the payload type is unrecognized, the message MUST be rejected
1488    and the response to the IKE request containing that payload MUST
1489    include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an
1490    unsupported critical payload was included. {{ 3.10.1-1 }} In that
1491    Notify payload, the notification data contains the one-octet payload
1492    type.  If the critical flag is not set and the payload type is
1493    unsupported, that payload MUST be ignored.  Payloads sent in IKE
1494    response messages MUST NOT have the critical flag set.  Note that the
1495    critical flag applies only to the payload type, not the contents.  If
1496    the payload type is recognized, but the payload contains something
1497    which is not (such as an unknown transform inside an SA payload, or
1498    an unknown Notify Message Type inside a Notify payload), the critical
1499    flag is ignored.
1500
1501    {{ Demoted the SHOULD in the second clause }}Although new payload
1502    types may be added in the future and may appear interleaved with the
1503    fields defined in this specification, implementations MUST send the
1504    payloads defined in this specification in the order shown in the
1505    figures in Section 2; implementations are explicitly allowed to
1506    reject as invalid a message with those payloads in any other order.
1507
1508
1509
1510
1511 Kaufman, et al.            Expires May 3, 2009                 [Page 27]
1512 \f
1513 Internet-Draft                  IKEv2bis                    October 2008
1514
1515
1516 2.6.  IKE SA SPIs and Cookies
1517
1518    The term "cookies" originates with Karn and Simpson [PHOTURIS] in
1519    Photuris, an early proposal for key management with IPsec, and it has
1520    persisted.  The Internet Security Association and Key Management
1521    Protocol (ISAKMP) [ISAKMP] fixed message header includes two eight-
1522    octet fields titled "cookies", and that syntax is used by both IKEv1
1523    and IKEv2, although in IKEv2 they are referred to as the "IKE SPI"
1524    and there is a new separate field in a Notify payload holding the
1525    cookie.  The initial two eight-octet fields in the header are used as
1526    a connection identifier at the beginning of IKE packets.  Each
1527    endpoint chooses one of the two SPIs and MUST choose them so as to be
1528    unique identifiers of an IKE SA.  An SPI value of zero is special and
1529    indicates that the remote SPI value is not yet known by the sender.
1530
1531    Incoming IKE packets are mapped to an IKE SA only using the packet's
1532    SPI, not using (for example) the source IP address of the packet.
1533
1534    Unlike ESP and AH where only the recipient's SPI appears in the
1535    header of a message, in IKE the sender's SPI is also sent in every
1536    message.  Since the SPI chosen by the original initiator of the IKE
1537    SA is always sent first, an endpoint with multiple IKE SAs open that
1538    wants to find the appropriate IKE SA using the SPI it assigned must
1539    look at the I(nitiator) Flag bit in the header to determine whether
1540    it assigned the first or the second eight octets.
1541
1542    In the first message of an initial IKE exchange, the initiator will
1543    not know the responder's SPI value and will therefore set that field
1544    to zero.
1545
1546    An expected attack against IKE is state and CPU exhaustion, where the
1547    target is flooded with session initiation requests from forged IP
1548    addresses.  This attack can be made less effective if an
1549    implementation of a responder uses minimal CPU and commits no state
1550    to an SA until it knows the initiator can receive packets at the
1551    address from which it claims to be sending them.
1552
1553    When a responder detects a large number of half-open IKE SAs, it
1554    SHOULD reply to IKE_SA_INIT requests with a response containing the
1555    COOKIE notification. {{ 3.10.1-16390 }} The data associated with this
1556    notification MUST be between 1 and 64 octets in length (inclusive),
1557    and its generation is described later in this section.  If the
1558    IKE_SA_INIT response includes the COOKIE notification, the initiator
1559    MUST then retry the IKE_SA_INIT request, and include the COOKIE
1560    notification containing the received data as the first payload, and
1561    all other payloads unchanged.  The initial exchange will then be as
1562    follows:
1563
1564
1565
1566
1567 Kaufman, et al.            Expires May 3, 2009                 [Page 28]
1568 \f
1569 Internet-Draft                  IKEv2bis                    October 2008
1570
1571
1572    Initiator                         Responder
1573    -------------------------------------------------------------------
1574    HDR(A,0), SAi1, KEi, Ni  -->
1575                                 <--  HDR(A,0), N(COOKIE)
1576    HDR(A,0), N(COOKIE), SAi1,
1577        KEi, Ni  -->
1578                                 <--  HDR(A,B), SAr1, KEr,
1579                                          Nr, [CERTREQ]
1580    HDR(A,B), SK {IDi, [CERT,]
1581        [CERTREQ,] [IDr,] AUTH,
1582        SAi2, TSi, TSr}  -->
1583                                 <--  HDR(A,B), SK {IDr, [CERT,]
1584                                          AUTH, SAr2, TSi, TSr}
1585
1586    The first two messages do not affect any initiator or responder state
1587    except for communicating the cookie.  In particular, the message
1588    sequence numbers in the first four messages will all be zero and the
1589    message sequence numbers in the last two messages will be one.  'A'
1590    is the SPI assigned by the initiator, while 'B' is the SPI assigned
1591    by the responder.
1592
1593    {{ Demoted the SHOULD }} An IKE implementation can implement its
1594    responder cookie generation in such a way as to not require any saved
1595    state to recognize its valid cookie when the second IKE_SA_INIT
1596    message arrives.  The exact algorithms and syntax they use to
1597    generate cookies do not affect interoperability and hence are not
1598    specified here.  The following is an example of how an endpoint could
1599    use cookies to implement limited DOS protection.
1600
1601    A good way to do this is to set the responder cookie to be:
1602
1603    Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)
1604
1605    where <secret> is a randomly generated secret known only to the
1606    responder and periodically changed and | indicates concatenation.
1607    <VersionIDofSecret> should be changed whenever <secret> is
1608    regenerated.  The cookie can be recomputed when the IKE_SA_INIT
1609    arrives the second time and compared to the cookie in the received
1610    message.  If it matches, the responder knows that the cookie was
1611    generated since the last change to <secret> and that IPi must be the
1612    same as the source address it saw the first time.  Incorporating SPIi
1613    into the calculation ensures that if multiple IKE SAs are being set
1614    up in parallel they will all get different cookies (assuming the
1615    initiator chooses unique SPIi's).  Incorporating Ni into the hash
1616    ensures that an attacker who sees only message 2 can't successfully
1617    forge a message 3.
1618
1619    If a new value for <secret> is chosen while there are connections in
1620
1621
1622
1623 Kaufman, et al.            Expires May 3, 2009                 [Page 29]
1624 \f
1625 Internet-Draft                  IKEv2bis                    October 2008
1626
1627
1628    the process of being initialized, an IKE_SA_INIT might be returned
1629    with other than the current <VersionIDofSecret>.  The responder in
1630    that case MAY reject the message by sending another response with a
1631    new cookie or it MAY keep the old value of <secret> around for a
1632    short time and accept cookies computed from either one. {{ Demoted
1633    the SHOULD NOT }} The responder should not accept cookies
1634    indefinitely after <secret> is changed, since that would defeat part
1635    of the denial of service protection. {{ Demoted the SHOULD }} The
1636    responder should change the value of <secret> frequently, especially
1637    if under attack.
1638
1639    {{ Clarif-2.1 }} In addition to cookies, there are several cases
1640    where the IKE_SA_INIT exchange does not result in the creation of an
1641    IKE SA (such as INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN).  In such a
1642    case, sending a zero value for the Responder's SPI is correct.  If
1643    the responder sends a non-zero responder SPI, the initiator should
1644    not reject the response for only that reason.
1645
1646    {{ Clarif-2.5 }} When one party receives an IKE_SA_INIT request
1647    containing a cookie whose contents do not match the value expected,
1648    that party MUST ignore the cookie and process the message as if no
1649    cookie had been included; usually this means sending a response
1650    containing a new cookie.  The initiator should limit the number of
1651    cookie exchanges it tries before giving up.  An attacker can forge
1652    multiple cookie responses to the initiator's IKE_SA_INIT message, and
1653    each of those forged cookie reply will trigger two packets: one
1654    packet from the initiator to the responder (which will reject those
1655    cookies), and one reply from responder to initiator that includes the
1656    correct cookie.
1657
1658 2.6.1.  Interaction of COOKIE and INVALID_KE_PAYLOAD
1659
1660    {{ This section added by Clarif-2.4 }}
1661
1662    There are two common reasons why the initiator may have to retry the
1663    IKE_SA_INIT exchange: the responder requests a cookie or wants a
1664    different Diffie-Hellman group than was included in the KEi payload.
1665    If the initiator receives a cookie from the responder, the initiator
1666    needs to decide whether or not to include the cookie in only the next
1667    retry of the IKE_SA_INIT request, or in all subsequent retries as
1668    well.
1669
1670    If the initiator includes the cookie only in the next retry, one
1671    additional roundtrip may be needed in some cases.  An additional
1672    roundtrip is needed also if the initiator includes the cookie in all
1673    retries, but the responder does not support this.  For instance, if
1674    the responder includes the SAi1 and KEi payloads in cookie
1675    calculation, it will reject the request by sending a new cookie.
1676
1677
1678
1679 Kaufman, et al.            Expires May 3, 2009                 [Page 30]
1680 \f
1681 Internet-Draft                  IKEv2bis                    October 2008
1682
1683
1684    If both peers support including the cookie in all retries, a slightly
1685    shorter exchange can happen.
1686
1687    Initiator                   Responder
1688    -----------------------------------------------------------
1689    HDR(A,0), SAi1, KEi, Ni -->
1690                            <-- HDR(A,0), N(COOKIE)
1691    HDR(A,0), N(COOKIE), SAi1, KEi, Ni  -->
1692                            <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
1693    HDR(A,0), N(COOKIE), SAi1, KEi', Ni -->
1694                            <-- HDR(A,B), SAr1, KEr, Nr
1695
1696    Implementations SHOULD support this shorter exchange, but MUST NOT
1697    fail if other implementations do not support this shorter exchange.
1698
1699 2.7.  Cryptographic Algorithm Negotiation
1700
1701    The payload type known as "SA" indicates a proposal for a set of
1702    choices of IPsec protocols (IKE, ESP, or AH) for the SA as well as
1703    cryptographic algorithms associated with each protocol.
1704
1705    An SA payload consists of one or more proposals. {{ Clarif-7.13 }}
1706    Each proposal includes one protocol.  Each protocol contains one or
1707    more transforms -- each specifying a cryptographic algorithm.  Each
1708    transform contains zero or more attributes (attributes are needed
1709    only if the transform identifier does not completely specify the
1710    cryptographic algorithm).
1711
1712    This hierarchical structure was designed to efficiently encode
1713    proposals for cryptographic suites when the number of supported
1714    suites is large because multiple values are acceptable for multiple
1715    transforms.  The responder MUST choose a single suite, which may be
1716    any subset of the SA proposal following the rules below:
1717
1718    {{ Clarif-7.13 }} Each proposal contains one protocol.  If a proposal
1719    is accepted, the SA response MUST contain the same protocol.  The
1720    responder MUST accept a single proposal or reject them all and return
1721    an error. {{ 3.10.1-14 }} The error is given in a notification of
1722    type NO_PROPOSAL_CHOSEN.
1723
1724    Each IPsec protocol proposal contains one or more transforms.  Each
1725    transform contains a transform type.  The accepted cryptographic
1726    suite MUST contain exactly one transform of each type included in the
1727    proposal.  For example: if an ESP proposal includes transforms
1728    ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256,
1729    AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one
1730    of the ENCR_ transforms and one of the AUTH_ transforms.  Thus, six
1731    combinations are acceptable.
1732
1733
1734
1735 Kaufman, et al.            Expires May 3, 2009                 [Page 31]
1736 \f
1737 Internet-Draft                  IKEv2bis                    October 2008
1738
1739
1740    If an initiator proposes both normal ciphers with integrity
1741    protection as well as combined-mode ciphers, then two proposals are
1742    needed.  One of the proposals includes the normal ciphers with the
1743    integrity algoritms for them, and the other proposal includes all the
1744    combined mode ciphers without the integrity algorithms (because
1745    combined mode ciphers are not allowed to have any integrity algorithm
1746    other than "none").
1747
1748    Since the initiator sends its Diffie-Hellman value in the
1749    IKE_SA_INIT, it must guess the Diffie-Hellman group that the
1750    responder will select from its list of supported groups.  If the
1751    initiator guesses wrong, the responder will respond with a Notify
1752    payload of type INVALID_KE_PAYLOAD indicating the selected group.  In
1753    this case, the initiator MUST retry the IKE_SA_INIT with the
1754    corrected Diffie-Hellman group.  The initiator MUST again propose its
1755    full set of acceptable cryptographic suites because the rejection
1756    message was unauthenticated and otherwise an active attacker could
1757    trick the endpoints into negotiating a weaker suite than a stronger
1758    one that they both prefer.
1759
1760    {{ Clarif-2.1 }} When the IKE_SA_INIT exchange does not result in the
1761    creation of an IKE SA due to INVALID_KE_PAYLOAD, NO_PROPOSAL_CHOSEN,
1762    or COOKIE (see Section 2.6), the responder's SPI will be zero.
1763    However, if the responder sends a non-zero responder SPI, the
1764    initiator should not reject the response for only that reason.
1765
1766 2.8.  Rekeying
1767
1768    {{ Demoted the SHOULD }} IKE, ESP, and AH security associations use
1769    secret keys that should be used only for a limited amount of time and
1770    to protect a limited amount of data.  This limits the lifetime of the
1771    entire security association.  When the lifetime of a security
1772    association expires, the security association MUST NOT be used.  If
1773    there is demand, new security associations MAY be established.
1774    Reestablishment of security associations to take the place of ones
1775    that expire is referred to as "rekeying".
1776
1777    To allow for minimal IPsec implementations, the ability to rekey SAs
1778    without restarting the entire IKE SA is optional.  An implementation
1779    MAY refuse all CREATE_CHILD_SA requests within an IKE SA.  If an SA
1780    has expired or is about to expire and rekeying attempts using the
1781    mechanisms described here fail, an implementation MUST close the IKE
1782    SA and any associated Child SAs and then MAY start new ones. {{
1783    Demoted the SHOULD }} Implementations may wish to support in-place
1784    rekeying of SAs, since doing so offers better performance and is
1785    likely to reduce the number of packets lost during the transition.
1786
1787    To rekey a Child SA within an existing IKE SA, create a new,
1788
1789
1790
1791 Kaufman, et al.            Expires May 3, 2009                 [Page 32]
1792 \f
1793 Internet-Draft                  IKEv2bis                    October 2008
1794
1795
1796    equivalent SA (see Section 2.17 below), and when the new one is
1797    established, delete the old one.  To rekey an IKE SA, establish a new
1798    equivalent IKE SA (see Section 2.18 below) with the peer to whom the
1799    old IKE SA is shared using a CREATE_CHILD_SA within the existing IKE
1800    SA.  An IKE SA so created inherits all of the original IKE SA's Child
1801    SAs, and the new IKE SA is used for all control messages needed to
1802    maintain those Child SAs.  The old IKE SA is then deleted, and the
1803    Delete payload to delete itself MUST be the last request sent over
1804    the old IKE SA.  Note that, when rekeying, the new Child SA MAY have
1805    different traffic selectors and algorithms than the old one.
1806
1807    {{ Demoted the SHOULD }} SAs should be rekeyed proactively, i.e., the
1808    new SA should be established before the old one expires and becomes
1809    unusable.  Enough time should elapse between the time the new SA is
1810    established and the old one becomes unusable so that traffic can be
1811    switched over to the new SA.
1812
1813    A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes
1814    were negotiated.  In IKEv2, each end of the SA is responsible for
1815    enforcing its own lifetime policy on the SA and rekeying the SA when
1816    necessary.  If the two ends have different lifetime policies, the end
1817    with the shorter lifetime will end up always being the one to request
1818    the rekeying.  If an SA has been inactive for a long time and if an
1819    endpoint would not initiate the SA in the absence of traffic, the
1820    endpoint MAY choose to close the SA instead of rekeying it when its
1821    lifetime expires. {{ Demoted the SHOULD }} It should do so if there
1822    has been no traffic since the last time the SA was rekeyed.
1823
1824    Note that IKEv2 deliberately allows parallel SAs with the same
1825    traffic selectors between common endpoints.  One of the purposes of
1826    this is to support traffic quality of service (QoS) differences among
1827    the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and section 4.1 of
1828    [DIFFTUNNEL]).  Hence unlike IKEv1, the combination of the endpoints
1829    and the traffic selectors may not uniquely identify an SA between
1830    those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on
1831    the basis of duplicate traffic selectors SHOULD NOT be used.
1832
1833    {{ Demoted the SHOULD }} The node that initiated the surviving
1834    rekeyed SA should delete the replaced SA after the new one is
1835    established.
1836
1837    There are timing windows -- particularly in the presence of lost
1838    packets -- where endpoints may not agree on the state of an SA.  The
1839    responder to a CREATE_CHILD_SA MUST be prepared to accept messages on
1840    an SA before sending its response to the creation request, so there
1841    is no ambiguity for the initiator.  The initiator MAY begin sending
1842    on an SA as soon as it processes the response.  The initiator,
1843    however, cannot receive on a newly created SA until it receives and
1844
1845
1846
1847 Kaufman, et al.            Expires May 3, 2009                 [Page 33]
1848 \f
1849 Internet-Draft                  IKEv2bis                    October 2008
1850
1851
1852    processes the response to its CREATE_CHILD_SA request.  How, then, is
1853    the responder to know when it is OK to send on the newly created SA?
1854
1855    From a technical correctness and interoperability perspective, the
1856    responder MAY begin sending on an SA as soon as it sends its response
1857    to the CREATE_CHILD_SA request.  In some situations, however, this
1858    could result in packets unnecessarily being dropped, so an
1859    implementation MAY defer such sending.
1860
1861    The responder can be assured that the initiator is prepared to
1862    receive messages on an SA if either (1) it has received a
1863    cryptographically valid message on the new SA, or (2) the new SA
1864    rekeys an existing SA and it receives an IKE request to close the
1865    replaced SA.  When rekeying an SA, the responder continues to send
1866    traffic on the old SA until one of those events occurs.  When
1867    establishing a new SA, the responder MAY defer sending messages on a
1868    new SA until either it receives one or a timeout has occurred. {{
1869    Demoted the SHOULD }} If an initiator receives a message on an SA for
1870    which it has not received a response to its CREATE_CHILD_SA request,
1871    it interprets that as a likely packet loss and retransmits the
1872    CREATE_CHILD_SA request.  An initiator MAY send a dummy message on a
1873    newly created SA if it has no messages queued in order to assure the
1874    responder that the initiator is ready to receive messages.
1875
1876 2.8.1.  Simultaneous Child SA rekeying
1877
1878    {{ The first two paragraphs were moved, and the rest was added, based
1879    on Clarif-5.11 }}
1880
1881    If the two ends have the same lifetime policies, it is possible that
1882    both will initiate a rekeying at the same time (which will result in
1883    redundant SAs).  To reduce the probability of this happening, the
1884    timing of rekeying requests SHOULD be jittered (delayed by a random
1885    amount of time after the need for rekeying is noticed).
1886
1887    This form of rekeying may temporarily result in multiple similar SAs
1888    between the same pairs of nodes.  When there are two SAs eligible to
1889    receive packets, a node MUST accept incoming packets through either
1890    SA.  If redundant SAs are created though such a collision, the SA
1891    created with the lowest of the four nonces used in the two exchanges
1892    SHOULD be closed by the endpoint that created it. {{ Clarif-5.10 }}
1893    "Lowest" means an octet-by-octet, lexicographical comparison (instead
1894    of, for instance, comparing the nonces as large integers).  In other
1895    words, start by comparing the first octet; if they're equal, move to
1896    the next octet, and so on.  If you reach the end of one nonce, that
1897    nonce is the lower one.
1898
1899    The following is an explanation on the impact this has on
1900
1901
1902
1903 Kaufman, et al.            Expires May 3, 2009                 [Page 34]
1904 \f
1905 Internet-Draft                  IKEv2bis                    October 2008
1906
1907
1908    implementations.  Assume that hosts A and B have an existing IPsec SA
1909    pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same
1910    time:
1911
1912    Host A                            Host B
1913    -------------------------------------------------------------------
1914    send req1: N(REKEY_SA,SPIa1),
1915        SA(..,SPIa2,..),Ni1,..  -->
1916                                 <--  send req2: N(REKEY_SA,SPIb1),
1917                                          SA(..,SPIb2,..),Ni2
1918    recv req2 <--
1919
1920    At this point, A knows there is a simultaneous rekeying going on.
1921    However, it cannot yet know which of the exchanges will have the
1922    lowest nonce, so it will just note the situation and respond as
1923    usual.
1924
1925    send resp2: SA(..,SPIa3,..),
1926         Nr1,..  -->
1927                                 -->  recv req1
1928
1929    Now B also knows that simultaneous rekeying is going on.  It responds
1930    as usual.
1931
1932                                <--  send resp1: SA(..,SPIb3,..),
1933                                         Nr2,..
1934    recv resp1 <--
1935                                -->  recv resp2
1936
1937    At this point, there are three Child SA pairs between A and B (the
1938    old one and two new ones).  A and B can now compare the nonces.
1939    Suppose that the lowest nonce was Nr1 in message resp2; in this case,
1940    B (the sender of req2) deletes the redundant new SA, and A (the node
1941    that initiated the surviving rekeyed SA), deletes the old one.
1942
1943    send req3: D(SPIa1) -->
1944                                 <--  send req4: D(SPIb2)
1945                                 -->  recv req3
1946                                 <--  send resp3: D(SPIb1)
1947    recv req4 <--
1948    send resp4: D(SPIa3) -->
1949
1950    The rekeying is now finished.
1951
1952    However, there is a second possible sequence of events that can
1953    happen if some packets are lost in the network, resulting in
1954    retransmissions.  The rekeying begins as usual, but A's first packet
1955    (req1) is lost.
1956
1957
1958
1959 Kaufman, et al.            Expires May 3, 2009                 [Page 35]
1960 \f
1961 Internet-Draft                  IKEv2bis                    October 2008
1962
1963
1964    Host A                            Host B
1965    -------------------------------------------------------------------
1966    send req1: N(REKEY_SA,SPIa1),
1967        SA(..,SPIa2,..),
1968        Ni1,..  -->  (lost)
1969                                 <--  send req2: N(REKEY_SA,SPIb1),
1970                                          SA(..,SPIb2,..),Ni2
1971    recv req2 <--
1972    send resp2: SA(..,SPIa3,..),
1973        Nr1,.. -->
1974                                 -->  recv resp2
1975                                 <--  send req3: D(SPIb1)
1976    recv req3 <--
1977    send resp3: D(SPIa1) -->
1978                                 -->  recv resp3
1979
1980    From B's point of view, the rekeying is now completed, and since it
1981    has not yet received A's req1, it does not even know that there was
1982    simultaneous rekeying.  However, A will continue retransmitting the
1983    message, and eventually it will reach B.
1984
1985    resend req1 -->
1986                                 -->  recv req1
1987
1988    To B, it looks like A is trying to rekey an SA that no longer exists;
1989    thus, B responds to the request with something non-fatal such as
1990    NO_PROPOSAL_CHOSEN.
1991
1992                                 <--  send resp1: N(NO_PROPOSAL_CHOSEN)
1993    recv resp1 <--
1994
1995    When A receives this error, it already knows there was simultaneous
1996    rekeying, so it can ignore the error message.
1997
1998 2.8.2.   Rekeying the IKE SA Versus Reauthentication
1999
2000    {{ Added this section from Clarif-5.2 }}
2001
2002    Rekeying the IKE SA and reauthentication are different concepts in
2003    IKEv2.  Rekeying the IKE SA establishes new keys for the IKE SA and
2004    resets the Message ID counters, but it does not authenticate the
2005    parties again (no AUTH or EAP payloads are involved).
2006
2007    Although rekeying the IKE SA may be important in some environments,
2008    reauthentication (the verification that the parties still have access
2009    to the long-term credentials) is often more important.
2010
2011    IKEv2 does not have any special support for reauthentication.
2012
2013
2014
2015 Kaufman, et al.            Expires May 3, 2009                 [Page 36]
2016 \f
2017 Internet-Draft                  IKEv2bis                    October 2008
2018
2019
2020    Reauthentication is done by creating a new IKE SA from scratch (using
2021    IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify
2022    payloads), creating new Child SAs within the new IKE SA (without
2023    REKEY_SA notify payloads), and finally deleting the old IKE SA (which
2024    deletes the old Child SAs as well).
2025
2026    This means that reauthentication also establishes new keys for the
2027    IKE SA and Child SAs.  Therefore, while rekeying can be performed
2028    more often than reauthentication, the situation where "authentication
2029    lifetime" is shorter than "key lifetime" does not make sense.
2030
2031    While creation of a new IKE SA can be initiated by either party
2032    (initiator or responder in the original IKE SA), the use of EAP
2033    authentication and/or configuration payloads means in practice that
2034    reauthentication has to be initiated by the same party as the
2035    original IKE SA.  IKEv2 does not currently allow the responder to
2036    request reauthentication in this case; however, there are extensions
2037    that add this functionality such as [REAUTH].
2038
2039 2.9.  Traffic Selector Negotiation
2040
2041    {{ Clarif-7.2 }} When an RFC4301-compliant IPsec subsystem receives
2042    an IP packet that matches a "protect" selector in its Security Policy
2043    Database (SPD), the subsystem protects that packet with IPsec.  When
2044    no SA exists yet, it is the task of IKE to create it.  Maintenance of
2045    a system's SPD is outside the scope of IKE (see [PFKEY] for an
2046    example protocol, although it only applies to IKEv1), though some
2047    implementations might update their SPD in connection with the running
2048    of IKE (for an example scenario, see Section 1.1.3).
2049
2050    Traffic Selector (TS) payloads allow endpoints to communicate some of
2051    the information from their SPD to their peers.  TS payloads specify
2052    the selection criteria for packets that will be forwarded over the
2053    newly set up SA.  This can serve as a consistency check in some
2054    scenarios to assure that the SPDs are consistent.  In others, it
2055    guides the dynamic update of the SPD.
2056
2057    Two TS payloads appear in each of the messages in the exchange that
2058    creates a Child SA pair.  Each TS payload contains one or more
2059    Traffic Selectors.  Each Traffic Selector consists of an address
2060    range (IPv4 or IPv6), a port range, and an IP protocol ID.
2061
2062    The first of the two TS payloads is known as TSi (Traffic Selector-
2063    initiator).  The second is known as TSr (Traffic Selector-responder).
2064    TSi specifies the source address of traffic forwarded from (or the
2065    destination address of traffic forwarded to) the initiator of the
2066    Child SA pair.  TSr specifies the destination address of the traffic
2067    forwarded to (or the source address of the traffic forwarded from)
2068
2069
2070
2071 Kaufman, et al.            Expires May 3, 2009                 [Page 37]
2072 \f
2073 Internet-Draft                  IKEv2bis                    October 2008
2074
2075
2076    the responder of the Child SA pair.  For example, if the original
2077    initiator requests the creation of a Child SA pair, and wishes to
2078    tunnel all traffic from subnet 192.0.1.* on the initiator's side to
2079    subnet 192.0.2.* on the responder's side, the initiator would include
2080    a single traffic selector in each TS payload.  TSi would specify the
2081    address range (192.0.1.0 - 192.0.1.255) and TSr would specify the
2082    address range (192.0.2.0 - 192.0.2.255).  Assuming that proposal was
2083    acceptable to the responder, it would send identical TS payloads
2084    back.  (Note: The IP address range 192.0.2.* has been reserved for
2085    use in examples in RFCs and similar documents.  This document needed
2086    two such ranges, and so also used 192.0.1.*.  This should not be
2087    confused with any actual address.)
2088
2089    IKEv2 allows the responder to choose a subset of the traffic proposed
2090    by the initiator.  This could happen when the configurations of the
2091    two endpoints are being updated but only one end has received the new
2092    information.  Since the two endpoints may be configured by different
2093    people, the incompatibility may persist for an extended period even
2094    in the absence of errors.  It also allows for intentionally different
2095    configurations, as when one end is configured to tunnel all addresses
2096    and depends on the other end to have the up-to-date list.
2097
2098    When the responder chooses a subset of the traffic proposed by the
2099    initiator, it narrows the traffic selectors to some subset of the
2100    initiator's proposal (provided the set does not become the null set).
2101    If the type of traffic selector proposed is unknown, the responder
2102    ignores that traffic selector, so that the unknown type is not be
2103    returned in the narrowed set.
2104
2105    To enable the responder to choose the appropriate range in this case,
2106    if the initiator has requested the SA due to a data packet, the
2107    initiator SHOULD include as the first traffic selector in each of TSi
2108    and TSr a very specific traffic selector including the addresses in
2109    the packet triggering the request.  In the example, the initiator
2110    would include in TSi two traffic selectors: the first containing the
2111    address range (192.0.1.43 - 192.0.1.43) and the source port and IP
2112    protocol from the packet and the second containing (192.0.1.0 -
2113    192.0.1.255) with all ports and IP protocols.  The initiator would
2114    similarly include two traffic selectors in TSr.  If the initiator
2115    creates the Child SA pair not in response to an arriving packet, but
2116    rather, say, upon startup, then there may be no specific addresses
2117    the initiator prefers for the initial tunnel over any other.  In that
2118    case, the first values in TSi and TSr can be ranges rather than
2119    specific values.
2120
2121    The responder performs the narrowing as follows: {{ Clarif-4.10 }}
2122
2123
2124
2125
2126
2127 Kaufman, et al.            Expires May 3, 2009                 [Page 38]
2128 \f
2129 Internet-Draft                  IKEv2bis                    October 2008
2130
2131
2132    o  If the responder's policy does not allow it to accept any part of
2133       the proposed traffic selectors, it responds with TS_UNACCEPTABLE.
2134
2135    o  If the responder's policy allows the entire set of traffic covered
2136       by TSi and TSr, no narrowing is necessary, and the responder can
2137       return the same TSi and TSr values.
2138
2139    o  If the responder's policy allows it to accept the first selector
2140       of TSi and TSr, then the responder MUST narrow the traffic
2141       selectors to a subset that includes the initiator's first choices.
2142       In this example above, the responder might respond with TSi being
2143       (192.0.1.43 - 192.0.1.43) with all ports and IP protocols.
2144
2145    o  If the responder's policy does not allow it to accept the first
2146       selector of TSi and TSr, the responder narrows to an acceptable
2147       subset of TSi and TSr.
2148
2149    When narrowing is done, there may be several subsets that are
2150    acceptable but their union is not.  In this case, the responder
2151    arbitrarily chooses one of them, and MAY include an
2152    ADDITIONAL_TS_POSSIBLE notification in the response. {{ 3.10.1-16386
2153    }} The ADDITIONAL_TS_POSSIBLE notification asserts that the responder
2154    narrowed the proposed traffic selectors but that other traffic
2155    selectors would also have been acceptable, though only in a separate
2156    SA.  There is no data associated with this Notify type.  This case
2157    will occur only when the initiator and responder are configured
2158    differently from one another.  If the initiator and responder agree
2159    on the granularity of tunnels, the initiator will never request a
2160    tunnel wider than the responder will accept. {{ Demoted the SHOULD }}
2161    Such misconfigurations should be recorded in error logs.
2162
2163    It is possible for the responder's policy to contain multiple smaller
2164    ranges, all encompassed by the initiator's traffic selector, and with
2165    the responder's policy being that each of those ranges should be sent
2166    over a different SA.  Continuing the example above, the responder
2167    might have a policy of being willing to tunnel those addresses to and
2168    from the initiator, but might require that each address pair be on a
2169    separately negotiated Child SA.  If the initiator generated its
2170    request in response to an incoming packet from 192.0.1.43 to
2171    192.0.2.123, there would be no way for the responder to determine
2172    which pair of addresses should be included in this tunnel, and it
2173    would have to make a guess or reject the request with a status of
2174    SINGLE_PAIR_REQUIRED.
2175
2176    {{ 3.10.1-34 }} The SINGLE_PAIR_REQUIRED error indicates that a
2177    CREATE_CHILD_SA request is unacceptable because its sender is only
2178    willing to accept traffic selectors specifying a single pair of
2179    addresses.  The requestor is expected to respond by requesting an SA
2180
2181
2182
2183 Kaufman, et al.            Expires May 3, 2009                 [Page 39]
2184 \f
2185 Internet-Draft                  IKEv2bis                    October 2008
2186
2187
2188    for only the specific traffic it is trying to forward.
2189
2190    {{ Clarif-4.11 }} Few implementations will have policies that require
2191    separate SAs for each address pair.  Because of this, if only some
2192    parts of the TSi and TSr proposed by the initiator are acceptable to
2193    the responder, responders SHOULD narrow the selectors to an
2194    acceptable subset rather than use SINGLE_PAIR_REQUIRED.
2195
2196 2.9.1.  Traffic Selectors Violating Own Policy
2197
2198    {{ Clarif-4.12 }}
2199
2200    When creating a new SA, the initiator needs to avoid proposing
2201    traffic selectors that violate its own policy.  If this rule is not
2202    followed, valid traffic may be dropped.  If you use decorrelated
2203    policies from [IPSECARCH], this kind of policy violations cannot
2204    happen.
2205
2206    This is best illustrated by an example.  Suppose that host A has a
2207    policy whose effect is that traffic to 192.0.1.66 is sent via host B
2208    encrypted using AES, and traffic to all other hosts in 192.0.1.0/24
2209    is also sent via B, but must use 3DES.  Suppose also that host B
2210    accepts any combination of AES and 3DES.
2211
2212    If host A now proposes an SA that uses 3DES, and includes TSr
2213    containing (192.0.1.0-192.0.1.255), this will be accepted by host B.
2214    Now, host B can also use this SA to send traffic from 192.0.1.66, but
2215    those packets will be dropped by A since it requires the use of AES
2216    for those traffic.  Even if host A creates a new SA only for
2217    192.0.1.66 that uses AES, host B may freely continue to use the first
2218    SA for the traffic.  In this situation, when proposing the SA, host A
2219    should have followed its own policy, and included a TSr containing
2220    ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead.
2221
2222    In general, if (1) the initiator makes a proposal "for traffic X
2223    (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator
2224    does not actually accept traffic X' with SA, and (3) the initiator
2225    would be willing to accept traffic X' with some SA' (!=SA), valid
2226    traffic can be unnecessarily dropped since the responder can apply
2227    either SA or SA' to traffic X'.
2228
2229 2.10.  Nonces
2230
2231    The IKE_SA_INIT messages each contain a nonce.  These nonces are used
2232    as inputs to cryptographic functions.  The CREATE_CHILD_SA request
2233    and the CREATE_CHILD_SA response also contain nonces.  These nonces
2234    are used to add freshness to the key derivation technique used to
2235    obtain keys for Child SA, and to ensure creation of strong pseudo-
2236
2237
2238
2239 Kaufman, et al.            Expires May 3, 2009                 [Page 40]
2240 \f
2241 Internet-Draft                  IKEv2bis                    October 2008
2242
2243
2244    random bits from the Diffie-Hellman key.  Nonces used in IKEv2 MUST
2245    be randomly chosen, MUST be at least 128 bits in size, and MUST be at
2246    least half the key size of the negotiated prf. ("prf" refers to
2247    "pseudo-random function", one of the cryptographic algorithms
2248    negotiated in the IKE exchange.) {{ Clarif-7.4 }} However, the
2249    initiator chooses the nonce before the outcome of the negotiation is
2250    known.  Because of that, the nonce has to be long enough for all the
2251    PRFs being proposed.  If the same random number source is used for
2252    both keys and nonces, care must be taken to ensure that the latter
2253    use does not compromise the former.
2254
2255 2.11.  Address and Port Agility
2256
2257    IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and
2258    AH associations for the same IP addresses it runs over.  The IP
2259    addresses and ports in the outer header are, however, not themselves
2260    cryptographically protected, and IKE is designed to work even through
2261    Network Address Translation (NAT) boxes.  An implementation MUST
2262    accept incoming requests even if the source port is not 500 or 4500,
2263    and MUST respond to the address and port from which the request was
2264    received.  It MUST specify the address and port at which the request
2265    was received as the source address and port in the response.  IKE
2266    functions identically over IPv4 or IPv6.
2267
2268 2.12.  Reuse of Diffie-Hellman Exponentials
2269
2270    IKE generates keying material using an ephemeral Diffie-Hellman
2271    exchange in order to gain the property of "perfect forward secrecy".
2272    This means that once a connection is closed and its corresponding
2273    keys are forgotten, even someone who has recorded all of the data
2274    from the connection and gets access to all of the long-term keys of
2275    the two endpoints cannot reconstruct the keys used to protect the
2276    conversation without doing a brute force search of the session key
2277    space.
2278
2279    Achieving perfect forward secrecy requires that when a connection is
2280    closed, each endpoint MUST forget not only the keys used by the
2281    connection but also any information that could be used to recompute
2282    those keys.
2283
2284    Since the computing of Diffie-Hellman exponentials is computationally
2285    expensive, an endpoint may find it advantageous to reuse those
2286    exponentials for multiple connection setups.  There are several
2287    reasonable strategies for doing this.  An endpoint could choose a new
2288    exponential only periodically though this could result in less-than-
2289    perfect forward secrecy if some connection lasts for less than the
2290    lifetime of the exponential.  Or it could keep track of which
2291    exponential was used for each connection and delete the information
2292
2293
2294
2295 Kaufman, et al.            Expires May 3, 2009                 [Page 41]
2296 \f
2297 Internet-Draft                  IKEv2bis                    October 2008
2298
2299
2300    associated with the exponential only when some corresponding
2301    connection was closed.  This would allow the exponential to be reused
2302    without losing perfect forward secrecy at the cost of maintaining
2303    more state.
2304
2305    Decisions as to whether and when to reuse Diffie-Hellman exponentials
2306    is a private decision in the sense that it will not affect
2307    interoperability.  An implementation that reuses exponentials MAY
2308    choose to remember the exponential used by the other endpoint on past
2309    exchanges and if one is reused to avoid the second half of the
2310    calculation.
2311
2312 2.13.  Generating Keying Material
2313
2314    In the context of the IKE SA, four cryptographic algorithms are
2315    negotiated: an encryption algorithm, an integrity protection
2316    algorithm, a Diffie-Hellman group, and a pseudo-random function
2317    (prf).  The pseudo-random function is used for the construction of
2318    keying material for all of the cryptographic algorithms used in both
2319    the IKE SA and the Child SAs.
2320
2321    We assume that each encryption algorithm and integrity protection
2322    algorithm uses a fixed-size key and that any randomly chosen value of
2323    that fixed size can serve as an appropriate key.  For algorithms that
2324    accept a variable length key, a fixed key size MUST be specified as
2325    part of the cryptographic transform negotiated (see Section 3.3.5 for
2326    the defintion of the Key Length transform attribute).  For algorithms
2327    for which not all values are valid keys (such as DES or 3DES with key
2328    parity), the algorithm by which keys are derived from arbitrary
2329    values MUST be specified by the cryptographic transform.  For
2330    integrity protection functions based on Hashed Message Authentication
2331    Code (HMAC), the fixed key size is the size of the output of the
2332    underlying hash function.
2333
2334    It is assumed that pseudo-random functions (PRFs) accept keys of any
2335    length, but have a preferred key size.  The preferred key size is
2336    used as the length of SK_d, SK_pi, and SK_pr (see Section 2.14).  For
2337    PRFs based on the HMAC construction, the preferred key size is equal
2338    to the length of the output of the underlying hash function.  Other
2339    types of PRFs MUST specify their preferred key size.
2340
2341    Keying material will always be derived as the output of the
2342    negotiated prf algorithm.  Since the amount of keying material needed
2343    may be greater than the size of the output of the prf algorithm, we
2344    will use the prf iteratively.  We will use the terminology prf+ to
2345    describe the function that outputs a pseudo-random stream based on
2346    the inputs to a prf as follows: (where | indicates concatenation)
2347
2348
2349
2350
2351 Kaufman, et al.            Expires May 3, 2009                 [Page 42]
2352 \f
2353 Internet-Draft                  IKEv2bis                    October 2008
2354
2355
2356    prf+ (K,S) = T1 | T2 | T3 | T4 | ...
2357
2358    where:
2359    T1 = prf (K, S | 0x01)
2360    T2 = prf (K, T1 | S | 0x02)
2361    T3 = prf (K, T2 | S | 0x03)
2362    T4 = prf (K, T3 | S | 0x04)
2363
2364    continuing as needed to compute all required keys.  The keys are
2365    taken from the output string without regard to boundaries (e.g., if
2366    the required keys are a 256-bit Advanced Encryption Standard (AES)
2367    key and a 160-bit HMAC key, and the prf function generates 160 bits,
2368    the AES key will come from T1 and the beginning of T2, while the HMAC
2369    key will come from the rest of T2 and the beginning of T3).
2370
2371    The constant concatenated to the end of each string feeding the prf
2372    is a single octet. prf+ in this document is not defined beyond 255
2373    times the size of the prf output.
2374
2375 2.14.  Generating Keying Material for the IKE SA
2376
2377    The shared keys are computed as follows.  A quantity called SKEYSEED
2378    is calculated from the nonces exchanged during the IKE_SA_INIT
2379    exchange and the Diffie-Hellman shared secret established during that
2380    exchange.  SKEYSEED is used to calculate seven other secrets: SK_d
2381    used for deriving new keys for the Child SAs established with this
2382    IKE SA; SK_ai and SK_ar used as a key to the integrity protection
2383    algorithm for authenticating the component messages of subsequent
2384    exchanges; SK_ei and SK_er used for encrypting (and of course
2385    decrypting) all subsequent exchanges; and SK_pi and SK_pr, which are
2386    used when generating an AUTH payload.  The lengths of SK_d, SK_pi,
2387    and SK_pr are the preferred key length of the agreed-to PRF.
2388
2389    SKEYSEED and its derivatives are computed as follows:
2390
2391    SKEYSEED = prf(Ni | Nr, g^ir)
2392
2393    {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr }
2394                    = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr )
2395
2396    (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, SK_er,
2397    SK_pi, and SK_pr are taken in order from the generated bits of the
2398    prf+). g^ir is the shared secret from the ephemeral Diffie-Hellman
2399    exchange. g^ir is represented as a string of octets in big endian
2400    order padded with zeros if necessary to make it the length of the
2401    modulus.  Ni and Nr are the nonces, stripped of any headers.  For
2402    historical backwards-compatibility reasons, there are two PRFs that
2403    are treated specially in this calculation.  If the negotiated PRF is
2404
2405
2406
2407 Kaufman, et al.            Expires May 3, 2009                 [Page 43]
2408 \f
2409 Internet-Draft                  IKEv2bis                    October 2008
2410
2411
2412    AES-XCBC-PRF-128 [RFC4434] or AES-CMAC-PRF-128 [RFC4615], only the
2413    first 64 bits of Ni and the first 64 bits of Nr are used in the
2414    calculation.
2415
2416    The two directions of traffic flow use different keys.  The keys used
2417    to protect messages from the original initiator are SK_ai and SK_ei.
2418    The keys used to protect messages in the other direction are SK_ar
2419    and SK_er.
2420
2421 2.15.  Authentication of the IKE SA
2422
2423    When not using extensible authentication (see Section 2.16), the
2424    peers are authenticated by having each sign (or MAC using a shared
2425    secret as the key) a block of data.  For the responder, the octets to
2426    be signed start with the first octet of the first SPI in the header
2427    of the second message (IKE_SA_INIT response) and end with the last
2428    octet of the last payload in the second message.  Appended to this
2429    (for purposes of computing the signature) are the initiator's nonce
2430    Ni (just the value, not the payload containing it), and the value
2431    prf(SK_pr,IDr') where IDr' is the responder's ID payload excluding
2432    the fixed header.  Note that neither the nonce Ni nor the value
2433    prf(SK_pr,IDr') are transmitted.  Similarly, the initiator signs the
2434    first message (IKE_SA_INIT request), starting with the first octet of
2435    the first SPI in the header and ending with the last octet of the
2436    last payload.  Appended to this (for purposes of computing the
2437    signature) are the responder's nonce Nr, and the value
2438    prf(SK_pi,IDi').  In the above calculation, IDi' and IDr' are the
2439    entire ID payloads excluding the fixed header.  It is critical to the
2440    security of the exchange that each side sign the other side's nonce.
2441
2442    {{ Clarif-3.1 }}
2443
2444    The initiator's signed octets can be described as:
2445
2446    InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
2447    GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
2448    RealIKEHDR =  SPIi | SPIr |  . . . | Length
2449    RealMessage1 = RealIKEHDR | RestOfMessage1
2450    NonceRPayload = PayloadHeader | NonceRData
2451    InitiatorIDPayload = PayloadHeader | RestOfIDPayload
2452    RestOfInitIDPayload = IDType | RESERVED | InitIDData
2453    MACedIDForI = prf(SK_pi, RestOfInitIDPayload)
2454
2455    The responder's signed octets can be described as:
2456
2457
2458
2459
2460
2461
2462
2463 Kaufman, et al.            Expires May 3, 2009                 [Page 44]
2464 \f
2465 Internet-Draft                  IKEv2bis                    October 2008
2466
2467
2468    ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
2469    GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
2470    RealIKEHDR =  SPIi | SPIr |  . . . | Length
2471    RealMessage2 = RealIKEHDR | RestOfMessage2
2472    NonceIPayload = PayloadHeader | NonceIData
2473    ResponderIDPayload = PayloadHeader | RestOfIDPayload
2474    RestOfRespIDPayload = IDType | RESERVED | RespIDData
2475    MACedIDForR = prf(SK_pr, RestOfRespIDPayload)
2476
2477    Note that all of the payloads are included under the signature,
2478    including any payload types not defined in this document.  If the
2479    first message of the exchange is sent multiple times (such as with a
2480    responder cookie and/or a different Diffie-Hellman group), it is the
2481    latest version of the message that is signed.
2482
2483    Optionally, messages 3 and 4 MAY include a certificate, or
2484    certificate chain providing evidence that the key used to compute a
2485    digital signature belongs to the name in the ID payload.  The
2486    signature or MAC will be computed using algorithms dictated by the
2487    type of key used by the signer, and specified by the Auth Method
2488    field in the Authentication payload.  There is no requirement that
2489    the initiator and responder sign with the same cryptographic
2490    algorithms.  The choice of cryptographic algorithms depends on the
2491    type of key each has.  In particular, the initiator may be using a
2492    shared key while the responder may have a public signature key and
2493    certificate.  It will commonly be the case (but it is not required)
2494    that if a shared secret is used for authentication that the same key
2495    is used in both directions.
2496
2497    Note that it is a common but typically insecure practice to have a
2498    shared key derived solely from a user-chosen password without
2499    incorporating another source of randomness.  This is typically
2500    insecure because user-chosen passwords are unlikely to have
2501    sufficient unpredictability to resist dictionary attacks and these
2502    attacks are not prevented in this authentication method.
2503    (Applications using password-based authentication for bootstrapping
2504    and IKE SA should use the authentication method in Section 2.16,
2505    which is designed to prevent off-line dictionary attacks.) {{ Demoted
2506    the SHOULD }} The pre-shared key needs to contain as much
2507    unpredictability as the strongest key being negotiated.  In the case
2508    of a pre-shared key, the AUTH value is computed as:
2509
2510    AUTH = prf(prf(Shared Secret,"Key Pad for IKEv2"), <msg octets>)
2511
2512    where the string "Key Pad for IKEv2" is 17 ASCII characters without
2513    null termination.  The shared secret can be variable length.  The pad
2514    string is added so that if the shared secret is derived from a
2515    password, the IKE implementation need not store the password in
2516
2517
2518
2519 Kaufman, et al.            Expires May 3, 2009                 [Page 45]
2520 \f
2521 Internet-Draft                  IKEv2bis                    October 2008
2522
2523
2524    cleartext, but rather can store the value prf(Shared Secret,"Key Pad
2525    for IKEv2"), which could not be used as a password equivalent for
2526    protocols other than IKEv2.  As noted above, deriving the shared
2527    secret from a password is not secure.  This construction is used
2528    because it is anticipated that people will do it anyway.  The
2529    management interface by which the Shared Secret is provided MUST
2530    accept ASCII strings of at least 64 octets and MUST NOT add a null
2531    terminator before using them as shared secrets.  It MUST also accept
2532    a hex encoding of the Shared Secret.  The management interface MAY
2533    accept other encodings if the algorithm for translating the encoding
2534    to a binary string is specified.
2535
2536 2.16.  Extensible Authentication Protocol Methods
2537
2538    In addition to authentication using public key signatures and shared
2539    secrets, IKE supports authentication using methods defined in RFC
2540    3748 [EAP].  Typically, these methods are asymmetric (designed for a
2541    user authenticating to a server), and they may not be mutual.  For
2542    this reason, these protocols are typically used to authenticate the
2543    initiator to the responder and MUST be used in conjunction with a
2544    public key signature based authentication of the responder to the
2545    initiator.  These methods are often associated with mechanisms
2546    referred to as "Legacy Authentication" mechanisms.
2547
2548    While this memo references [EAP] with the intent that new methods can
2549    be added in the future without updating this specification, some
2550    simpler variations are documented here and in Section 3.16.  [EAP]
2551    defines an authentication protocol requiring a variable number of
2552    messages.  Extensible Authentication is implemented in IKE as
2553    additional IKE_AUTH exchanges that MUST be completed in order to
2554    initialize the IKE SA.
2555
2556    An initiator indicates a desire to use extensible authentication by
2557    leaving out the AUTH payload from message 3.  By including an IDi
2558    payload but not an AUTH payload, the initiator has declared an
2559    identity but has not proven it.  If the responder is willing to use
2560    an extensible authentication method, it will place an Extensible
2561    Authentication Protocol (EAP) payload in message 4 and defer sending
2562    SAr2, TSi, and TSr until initiator authentication is complete in a
2563    subsequent IKE_AUTH exchange.  In the case of a minimal extensible
2564    authentication, the initial SA establishment will appear as follows:
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575 Kaufman, et al.            Expires May 3, 2009                 [Page 46]
2576 \f
2577 Internet-Draft                  IKEv2bis                    October 2008
2578
2579
2580    Initiator                         Responder
2581    -------------------------------------------------------------------
2582    HDR, SAi1, KEi, Ni  -->
2583                                 <--  HDR, SAr1, KEr, Nr, [CERTREQ]
2584    HDR, SK {IDi, [CERTREQ,]
2585        [IDr,] SAi2,
2586        TSi, TSr}  -->
2587                                 <--  HDR, SK {IDr, [CERT,] AUTH,
2588                                          EAP }
2589    HDR, SK {EAP}  -->
2590                                 <--  HDR, SK {EAP (success)}
2591    HDR, SK {AUTH}  -->
2592                                 <--  HDR, SK {AUTH, SAr2, TSi, TSr }
2593
2594    {{ Clarif-3.10 }} As described in Section 2.2, when EAP is used, each
2595    pair of IKE SA initial setup messages will have their message numbers
2596    incremented; the first pair of AUTH messages will have an ID of 1,
2597    the second will be 2, and so on.
2598
2599    For EAP methods that create a shared key as a side effect of
2600    authentication, that shared key MUST be used by both the initiator
2601    and responder to generate AUTH payloads in messages 7 and 8 using the
2602    syntax for shared secrets specified in Section 2.15.  The shared key
2603    from EAP is the field from the EAP specification named MSK.  This
2604    shared key generated during an IKE exchange MUST NOT be used for any
2605    other purpose.
2606
2607    EAP methods that do not establish a shared key SHOULD NOT be used, as
2608    they are subject to a number of man-in-the-middle attacks [EAPMITM]
2609    if these EAP methods are used in other protocols that do not use a
2610    server-authenticated tunnel.  Please see the Security Considerations
2611    section for more details.  If EAP methods that do not generate a
2612    shared key are used, the AUTH payloads in messages 7 and 8 MUST be
2613    generated using SK_pi and SK_pr, respectively.
2614
2615    {{ Demoted the SHOULD }} The initiator of an IKE SA using EAP needs
2616    to be capable of extending the initial protocol exchange to at least
2617    ten IKE_AUTH exchanges in the event the responder sends notification
2618    messages and/or retries the authentication prompt.  Once the protocol
2619    exchange defined by the chosen EAP authentication method has
2620    successfully terminated, the responder MUST send an EAP payload
2621    containing the Success message.  Similarly, if the authentication
2622    method has failed, the responder MUST send an EAP payload containing
2623    the Failure message.  The responder MAY at any time terminate the IKE
2624    exchange by sending an EAP payload containing the Failure message.
2625
2626    Following such an extended exchange, the EAP AUTH payloads MUST be
2627    included in the two messages following the one containing the EAP
2628
2629
2630
2631 Kaufman, et al.            Expires May 3, 2009                 [Page 47]
2632 \f
2633 Internet-Draft                  IKEv2bis                    October 2008
2634
2635
2636    Success message.
2637
2638    {{ Clarif-3.5 }} When the initiator authentication uses EAP, it is
2639    possible that the contents of the IDi payload is used only for AAA
2640    routing purposes and selecting which EAP method to use.  This value
2641    may be different from the identity authenticated by the EAP method.
2642    It is important that policy lookups and access control decisions use
2643    the actual authenticated identity.  Often the EAP server is
2644    implemented in a separate AAA server that communicates with the IKEv2
2645    responder.  In this case, the authenticated identity has to be sent
2646    from the AAA server to the IKEv2 responder.
2647
2648 2.17.  Generating Keying Material for Child SAs
2649
2650    A single Child SA is created by the IKE_AUTH exchange, and additional
2651    Child SAs can optionally be created in CREATE_CHILD_SA exchanges.
2652    Keying material for them is generated as follows:
2653
2654    KEYMAT = prf+(SK_d, Ni | Nr)
2655
2656    Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this
2657    request is the first Child SA created or the fresh Ni and Nr from the
2658    CREATE_CHILD_SA exchange if this is a subsequent creation.
2659
2660    For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman
2661    exchange, the keying material is defined as:
2662
2663    KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr )
2664
2665    where g^ir (new) is the shared secret from the ephemeral Diffie-
2666    Hellman exchange of this CREATE_CHILD_SA exchange (represented as an
2667    octet string in big endian order padded with zeros in the high-order
2668    bits if necessary to make it the length of the modulus).
2669
2670    For ESP and AH, a single Child SA negotiation results in two security
2671    associations (one in each direction).  Keying material MUST be taken
2672    from the expanded KEYMAT in the following order:
2673
2674    o  The encryption key (if any) for the SA carrying data from the
2675       initiator to the responder.
2676
2677    o  The authentication key (if any) for the SA carrying data from the
2678       initiator to the responder.
2679
2680    o  The encryption key (if any) for the SA carrying data from the
2681       responder to the initiator.
2682
2683
2684
2685
2686
2687 Kaufman, et al.            Expires May 3, 2009                 [Page 48]
2688 \f
2689 Internet-Draft                  IKEv2bis                    October 2008
2690
2691
2692    o  The authentication key (if any) for the SA carrying data from the
2693       responder to the initiator.
2694
2695    Each cryptographic algorithm takes a fixed number of bits of keying
2696    material specified as part of the algorithm, or negotiated in SA
2697    payloads (see Section 2.13 for description of key lengths, and
2698    Section 3.3.5 for the definition of the Key Length transform
2699    attribute).
2700
2701 2.18.  Rekeying IKE SAs Using a CREATE_CHILD_SA Exchange
2702
2703    The CREATE_CHILD_SA exchange can be used to rekey an existing IKE SA
2704    (see Section 2.8). {{ Clarif-5.3 }} New initiator and responder SPIs
2705    are supplied in the SPI fields in the Proposal structures inside the
2706    Security Association (SA) payloads (not the SPI fields in the IKE
2707    header).  The TS payloads are omitted when rekeying an IKE SA.
2708    SKEYSEED for the new IKE SA is computed using SK_d from the existing
2709    IKE SA as follows:
2710
2711    SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)
2712
2713    where g^ir (new) is the shared secret from the ephemeral Diffie-
2714    Hellman exchange of this CREATE_CHILD_SA exchange (represented as an
2715    octet string in big endian order padded with zeros if necessary to
2716    make it the length of the modulus) and Ni and Nr are the two nonces
2717    stripped of any headers.
2718
2719    {{ Clarif-5.5 }} The old and new IKE SA may have selected a different
2720    PRF.  Because the rekeying exchange belongs to the old IKE SA, it is
2721    the old IKE SA's PRF that is used.
2722
2723    {{ Clarif-5.12}} The main rekeying the IKE SA is to ensure that the
2724    compromise of old keying material does not provide information about
2725    the current keys, or vice versa.  Therefore, implementations SHOULD
2726    perform a new Diffie-Hellman exchange when rekeying the IKE SA.  In
2727    other words, an initiator SHOULD NOT propose the value "NONE" for the
2728    D-H transform, and a responder SHOULD NOT accept such a proposal.
2729    This means that a succesful exchange rekeying the IKE SA always
2730    includes the KEi/KEr payloads.
2731
2732    The new IKE SA MUST reset its message counters to 0.
2733
2734    SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as
2735    specified in Section 2.14.
2736
2737
2738
2739
2740
2741
2742
2743 Kaufman, et al.            Expires May 3, 2009                 [Page 49]
2744 \f
2745 Internet-Draft                  IKEv2bis                    October 2008
2746
2747
2748 2.19.  Requesting an Internal Address on a Remote Network
2749
2750    Most commonly occurring in the endpoint-to-security-gateway scenario,
2751    an endpoint may need an IP address in the network protected by the
2752    security gateway and may need to have that address dynamically
2753    assigned.  A request for such a temporary address can be included in
2754    any request to create a Child SA (including the implicit request in
2755    message 3) by including a CP payload.
2756
2757    This function provides address allocation to an IPsec Remote Access
2758    Client (IRAC) trying to tunnel into a network protected by an IPsec
2759    Remote Access Server (IRAS).  Since the IKE_AUTH exchange creates an
2760    IKE SA and a Child SA, the IRAC MUST request the IRAS-controlled
2761    address (and optionally other information concerning the protected
2762    network) in the IKE_AUTH exchange.  The IRAS may procure an address
2763    for the IRAC from any number of sources such as a DHCP/BOOTP server
2764    or its own address pool.
2765
2766    Initiator                         Responder
2767    -------------------------------------------------------------------
2768     HDR, SK {IDi, [CERT,]
2769        [CERTREQ,] [IDr,] AUTH,
2770        CP(CFG_REQUEST), SAi2,
2771        TSi, TSr}  -->
2772                                 <--  HDR, SK {IDr, [CERT,] AUTH,
2773                                          CP(CFG_REPLY), SAr2,
2774                                          TSi, TSr}
2775
2776    In all cases, the CP payload MUST be inserted before the SA payload.
2777    In variations of the protocol where there are multiple IKE_AUTH
2778    exchanges, the CP payloads MUST be inserted in the messages
2779    containing the SA payloads.
2780
2781    CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute
2782    (either IPv4 or IPv6) but MAY contain any number of additional
2783    attributes the initiator wants returned in the response.
2784
2785    For example, message from initiator to responder:
2786
2787    CP(CFG_REQUEST)=
2788      INTERNAL_ADDRESS()
2789    TSi = (0, 0-65535,0.0.0.0-255.255.255.255)
2790    TSr = (0, 0-65535,0.0.0.0-255.255.255.255)
2791
2792    NOTE: Traffic Selectors contain (protocol, port range, address
2793    range).
2794
2795    Message from responder to initiator:
2796
2797
2798
2799 Kaufman, et al.            Expires May 3, 2009                 [Page 50]
2800 \f
2801 Internet-Draft                  IKEv2bis                    October 2008
2802
2803
2804    CP(CFG_REPLY)=
2805      INTERNAL_ADDRESS(192.0.2.202)
2806      INTERNAL_NETMASK(255.255.255.0)
2807      INTERNAL_SUBNET(192.0.2.0/255.255.255.0)
2808    TSi = (0, 0-65535,192.0.2.202-192.0.2.202)
2809    TSr = (0, 0-65535,192.0.2.0-192.0.2.255)
2810
2811    All returned values will be implementation dependent.  As can be seen
2812    in the above example, the IRAS MAY also send other attributes that
2813    were not included in CP(CFG_REQUEST) and MAY ignore the non-
2814    mandatory attributes that it does not support.
2815
2816    {{ 3.10.1-37 }} The FAILED_CP_REQUIRED notification is sent by
2817    responder in the case where CP(CFG_REQUEST) was expected but not
2818    received, and so is a conflict with locally configured policy.  There
2819    is no associated data.
2820
2821    The responder MUST NOT send a CFG_REPLY without having first received
2822    a CP(CFG_REQUEST) from the initiator, because we do not want the IRAS
2823    to perform an unnecessary configuration lookup if the IRAC cannot
2824    process the REPLY.  In the case where the IRAS's configuration
2825    requires that CP be used for a given identity IDi, but IRAC has
2826    failed to send a CP(CFG_REQUEST), IRAS MUST fail the request, and
2827    terminate the IKE exchange with a FAILED_CP_REQUIRED error.  The
2828    FAILED_CP_REQUIRED is not fatal to the IKE SA; it simply causes the
2829    Child SA creation fail.  The initiator can fix this by later starting
2830    a new configuration payload request.
2831
2832 2.19.1.  Configuration Payloads
2833
2834    Editor's note: some of this sub-section is redundant and will go away
2835    in the next version of the document.
2836
2837    In support of the scenario described in Section 1.1.3, an initiator
2838    may request that the responder assign an IP address and tell the
2839    initiator what it is. {{ Clarif-6.1 }} That request is done using
2840    configuration payloads, not traffic selectors.  An address in a TSi
2841    payload in a response does not mean that the responder has assigned
2842    that address to the initiator: it only means that if packets matching
2843    these traffic selectors are sent by the initiator, IPsec processing
2844    can be performed as agreed for this SA.
2845
2846    Configuration payloads are of type CFG_REQUEST/CFG_REPLY or CFG_SET/
2847    CFG_ACK (see CFG Type in the payload description below).  CFG_REQUEST
2848    and CFG_SET payloads may optionally be added to any IKE request.  The
2849    IKE response MUST include either a corresponding CFG_REPLY or CFG_ACK
2850    or a Notify payload with an error type indicating why the request
2851    could not be honored.  An exception is that a minimal implementation
2852
2853
2854
2855 Kaufman, et al.            Expires May 3, 2009                 [Page 51]
2856 \f
2857 Internet-Draft                  IKEv2bis                    October 2008
2858
2859
2860    MAY ignore all CFG_REQUEST and CFG_SET payloads, so a response
2861    message without a corresponding CFG_REPLY or CFG_ACK MUST be accepted
2862    as an indication that the request was not supported.
2863
2864    "CFG_REQUEST/CFG_REPLY" allows an IKE endpoint to request information
2865    from its peer.  If an attribute in the CFG_REQUEST Configuration
2866    Payload is not zero-length, it is taken as a suggestion for that
2867    attribute.  The CFG_REPLY Configuration Payload MAY return that
2868    value, or a new one.  It MAY also add new attributes and not include
2869    some requested ones.  Requestors MUST ignore returned attributes that
2870    they do not recognize.
2871
2872    Some attributes MAY be multi-valued, in which case multiple attribute
2873    values of the same type are sent and/or returned.  Generally, all
2874    values of an attribute are returned when the attribute is requested.
2875    For some attributes (in this version of the specification only
2876    internal addresses), multiple requests indicates a request that
2877    multiple values be assigned.  For these attributes, the number of
2878    values returned SHOULD NOT exceed the number requested.
2879
2880    If the data type requested in a CFG_REQUEST is not recognized or not
2881    supported, the responder MUST NOT return an error type but rather
2882    MUST either send a CFG_REPLY that MAY be empty or a reply not
2883    containing a CFG_REPLY payload at all.  Error returns are reserved
2884    for cases where the request is recognized but cannot be performed as
2885    requested or the request is badly formatted.
2886
2887    "CFG_SET/CFG_ACK" allows an IKE endpoint to push configuration data
2888    to its peer.  In this case, the CFG_SET Configuration Payload
2889    contains attributes the initiator wants its peer to alter.  The
2890    responder MUST return a Configuration Payload if it accepted any of
2891    the configuration data and it MUST contain the attributes that the
2892    responder accepted with zero-length data.  Those attributes that it
2893    did not accept MUST NOT be in the CFG_ACK Configuration Payload.  If
2894    no attributes were accepted, the responder MUST return either an
2895    empty CFG_ACK payload or a response message without a CFG_ACK
2896    payload.  There are currently no defined uses for the CFG_SET/CFG_ACK
2897    exchange, though they may be used in connection with extensions based
2898    on Vendor IDs.  An minimal implementation of this specification MAY
2899    ignore CFG_SET payloads.
2900
2901    {{ Demoted the SHOULD }} Extensions via the CP payload should not be
2902    used for general purpose management.  Its main intent is to provide a
2903    bootstrap mechanism to exchange information within IPsec from IRAS to
2904    IRAC.  While it MAY be useful to use such a method to exchange
2905    information between some Security Gateways (SGW) or small networks,
2906    existing management protocols such as DHCP [DHCP], RADIUS [RADIUS],
2907    SNMP, or LDAP [LDAP] should be preferred for enterprise management as
2908
2909
2910
2911 Kaufman, et al.            Expires May 3, 2009                 [Page 52]
2912 \f
2913 Internet-Draft                  IKEv2bis                    October 2008
2914
2915
2916    well as subsequent information exchanges.
2917
2918 2.20.  Requesting the Peer's Version
2919
2920    An IKE peer wishing to inquire about the other peer's IKE software
2921    version information MAY use the method below.  This is an example of
2922    a configuration request within an INFORMATIONAL exchange, after the
2923    IKE SA and first Child SA have been created.
2924
2925    An IKE implementation MAY decline to give out version information
2926    prior to authentication or even after authentication to prevent
2927    trolling in case some implementation is known to have some security
2928    weakness.  In that case, it MUST either return an empty string or no
2929    CP payload if CP is not supported.
2930
2931    Initiator                         Responder
2932    -------------------------------------------------------------------
2933    HDR, SK{CP(CFG_REQUEST)}  -->
2934                                 <--  HDR, SK{CP(CFG_REPLY)}
2935
2936    CP(CFG_REQUEST)=
2937      APPLICATION_VERSION("")
2938
2939    CP(CFG_REPLY) APPLICATION_VERSION("foobar v1.3beta, (c) Foo Bar
2940      Inc.")
2941
2942 2.21.  Error Handling
2943
2944    There are many kinds of errors that can occur during IKE processing.
2945    If a request is received that is badly formatted or unacceptable for
2946    reasons of policy (e.g., no matching cryptographic algorithms), the
2947    response MUST contain a Notify payload indicating the error.  If an
2948    error occurs outside the context of an IKE request (e.g., the node is
2949    getting ESP messages on a nonexistent SPI), the node SHOULD initiate
2950    an INFORMATIONAL exchange with a Notify payload describing the
2951    problem.
2952
2953    Errors that occur before a cryptographically protected IKE SA is
2954    established must be handled very carefully.  There is a trade-off
2955    between wanting to be helpful in diagnosing a problem and responding
2956    to it and wanting to avoid being a dupe in a denial of service attack
2957    based on forged messages.
2958
2959    If a node receives a message on UDP port 500 or 4500 outside the
2960    context of an IKE SA known to it (and not a request to start one), it
2961    may be the result of a recent crash of the node.  If the message is
2962    marked as a response, the node MAY audit the suspicious event but
2963    MUST NOT respond.  If the message is marked as a request, the node
2964
2965
2966
2967 Kaufman, et al.            Expires May 3, 2009                 [Page 53]
2968 \f
2969 Internet-Draft                  IKEv2bis                    October 2008
2970
2971
2972    MAY audit the suspicious event and MAY send a response.  If a
2973    response is sent, the response MUST be sent to the IP address and
2974    port from whence it came with the same IKE SPIs and the Message ID
2975    copied.  The response MUST NOT be cryptographically protected and
2976    MUST contain a Notify payload indicating INVALID_IKE_SPI. {{ 3.10.1-4
2977    }} The INVALID_IKE_SPI notification indicates an IKE message was
2978    received with an unrecognized destination SPI; this usually indicates
2979    that the recipient has rebooted and forgotten the existence of an IKE
2980    SA.
2981
2982    A node receiving such an unprotected Notify payload MUST NOT respond
2983    and MUST NOT change the state of any existing SAs.  The message might
2984    be a forgery or might be a response the genuine correspondent was
2985    tricked into sending. {{ Demoted two SHOULDs }} A node should treat
2986    such a message (and also a network message like ICMP destination
2987    unreachable) as a hint that there might be problems with SAs to that
2988    IP address and should initiate a liveness test for any such IKE SA.
2989    An implementation SHOULD limit the frequency of such tests to avoid
2990    being tricked into participating in a denial of service attack.
2991
2992    A node receiving a suspicious message from an IP address with which
2993    it has an IKE SA MAY send an IKE Notify payload in an IKE
2994    INFORMATIONAL exchange over that SA. {{ Demoted the SHOULD }} The
2995    recipient MUST NOT change the state of any SAs as a result, but may
2996    wish to audit the event to aid in diagnosing malfunctions.  A node
2997    MUST limit the rate at which it will send messages in response to
2998    unprotected messages.
2999
3000 2.22.  IPComp
3001
3002    Use of IP compression [IP-COMP] can be negotiated as part of the
3003    setup of a Child SA.  While IP compression involves an extra header
3004    in each packet and a compression parameter index (CPI), the virtual
3005    "compression association" has no life outside the ESP or AH SA that
3006    contains it.  Compression associations disappear when the
3007    corresponding ESP or AH SA goes away.  It is not explicitly mentioned
3008    in any DELETE payload.
3009
3010    Negotiation of IP compression is separate from the negotiation of
3011    cryptographic parameters associated with a Child SA.  A node
3012    requesting a Child SA MAY advertise its support for one or more
3013    compression algorithms through one or more Notify payloads of type
3014    IPCOMP_SUPPORTED.  This notification may be included only in a
3015    message containing an SA payload negotiating a Child SA and indicates
3016    a willingness by its sender to use IPComp on this SA.  The response
3017    MAY indicate acceptance of a single compression algorithm with a
3018    Notify payload of type IPCOMP_SUPPORTED.  These payloads MUST NOT
3019    occur in messages that do not contain SA payloads.
3020
3021
3022
3023 Kaufman, et al.            Expires May 3, 2009                 [Page 54]
3024 \f
3025 Internet-Draft                  IKEv2bis                    October 2008
3026
3027
3028    {{ 3.10.1-16387 }}The data associated with this notification includes
3029    a two-octet IPComp CPI followed by a one-octet transform ID
3030    optionally followed by attributes whose length and format are defined
3031    by that transform ID.  A message proposing an SA may contain multiple
3032    IPCOMP_SUPPORTED notifications to indicate multiple supported
3033    algorithms.  A message accepting an SA may contain at most one.
3034
3035    The transform IDs currently defined are:
3036
3037    Name              Number   Defined In
3038    -------------------------------------
3039    RESERVED          0
3040    IPCOMP_OUI        1
3041    IPCOMP_DEFLATE    2        RFC 2394
3042    IPCOMP_LZS        3        RFC 2395
3043    IPCOMP_LZJH       4        RFC 3051
3044    RESERVED TO IANA  5-240
3045    PRIVATE USE       241-255
3046
3047    Although there has been discussion of allowing multiple compression
3048    algorithms to be accepted and to have different compression
3049    algorithms available for the two directions of a Child SA,
3050    implementations of this specification MUST NOT accept an IPComp
3051    algorithm that was not proposed, MUST NOT accept more than one, and
3052    MUST NOT compress using an algorithm other than one proposed and
3053    accepted in the setup of the Child SA.