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