restructured file layout
[strongswan.git] / doc / standards / draft-hoffman-ikev2-1-00.txt
1
2
3
4 Network Working Group                                         P. Hoffman
5 Internet-Draft                                            VPN Consortium
6 Expires: July 5, 2006                                       January 2006
7
8
9                 Internet Key Exchange Protocol: IKEv2.1
10                       draft-hoffman-ikev2-1-00.txt
11
12 Status of this Memo
13
14    By submitting this Internet-Draft, each author represents that any
15    applicable patent or other IPR claims of which he or she is aware
16    have been or will be disclosed, and any of which he or she becomes
17    aware will be disclosed, in accordance with Section 6 of BCP 79.
18
19    Internet-Drafts are working documents of the Internet Engineering
20    Task Force (IETF), its areas, and its working groups.  Note that
21    other groups may also distribute working documents as Internet-
22    Drafts.
23
24    Internet-Drafts are draft documents valid for a maximum of six months
25    and may be updated, replaced, or obsoleted by other documents at any
26    time.  It is inappropriate to use Internet-Drafts as reference
27    material or to cite them other than as "work in progress."
28
29    The list of current Internet-Drafts can be accessed at
30    http://www.ietf.org/ietf/1id-abstracts.txt.
31
32    The list of Internet-Draft Shadow Directories can be accessed at
33    http://www.ietf.org/shadow.html.
34
35    This Internet-Draft will expire on July 5, 2006.
36
37 Copyright Notice
38
39    Copyright (C) The Internet Society (2006).
40
41 Abstract
42
43    This document describes version 2.1 of the Internet Key Exchange
44    (IKE) protocol.  IKEv2.1 is heavily based on IKEv2 from RFC 4306
45    (edited by Charlie Kaufman), and includes all of the clarifications
46    from the "IKEv2 Clarifications" document (edited by Pasi Eronen and
47    Paul Hoffman).  IKEv2.1 makes additional changes to those two
48    documents in places where IKEv2 was unclear and the clarifications
49    document did not commit to a particular protocol interpretation.
50
51
52
53
54
55 Hoffman                   Expires July 5, 2006                  [Page 1]
56 \f
57 Internet-Draft                    IKEv2                     January 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  .  13
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.  Introduction to IKEv2.1 . . . . . . . . . . . . . . . . .  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 Hoffman                   Expires July 5, 2006                  [Page 2]
112 \f
113 Internet-Draft                    IKEv2                     January 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    6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 107
148    7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . 107
149    8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . 108
150      8.1.  Normative References  . . . . . . . . . . . . . . . . . . 108
151      8.2.  Informative References  . . . . . . . . . . . . . . . . . 109
152    Appendix A.  Summary of changes from IKEv1  . . . . . . . . . . . 112
153    Appendix B.  Diffie-Hellman Groups  . . . . . . . . . . . . . . . 114
154      B.1.  Group 1 - 768 Bit MODP  . . . . . . . . . . . . . . . . . 114
155      B.2.  Group 2 - 1024 Bit MODP . . . . . . . . . . . . . . . . . 114
156    Appendix C.  Exchanges and Payloads . . . . . . . . . . . . . . . 115
157      C.1.  IKE_SA_INIT Exchange  . . . . . . . . . . . . . . . . . . 115
158      C.2.  IKE_AUTH Exchange without EAP . . . . . . . . . . . . . . 116
159      C.3.  IKE_AUTH Exchange with EAP  . . . . . . . . . . . . . . . 117
160      C.4.  CREATE_CHILD_SA Exchange for Creating or Rekeying
161            CHILD_SAs . . . . . . . . . . . . . . . . . . . . . . . . 118
162      C.5.  CREATE_CHILD_SA Exchange for Rekeying the IKE_SA  . . . . 118
163      C.6.  INFORMATIONAL Exchange  . . . . . . . . . . . . . . . . . 118
164
165
166
167 Hoffman                   Expires July 5, 2006                  [Page 3]
168 \f
169 Internet-Draft                    IKEv2                     January 2006
170
171
172    Appendix D.  Changes Between Internet Draft Versions  . . . . . . 118
173      D.1.  Changes from IKEv2 to draft -00 . . . . . . . . . . . . . 118
174    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . 119
175    Intellectual Property and Copyright Statements  . . . . . . . . . 119
176
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 Hoffman                   Expires July 5, 2006                  [Page 4]
224 \f
225 Internet-Draft                    IKEv2                     January 2006
226
227
228 1.  Introduction
229
230    {{ An introduction to IKEv2.1 is given at the end of Section 1.  It
231    is put there (instead of here) to preserve the section numbering of
232    the original IKEv2 document. }}
233
234    IP Security (IPsec) provides confidentiality, data integrity, access
235    control, and data source authentication to IP datagrams.  These
236    services are provided by maintaining shared state between the source
237    and the sink of an IP datagram.  This state defines, among other
238    things, the specific services provided to the datagram, which
239    cryptographic algorithms will be used to provide the services, and
240    the keys used as input to the cryptographic algorithms.
241
242    Establishing this shared state in a manual fashion does not scale
243    well.  Therefore, a protocol to establish this state dynamically is
244    needed.  This memo describes such a protocol -- the Internet Key
245    Exchange (IKE).  This is version 2.1 of IKE.  Version 1 of IKE was
246    defined in RFCs 2407 [DOI], 2408 [ISAKMP], and 2409 [IKEV1].  IKEv2
247    was defined in [IKEV2].  This single document is intended to replace
248    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 and IKEv2.1 rely on some of the
253    processing rules in [IPSECARCH], as described in various sections of
254    this 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 Hoffman                   Expires July 5, 2006                  [Page 5]
280 \f
281 Internet-Draft                    IKEv2                     January 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 Hoffman                   Expires July 5, 2006                  [Page 6]
336 \f
337 Internet-Draft                    IKEv2                     January 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 Hoffman                   Expires July 5, 2006                  [Page 7]
392 \f
393 Internet-Draft                    IKEv2                     January 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 Hoffman                   Expires July 5, 2006                  [Page 8]
448 \f
449 Internet-Draft                    IKEv2                     January 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 Hoffman                   Expires July 5, 2006                  [Page 9]
504 \f
505 Internet-Draft                    IKEv2                     January 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 Hoffman                   Expires July 5, 2006                 [Page 10]
560 \f
561 Internet-Draft                    IKEv2                     January 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 Hoffman                   Expires July 5, 2006                 [Page 11]
616 \f
617 Internet-Draft                    IKEv2                     January 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 other value
627    than NONE.  Implementations MUST leave the transform out entirely in
628    this case.
629
630 1.3.  The CREATE_CHILD_SA Exchange
631
632    {{ This is a heavy rewrite of most of this section.  The major
633    organization changes are described in Clarif-4.1 and Clarif-5.1. }}
634
635    The CREATE_CHILD_SA exchange is used to create new CHILD_SAs and to
636    rekey both IKE_SAs and CHILD_SAs.  This exchange consists of a single
637    request/response pair, and some of its function was referred to as a
638    phase 2 exchange in IKEv1.  It MAY be initiated by either end of the
639    IKE_SA after the initial exchanges are completed.
640
641    All messages following the initial exchange are cryptographically
642    protected using the cryptographic algorithms and keys negotiated in
643    the first two messages of the IKE exchange.  These subsequent
644    messages use the syntax of the Encrypted Payload described in
645    Section 3.14.  All subsequent messages included an Encrypted Payload,
646    even if they are referred to in the text as "empty".  For both
647    messages in the CREATE_CHILD_SA, the message following the header is
648    encrypted and the message including the header is integrity protected
649    using the cryptographic algorithms negotiated for the IKE_SA.
650
651    The CREATE_CHILD_SA is used for rekeying IKE_SAs and CHILD_SAs.  This
652    section describes the first part of rekeying, the creation of new
653    SAs; Section 2.8 covers the mechanics of rekeying, including moving
654    traffic from old to new SAs and the deletion of the old SAs.  The two
655    sections must be read together to understand the entire process of
656    rekeying.
657
658    Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this
659    section the term initiator refers to the endpoint initiating this
660    exchange.  An implementation MAY refuse all CREATE_CHILD_SA requests
661    within an IKE_SA.
662
663    The CREATE_CHILD_SA request MAY optionally contain a KE payload for
664    an additional Diffie-Hellman exchange to enable stronger guarantees
665    of forward secrecy for the CHILD_SA.  The keying material for the
666    CHILD_SA is a function of SK_d established during the establishment
667    of the IKE_SA, the nonces exchanged during the CREATE_CHILD_SA
668
669
670
671 Hoffman                   Expires July 5, 2006                 [Page 12]
672 \f
673 Internet-Draft                    IKEv2                     January 2006
674
675
676    exchange, and the Diffie-Hellman value (if KE payloads are included
677    in the CREATE_CHILD_SA exchange).
678
679    If a CREATE_CHILD_SA exchange includes a KEi payload, at least one of
680    the SA offers MUST include the Diffie-Hellman group of the KEi.  The
681    Diffie-Hellman group of the KEi MUST be an element of the group the
682    initiator expects the responder to accept (additional Diffie-Hellman
683    groups can be proposed).  If the responder rejects the Diffie-Hellman
684    group of the KEi payload, the responder MUST reject the request and
685    indicate its preferred Diffie-Hellman group in the INVALID_KE_PAYLOAD
686    Notification payload.  In the case of such a rejection, the
687    CREATE_CHILD_SA exchange fails, and the initiator will probably retry
688    the exchange with a Diffie-Hellman proposal and KEi in the group that
689    the responder gave in the INVALID_KE_PAYLOAD.
690
691 1.3.1.  Creating New CHILD_SAs with the  CREATE_CHILD_SA Exchange
692
693    A CHILD_SA may be created by sending a CREATE_CHILD_SA request.  The
694    CREATE_CHILD_SA request for creating a new CHILD_SA is:
695
696    Initiator                         Responder
697    -------------------------------------------------------------------
698    HDR, SK {SA, Ni, [KEi],
699               TSi, TSr}  -->
700
701    The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
702    payload, optionally a Diffie-Hellman value in the KEi payload, and
703    the proposed traffic selectors for the proposed CHILD_SA in the TSi
704    and TSr payloads.
705
706    The CREATE_CHILD_SA response for creating a new CHILD_SA is:
707
708                                 <--  HDR, SK {SA, Nr, [KEr],
709                                          TSi, TSr}
710
711    The responder replies (using the same Message ID to respond) with the
712    accepted offer in an SA payload, and a Diffie-Hellman value in the
713    KEr payload if KEi was included in the request and the selected
714    cryptographic suite includes that group.
715
716    The traffic selectors for traffic to be sent on that SA are specified
717    in the TS payloads in the response, which may be a subset of what the
718    initiator of the CHILD_SA proposed.
719
720 1.3.2.  Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange
721
722    The CREATE_CHILD_SA request for rekeying an IKE_SA is:
723
724
725
726
727 Hoffman                   Expires July 5, 2006                 [Page 13]
728 \f
729 Internet-Draft                    IKEv2                     January 2006
730
731
732    Initiator                         Responder
733    -------------------------------------------------------------------
734    HDR, SK {SA, Ni, KEi} -->
735
736    The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
737    payload, and a Diffie-Hellman value in the KEi payload.  New
738    initiator and responder SPIs are supplied in the SPI fields.
739
740    The CREATE_CHILD_SA response for rekeying an IKE_SA is:
741
742                                 <--  HDR, SK {SA, Nr, KEr}
743
744    The responder replies (using the same Message ID to respond) with the
745    accepted offer in an SA payload, and a Diffie-Hellman value in the
746    KEr payload if the selected cryptographic suite includes that group.
747
748    The new IKE_SA has its message counters set to 0, regardless of what
749    they were in the earlier IKE_SA.  The window size starts at 1 for any
750    new IKE_SA.
751
752    KEi and KEr are required for rekeying an IKE_SA.
753
754 1.3.3.  Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange
755
756    The CREATE_CHILD_SA request for rekeying a CHILD_SA is:
757
758    Initiator                         Responder
759    -------------------------------------------------------------------
760    HDR, SK {N, SA, Ni, [KEi],
761        TSi, TSr}   -->
762
763    The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
764    payload, optionally a Diffie-Hellman value in the KEi payload, and
765    the proposed traffic selectors for the proposed CHILD_SA in the TSi
766    and TSr payloads.  When rekeying an existing CHILD_SA, the leading N
767    payload of type REKEY_SA MUST be included and MUST give the SPI (as
768    they would be expected in the headers of inbound packets) of the SAs
769    being rekeyed.
770
771    The CREATE_CHILD_SA response for rekeying a CHILD_SA is:
772
773                                 <--  HDR, SK {SA, Nr, [KEr],
774                                          Si, TSr}
775
776    The responder replies (using the same Message ID to respond) with the
777    accepted offer in an SA payload, and a Diffie-Hellman value in the
778    KEr payload if KEi was included in the request and the selected
779    cryptographic suite includes that group.
780
781
782
783 Hoffman                   Expires July 5, 2006                 [Page 14]
784 \f
785 Internet-Draft                    IKEv2                     January 2006
786
787
788    The traffic selectors for traffic to be sent on that SA are specified
789    in the TS payloads in the response, which may be a subset of what the
790    initiator of the CHILD_SA proposed.
791
792 1.4.  The INFORMATIONAL Exchange
793
794    At various points during the operation of an IKE_SA, peers may desire
795    to convey control messages to each other regarding errors or
796    notifications of certain events.  To accomplish this, IKE defines an
797    INFORMATIONAL exchange.  INFORMATIONAL exchanges MUST ONLY occur
798    after the initial exchanges and are cryptographically protected with
799    the negotiated keys.
800
801    Control messages that pertain to an IKE_SA MUST be sent under that
802    IKE_SA.  Control messages that pertain to CHILD_SAs MUST be sent
803    under the protection of the IKE_SA which generated them (or its
804    successor if the IKE_SA was replaced for the purpose of rekeying).
805
806    Messages in an INFORMATIONAL exchange contain zero or more
807    Notification, Delete, and Configuration payloads.  The Recipient of
808    an INFORMATIONAL exchange request MUST send some response (else the
809    Sender will assume the message was lost in the network and will
810    retransmit it).  That response MAY be a message with no payloads.
811    The request message in an INFORMATIONAL exchange MAY also contain no
812    payloads.  This is the expected way an endpoint can ask the other
813    endpoint to verify that it is alive.
814
815    {{ Clarif-5.6 }} ESP and AH SAs always exist in pairs, with one SA in
816    each direction.  When an SA is closed, both members of the pair MUST
817    be closed (that is, deleted).  When SAs are nested, as when data (and
818    IP headers if in tunnel mode) are encapsulated first with IPComp,
819    then with ESP, and finally with AH between the same pair of
820    endpoints, all of the SAs MUST be deleted together.  Each endpoint
821    MUST close its incoming SAs and allow the other endpoint to close the
822    other SA in each pair.  To delete an SA, an INFORMATIONAL exchange
823    with one or more delete payloads is sent listing the SPIs (as they
824    would be expected in the headers of inbound packets) of the SAs to be
825    deleted.  The recipient MUST close the designated SAs. {{ Clarif-5.7
826    }} Note that you never send delete payloads for the two sides of an
827    SA in a single message.  If you have many SAs to delete at the same
828    time (such as for nested SAs), you include delete payloads for in
829    inbound half of each SA in your Informational exchange.
830
831    Normally, the reply in the INFORMATIONAL exchange will contain delete
832    payloads for the paired SAs going in the other direction.  There is
833    one exception.  If by chance both ends of a set of SAs independently
834    decide to close them, each may send a delete payload and the two
835    requests may cross in the network.  If a node receives a delete
836
837
838
839 Hoffman                   Expires July 5, 2006                 [Page 15]
840 \f
841 Internet-Draft                    IKEv2                     January 2006
842
843
844    request for SAs for which it has already issued a delete request, it
845    MUST delete the outgoing SAs while processing the request and the
846    incoming SAs while processing the response.  In that case, the
847    responses MUST NOT include delete payloads for the deleted SAs, since
848    that would result in duplicate deletion and could in theory delete
849    the wrong SA.
850
851    {{ Demoted the SHOULD }} Half-closed connections are anomalous and,
852    and a node with auditing capability will probably audit their
853    existence if they persist.  Note that this specification nowhere
854    specifies time periods, so it is up to individual endpoints to decide
855    how long to wait.  A node MAY refuse to accept incoming data on half-
856    closed connections but MUST NOT unilaterally close them and reuse the
857    SPIs.  If connection state becomes sufficiently messed up, a node MAY
858    close the IKE_SA; doing so will implicitly close all SAs negotiated
859    under it.  It can then rebuild the SAs it needs on a clean base under
860    a new IKE_SA. {{ Clarif-5.8 }} The response to a request that deletes
861    the IKE_SA is an empty Informational response.
862
863    The INFORMATIONAL exchange is defined as:
864
865    Initiator                         Responder
866    -------------------------------------------------------------------
867    HDR, SK {[N,] [D,]
868        [CP,] ...}  -->
869                                 <--  HDR, SK {[N,] [D,]
870                                          [CP], ...}
871
872    The processing of an INFORMATIONAL exchange is determined by its
873    component payloads.
874
875 1.5.  Informational Messages outside of an IKE_SA
876
877    If an encrypted IKE packet arrives on port 500 or 4500 with an
878    unrecognized SPI, it could be because the receiving node has recently
879    crashed and lost state or because of some other system malfunction or
880    attack.  If the receiving node has an active IKE_SA to the IP address
881    from whence the packet came, it MAY send a notification of the
882    wayward packet over that IKE_SA in an INFORMATIONAL exchange.  If it
883    does not have such an IKE_SA, it MAY send an Informational message
884    without cryptographic protection to the source IP address.  Such a
885    message is not part of an informational exchange, and the receiving
886    node MUST NOT respond to it.  Doing so could cause a message loop.
887
888    {{ Clarif-7.7 }} There are two cases when such a one-way notification
889    is sent: INVALID_IKE_SPI and INVALID_SPI.  These notifications are
890    sent outside of an IKE_SA.  Note that such notifications are
891    explicitly not Informational exchanges; these are one-way messages
892
893
894
895 Hoffman                   Expires July 5, 2006                 [Page 16]
896 \f
897 Internet-Draft                    IKEv2                     January 2006
898
899
900    that must not be responded to.  In case of INVALID_IKE_SPI, the
901    message sent is a response message, and thus it is sent to the IP
902    address and port from whence it came with the same IKE SPIs and the
903    Message ID copied.  In case of INVALID_SPI, however, there are no IKE
904    SPI values that would be meaningful to the recipient of such a
905    notification.  Using zero values or random values are both
906    acceptable.
907
908 1.6.  Requirements Terminology
909
910    Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
911    "MAY" that appear in this document are to be interpreted as described
912    in [MUSTSHOULD].
913
914    The term "Expert Review" is to be interpreted as defined in
915    [IANACONS].
916
917 1.7.  Introduction to IKEv2.1
918
919    IKEv2.1 is very similar to IKEv2.  Most of the differences between
920    this document at [IKEV2] are clarifications, mostly based on
921    [Clarif].  The changes listed in that document were discussed in the
922    IPsec Working Group and, after the Working Group was disbanded, on
923    the IPsec mailing list.  That document contains detailed explanations
924    of areas that were unclear in IKEv2, and is thus useful to
925    implementers of IKEv2 and IKEv2.1.
926
927    In the body of this document, notes that are enclosed in double curly
928    braces {{ such as this }} point out changes from IKEv2.  Changes that
929    come from [Clarif] are marked with the section from that document,
930    such as "{{ Clarif-2.10 }}".
931
932    This document also make the figures and references a bit more regular
933    than in IKEv2.
934
935    IKEv2 developers have noted that the SHOULD-level requirements are
936    often unclear in that they don't say when it is OK to not obey the
937    requirements.  They also have noted that there are MUST-level
938    requirements that are not related to interoperability.  This document
939    has more explanation of some of these SHOULD-level requirements, and
940    some SHOULD-level and MUST-level requirements have been changed to
941    better match the definitions in [MUSTSHOULD].  All non-capitalized
942    uses of the words SHOULD and MUST now mean their normal English
943    sense, not the interoperability sense of [MUSTSHOULD].
944
945    IKEv2 (and IKEv1) developers have noted that there is a great deal of
946    material in the tables of codes in Section 3.10.  This leads to
947    implementers not having all the needed information in the main body
948
949
950
951 Hoffman                   Expires July 5, 2006                 [Page 17]
952 \f
953 Internet-Draft                    IKEv2                     January 2006
954
955
956    of the docment.  A later version of this document may move much of
957    the material from those tables into the associated parts of the main
958    body of the document.
959
960    A later version of this document will probably have all the {{ }}
961    comments removed from the body of the document and instead appear in
962    an appendix.
963
964
965 2.  IKE Protocol Details and Variations
966
967    IKE normally listens and sends on UDP port 500, though IKE messages
968    may also be received on UDP port 4500 with a slightly different
969    format (see Section 2.23).  Since UDP is a datagram (unreliable)
970    protocol, IKE includes in its definition recovery from transmission
971    errors, including packet loss, packet replay, and packet forgery.
972    IKE is designed to function so long as (1) at least one of a series
973    of retransmitted packets reaches its destination before timing out;
974    and (2) the channel is not so full of forged and replayed packets so
975    as to exhaust the network or CPU capacities of either endpoint.  Even
976    in the absence of those minimum performance requirements, IKE is
977    designed to fail cleanly (as though the network were broken).
978
979    Although IKEv2 messages are intended to be short, they contain
980    structures with no hard upper bound on size (in particular, X.509
981    certificates), and IKEv2 itself does not have a mechanism for
982    fragmenting large messages.  IP defines a mechanism for fragmentation
983    of oversize UDP messages, but implementations vary in the maximum
984    message size supported.  Furthermore, use of IP fragmentation opens
985    an implementation to denial of service attacks [DOSUDPPROT].
986    Finally, some NAT and/or firewall implementations may block IP
987    fragments.
988
989    All IKEv2 implementations MUST be able to send, receive, and process
990    IKE messages that are up to 1280 bytes long, and they SHOULD be able
991    to send, receive, and process messages that are up to 3000 bytes
992    long. {{ Demoted the SHOULD }} IKEv2 implementations need to be aware
993    of the maximum UDP message size supported and MAY shorten messages by
994    leaving out some certificates or cryptographic suite proposals if
995    that will keep messages below the maximum.  Use of the "Hash and URL"
996    formats rather than including certificates in exchanges where
997    possible can avoid most problems. {{ Demoted the SHOULD }}
998    Implementations and configuration need to keep in mind, however, that
999    if the URL lookups are possible only after the IPsec SA is
1000    established, recursion issues could prevent this technique from
1001    working.
1002
1003
1004
1005
1006
1007 Hoffman                   Expires July 5, 2006                 [Page 18]
1008 \f
1009 Internet-Draft                    IKEv2                     January 2006
1010
1011
1012 2.1.  Use of Retransmission Timers
1013
1014    All messages in IKE exist in pairs: a request and a response.  The
1015    setup of an IKE_SA normally consists of two request/response pairs.
1016    Once the IKE_SA is set up, either end of the security association may
1017    initiate requests at any time, and there can be many requests and
1018    responses "in flight" at any given moment.  But each message is
1019    labeled as either a request or a response, and for each request/
1020    response pair one end of the security association is the initiator
1021    and the other is the responder.
1022
1023    For every pair of IKE messages, the initiator is responsible for
1024    retransmission in the event of a timeout.  The responder MUST never
1025    retransmit a response unless it receives a retransmission of the
1026    request.  In that event, the responder MUST ignore the retransmitted
1027    request except insofar as it triggers a retransmission of the
1028    response.  The initiator MUST remember each request until it receives
1029    the corresponding response.  The responder MUST remember each
1030    response until it receives a request whose sequence number is larger
1031    than the sequence number in the response plus its window size (see
1032    Section 2.3).
1033
1034    IKE is a reliable protocol, in the sense that the initiator MUST
1035    retransmit a request until either it receives a corresponding reply
1036    OR it deems the IKE security association to have failed and it
1037    discards all state associated with the IKE_SA and any CHILD_SAs
1038    negotiated using that IKE_SA.
1039
1040    {{ Clarif-7.5 }} All packets sent on port 4500 MUST begin with the
1041    prefix of four zeros; otherwise, the receiver won't know how to
1042    handle them.
1043
1044 2.2.  Use of Sequence Numbers for Message ID
1045
1046    Every IKE message contains a Message ID as part of its fixed header.
1047    This Message ID is used to match up requests and responses, and to
1048    identify retransmissions of messages.
1049
1050    The Message ID is a 32-bit quantity, which is zero for the first IKE
1051    request in each direction. {{ Clarif-3.11 }} When the IKE_AUTH
1052    exchange does not use EAP, the IKE_SA initial setup messages will
1053    always be numbered 0 and 1.  When EAP is used, each pair of messages
1054    have their message numbers incremented; the first pair of AUTH
1055    messages will have an ID of 1, the second will be 2, and so on.
1056
1057    Each endpoint in the IKE Security Association maintains two "current"
1058    Message IDs: the next one to be used for a request it initiates and
1059    the next one it expects to see in a request from the other end.
1060
1061
1062
1063 Hoffman                   Expires July 5, 2006                 [Page 19]
1064 \f
1065 Internet-Draft                    IKEv2                     January 2006
1066
1067
1068    These counters increment as requests are generated and received.
1069    Responses always contain the same message ID as the corresponding
1070    request.  That means that after the initial exchange, each integer n
1071    may appear as the message ID in four distinct messages: the nth
1072    request from the original IKE initiator, the corresponding response,
1073    the nth request from the original IKE responder, and the
1074    corresponding response.  If the two ends make very different numbers
1075    of requests, the Message IDs in the two directions can be very
1076    different.  There is no ambiguity in the messages, however, because
1077    the (I)nitiator and (R)esponse bits in the message header specify
1078    which of the four messages a particular one is.
1079
1080    {{ Clarif-2.2 }} The Message ID for IKE_SA_INIT messages is always
1081    zero, including for retries of the message due to responses such as
1082    COOKIE and INVALID_KE_PAYLOAD.
1083
1084    Note that Message IDs are cryptographically protected and provide
1085    protection against message replays.  In the unlikely event that
1086    Message IDs grow too large to fit in 32 bits, the IKE_SA MUST be
1087    closed.  Rekeying an IKE_SA resets the sequence numbers.
1088
1089    {{ Clarif-2.3 }} When a responder receives an IKE_SA_INIT request, it
1090    has to determine whether the packet is a retransmission belonging to
1091    an existing "half-open" IKE_SA (in which case the responder
1092    retransmits the same response), or a new request (in which case the
1093    responder creates a new IKE_SA and sends a fresh response).  It is
1094    not sufficient to use the initiator's SPI and/or IP address to
1095    differentiate between the two cases because two different peers
1096    behind a single NAT could choose the same initiator SPI.  Instead, a
1097    robust responder will do the IKE_SA lookup using the whole packet,
1098    its hash, or the Ni payload.
1099
1100 2.3.  Window Size for Overlapping Requests
1101
1102    In order to maximize IKE throughput, an IKE endpoint MAY issue
1103    multiple requests before getting a response to any of them if the
1104    other endpoint has indicated its ability to handle such requests.
1105    For simplicity, an IKE implementation MAY choose to process requests
1106    strictly in order and/or wait for a response to one request before
1107    issuing another.  Certain rules must be followed to ensure
1108    interoperability between implementations using different strategies.
1109
1110    After an IKE_SA is set up, either end can initiate one or more
1111    requests.  These requests may pass one another over the network.  An
1112    IKE endpoint MUST be prepared to accept and process a request while
1113    it has a request outstanding in order to avoid a deadlock in this
1114    situation. {{ Changed the SHOULD to MUST }} An IKE endpoint MUST be
1115    prepared to accept and process multiple requests while it has a
1116
1117
1118
1119 Hoffman                   Expires July 5, 2006                 [Page 20]
1120 \f
1121 Internet-Draft                    IKEv2                     January 2006
1122
1123
1124    request outstanding.
1125
1126    An IKE endpoint MUST wait for a response to each of its messages
1127    before sending a subsequent message unless it has received a
1128    SET_WINDOW_SIZE Notify message from its peer informing it that the
1129    peer is prepared to maintain state for multiple outstanding messages
1130    in order to allow greater throughput.
1131
1132    An IKE endpoint MUST NOT exceed the peer's stated window size for
1133    transmitted IKE requests.  In other words, if the responder stated
1134    its window size is N, then when the initiator needs to make a request
1135    X, it MUST wait until it has received responses to all requests up
1136    through request X-N.  An IKE endpoint MUST keep a copy of (or be able
1137    to regenerate exactly) each request it has sent until it receives the
1138    corresponding response.  An IKE endpoint MUST keep a copy of (or be
1139    able to regenerate exactly) the number of previous responses equal to
1140    its declared window size in case its response was lost and the
1141    initiator requests its retransmission by retransmitting the request.
1142
1143    An IKE endpoint supporting a window size greater than one should be
1144    capable of processing incoming requests out of order to maximize
1145    performance in the event of network failures or packet reordering.
1146
1147    {{ Clarif-7.3 }} The window size is assumed to be a (possibly
1148    configurable) property of a particular implementation, and is not
1149    related to congestion control (unlike the window size in TCP, for
1150    example).  In particular, it is not defined what the responder should
1151    do when it receives a SET_WINDOW_SIZE notification containing a
1152    smaller value than is currently in effect.  Thus, there is currently
1153    no way to reduce the window size of an existing IKE_SA; you can only
1154    increase it.  When rekeying an IKE_SA, the new IKE_SA starts with
1155    window size 1 until it is explicitly increased by sending a new
1156    SET_WINDOW_SIZE notification.
1157
1158 2.4.  State Synchronization and Connection Timeouts
1159
1160    An IKE endpoint is allowed to forget all of its state associated with
1161    an IKE_SA and the collection of corresponding CHILD_SAs at any time.
1162    This is the anticipated behavior in the event of an endpoint crash
1163    and restart.  It is important when an endpoint either fails or
1164    reinitializes its state that the other endpoint detect those
1165    conditions and not continue to waste network bandwidth by sending
1166    packets over discarded SAs and having them fall into a black hole.
1167
1168    Since IKE is designed to operate in spite of Denial of Service (DoS)
1169    attacks from the network, an endpoint MUST NOT conclude that the
1170    other endpoint has failed based on any routing information (e.g.,
1171    ICMP messages) or IKE messages that arrive without cryptographic
1172
1173
1174
1175 Hoffman                   Expires July 5, 2006                 [Page 21]
1176 \f
1177 Internet-Draft                    IKEv2                     January 2006
1178
1179
1180    protection (e.g., Notify messages complaining about unknown SPIs).
1181    An endpoint MUST conclude that the other endpoint has failed only
1182    when repeated attempts to contact it have gone unanswered for a
1183    timeout period or when a cryptographically protected INITIAL_CONTACT
1184    notification is received on a different IKE_SA to the same
1185    authenticated identity. {{ Demoted the SHOULD }} An endpoint should
1186    suspect that the other endpoint has failed based on routing
1187    information and initiate a request to see whether the other endpoint
1188    is alive.  To check whether the other side is alive, IKE specifies an
1189    empty INFORMATIONAL message that (like all IKE requests) requires an
1190    acknowledgement (note that within the context of an IKE_SA, an
1191    "empty" message consists of an IKE header followed by an Encrypted
1192    payload that contains no payloads).  If a cryptographically protected
1193    message has been received from the other side recently, unprotected
1194    notifications MAY be ignored.  Implementations MUST limit the rate at
1195    which they take actions based on unprotected messages.
1196
1197    Numbers of retries and lengths of timeouts are not covered in this
1198    specification because they do not affect interoperability.  It is
1199    suggested that messages be retransmitted at least a dozen times over
1200    a period of at least several minutes before giving up on an SA, but
1201    different environments may require different rules.  To be a good
1202    network citizen, retranmission times MUST increase exponentially to
1203    avoid flooding the network and making an existing congestion
1204    situation worse.  If there has only been outgoing traffic on all of
1205    the SAs associated with an IKE_SA, it is essential to confirm
1206    liveness of the other endpoint to avoid black holes.  If no
1207    cryptographically protected messages have been received on an IKE_SA
1208    or any of its CHILD_SAs recently, the system needs to perform a
1209    liveness check in order to prevent sending messages to a dead peer.
1210    Receipt of a fresh cryptographically protected message on an IKE_SA
1211    or any of its CHILD_SAs ensures liveness of the IKE_SA and all of its
1212    CHILD_SAs.  Note that this places requirements on the failure modes
1213    of an IKE endpoint.  An implementation MUST NOT continue sending on
1214    any SA if some failure prevents it from receiving on all of the
1215    associated SAs.  If CHILD_SAs can fail independently from one another
1216    without the associated IKE_SA being able to send a delete message,
1217    then they MUST be negotiated by separate IKE_SAs.
1218
1219    There is a Denial of Service attack on the initiator of an IKE_SA
1220    that can be avoided if the initiator takes the proper care.  Since
1221    the first two messages of an SA setup are not cryptographically
1222    protected, an attacker could respond to the initiator's message
1223    before the genuine responder and poison the connection setup attempt.
1224    To prevent this, the initiator MAY be willing to accept multiple
1225    responses to its first message, treat each as potentially legitimate,
1226    respond to it, and then discard all the invalid half-open connections
1227    when it receives a valid cryptographically protected response to any
1228
1229
1230
1231 Hoffman                   Expires July 5, 2006                 [Page 22]
1232 \f
1233 Internet-Draft                    IKEv2                     January 2006
1234
1235
1236    one of its requests.  Once a cryptographically valid response is
1237    received, all subsequent responses should be ignored whether or not
1238    they are cryptographically valid.
1239
1240    Note that with these rules, there is no reason to negotiate and agree
1241    upon an SA lifetime.  If IKE presumes the partner is dead, based on
1242    repeated lack of acknowledgement to an IKE message, then the IKE SA
1243    and all CHILD_SAs set up through that IKE_SA are deleted.
1244
1245    An IKE endpoint may at any time delete inactive CHILD_SAs to recover
1246    resources used to hold their state.  If an IKE endpoint chooses to
1247    delete CHILD_SAs, it MUST send Delete payloads to the other end
1248    notifying it of the deletion.  It MAY similarly time out the IKE_SA.
1249    {{ Clarified the SHOULD }} Closing the IKE_SA implicitly closes all
1250    associated CHILD_SAs.  In this case, an IKE endpoint SHOULD send a
1251    Delete payload indicating that it has closed the IKE_SA unless the
1252    other endpoint is no longer responding.
1253
1254 2.5.  Version Numbers and Forward Compatibility
1255
1256    {{ The version number is changed in the following paragraph, and the
1257    discussion of handling of multiple versions is also changed
1258    throughout the section. }}
1259
1260    This document describes version 2.1 of IKE, meaning the major version
1261    number is 2 and the minor version number is 1.  It is likely that
1262    some implementations will want to support version 1.0 and version 2.0
1263    and version 2.1, and in the future, other versions.
1264
1265    The major version number should be incremented only if the packet
1266    formats or required actions have changed so dramatically that an
1267    older version node would not be able to interoperate with a newer
1268    version node if it simply ignored the fields it did not understand
1269    and took the actions specified in the older specification.  The minor
1270    version number indicates new capabilities, and MUST be ignored by a
1271    node with a smaller minor version number, but used for informational
1272    purposes by the node with the larger minor version number.  For
1273    example, it might indicate the ability to process a newly defined
1274    notification message.  The node with the larger minor version number
1275    would simply note that its correspondent would not be able to
1276    understand that message and therefore would not send it.
1277
1278    In the discussion of clarifications to IKEv2, it became clear that
1279    there was a need for additional "MUST" and "SHOULD" requirements.
1280    Some of those changes are reflected in IKEv2.1.  Thus, the node with
1281    the higher version number may also need to note that its
1282    correspondent may not be following the same required actions, which
1283    could affect interoperability.
1284
1285
1286
1287 Hoffman                   Expires July 5, 2006                 [Page 23]
1288 \f
1289 Internet-Draft                    IKEv2                     January 2006
1290
1291
1292    {{ Promoted the SHOULD }} If an endpoint receives a message with a
1293    higher major version number, it MUST drop the message and MUST send
1294    an unauthenticated notification message containing the highest
1295    version number it supports.  If an endpoint supports major version n,
1296    and major version m, it MUST support all versions between n and m.
1297    If it receives a message with a major version that it supports, it
1298    MUST respond with that version number.  In order to prevent two nodes
1299    from being tricked into corresponding with a lower major version
1300    number than the maximum that they both support, IKE has a flag that
1301    indicates that the node is capable of speaking a higher major version
1302    number.
1303
1304    Thus, the major version number in the IKE header indicates the
1305    version number of the message, not the highest version number that
1306    the transmitter supports.  If the initiator is capable of speaking
1307    versions n, n+1, and n+2, and the responder is capable of speaking
1308    versions n and n+1, then they will negotiate speaking n+1, where the
1309    initiator will set the flag indicating its ability to speak a higher
1310    version.  If they mistakenly (perhaps through an active attacker
1311    sending error messages) negotiate to version n, then both will notice
1312    that the other side can support a higher version number, and they
1313    MUST break the connection and reconnect using version n+1.
1314
1315    Note that IKEv1 does not follow these rules, because there is no way
1316    in v1 of noting that you are capable of speaking a higher version
1317    number.  So an active attacker can trick two v2-capable nodes into
1318    speaking v1. {{ Demoted the SHOULD }} When a v2-capable node
1319    negotiates down to v1, it should note that fact in its logs.
1320
1321    Also for forward compatibility, all fields marked RESERVED MUST be
1322    set to zero by an implementation running version 2.0 or later, and
1323    their content MUST be ignored by an implementation running version
1324    2.0 or later ("Be conservative in what you send and liberal in what
1325    you receive").  In this way, future versions of the protocol can use
1326    those fields in a way that is guaranteed to be ignored by
1327    implementations that do not understand them.  Similarly, payload
1328    types that are not defined are reserved for future use;
1329    implementations of a version where they are undefined MUST skip over
1330    those payloads and ignore their contents.
1331
1332    IKEv2 adds a "critical" flag to each payload header for further
1333    flexibility for forward compatibility.  If the critical flag is set
1334    and the payload type is unrecognized, the message MUST be rejected
1335    and the response to the IKE request containing that payload MUST
1336    include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an
1337    unsupported critical payload was included.  If the critical flag is
1338    not set and the payload type is unsupported, that payload MUST be
1339    ignored.
1340
1341
1342
1343 Hoffman                   Expires July 5, 2006                 [Page 24]
1344 \f
1345 Internet-Draft                    IKEv2                     January 2006
1346
1347
1348    {{ Demoted the SHOULD }}Although new payload types may be added in
1349    the future and may appear interleaved with the fields defined in this
1350    specification, implementations MUST send the payloads defined in this
1351    specification in the order shown in the figures in Section 2 and
1352    implementations MAY reject as invalid a message with those payloads
1353    in any other order.
1354
1355 2.6.  Cookies
1356
1357    The term "cookies" originates with Karn and Simpson [PHOTURIS] in
1358    Photuris, an early proposal for key management with IPsec, and it has
1359    persisted.  The Internet Security Association and Key Management
1360    Protocol (ISAKMP) [ISAKMP] fixed message header includes two eight-
1361    octet fields titled "cookies", and that syntax is used by both IKEv1
1362    and IKEv2 though in IKEv2 they are referred to as the IKE SPI and
1363    there is a new separate field in a Notify payload holding the cookie.
1364    The initial two eight-octet fields in the header are used as a
1365    connection identifier at the beginning of IKE packets. {{ Promoted
1366    the SHOULD }} Each endpoint chooses one of the two SPIs and MUST
1367    choose them so as to be unique identifiers of an IKE_SA.  An SPI
1368    value of zero is special and indicates that the remote SPI value is
1369    not yet known by the sender.
1370
1371    Unlike ESP and AH where only the recipient's SPI appears in the
1372    header of a message, in IKE the sender's SPI is also sent in every
1373    message.  Since the SPI chosen by the original initiator of the
1374    IKE_SA is always sent first, an endpoint with multiple IKE_SAs open
1375    that wants to find the appropriate IKE_SA using the SPI it assigned
1376    must look at the I(nitiator) Flag bit in the header to determine
1377    whether it assigned the first or the second eight octets.
1378
1379    In the first message of an initial IKE exchange, the initiator will
1380    not know the responder's SPI value and will therefore set that field
1381    to zero.
1382
1383    An expected attack against IKE is state and CPU exhaustion, where the
1384    target is flooded with session initiation requests from forged IP
1385    addresses.  This attack can be made less effective if an
1386    implementation of a responder uses minimal CPU and commits no state
1387    to an SA until it knows the initiator can receive packets at the
1388    address from which it claims to be sending them.  To accomplish this,
1389    a responder SHOULD -- when it detects a large number of half-open
1390    IKE_SAs -- reject initial IKE messages unless they contain a Notify
1391    payload of type COOKIE. {{ Clarified the SHOULD }} If the responder
1392    wants to set up an SA, it SHOULD instead send an unprotected IKE
1393    message as a response and include COOKIE Notify payload with the
1394    cookie data to be returned.  Initiators who receive such responses
1395    MUST retry the IKE_SA_INIT with a Notify payload of type COOKIE
1396
1397
1398
1399 Hoffman                   Expires July 5, 2006                 [Page 25]
1400 \f
1401 Internet-Draft                    IKEv2                     January 2006
1402
1403
1404    containing the responder supplied cookie data as the first payload
1405    and all other payloads unchanged.  The initial exchange will then be
1406    as follows:
1407
1408    Initiator                         Responder
1409    -------------------------------------------------------------------
1410    HDR(A,0), SAi1, KEi, Ni  -->
1411                                 <--  HDR(A,0), N(COOKIE)
1412    HDR(A,0), N(COOKIE), SAi1,
1413        KEi, Ni  -->
1414                                 <--  HDR(A,B), SAr1, KEr,
1415                                          Nr, [CERTREQ]
1416    HDR(A,B), SK {IDi, [CERT,]
1417        [CERTREQ,] [IDr,] AUTH,
1418        SAi2, TSi, TSr}  -->
1419                                 <--  HDR(A,B), SK {IDr, [CERT,]
1420                                          AUTH, SAr2, TSi, TSr}
1421
1422    The first two messages do not affect any initiator or responder state
1423    except for communicating the cookie.  In particular, the message
1424    sequence numbers in the first four messages will all be zero and the
1425    message sequence numbers in the last two messages will be one.  'A'
1426    is the SPI assigned by the initiator, while 'B' is the SPI assigned
1427    by the responder.
1428
1429    {{ Clarif-2.1 }} Because the responder's SPI identifies security-
1430    related state held by the responder, and in this case no state is
1431    created, the responder sends a zero value for the responder's SPI.
1432
1433    {{ Demoted the SHOULD }} An IKE implementation should implement its
1434    responder cookie generation in such a way as to not require any saved
1435    state to recognize its valid cookie when the second IKE_SA_INIT
1436    message arrives.  The exact algorithms and syntax they use to
1437    generate cookies do not affect interoperability and hence are not
1438    specified here.  The following is an example of how an endpoint could
1439    use cookies to implement limited DOS protection.
1440
1441    A good way to do this is to set the responder cookie to be:
1442
1443    Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)
1444
1445    where <secret> is a randomly generated secret known only to the
1446    responder and periodically changed and | indicates concatenation.
1447    <VersionIDofSecret> should be changed whenever <secret> is
1448    regenerated.  The cookie can be recomputed when the IKE_SA_INIT
1449    arrives the second time and compared to the cookie in the received
1450    message.  If it matches, the responder knows that the cookie was
1451    generated since the last change to <secret> and that IPi must be the
1452
1453
1454
1455 Hoffman                   Expires July 5, 2006                 [Page 26]
1456 \f
1457 Internet-Draft                    IKEv2                     January 2006
1458
1459
1460    same as the source address it saw the first time.  Incorporating SPIi
1461    into the calculation ensures that if multiple IKE_SAs are being set
1462    up in parallel they will all get different cookies (assuming the
1463    initiator chooses unique SPIi's).  Incorporating Ni into the hash
1464    ensures that an attacker who sees only message 2 can't successfully
1465    forge a message 3.
1466
1467    If a new value for <secret> is chosen while there are connections in
1468    the process of being initialized, an IKE_SA_INIT might be returned
1469    with other than the current <VersionIDofSecret>.  The responder in
1470    that case MAY reject the message by sending another response with a
1471    new cookie or it MAY keep the old value of <secret> around for a
1472    short time and accept cookies computed from either one. {{ Demoted
1473    the SHOULD NOT }} The responder should not accept cookies
1474    indefinitely after <secret> is changed, since that would defeat part
1475    of the denial of service protection. {{ Demoted the SHOULD }} The
1476    responder should change the value of <secret> frequently, especially
1477    if under attack.
1478
1479    {{ Clarif-2.1 }} In addition to cookies, there are several cases
1480    where the IKE_SA_INIT exchange does not result in the creation of an
1481    IKE_SA (such as INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN).  In such a
1482    case, sending a zero value for the Responder's SPI is correct.  If
1483    the responder sends a non-zero responder SPI, the initiator should
1484    not reject the response for only that reason.
1485
1486    {{ Clarif-2.5 }} When one party receives an IKE_SA_INIT request
1487    containing a cookie whose contents do not match the value expected,
1488    that party MUST ignore the cookie and process the message as if no
1489    cookie had been included; usually this means sending a response
1490    containing a new cookie.
1491
1492 2.6.1.  Interaction of COOKIE and INVALID_KE_PAYLOAD
1493
1494    {{ This section added by Clarif-2.4 }}
1495
1496    There are two common reasons why the initiator may have to retry the
1497    IKE_SA_INIT exchange: the responder requests a cookie or wants a
1498    different Diffie-Hellman group than was included in the KEi payload.
1499    If the initiator receives a cookie from the responder, the initiator
1500    needs to decide whether or not tp include the cookie in only the next
1501    retry of the IKE_SA_INIT request, or in all subsequent retries as
1502    well.
1503
1504    If the initiator includes the cookie only in the next retry, one
1505    additional roundtrip may be needed in some cases.  An additional
1506    roundtrip is needed also if the initiator includes the cookie in all
1507    retries, but the responder does not support this.  For instance, if
1508
1509
1510
1511 Hoffman                   Expires July 5, 2006                 [Page 27]
1512 \f
1513 Internet-Draft                    IKEv2                     January 2006
1514
1515
1516    the responder includes the SAi1 and KEi payloads in cookie
1517    calculation, it will reject the request by sending a new cookie.
1518
1519    If both peers support including the cookie in all retries, a slightly
1520    shorter exchange can happen.  Implementations MUST support this
1521    shorter exchange, but MUST NOT assume other implementations also
1522    supports this shorter exchange.
1523
1524 2.7.  Cryptographic Algorithm Negotiation
1525
1526    The payload type known as "SA" indicates a proposal for a set of
1527    choices of IPsec protocols (IKE, ESP, and/or AH) for the SA as well
1528    as cryptographic algorithms associated with each protocol.
1529
1530    An SA payload consists of one or more proposals.  Each proposal
1531    includes one or more protocols (usually one).  Each protocol contains
1532    one or more transforms -- each specifying a cryptographic algorithm.
1533    Each transform contains zero or more attributes (attributes are
1534    needed only if the transform identifier does not completely specify
1535    the cryptographic algorithm).
1536
1537    This hierarchical structure was designed to efficiently encode
1538    proposals for cryptographic suites when the number of supported
1539    suites is large because multiple values are acceptable for multiple
1540    transforms.  The responder MUST choose a single suite, which MAY be
1541    any subset of the SA proposal following the rules below:
1542
1543    Each proposal contains one or more protocols.  If a proposal is
1544    accepted, the SA response MUST contain the same protocols in the same
1545    order as the proposal.  The responder MUST accept a single proposal
1546    or reject them all and return an error.  (Example: if a single
1547    proposal contains ESP and AH and that proposal is accepted, both ESP
1548    and AH MUST be accepted.  If ESP and AH are included in separate
1549    proposals, the responder MUST accept only one of them).
1550
1551    Each IPsec protocol proposal contains one or more transforms.  Each
1552    transform contains a transform type.  The accepted cryptographic
1553    suite MUST contain exactly one transform of each type included in the
1554    proposal.  For example: if an ESP proposal includes transforms
1555    ENCR_3DES, ENCR_AES w/keysize 128, ENCR_AES w/keysize 256,
1556    AUTH_HMAC_MD5, and AUTH_HMAC_SHA, the accepted suite MUST contain one
1557    of the ENCR_ transforms and one of the AUTH_ transforms.  Thus, six
1558    combinations are acceptable.
1559
1560    Since the initiator sends its Diffie-Hellman value in the
1561    IKE_SA_INIT, it must guess the Diffie-Hellman group that the
1562    responder will select from its list of supported groups.  If the
1563    initiator guesses wrong, the responder will respond with a Notify
1564
1565
1566
1567 Hoffman                   Expires July 5, 2006                 [Page 28]
1568 \f
1569 Internet-Draft                    IKEv2                     January 2006
1570
1571
1572    payload of type INVALID_KE_PAYLOAD indicating the selected group.  In
1573    this case, the initiator MUST retry the IKE_SA_INIT with the
1574    corrected Diffie-Hellman group.  The initiator MUST again propose its
1575    full set of acceptable cryptographic suites because the rejection
1576    message was unauthenticated and otherwise an active attacker could
1577    trick the endpoints into negotiating a weaker suite than a stronger
1578    one that they both prefer.
1579
1580 2.8.  Rekeying
1581
1582    {{ Demoted the SHOULD }} IKE, ESP, and AH security associations use
1583    secret keys that should be used only for a limited amount of time and
1584    to protect a limited amount of data.  This limits the lifetime of the
1585    entire security association.  When the lifetime of a security
1586    association expires, the security association MUST NOT be used.  If
1587    there is demand, new security associations MAY be established.
1588    Reestablishment of security associations to take the place of ones
1589    that expire is referred to as "rekeying".
1590
1591    To allow for minimal IPsec implementations, the ability to rekey SAs
1592    without restarting the entire IKE_SA is optional.  An implementation
1593    MAY refuse all CREATE_CHILD_SA requests within an IKE_SA.  If an SA
1594    has expired or is about to expire and rekeying attempts using the
1595    mechanisms described here fail, an implementation MUST close the
1596    IKE_SA and any associated CHILD_SAs and then MAY start new ones. {{
1597    Demoted the SHOULD }} Implementations should support in-place
1598    rekeying of SAs, since doing so offers better performance and is
1599    likely to reduce the number of packets lost during the transition.
1600
1601    To rekey a CHILD_SA within an existing IKE_SA, create a new,
1602    equivalent SA (see Section 2.17 below), and when the new one is
1603    established, delete the old one.  To rekey an IKE_SA, establish a new
1604    equivalent IKE_SA (see Section 2.18 below) with the peer to whom the
1605    old IKE_SA is shared using a CREATE_CHILD_SA within the existing
1606    IKE_SA.  An IKE_SA so created inherits all of the original IKE_SA's
1607    CHILD_SAs.  Use the new IKE_SA for all control messages needed to
1608    maintain the CHILD_SAs created by the old IKE_SA, and delete the old
1609    IKE_SA.  The Delete payload to delete itself MUST be the last request
1610    sent over an IKE_SA.
1611
1612    {{ Demoted the SHOULD }} SAs should be rekeyed proactively, i.e., the
1613    new SA should be established before the old one expires and becomes
1614    unusable.  Enough time should elapse between the time the new SA is
1615    established and the old one becomes unusable so that traffic can be
1616    switched over to the new SA.
1617
1618    A difference between IKEv1 and IKEv2 is that in IKEv1 SA lifetimes
1619    were negotiated.  In IKEv2, each end of the SA is responsible for
1620
1621
1622
1623 Hoffman                   Expires July 5, 2006                 [Page 29]
1624 \f
1625 Internet-Draft                    IKEv2                     January 2006
1626
1627
1628    enforcing its own lifetime policy on the SA and rekeying the SA when
1629    necessary.  If the two ends have different lifetime policies, the end
1630    with the shorter lifetime will end up always being the one to request
1631    the rekeying.  If an SA bundle has been inactive for a long time and
1632    if an endpoint would not initiate the SA in the absence of traffic,
1633    the endpoint MAY choose to close the SA instead of rekeying it when
1634    its lifetime expires. {{ Demoted the SHOULD }} It should do so if
1635    there has been no traffic since the last time the SA was rekeyed.
1636
1637    Note that IKEv2 deliberately allows parallel SAs with the same
1638    traffic selectors between common endpoints.  One of the purposes of
1639    this is to support traffic quality of service (QoS) differences among
1640    the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and section 4.1 of
1641    [DIFFTUNNEL]).  Hence unlike IKEv1, the combination of the endpoints
1642    and the traffic selectors may not uniquely identify an SA between
1643    those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on
1644    the basis of duplicate traffic selectors SHOULD NOT be used.
1645
1646    {{ Demoted the SHOULD }} The node that initiated the surviving
1647    rekeyed SA should delete the replaced SA after the new one is
1648    established.
1649
1650    There are timing windows -- particularly in the presence of lost
1651    packets -- where endpoints may not agree on the state of an SA.  The
1652    responder to a CREATE_CHILD_SA MUST be prepared to accept messages on
1653    an SA before sending its response to the creation request, so there
1654    is no ambiguity for the initiator.  The initiator MAY begin sending
1655    on an SA as soon as it processes the response.  The initiator,
1656    however, cannot receive on a newly created SA until it receives and
1657    processes the response to its CREATE_CHILD_SA request.  How, then, is
1658    the responder to know when it is OK to send on the newly created SA?
1659
1660    From a technical correctness and interoperability perspective, the
1661    responder MAY begin sending on an SA as soon as it sends its response
1662    to the CREATE_CHILD_SA request.  In some situations, however, this
1663    could result in packets unnecessarily being dropped, so an
1664    implementation MAY want to defer such sending.
1665
1666    The responder can be assured that the initiator is prepared to
1667    receive messages on an SA if either (1) it has received a
1668    cryptographically valid message on the new SA, or (2) the new SA
1669    rekeys an existing SA and it receives an IKE request to close the
1670    replaced SA. {{ Clarif-5.10 }} When rekeying an SA, the responder
1671    SHOULD continue to send traffic on the old SA until one of those
1672    events occurs.  When establishing a new SA, the responder MAY defer
1673    sending messages on a new SA until either it receives one or a
1674    timeout has occurred. {{ Demoted the SHOULD }} If an initiator
1675    receives a message on an SA for which it has not received a response
1676
1677
1678
1679 Hoffman                   Expires July 5, 2006                 [Page 30]
1680 \f
1681 Internet-Draft                    IKEv2                     January 2006
1682
1683
1684    to its CREATE_CHILD_SA request, it should interpret that as a likely
1685    packet loss and retransmit the CREATE_CHILD_SA request.  An initiator
1686    MAY send a dummy message on a newly created SA if it has no messages
1687    queued in order to assure the responder that the initiator is ready
1688    to receive messages.
1689
1690    {{ Clarif-5.9 }} Throughout this document, "initiator" refers to the
1691    party who initiated the exchange being described, and "original
1692    initiator" refers to the party who initiated the whole IKE_SA.  The
1693    "original initiator" always refers to the party who initiated the
1694    exchange which resulted in the current IKE_SA.  In other words, if
1695    the the "original responder" starts rekeying the IKE_SA, that party
1696    becomes the "original initiator" of the new IKE_SA.
1697
1698 2.8.1.  Simultaneous CHILD_SA rekeying
1699
1700    {{ The first two paragraphs were moved, and the rest was added, based
1701    on Clarif-5.12 }}
1702
1703    If the two ends have the same lifetime policies, it is possible that
1704    both will initiate a rekeying at the same time (which will result in
1705    redundant SAs).  To reduce the probability of this happening, the
1706    timing of rekeying requests SHOULD be jittered (delayed by a random
1707    amount of time after the need for rekeying is noticed).
1708
1709    This form of rekeying may temporarily result in multiple similar SAs
1710    between the same pairs of nodes.  When there are two SAs eligible to
1711    receive packets, a node MUST accept incoming packets through either
1712    SA.  If redundant SAs are created though such a collision, the SA
1713    created with the lowest of the four nonces used in the two exchanges
1714    SHOULD be closed by the endpoint that created it. {{ Clarif-5.11 }}
1715    "Lowest" means an octet-by-octet, lexicographical comparison (instead
1716    of, for instance, comparing the nonces as large integers).  In other
1717    words, start by comparing the first octet; if they're equal, move to
1718    the next octet, and so on.  If you reach the end of one nonce, that
1719    nonce is the lower one.
1720
1721    The following is an explanation on the impact this has on
1722    implementations.  Assume that hosts A and B have an existing IPsec SA
1723    pair with SPIs (SPIa1,SPIb1), and both start rekeying it at the same
1724    time:
1725
1726    Host A                            Host B
1727    -------------------------------------------------------------------
1728    send req1: N(REKEY_SA,SPIa1),
1729        SA(..,SPIa2,..),Ni1,..  -->
1730                                 <--  send req2: N(REKEY_SA,SPIb1),
1731                                          SA(..,SPIb2,..),Ni2
1732
1733
1734
1735 Hoffman                   Expires July 5, 2006                 [Page 31]
1736 \f
1737 Internet-Draft                    IKEv2                     January 2006
1738
1739
1740    recv req2 <--
1741
1742    At this point, A knows there is a simultaneous rekeying going on.
1743    However, it cannot yet know which of the exchanges will have the
1744    lowest nonce, so it will just note the situation and respond as
1745    usual.
1746
1747    send resp2: SA(..,SPIa3,..),
1748         Nr1,..  -->
1749                                 -->  recv req1
1750
1751    Now B also knows that simultaneous rekeying is going on.  It responds
1752    as usual.
1753
1754                                <--  send resp1: SA(..,SPIb3,..),
1755                                         Nr2,..
1756    recv resp1 <--
1757                                -->  recv resp2
1758
1759    At this point, there are three CHILD_SA pairs between A and B (the
1760    old one and two new ones).  A and B can now compare the nonces.
1761    Suppose that the lowest nonce was Nr1 in message resp2; in this case,
1762    B (the sender of req2) deletes the redundant new SA, and A (the node
1763    that initiated the surviving rekeyed SA), deletes the old one.
1764
1765    send req3: D(SPIa1) -->
1766                                 <--  send req4: D(SPIb2)
1767                                 -->  recv req3
1768                                 <--  send resp4: D(SPIb1)
1769    recv req4 <--
1770    send resp4: D(SPIa3) -->
1771
1772    The rekeying is now finished.
1773
1774    However, there is a second possible sequence of events that can
1775    happen if some packets are lost in the network, resulting in
1776    retransmissions.  The rekeying begins as usual, but A's first packet
1777    (req1) is lost.
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791 Hoffman                   Expires July 5, 2006                 [Page 32]
1792 \f
1793 Internet-Draft                    IKEv2                     January 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 these 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 Hoffman                   Expires July 5, 2006                 [Page 33]
1848 \f
1849 Internet-Draft                    IKEv2                     January 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 Hoffman                   Expires July 5, 2006                 [Page 34]
1904 \f
1905 Internet-Draft                    IKEv2                     January 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 Hoffman                   Expires July 5, 2006                 [Page 35]
1960 \f
1961 Internet-Draft                    IKEv2                     January 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 Hoffman                   Expires July 5, 2006                 [Page 36]
2016 \f
2017 Internet-Draft                    IKEv2                     January 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 should not propose traffic
2041    selectors that violate its own policy.  If this rule is not followed,
2042    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 Hoffman                   Expires July 5, 2006                 [Page 37]
2072 \f
2073 Internet-Draft                    IKEv2                     January 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 Hoffman                   Expires July 5, 2006                 [Page 38]
2128 \f
2129 Internet-Draft                    IKEv2                     January 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 Hoffman                   Expires July 5, 2006                 [Page 39]
2184 \f
2185 Internet-Draft                    IKEv2                     January 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 Hoffman                   Expires July 5, 2006                 [Page 40]
2240 \f
2241 Internet-Draft                    IKEv2                     January 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 Hoffman                   Expires July 5, 2006                 [Page 41]
2296 \f
2297 Internet-Draft                    IKEv2                     January 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 Hoffman                   Expires July 5, 2006                 [Page 42]
2352 \f
2353 Internet-Draft                    IKEv2                     January 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.8 }} 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.  For
2387    this reason, these protocols are typically used to authenticate the
2388    initiator to the responder and MUST be used in conjunction with a
2389    public key signature based authentication of the responder to the
2390    initiator.  These methods are often associated with mechanisms
2391    referred to as "Legacy Authentication" mechanisms.
2392
2393    While this memo references [EAP] with the intent that new methods can
2394    be added in the future without updating this specification, some
2395    simpler variations are documented here and in Section 3.16.  [EAP]
2396    defines an authentication protocol requiring a variable number of
2397    messages.  Extensible Authentication is implemented in IKE as
2398    additional IKE_AUTH exchanges that MUST be completed in order to
2399    initialize the IKE_SA.
2400
2401    An initiator indicates a desire to use extensible authentication by
2402    leaving out the AUTH payload from message 3.  By including an IDi
2403    payload but not an AUTH payload, the initiator has declared an
2404
2405
2406
2407 Hoffman                   Expires July 5, 2006                 [Page 43]
2408 \f
2409 Internet-Draft                    IKEv2                     January 2006
2410
2411
2412    identity but has not proven it.  If the responder is willing to use
2413    an extensible authentication method, it will place an Extensible
2414    Authentication Protocol (EAP) payload in message 4 and defer sending
2415    SAr2, TSi, and TSr until initiator authentication is complete in a
2416    subsequent IKE_AUTH exchange.  In the case of a minimal extensible
2417    authentication, the initial SA establishment will appear as follows:
2418
2419    Initiator                         Responder
2420    -------------------------------------------------------------------
2421    HDR, SAi1, KEi, Ni  -->
2422                                 <--  HDR, SAr1, KEr, Nr, [CERTREQ]
2423    HDR, SK {IDi, [CERTREQ,]
2424        [IDr,] SAi2,
2425        TSi, TSr}  -->
2426                                 <--  HDR, SK {IDr, [CERT,] AUTH,
2427                                          EAP }
2428    HDR, SK {EAP}  -->
2429                                 <--  HDR, SK {EAP (success)}
2430    HDR, SK {AUTH}  -->
2431                                 <--  HDR, SK {AUTH, SAr2, TSi, TSr }
2432
2433    {{ Clarif-3.11 }} As described in Section 2.2, when EAP is used, each
2434    pair of IKE_SA initial setup messages will have their message numbers
2435    incremented; the first pair of AUTH messages will have an ID of 1,
2436    the second will be 2, and so on.
2437
2438    For EAP methods that create a shared key as a side effect of
2439    authentication, that shared key MUST be used by both the initiator
2440    and responder to generate AUTH payloads in messages 7 and 8 using the
2441    syntax for shared secrets specified in Section 2.15.  The shared key
2442    from EAP is the field from the EAP specification named MSK.  The
2443    shared key generated during an IKE exchange MUST NOT be used for any
2444    other purpose.
2445
2446    EAP methods that do not establish a shared key SHOULD NOT be used, as
2447    they are subject to a number of man-in-the-middle attacks [EAPMITM]
2448    if these EAP methods are used in other protocols that do not use a
2449    server-authenticated tunnel.  Please see the Security Considerations
2450    section for more details.  If EAP methods that do not generate a
2451    shared key are used, the AUTH payloads in messages 7 and 8 MUST be
2452    generated using SK_pi and SK_pr, respectively.
2453
2454    {{ Demoted the SHOULD }} The initiator of an IKE_SA using EAP needs
2455    to be capable of extending the initial protocol exchange to at least
2456    ten IKE_AUTH exchanges in the event the responder sends notification
2457    messages and/or retries the authentication prompt.  Once the protocol
2458    exchange defined by the chosen EAP authentication method has
2459    successfully terminated, the responder MUST send an EAP payload
2460
2461
2462
2463 Hoffman                   Expires July 5, 2006                 [Page 44]
2464 \f
2465 Internet-Draft                    IKEv2                     January 2006
2466
2467
2468    containing the Success message.  Similarly, if the authentication
2469    method has failed, the responder MUST send an EAP payload containing
2470    the Failure message.  The responder MAY at any time terminate the IKE
2471    exchange by sending an EAP payload containing the Failure message.
2472
2473    Following such an extended exchange, the EAP AUTH payloads MUST be
2474    included in the two messages following the one containing the EAP
2475    Success message.
2476
2477    {{ Clarif-3.5 }} When the initiator authentication uses EAP, it is
2478    possible that the contents of the IDi payload is used only for AAA
2479    routing purposes and selecting which EAP method to use.  This value
2480    may be different from the identity authenticated by the EAP method.
2481    It is important that policy lookups and access control decisions use
2482    the actual authenticated identity.  Often the EAP server is
2483    implemented in a separate AAA server that communicates with the IKEv2
2484    responder.  In this case, the authenticated identity has to be sent
2485    from the AAA server to the IKEv2 responder.
2486
2487    {{ Clarif-3.9 }} The information in Section 2.17 about PRFs with
2488    fixed-size keys also applies to EAP authentication.  For instance, a
2489    PRF that requires a 128-bit key cannot be used with EAP because
2490    specifies that the MSK is at least 512 bits long.
2491
2492 2.17.  Generating Keying Material for CHILD_SAs
2493
2494    A single CHILD_SA is created by the IKE_AUTH exchange, and additional
2495    CHILD_SAs can optionally be created in CREATE_CHILD_SA exchanges.
2496    Keying material for them is generated as follows:
2497
2498    KEYMAT = prf+(SK_d, Ni | Nr)
2499
2500    Where Ni and Nr are the nonces from the IKE_SA_INIT exchange if this
2501    request is the first CHILD_SA created or the fresh Ni and Nr from the
2502    CREATE_CHILD_SA exchange if this is a subsequent creation.
2503
2504    For CREATE_CHILD_SA exchanges including an optional Diffie-Hellman
2505    exchange, the keying material is defined as:
2506
2507    KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr )
2508
2509    where g^ir (new) is the shared secret from the ephemeral Diffie-
2510    Hellman exchange of this CREATE_CHILD_SA exchange (represented as an
2511    octet string in big endian order padded with zeros in the high-order
2512    bits if necessary to make it the length of the modulus).
2513
2514    A single CHILD_SA negotiation may result in multiple security
2515    associations.  ESP and AH SAs exist in pairs (one in each direction),
2516
2517
2518
2519 Hoffman                   Expires July 5, 2006                 [Page 45]
2520 \f
2521 Internet-Draft                    IKEv2                     January 2006
2522
2523
2524    and four SAs could be created in a single CHILD_SA negotiation if a
2525    combination of ESP and AH is being negotiated.
2526
2527    Keying material MUST be taken from the expanded KEYMAT in the
2528    following order:
2529
2530    o  All keys for SAs carrying data from the initiator to the responder
2531       are taken before SAs going in the reverse direction.
2532
2533    o  If multiple IPsec protocols are negotiated, keying material is
2534       taken in the order in which the protocol headers will appear in
2535       the encapsulated packet.
2536
2537    o  If a single protocol has both encryption and authentication keys,
2538       the encryption key is taken from the first octets of KEYMAT and
2539       the authentication key is taken from the next octets.
2540
2541    Each cryptographic algorithm takes a fixed number of bits of keying
2542    material specified as part of the algorithm.
2543
2544 2.18.  Rekeying IKE_SAs Using a CREATE_CHILD_SA Exchange
2545
2546    The CREATE_CHILD_SA exchange can be used to rekey an existing IKE_SA
2547    (see Section 2.8). {{ Clarif-5.3 }} New initiator and responder SPIs
2548    are supplied in the SPI fields in the Proposal structures inside the
2549    Security Association (SA) payloads (not the SPI fields in the IKE
2550    header).  The TS payloads are omitted when rekeying an IKE_SA.
2551    SKEYSEED for the new IKE_SA is computed using SK_d from the existing
2552    IKE_SA as follows:
2553
2554    SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)
2555
2556    where g^ir (new) is the shared secret from the ephemeral Diffie-
2557    Hellman exchange of this CREATE_CHILD_SA exchange (represented as an
2558    octet string in big endian order padded with zeros if necessary to
2559    make it the length of the modulus) and Ni and Nr are the two nonces
2560    stripped of any headers.
2561
2562    {{ Clarif-5.5 }} The old and new IKE_SA may have selected a different
2563    PRF.  Because the rekeying exchange belongs to the old IKE_SA, it is
2564    the old IKE_SA's PRF that is used.  Note that this may not work if
2565    the new IKE_SA's PRF has a fixed key size because the output of the
2566    PRF may not be of the correct size.
2567
2568    The new IKE_SA MUST reset its message counters to 0.
2569
2570    SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as
2571    specified in Section 2.14.
2572
2573
2574
2575 Hoffman                   Expires July 5, 2006                 [Page 46]
2576 \f
2577 Internet-Draft                    IKEv2                     January 2006
2578
2579
2580 2.19.  Requesting an Internal Address on a Remote Network
2581
2582    Most commonly occurring in the endpoint-to-security-gateway scenario,
2583    an endpoint may need an IP address in the network protected by the
2584    security gateway and may need to have that address dynamically
2585    assigned.  A request for such a temporary address can be included in
2586    any request to create a CHILD_SA (including the implicit request in
2587    message 3) by including a CP payload.
2588
2589    This function provides address allocation to an IPsec Remote Access
2590    Client (IRAC) trying to tunnel into a network protected by an IPsec
2591    Remote Access Server (IRAS).  Since the IKE_AUTH exchange creates an
2592    IKE_SA and a CHILD_SA, the IRAC MUST request the IRAS-controlled
2593    address (and optionally other information concerning the protected
2594    network) in the IKE_AUTH exchange.  The IRAS may procure an address
2595    for the IRAC from any number of sources such as a DHCP/BOOTP server
2596    or its own address pool.
2597
2598    Initiator                         Responder
2599    -------------------------------------------------------------------
2600     HDR, SK {IDi, [CERT,]
2601        [CERTREQ,] [IDr,] AUTH,
2602        CP(CFG_REQUEST), SAi2,
2603        TSi, TSr}  -->
2604                                 <--  HDR, SK {IDr, [CERT,] AUTH,
2605                                          CP(CFG_REPLY), SAr2,
2606                                          TSi, TSr}
2607
2608    In all cases, the CP payload MUST be inserted before the SA payload.
2609    In variations of the protocol where there are multiple IKE_AUTH
2610    exchanges, the CP payloads MUST be inserted in the messages
2611    containing the SA payloads.
2612
2613    CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute
2614    (either IPv4 or IPv6) but MAY contain any number of additional
2615    attributes the initiator wants returned in the response.
2616
2617    For example, message from initiator to responder:
2618
2619    {{ Clarif-6.3 }}
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 Hoffman                   Expires July 5, 2006                 [Page 47]
2632 \f
2633 Internet-Draft                    IKEv2                     January 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 Hoffman                   Expires July 5, 2006                 [Page 48]
2688 \f
2689 Internet-Draft                    IKEv2                     January 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 Hoffman                   Expires July 5, 2006                 [Page 49]
2744 \f
2745 Internet-Draft                    IKEv2                     January 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 Hoffman                   Expires July 5, 2006                 [Page 50]
2800 \f
2801 Internet-Draft                    IKEv2                     January 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 Hoffman                   Expires July 5, 2006                 [Page 51]
2856 \f
2857 Internet-Draft                    IKEv2                     January 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 Hoffman                   Expires July 5, 2006                 [Page 52]
2912 \f
2913 Internet-Draft                    IKEv2                     January 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). {{ Promoted the SHOULD }} A host behind a NAT
2930       MUST NOT do this because it opens a DoS attack possibility.  Any
2931       authenticated IKE packet or any authenticated UDP-encapsulated ESP
2932       packet can be used to detect that the IP address or the port has
2933       changed.
2934
2935    Note that similar but probably not identical actions will likely be
2936    needed to make IKE work with Mobile IP, but such processing is not
2937    addressed by this document.
2938
2939 2.24.  Explicit Congestion Notification (ECN)
2940
2941    When IPsec tunnels behave as originally specified in [IPSECARCH-OLD],
2942    ECN usage is not appropriate for the outer IP headers because tunnel
2943    decapsulation processing discards ECN congestion indications to the
2944    detriment of the network.  ECN support for IPsec tunnels for IKEv1-
2945    based IPsec requires multiple operating modes and negotiation (see
2946    [ECN]).  IKEv2 simplifies this situation by requiring that ECN be
2947    usable in the outer IP headers of all tunnel-mode IPsec SAs created
2948    by IKEv2.  Specifically, tunnel encapsulators and decapsulators for
2949    all tunnel-mode SAs created by IKEv2 MUST support the ECN full-
2950    functionality option for tunnels specified in [ECN] and MUST
2951    implement the tunnel encapsulation and decapsulation processing
2952    specified in [IPSECARCH] to prevent discarding of ECN congestion
2953    indications.
2954
2955
2956 3.  Header and Payload Formats
2957
2958 3.1.  The IKE Header
2959
2960    IKE messages use UDP ports 500 and/or 4500, with one IKE message per
2961    UDP datagram.  Information from the beginning of the packet through
2962    the UDP header is largely ignored except that the IP addresses and
2963    UDP ports from the headers are reversed and used for return packets.
2964
2965
2966
2967 Hoffman                   Expires July 5, 2006                 [Page 53]
2968 \f
2969 Internet-Draft                    IKEv2                     January 2006
2970
2971
2972    When sent on UDP port 500, IKE messages begin immediately following
2973    the UDP header.  When sent on UDP port 4500, IKE messages have
2974    prepended four octets of zero.  These four octets of zero are not
2975    part of the IKE message and are not included in any of the length
2976    fields or checksums defined by IKE.  Each IKE message begins with the
2977    IKE header, denoted HDR in this memo.  Following the header are one
2978    or more IKE payloads each identified by a "Next Payload" field in the
2979    preceding payload.  Payloads are processed in the order in which they
2980    appear in an IKE message by invoking the appropriate processing
2981    routine according to the "Next Payload" field in the IKE header and
2982    subsequently according to the "Next Payload" field in the IKE payload
2983    itself until a "Next Payload" field of zero indicates that no
2984    payloads follow.  If a payload of type "Encrypted" is found, that
2985    payload is decrypted and its contents parsed as additional payloads.
2986    An Encrypted payload MUST be the last payload in a packet and an
2987    Encrypted payload MUST NOT contain another Encrypted payload.
2988
2989    The Recipient SPI in the header identifies an instance of an IKE
2990    security association.  It is therefore possible for a single instance
2991    of IKE to multiplex distinct sessions with multiple peers.
2992
2993    All multi-octet fields representing integers are laid out in big
2994    endian order (aka most significant byte first, or network byte
2995    order).
2996
2997    The format of the IKE header is shown in Figure 4.
2998
2999                         1                   2                   3
3000     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
3001    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3002    !                       IKE_SA Initiator's SPI                  !
3003    !                                                               !
3004    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3005    !                       IKE_SA Responder's SPI                  !
3006    !                                                               !
3007    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3008    !  Next Payload ! MjVer ! MnVer ! Exchange Type !     Flags     !
3009    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3010    !                          Message ID                           !
3011    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3012    !                            Length                             !
3013    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3014
3015                     Figure 4:  IKE Header Format
3016
3017    o  Initiator's SPI (8 octets) - A value chosen by the initiator to
3018       identify a unique IKE security association.  This value MUST NOT
3019       be zero.
3020
3021
3022
3023 Hoffman                   Expires July 5, 2006                 [Page 54]
3024 \f
3025 Internet-Draft                    IKEv2                     January 2006
3026
3027
3028    o  Responder's SPI (8 octets) - A value chosen by the responder to
3029       identify a unique IKE security association.  This value MUST be
3030       zero in the first message of an IKE Initial Exchange (including
3031       repeats of that message including a cookie). {{ The phrase "and
3032       MUST NOT be zero in any other message" was removed; Clarif-2.1 }}
3033
3034    o  Next Payload (1 octet) - Indicates the type of payload that
3035       immediately follows the header.  The format and value of each
3036       payload are defined below.
3037
3038    o  Major Version (4 bits) - Indicates the major version of the IKE
3039       protocol in use.  Implementations based on this version of IKE
3040       MUST set the Major Version to 2.  Implementations based on
3041       previous versions of IKE and ISAKMP MUST set the Major Version to
3042       1.  Implementations based on this version of IKE MUST reject or
3043       ignore messages containing a version number greater than 2.
3044
3045    o  Minor Version (4 bits) - Indicates the minor version of the IKE
3046       protocol in use.  Implementations based on this version of IKE
3047       MUST set the Minor Version to 0.  They MUST ignore the minor
3048       version number of received messages.
3049
3050    o  Exchange Type (1 octet) - Indicates the type of exchange being
3051       used.  This constrains the payloads sent in each message and
3052       orderings of messages in an exchange.
3053
3054       Exchange Type             Value
3055       ----------------------------------
3056       RESERVED                  0-33
3057       IKE_SA_INIT               34
3058       IKE_AUTH                  35
3059       CREATE_CHILD_SA           36
3060       INFORMATIONAL             37
3061       RESERVED TO IANA          38-239
3062       Reserved for private use  240-255
3063
3064    o  Flags (1 octet) - Indicates specific options that are set for the
3065       message.  Presence of options are indicated by the appropriate bit
3066       in the flags field being set.  The bits are defined LSB first, so
3067       bit 0 would be the least significant bit of the Flags octet.  In
3068       the description below, a bit being 'set' means its value is '1',
3069       while 'cleared' means its value is '0'.
3070
3071       *  X(reserved) (bits 0-2) - These bits MUST be cleared when
3072          sending and MUST be ignored on receipt.
3073
3074       *  I(nitiator) (bit 3 of Flags) - This bit MUST be set in messages
3075          sent by the original initiator of the IKE_SA and MUST be
3076
3077
3078
3079 Hoffman                   Expires July 5, 2006                 [Page 55]
3080 \f
3081 Internet-Draft                    IKEv2                     January 2006
3082
3083
3084          cleared in messages sent by the original responder.  It is used
3085          by the recipient to determine which eight octets of the SPI
3086          were generated by the recipient.
3087
3088       *  V(ersion) (bit 4 of Flags) - This bit indicates that the
3089          transmitter is capable of speaking a higher major version
3090          number of the protocol than the one indicated in the major
3091          version number field.  Implementations of IKEv2 must clear this
3092          bit when sending and MUST ignore it in incoming messages.
3093
3094       *  R(esponse) (bit 5 of Flags) - This bit indicates that this
3095          message is a response to a message containing the same message
3096          ID.  This bit MUST be cleared in all request messages and MUST
3097          be set in all responses.  An IKE endpoint MUST NOT generate a
3098          response to a message that is marked as being a response.
3099
3100       *  X(reserved) (bits 6-7 of Flags) - These bits MUST be cleared
3101          when sending and MUST be ignored on receipt.
3102
3103    o  Message ID (4 octets) - Message identifier used to control
3104       retransmission of lost packets and matching of requests and
3105       responses.  It is essential to the security of the protocol
3106       because it is used to prevent message replay attacks.  See
3107       Section 2.1 and Section 2.2.
3108
3109    o  Length (4 octets) - Length of total message (header + payloads) in
3110       octets.
3111