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