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