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