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