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