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