child-sa: Don't update outbound policies if they are not installed
[strongswan.git] / doc / standards / rfc4718.txt
1
2
3
4
5
6
7 Network Working Group                                          P. Eronen
8 Request for Comments: 4718                                         Nokia
9 Category: Informational                                       P. Hoffman
10                                                           VPN Consortium
11                                                             October 2006
12
13
14            IKEv2 Clarifications and Implementation Guidelines
15
16 Status of This Memo
17
18    This memo provides information for the Internet community.  It does
19    not specify an Internet standard of any kind.  Distribution of this
20    memo is unlimited.
21
22 Copyright Notice
23
24    Copyright (C) The Internet Society (2006).
25
26 Abstract
27
28    This document clarifies many areas of the IKEv2 specification.  It
29    does not to introduce any changes to the protocol, but rather
30    provides descriptions that are less prone to ambiguous
31    interpretations.  The purpose of this document is to encourage the
32    development of interoperable implementations.
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58 Eronen & Hoffman             Informational                      [Page 1]
59 \f
60 RFC 4718                  IKEv2 Clarifications              October 2006
61
62
63 Table of Contents
64
65    1. Introduction ....................................................4
66    2. Creating the IKE_SA .............................................4
67       2.1. SPI Values in IKE_SA_INIT Exchange .........................4
68       2.2. Message IDs for IKE_SA_INIT Messages .......................5
69       2.3. Retransmissions of IKE_SA_INIT Requests ....................5
70       2.4. Interaction of COOKIE and INVALID_KE_PAYLOAD ...............6
71       2.5. Invalid Cookies ............................................8
72    3. Authentication ..................................................9
73       3.1. Data Included in AUTH Payload Calculation ..................9
74       3.2. Hash Function for RSA Signatures ...........................9
75       3.3. Encoding Method for RSA Signatures ........................10
76       3.4. Identification Type for EAP ...............................11
77       3.5. Identity for Policy Lookups When Using EAP ................11
78       3.6. Certificate Encoding Types ................................12
79       3.7. Shared Key Authentication and Fixed PRF Key Size ..........12
80       3.8. EAP Authentication and Fixed PRF Key Size .................13
81       3.9. Matching ID Payloads to Certificate Contents ..............13
82       3.10. Message IDs for IKE_AUTH Messages ........................14
83    4. Creating CHILD_SAs .............................................14
84       4.1. Creating SAs with the CREATE_CHILD_SA Exchange ............14
85       4.2. Creating an IKE_SA without a CHILD_SA .....................16
86       4.3. Diffie-Hellman for First CHILD_SA .........................16
87       4.4. Extended Sequence Numbers (ESN) Transform .................17
88       4.5. Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED ..............17
89       4.6. Negotiation of NON_FIRST_FRAGMENTS_ALSO ...................18
90       4.7. Semantics of Complex Traffic Selector Payloads ............18
91       4.8. ICMP Type/Code in Traffic Selector Payloads ...............19
92       4.9. Mobility Header in Traffic Selector Payloads ..............20
93       4.10. Narrowing the Traffic Selectors ..........................20
94       4.11. SINGLE_PAIR_REQUIRED .....................................21
95       4.12. Traffic Selectors Violating Own Policy ...................21
96       4.13. Traffic Selector Authorization ...........................22
97    5. Rekeying and Deleting SAs ......................................23
98       5.1. Rekeying SAs with the CREATE_CHILD_SA Exchange ............23
99       5.2. Rekeying the IKE_SA vs. Reauthentication ..................24
100       5.3. SPIs When Rekeying the IKE_SA .............................25
101       5.4. SPI When Rekeying a CHILD_SA ..............................25
102       5.5. Changing PRFs When Rekeying the IKE_SA ....................26
103       5.6. Deleting vs. Closing SAs ..................................26
104       5.7. Deleting a CHILD_SA Pair ..................................26
105       5.8. Deleting an IKE_SA ........................................27
106       5.9. Who is the original initiator of IKE_SA ...................27
107       5.10. Comparing Nonces .........................................27
108       5.11. Exchange Collisions ......................................28
109       5.12. Diffie-Hellman and Rekeying the IKE_SA ...................36
110
111
112
113
114 Eronen & Hoffman             Informational                      [Page 2]
115 \f
116 RFC 4718                  IKEv2 Clarifications              October 2006
117
118
119    6. Configuration Payloads .........................................37
120       6.1. Assigning IP Addresses ....................................37
121       6.2. Requesting any INTERNAL_IP4/IP6_ADDRESS ...................38
122       6.3. INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET ...................38
123       6.4. INTERNAL_IP4_NETMASK ......................................41
124       6.5. Configuration Payloads for IPv6 ...........................42
125       6.6. INTERNAL_IP6_NBNS .........................................43
126       6.7. INTERNAL_ADDRESS_EXPIRY ...................................43
127       6.8. Address Assignment Failures ...............................44
128    7. Miscellaneous Issues ...........................................45
129       7.1. Matching ID_IPV4_ADDR and ID_IPV6_ADDR ....................45
130       7.2. Relationship of IKEv2 to RFC 4301 .........................45
131       7.3. Reducing the Window Size ..................................46
132       7.4. Minimum Size of Nonces ....................................46
133       7.5. Initial Zero Octets on Port 4500 ..........................46
134       7.6. Destination Port for NAT Traversal ........................47
135       7.7. SPI Values for Messages outside an IKE_SA .................47
136       7.8. Protocol ID/SPI Fields in Notify Payloads .................48
137       7.9. Which message should contain INITIAL_CONTACT ..............48
138       7.10. Alignment of Payloads ....................................48
139       7.11. Key Length Transform Attribute ...........................48
140       7.12. IPsec IANA Considerations ................................49
141       7.13. Combining ESP and AH .....................................50
142    8. Implementation Mistakes ........................................50
143    9. Security Considerations ........................................51
144    10. Acknowledgments ...............................................51
145    11. References ....................................................51
146       11.1. Normative References .....................................51
147       11.2. Informative References ...................................52
148    Appendix A. Exchanges and Payloads ................................54
149       A.1. IKE_SA_INIT Exchange ......................................54
150       A.2. IKE_AUTH Exchange without EAP .............................54
151       A.3. IKE_AUTH Exchange with EAP ................................55
152       A.4. CREATE_CHILD_SA Exchange for Creating/Rekeying
153            CHILD_SAs .................................................56
154       A.5. CREATE_CHILD_SA Exchange for Rekeying the IKE_SA ..........56
155       A.6. INFORMATIONAL Exchange ....................................56
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170 Eronen & Hoffman             Informational                      [Page 3]
171 \f
172 RFC 4718                  IKEv2 Clarifications              October 2006
173
174
175 1.  Introduction
176
177    This document clarifies many areas of the IKEv2 specification that
178    may be difficult to understand to developers not intimately familiar
179    with the specification and its history.  The clarifications in this
180    document come from the discussion on the IPsec WG mailing list, from
181    experience in interoperability testing, and from implementation
182    issues that have been brought to the editors' attention.
183
184    IKEv2/IPsec can be used for several different purposes, including
185    IPsec-based remote access (sometimes called the "road warrior" case),
186    site-to-site virtual private networks (VPNs), and host-to-host
187    protection of application traffic.  While this document attempts to
188    consider all of these uses, the remote access scenario has perhaps
189    received more attention here than the other uses.
190
191    This document does not place any requirements on anyone and does not
192    use [RFC2119] keywords such as "MUST" and "SHOULD", except in
193    quotations from the original IKEv2 documents.  The requirements are
194    given in the IKEv2 specification [IKEv2] and IKEv2 cryptographic
195    algorithms document [IKEv2ALG].
196
197    In this document, references to a numbered section (such as "Section
198    2.15") mean that section in [IKEv2].  References to mailing list
199    messages or threads refer to the IPsec WG mailing list at
200    ipsec@ietf.org.  Archives of the mailing list can be found at
201    <http://www.ietf.org/mail-archive/web/ipsec/index.html>.
202
203 2.  Creating the IKE_SA
204
205 2.1.  SPI Values in IKE_SA_INIT Exchange
206
207    Normal IKE messages include the initiator's and responder's Security
208    Parameter Indexes (SPIs), both of which are non-zero, in the IKE
209    header.  However, there are some corner cases where the IKEv2
210    specification is not fully consistent about what values should be
211    used.
212
213    First, Section 3.1 says that the Responder's SPI "...MUST NOT be zero
214    in any other message" (than the first message of the IKE_SA_INIT
215    exchange).  However, the figure in Section 2.6 shows the second
216    IKE_SA_INIT message as "HDR(A,0), N(COOKIE)", contradicting the text
217    in 3.1.
218
219    Since the responder's SPI identifies security-related state held by
220    the responder, and in this case no state is created, sending a zero
221    value seems reasonable.
222
223
224
225
226 Eronen & Hoffman             Informational                      [Page 4]
227 \f
228 RFC 4718                  IKEv2 Clarifications              October 2006
229
230
231    Second, in addition to cookies, there are several other cases when
232    the IKE_SA_INIT exchange does not result in the creation of an IKE_SA
233    (for instance, INVALID_KE_PAYLOAD or NO_PROPOSAL_CHOSEN).  What
234    responder SPI value should be used in the IKE_SA_INIT response in
235    this case?
236
237    Since the IKE_SA_INIT request always has a zero responder SPI, the
238    value will not be actually used by the initiator.  Thus, we think
239    sending a zero value is correct also in this case.
240
241    If the responder sends a non-zero responder SPI, the initiator should
242    not reject the response only for that reason.  However, when retrying
243    the IKE_SA_INIT request, the initiator will use a zero responder SPI,
244    as described in Section 3.1: "Responder's SPI [...]  This value MUST
245    be zero in the first message of an IKE Initial Exchange (including
246    repeats of that message including a cookie) [...]".  We believe the
247    intent was to cover repeats of that message due to other reasons,
248    such as INVALID_KE_PAYLOAD, as well.
249
250    (References: "INVALID_KE_PAYLOAD and clarifications document" thread,
251    Sep-Oct 2005.)
252
253 2.2.  Message IDs for IKE_SA_INIT Messages
254
255    The Message ID for IKE_SA_INIT messages is always zero.  This
256    includes retries of the message due to responses such as COOKIE and
257    INVALID_KE_PAYLOAD.
258
259    This is because Message IDs are part of the IKE_SA state, and when
260    the responder replies to IKE_SA_INIT request with N(COOKIE) or
261    N(INVALID_KE_PAYLOAD), the responder does not allocate any state.
262
263    (References: "Question about N(COOKIE) and N(INVALID_KE_PAYLOAD)
264    combination" thread, Oct 2004.  Tero Kivinen's mail "Comments of
265    draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.)
266
267 2.3.  Retransmissions of IKE_SA_INIT Requests
268
269    When a responder receives an IKE_SA_INIT request, it has to determine
270    whether the packet is a retransmission belonging to an existing
271    "half-open" IKE_SA (in which case the responder retransmits the same
272    response), or a new request (in which case the responder creates a
273    new IKE_SA and sends a fresh response).
274
275    The specification does not describe in detail how this determination
276    is done.  In particular, it is not sufficient to use the initiator's
277    SPI and/or IP address for this purpose: two different peers behind a
278    single NAT could choose the same initiator SPI (and the probability
279
280
281
282 Eronen & Hoffman             Informational                      [Page 5]
283 \f
284 RFC 4718                  IKEv2 Clarifications              October 2006
285
286
287    of this happening is not necessarily small, since IKEv2 does not
288    require SPIs to be chosen randomly).  Instead, the responder should
289    do the IKE_SA lookup using the whole packet or its hash (or at the
290    minimum, the Ni payload which is always chosen randomly).
291
292    For all other packets than IKE_SA_INIT requests, looking up right
293    IKE_SA is of course done based on the recipient's SPI (either the
294    initiator or responder SPI depending on the value of the Initiator
295    bit in the IKE header).
296
297 2.4.  Interaction of COOKIE and INVALID_KE_PAYLOAD
298
299    There are two common reasons why the initiator may have to retry the
300    IKE_SA_INIT exchange: the responder requests a cookie or wants a
301    different Diffie-Hellman group than was included in the KEi payload.
302    Both of these cases are quite simple alone, but it is not totally
303    obvious what happens when they occur at the same time, that is, the
304    IKE_SA_INIT exchange is retried several times.
305
306    The main question seems to be the following: if the initiator
307    receives a cookie from the responder, should it include the cookie in
308    only the next retry of the IKE_SA_INIT request, or in all subsequent
309    retries as well?  Section 3.10.1 says that:
310
311       "This notification MUST be included in an IKE_SA_INIT request
312       retry if a COOKIE notification was included in the initial
313       response."
314
315    This could be interpreted as saying that when a cookie is received in
316    the initial response, it is included in all retries.  On the other
317    hand, Section 2.6 says that:
318
319       "Initiators who receive such responses MUST retry the
320       IKE_SA_INIT with a Notify payload of type COOKIE containing
321       the responder supplied cookie data as the first payload and
322       all other payloads unchanged."
323
324    Including the same cookie in later retries makes sense only if the
325    "all other payloads unchanged" restriction applies only to the first
326    retry, but not to subsequent retries.
327
328    It seems that both interpretations can peacefully coexist.  If the
329    initiator includes the cookie only in the next retry, one additional
330    roundtrip may be needed in some cases:
331
332
333
334
335
336
337
338 Eronen & Hoffman             Informational                      [Page 6]
339 \f
340 RFC 4718                  IKEv2 Clarifications              October 2006
341
342
343       Initiator                   Responder
344      -----------                 -----------
345       HDR(A,0), SAi1, KEi, Ni -->
346                               <-- HDR(A,0), N(COOKIE)
347       HDR(A,0), N(COOKIE), SAi1, KEi, Ni  -->
348                               <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
349       HDR(A,0), SAi1, KEi', Ni -->
350                               <-- HDR(A,0), N(COOKIE')
351       HDR(A,0), N(COOKIE'), SAi1, KEi',Ni -->
352                               <-- HDR(A,B), SAr1, KEr, Nr
353
354    An additional roundtrip is needed also if the initiator includes the
355    cookie in all retries, but the responder does not support this
356    functionality.  For instance, if the responder includes the SAi1 and
357    KEi payloads in cookie calculation, it will reject the request by
358    sending a new cookie (see also Section 2.5 of this document for more
359    text about invalid cookies):
360
361
362       Initiator                   Responder
363      -----------                 -----------
364       HDR(A,0), SAi1, KEi, Ni -->
365                               <-- HDR(A,0), N(COOKIE)
366       HDR(A,0), N(COOKIE), SAi1, KEi, Ni  -->
367                               <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
368       HDR(A,0), N(COOKIE), SAi1, KEi', Ni -->
369                               <-- HDR(A,0), N(COOKIE')
370       HDR(A,0), N(COOKIE'), SAi1, KEi',Ni -->
371                               <-- HDR(A,B), SAr1, KEr, Nr
372
373    If both peers support including the cookie in all retries, a slightly
374    shorter exchange can happen:
375
376       Initiator                   Responder
377      -----------                 -----------
378       HDR(A,0), SAi1, KEi, Ni -->
379                               <-- HDR(A,0), N(COOKIE)
380       HDR(A,0), N(COOKIE), SAi1, KEi, Ni  -->
381                               <-- HDR(A,0), N(INVALID_KE_PAYLOAD)
382       HDR(A,0), N(COOKIE), SAi1, KEi', Ni -->
383                               <-- HDR(A,B), SAr1, KEr, Nr
384
385    This document recommends that implementations should support this
386    shorter exchange, but it must not be assumed the other peer also
387    supports the shorter exchange.
388
389
390
391
392
393
394 Eronen & Hoffman             Informational                      [Page 7]
395 \f
396 RFC 4718                  IKEv2 Clarifications              October 2006
397
398
399    In theory, even this exchange has one unnecessary roundtrip, as both
400    the cookie and Diffie-Hellman group could be checked at the same
401    time:
402
403       Initiator                   Responder
404      -----------                 -----------
405       HDR(A,0), SAi1, KEi, Ni -->
406                               <-- HDR(A,0), N(COOKIE),
407                                             N(INVALID_KE_PAYLOAD)
408       HDR(A,0), N(COOKIE), SAi1, KEi',Ni -->
409                               <-- HDR(A,B), SAr1, KEr, Nr
410
411    However, it is clear that this case is not allowed by the text in
412    Section 2.6, since "all other payloads" clearly includes the KEi
413    payload as well.
414
415    (References: "INVALID_KE_PAYLOAD and clarifications document" thread,
416    Sep-Oct 2005.)
417
418 2.5.  Invalid Cookies
419
420    There has been some confusion what should be done when an IKE_SA_INIT
421    request containing an invalid cookie is received ("invalid" in the
422    sense that its contents do not match the value expected by the
423    responder).
424
425    The correct action is to ignore the cookie and process the message as
426    if no cookie had been included (usually this means sending a response
427    containing a new cookie).  This is shown in Section 2.6 when it says
428    "The responder in that case MAY reject the message by sending another
429    response with a new cookie [...]".
430
431    Other possible actions, such as ignoring the whole request (or even
432    all requests from this IP address for some time), create strange
433    failure modes even in the absence of any malicious attackers and do
434    not provide any additional protection against DoS attacks.
435
436    (References: "Invalid Cookie" thread, Sep-Oct 2005.)
437
438
439
440
441
442
443
444
445
446
447
448
449
450 Eronen & Hoffman             Informational                      [Page 8]
451 \f
452 RFC 4718                  IKEv2 Clarifications              October 2006
453
454
455 3.  Authentication
456
457 3.1.  Data Included in AUTH Payload Calculation
458
459    Section 2.15 describes how the AUTH payloads are calculated; this
460    calculation involves values prf(SK_pi,IDi') and prf(SK_pr,IDr').  The
461    text describes the method in words, but does not give clear
462    definitions of what is signed or MACed (i.e., protected with a
463    message authentication code).
464
465    The initiator's signed octets can be described as:
466
467        InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI
468        GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
469        RealIKEHDR =  SPIi | SPIr |  . . . | Length
470        RealMessage1 = RealIKEHDR | RestOfMessage1
471        NonceRPayload = PayloadHeader | NonceRData
472        InitiatorIDPayload = PayloadHeader | RestOfIDPayload
473        RestOfInitIDPayload = IDType | RESERVED | InitIDData
474        MACedIDForI = prf(SK_pi, RestOfInitIDPayload)
475
476    The responder's signed octets can be described as:
477
478        ResponderSignedOctets = RealMessage2 | NonceIData | MACedIDForR
479        GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR
480        RealIKEHDR =  SPIi | SPIr |  . . . | Length
481        RealMessage2 = RealIKEHDR | RestOfMessage2
482        NonceIPayload = PayloadHeader | NonceIData
483        ResponderIDPayload = PayloadHeader | RestOfIDPayload
484        RestOfRespIDPayload = IDType | RESERVED | InitIDData
485        MACedIDForR = prf(SK_pr, RestOfRespIDPayload)
486
487 3.2.  Hash Function for RSA Signatures
488
489    Section 3.8 says that RSA digital signature is "Computed as specified
490    in section 2.15 using an RSA private key over a PKCS#1 padded hash."
491
492    Unlike IKEv1, IKEv2 does not negotiate a hash function for the
493    IKE_SA.  The algorithm for signatures is selected by the signing
494    party who, in general, may not know beforehand what algorithms the
495    verifying party supports.  Furthermore, [IKEv2ALG] does not say what
496    algorithms implementations are required or recommended to support.
497    This clearly has a potential for causing interoperability problems,
498    since authentication will fail if the signing party selects an
499    algorithm that is not supported by the verifying party, or not
500    acceptable according to the verifying party's policy.
501
502
503
504
505
506 Eronen & Hoffman             Informational                      [Page 9]
507 \f
508 RFC 4718                  IKEv2 Clarifications              October 2006
509
510
511    This document recommends that all implementations support SHA-1 and
512    use SHA-1 as the default hash function when generating the
513    signatures, unless there are good reasons (such as explicit manual
514    configuration) to believe that the peer supports something else.
515
516    Note that hash function collision attacks are not important for the
517    AUTH payloads, since they are not intended for third-party
518    verification, and the data includes fresh nonces.  See [HashUse] for
519    more discussion about hash function attacks and IPsec.
520
521    Another reasonable choice would be to use the hash function that was
522    used by the CA when signing the peer certificate.  However, this does
523    not guarantee that the IKEv2 peer would be able to validate the AUTH
524    payload, because the same code might not be used to validate
525    certificate signatures and IKEv2 message signatures, and these two
526    routines may support a different set of hash algorithms.  The peer
527    could be configured with a fingerprint of the certificate, or
528    certificate validation could be performed by an external entity using
529    [SCVP].  Furthermore, not all CERT payloads types include a
530    signature, and the certificate could be signed with some algorithm
531    other than RSA.
532
533    Note that unlike IKEv1, IKEv2 uses the PKCS#1 v1.5 [PKCS1v20]
534    signature encoding method (see next section for details), which
535    includes the algorithm identifier for the hash algorithm.  Thus, when
536    the verifying party receives the AUTH payload it can at least
537    determine which hash function was used.
538
539    (References: Magnus Alstrom's mail "RE:", 2005-01-03.  Pasi Eronen's
540    reply, 2005-01-04.  Tero Kivinen's reply, 2005-01-04.  "First draft
541    of IKEv2.1" thread, Dec 2005/Jan 2006.)
542
543 3.3.  Encoding Method for RSA Signatures
544
545    Section 3.8 says that the RSA digital signature is "Computed as
546    specified in section 2.15 using an RSA private key over a PKCS#1
547    padded hash."
548
549    The PKCS#1 specification [PKCS1v21] defines two different encoding
550    methods (ways of "padding the hash") for signatures.  However, the
551    Internet-Draft approved by the IESG had a reference to the older
552    PKCS#1 v2.0 [PKCS1v20].  That version has only one encoding method
553    for signatures (EMSA-PKCS1-v1_5), and thus there is no ambiguity.
554
555
556
557
558
559
560
561
562 Eronen & Hoffman             Informational                     [Page 10]
563 \f
564 RFC 4718                  IKEv2 Clarifications              October 2006
565
566
567    Note that this encoding method is different from the encoding method
568    used in IKEv1.  If future revisions of IKEv2 provide support for
569    other encoding methods (such as EMSA-PSS), they will be given new
570    Auth Method numbers.
571
572    (References: Pasi Eronen's mail "RE:", 2005-01-04.)
573
574 3.4.  Identification Type for EAP
575
576    Section 3.5 defines several different types for identification
577    payloads, including, e.g., ID_FQDN, ID_RFC822_ADDR, and ID_KEY_ID.
578    EAP [EAP] does not mandate the use of any particular type of
579    identifier, but often EAP is used with Network Access Identifiers
580    (NAIs) defined in [NAI].  Although NAIs look a bit like email
581    addresses (e.g., "joe@example.com"), the syntax is not exactly the
582    same as the syntax of email address in [RFC822].  This raises the
583    question of which identification type should be used.
584
585    This document recommends that ID_RFC822_ADDR identification type is
586    used for those NAIs that include the realm component.  Therefore,
587    responder implementations should not attempt to verify that the
588    contents actually conform to the exact syntax given in [RFC822] or
589    [RFC2822], but instead should accept any reasonable looking NAI.
590
591    For NAIs that do not include the realm component, this document
592    recommends using the ID_KEY_ID identification type.
593
594    (References: "need your help on this IKEv2/i18n/EAP issue" and "IKEv2
595    identifier issue with EAP" threads, Aug 2004.)
596
597 3.5.  Identity for Policy Lookups When Using EAP
598
599    When the initiator authentication uses EAP, it is possible that the
600    contents of the IDi payload is used only for AAA routing purposes and
601    selecting which EAP method to use.  This value may be different from
602    the identity authenticated by the EAP method (see [EAP], Sections 5.1
603    and 7.3).
604
605    It is important that policy lookups and access control decisions use
606    the actual authenticated identity.  Often the EAP server is
607    implemented in a separate AAA server that communicates with the IKEv2
608    responder using, e.g., RADIUS [RADEAP].  In this case, the
609    authenticated identity has to be sent from the AAA server to the
610    IKEv2 responder.
611
612    (References: Pasi Eronen's mail "RE: Reauthentication in IKEv2",
613    2004-10-28.  "Policy lookups" thread, Oct/Nov 2004.  RFC 3748,
614    Section 7.3.)
615
616
617
618 Eronen & Hoffman             Informational                     [Page 11]
619 \f
620 RFC 4718                  IKEv2 Clarifications              October 2006
621
622
623 3.6.  Certificate Encoding Types
624
625    Section 3.6 defines a total of twelve different certificate encoding
626    types, and continues that "Specific syntax is for some of the
627    certificate type codes above is not defined in this document."
628    However, the text does not provide references to other documents that
629    would contain information about the exact contents and use of those
630    values.
631
632    Without this information, it is not possible to develop interoperable
633    implementations.  Therefore, this document recommends that the
634    following certificate encoding values should not be used before new
635    specifications that specify their use are available.
636
637         PKCS #7 wrapped X.509 certificate    1
638         PGP Certificate                      2
639         DNS Signed Key                       3
640         Kerberos Token                       6
641         SPKI Certificate                     9
642
643    This document recommends that most implementations should use only
644    those values that are "MUST"/"SHOULD" requirements in [IKEv2]; i.e.,
645    "X.509 Certificate - Signature" (4), "Raw RSA Key" (11), "Hash and
646    URL of X.509 certificate" (12), and "Hash and URL of X.509 bundle"
647    (13).
648
649    Furthermore, Section 3.7 says that the "Certificate Encoding" field
650    for the Certificate Request payload uses the same values as for
651    Certificate payload.  However, the contents of the "Certification
652    Authority" field are defined only for X.509 certificates (presumably
653    covering at least types 4, 10, 12, and 13).  This document recommends
654    that other values should not be used before new specifications that
655    specify their use are available.
656
657    The "Raw RSA Key" type needs one additional clarification.  Section
658    3.6 says it contains "a PKCS #1 encoded RSA key".  What this means is
659    a DER-encoded RSAPublicKey structure from PKCS#1 [PKCS1v21].
660
661 3.7.  Shared Key Authentication and Fixed PRF Key Size
662
663    Section 2.15 says that "If the negotiated prf takes a fixed-size key,
664    the shared secret MUST be of that fixed size".  This statement is
665    correct: the shared secret must be of the correct size.  If it is
666    not, it cannot be used; there is no padding, truncation, or other
667    processing involved to force it to that correct size.
668
669
670
671
672
673
674 Eronen & Hoffman             Informational                     [Page 12]
675 \f
676 RFC 4718                  IKEv2 Clarifications              October 2006
677
678
679    This requirement means that it is difficult to use these pseudo-
680    random functions (PRFs) with shared key authentication.  The authors
681    think this part of the specification was very poorly thought out, and
682    using PRFs with a fixed key size is likely to result in
683    interoperability problems.  Thus, we recommend that such PRFs should
684    not be used with shared key authentication.  PRF_AES128_XCBC
685    [RFC3664] originally used fixed key sizes; that RFC has been updated
686    to handle variable key sizes in [RFC4434].
687
688    Note that Section 2.13 also contains text that is related to PRFs
689    with fixed key size: "When the key for the prf function has fixed
690    length, the data provided as a key is truncated or padded with zeros
691    as necessary unless exceptional processing is explained following the
692    formula".  However, this text applies only to the prf+ construction,
693    so it does not contradict the text in Section 2.15.
694
695    (References: Paul Hoffman's mail "Re: ikev2-07: last nits",
696    2003-05-02.  Hugo Krawczyk's reply, 2003-05-12.  Thread "Question
697    about PRFs with fixed size key", Jan 2005.)
698
699 3.8.  EAP Authentication and Fixed PRF Key Size
700
701    As described in the previous section, PRFs with a fixed key size
702    require a shared secret of exactly that size.  This restriction
703    applies also to EAP authentication.  For instance, a PRF that
704    requires a 128-bit key cannot be used with EAP since [EAP] specifies
705    that the MSK is at least 512 bits long.
706
707    (References: Thread "Question about PRFs with fixed size key", Jan
708    2005.)
709
710 3.9.  Matching ID Payloads to Certificate Contents
711
712    In IKEv1, there was some confusion about whether or not the
713    identities in certificates used to authenticate IKE were required to
714    match the contents of the ID payloads.  The PKI4IPsec Working Group
715    produced the document [PKI4IPsec] which covers this topic in much
716    more detail.  However, Section 3.5 of [IKEv2] explicitly says that
717    the ID payload "does not necessarily have to match anything in the
718    CERT payload".
719
720
721
722
723
724
725
726
727
728
729
730 Eronen & Hoffman             Informational                     [Page 13]
731 \f
732 RFC 4718                  IKEv2 Clarifications              October 2006
733
734
735 3.10.  Message IDs for IKE_AUTH Messages
736
737    According to Section 2.2, "The IKE_SA initial setup messages will
738    always be numbered 0 and 1."  That is true when the IKE_AUTH exchange
739    does not use EAP.  When EAP is used, each pair of messages has their
740    message numbers incremented.  The first pair of AUTH messages will
741    have an ID of 1, the second will be 2, and so on.
742
743    (References: "Question about MsgID in AUTH exchange" thread, April
744    2005.)
745
746 4.  Creating CHILD_SAs
747
748 4.1.  Creating SAs with the CREATE_CHILD_SA Exchange
749
750    Section 1.3's organization does not lead to clear understanding of
751    what is needed in which environment.  The section can be reorganized
752    with subsections for each use of the CREATE_CHILD_SA exchange
753    (creating child SAs, rekeying IKE SAs, and rekeying child SAs.)
754
755    The new Section 1.3 with subsections and the above changes might look
756    like the following.
757
758    NEW-1.3 The CREATE_CHILD_SA Exchange
759
760         The CREATE_CHILD_SA Exchange is used to create new CHILD_SAs and
761         to rekey both IKE_SAs and CHILD_SAs.  This exchange consists of
762         a single request/response pair, and some of its function was
763         referred to as a phase 2 exchange in IKEv1.  It MAY be initiated
764         by either end of the IKE_SA after the initial exchanges are
765         completed.
766
767         All messages following the initial exchange are
768         cryptographically protected using the cryptographic algorithms
769         and keys negotiated in the first two messages of the IKE
770         exchange.  These subsequent messages use the syntax of the
771         Encrypted Payload described in section 3.14.  All subsequent
772         messages include an Encrypted Payload, even if they are referred
773         to in the text as "empty".
774
775         The CREATE_CHILD_SA is used for rekeying IKE_SAs and CHILD_SAs.
776         This section describes the first part of rekeying, the creation
777         of new SAs; Section 2.8 covers the mechanics of rekeying,
778         including moving traffic from old to new SAs and the deletion of
779         the old SAs.  The two sections must be read together to
780         understand the entire process of rekeying.
781
782
783
784
785
786 Eronen & Hoffman             Informational                     [Page 14]
787 \f
788 RFC 4718                  IKEv2 Clarifications              October 2006
789
790
791         Either endpoint may initiate a CREATE_CHILD_SA exchange, so in
792         this section the term initiator refers to the endpoint
793         initiating this exchange.  An implementation MAY refuse all
794         CREATE_CHILD_SA requests within an IKE_SA.
795
796         The CREATE_CHILD_SA request MAY optionally contain a KE payload
797         for an additional Diffie-Hellman exchange to enable stronger
798         guarantees of forward secrecy for the CHILD_SA or IKE_SA.  The
799         keying material for the SA is a function of SK_d established
800         during the establishment of the IKE_SA, the nonces exchanged
801         during the CREATE_CHILD_SA exchange, and the Diffie-Hellman
802         value (if KE payloads are included in the CREATE_CHILD_SA
803         exchange).  The details are described in sections 2.17 and 2.18.
804
805         If a CREATE_CHILD_SA exchange includes a KEi payload, at least
806         one of the SA offers MUST include the Diffie-Hellman group of
807         the KEi.  The Diffie-Hellman group of the KEi MUST be an element
808         of the group the initiator expects the responder to accept
809         (additional Diffie-Hellman groups can be proposed).  If the
810         responder rejects the Diffie-Hellman group of the KEi payload,
811         the responder MUST reject the request and indicate its preferred
812         Diffie-Hellman group in the INVALID_KE_PAYLOAD Notification
813         payload.  In the case of such a rejection, the CREATE_CHILD_SA
814         exchange fails, and the initiator SHOULD retry the exchange with
815         a Diffie-Hellman proposal and KEi in the group that the
816         responder gave in the INVALID_KE_PAYLOAD.
817
818    NEW-1.3.1 Creating New CHILD_SAs with the CREATE_CHILD_SA Exchange
819
820         A CHILD_SA may be created by sending a CREATE_CHILD_SA request.
821         The CREATE_CHILD_SA request for creating a new CHILD_SA is:
822
823             Initiator                                 Responder
824            -----------                               -----------
825             HDR, SK {[N+], SA, Ni, [KEi],
826                        TSi, TSr}        -->
827
828         The initiator sends SA offer(s) in the SA payload, a nonce in
829         the Ni payload, optionally a Diffie-Hellman value in the KEi
830         payload, and the proposed traffic selectors for the proposed
831         CHILD_SA in the TSi and TSr payloads.  The request can also
832         contain Notify payloads that specify additional details for the
833         CHILD_SA: these include IPCOMP_SUPPORTED, USE_TRANSPORT_MODE,
834         ESP_TFC_PADDING_NOT_SUPPORTED, and NON_FIRST_FRAGMENTS_ALSO.
835
836
837
838
839
840
841
842 Eronen & Hoffman             Informational                     [Page 15]
843 \f
844 RFC 4718                  IKEv2 Clarifications              October 2006
845
846
847         The CREATE_CHILD_SA response for creating a new CHILD_SA is:
848
849                                        <--    HDR, SK {[N+], SA, Nr,
850                                                     [KEr], TSi, TSr}
851
852         The responder replies with the accepted offer in an SA payload,
853         and a Diffie-Hellman value in the KEr payload if KEi was
854         included in the request and the selected cryptographic suite
855         includes that group.  As with the request, optional Notification
856         payloads can specify additional details for the CHILD_SA.
857
858         The traffic selectors for traffic to be sent on that SA are
859         specified in the TS payloads in the response, which may be a
860         subset of what the initiator of the CHILD_SA proposed.
861
862    The text about rekeying SAs can be found in Section 5.1 of this
863    document.
864
865 4.2.  Creating an IKE_SA without a CHILD_SA
866
867    CHILD_SAs can be created either by being piggybacked on the IKE_AUTH
868    exchange, or using a separate CREATE_CHILD_SA exchange.  The
869    specification is not clear about what happens if creating the
870    CHILD_SA during the IKE_AUTH exchange fails for some reason.
871
872    Our recommendation in this situation is that the IKE_SA is created as
873    usual.  This is also in line with how the CREATE_CHILD_SA exchange
874    works: a failure to create a CHILD_SA does not close the IKE_SA.
875
876    The list of responses in the IKE_AUTH exchange that do not prevent an
877    IKE_SA from being set up include at least the following:
878    NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED,
879    INTERNAL_ADDRESS_FAILURE, and FAILED_CP_REQUIRED.
880
881    (References: "Questions about internal address" thread, April 2005.)
882
883 4.3.  Diffie-Hellman for First CHILD_SA
884
885    Section 1.2 shows that IKE_AUTH messages do not contain KEi/KEr or
886    Ni/Nr payloads.  This implies that the SA payload in IKE_AUTH
887    exchange cannot contain Transform Type 4 (Diffie-Hellman Group) with
888    any other value than NONE.  Implementations should probably leave the
889    transform out entirely in this case.
890
891
892
893
894
895
896
897
898 Eronen & Hoffman             Informational                     [Page 16]
899 \f
900 RFC 4718                  IKEv2 Clarifications              October 2006
901
902
903 4.4.  Extended Sequence Numbers (ESN) Transform
904
905    The description of the ESN transform in Section 3.3 has be proved
906    difficult to understand.  The ESN transform has the following
907    meaning:
908
909    o  A proposal containing one ESN transform with value 0 means "do not
910       use extended sequence numbers".
911
912    o  A proposal containing one ESN transform with value 1 means "use
913       extended sequence numbers".
914
915    o  A proposal containing two ESN transforms with values 0 and 1 means
916       "I support both normal and extended sequence numbers, you choose".
917       (Obviously this case is only allowed in requests; the response
918       will contain only one ESN transform.)
919
920    In most cases, the exchange initiator will include either the first
921    or third alternative in its SA payload.  The second alternative is
922    rarely useful for the initiator: it means that using normal sequence
923    numbers is not acceptable (so if the responder does not support ESNs,
924    the exchange will fail with NO_PROPOSAL_CHOSEN).
925
926    Note that including the ESN transform is mandatory when creating
927    ESP/AH SAs (it was optional in earlier drafts of the IKEv2
928    specification).
929
930    (References: "Technical change needed to IKEv2 before publication",
931    "STRAW POLL: Dealing with the ESN negotiation interop issue in IKEv2"
932    and "Results of straw poll regarding: IKEv2 interoperability issue"
933    threads, March-April 2005.)
934
935 4.5.  Negotiation of ESP_TFC_PADDING_NOT_SUPPORTED
936
937    The description of ESP_TFC_PADDING_NOT_SUPPORTED notification in
938    Section 3.10.1 says that "This notification asserts that the sending
939    endpoint will NOT accept packets that contain Flow Confidentiality
940    (TFC) padding".
941
942    However, the text does not say in which messages this notification
943    should be included, or whether the scope of this notification is a
944    single CHILD_SA or all CHILD_SAs of the peer.
945
946    Our interpretation is that the scope is a single CHILD_SA, and thus
947    this notification is included in messages containing an SA payload
948    negotiating a CHILD_SA.  If neither endpoint accepts TFC padding,
949    this notification will be included in both the request proposing an
950    SA and the response accepting it.  If this notification is included
951
952
953
954 Eronen & Hoffman             Informational                     [Page 17]
955 \f
956 RFC 4718                  IKEv2 Clarifications              October 2006
957
958
959    in only one of the messages, TFC padding can still be sent in one
960    direction.
961
962 4.6.  Negotiation of NON_FIRST_FRAGMENTS_ALSO
963
964    NON_FIRST_FRAGMENTS_ALSO notification is described in Section 3.10.1
965    simply as "Used for fragmentation control.  See [RFC4301] for
966    explanation."
967
968    [RFC4301] says "Implementations that will transmit non-initial
969    fragments on a tunnel mode SA that makes use of non-trivial port (or
970    ICMP type/code or MH type) selectors MUST notify a peer via the IKE
971    NOTIFY NON_FIRST_FRAGMENTS_ALSO payload.  The peer MUST reject this
972    proposal if it will not accept non-initial fragments in this context.
973    If an implementation does not successfully negotiate transmission of
974    non-initial fragments for such an SA, it MUST NOT send such fragments
975    over the SA."
976
977    However, it is not clear exactly how the negotiation works.  Our
978    interpretation is that the negotiation works the same way as for
979    IPCOMP_SUPPORTED and USE_TRANSPORT_MODE: sending non-first fragments
980    is enabled only if NON_FIRST_FRAGMENTS_ALSO notification is included
981    in both the request proposing an SA and the response accepting it.
982    In other words, if the peer "rejects this proposal", it only omits
983    NON_FIRST_FRAGMENTS_ALSO notification from the response, but does not
984    reject the whole CHILD_SA creation.
985
986 4.7.  Semantics of Complex Traffic Selector Payloads
987
988    As described in Section 3.13, the TSi/TSr payloads can include one or
989    more individual traffic selectors.
990
991    There is no requirement that TSi and TSr contain the same number of
992    individual traffic selectors.  Thus, they are interpreted as follows:
993    a packet matches a given TSi/TSr if it matches at least one of the
994    individual selectors in TSi, and at least one of the individual
995    selectors in TSr.
996
997    For instance, the following traffic selectors:
998
999         TSi = ((17, 100, 192.0.1.66-192.0.1.66),
1000                (17, 200, 192.0.1.66-192.0.1.66))
1001         TSr = ((17, 300, 0.0.0.0-255.255.255.255),
1002                (17, 400, 0.0.0.0-255.255.255.255))
1003
1004    would match UDP packets from 192.0.1.66 to anywhere, with any of the
1005    four combinations of source/destination ports (100,300), (100,400),
1006    (200,300), and (200, 400).
1007
1008
1009
1010 Eronen & Hoffman             Informational                     [Page 18]
1011 \f
1012 RFC 4718                  IKEv2 Clarifications              October 2006
1013
1014
1015    This implies that some types of policies may require several CHILD_SA
1016    pairs.  For instance, a policy matching only source/destination ports
1017    (100,300) and (200,400), but not the other two combinations, cannot
1018    be negotiated as a single CHILD_SA pair using IKEv2.
1019
1020    (References: "IKEv2 Traffic Selectors?" thread, Feb 2005.)
1021
1022 4.8.  ICMP Type/Code in Traffic Selector Payloads
1023
1024    The traffic selector types 7 and 8 can also refer to ICMP type and
1025    code fields.  As described in Section 3.13.1, "For the ICMP protocol,
1026    the two one-octet fields Type and Code are treated as a single 16-bit
1027    integer (with Type in the most significant eight bits and Code in the
1028    least significant eight bits) port number for the purposes of
1029    filtering based on this field."
1030
1031    Since ICMP packets do not have separate source and destination port
1032    fields, there is some room for confusion what exactly the four TS
1033    payloads (two in the request, two in the response, each containing
1034    both start and end port fields) should contain.
1035
1036    The answer to this question can be found from [RFC4301] Section
1037    4.4.1.3.
1038
1039    To give a concrete example, if a host at 192.0.1.234 wants to create
1040    a transport mode SA for sending "Destination Unreachable" packets
1041    (ICMPv4 type 3) to 192.0.2.155, but is not willing to receive them
1042    over this SA pair, the CREATE_CHILD_SA exchange would look like this:
1043
1044       Initiator                   Responder
1045      -----------                 -----------
1046       HDR, SK { N(USE_TRANSPORT_MODE), SA, Ni,
1047                 TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
1048                 TSr(1, 65535-0, 192.0.2.155-192.0.2.155) } -->
1049
1050          <-- HDR, SK { N(USE_TRANSPORT_MODE), SA, Nr,
1051                        TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
1052                        TSr(1, 65535-0, 192.0.2.155-192.0.2.155) }
1053
1054    Since IKEv2 always creates IPsec SAs in pairs, two SAs are also
1055    created in this case, even though the second SA is never used for
1056    data traffic.
1057
1058    An exchange creating an SA pair that can be used both for sending and
1059    receiving "Destination Unreachable" places the same value in all the
1060    port:
1061
1062
1063
1064
1065
1066 Eronen & Hoffman             Informational                     [Page 19]
1067 \f
1068 RFC 4718                  IKEv2 Clarifications              October 2006
1069
1070
1071       Initiator                   Responder
1072      -----------                 -----------
1073       HDR, SK { N(USE_TRANSPORT_MODE), SA, Ni,
1074                 TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
1075                 TSr(1, 0x0300-0x03FF, 192.0.2.155-192.0.2.155) } -->
1076
1077          <-- HDR, SK { N(USE_TRANSPORT_MODE), SA, Nr,
1078                        TSi(1, 0x0300-0x03FF, 192.0.1.234-192.0.1.234),
1079                        TSr(1, 0x0300-0x03FF, 192.0.2.155-192.0.2.155) }
1080
1081    (References: "ICMP and MH TSs for IKEv2" thread, Sep 2005.)
1082
1083 4.9.  Mobility Header in Traffic Selector Payloads
1084
1085    Traffic selectors can use IP Protocol ID 135 to match the IPv6
1086    mobility header [MIPv6].  However, the IKEv2 specification does not
1087    define how to represent the "MH Type" field in traffic selectors.
1088
1089    At some point, it was expected that this will be defined in a
1090    separate document later.  However, [RFC4301] says that "For IKE, the
1091    IPv6 mobility header message type (MH type) is placed in the most
1092    significant eight bits of the 16 bit local "port" selector".  The
1093    direction semantics of TSi/TSr port fields are the same as for ICMP
1094    and are described in the previous section.
1095
1096    (References: Tero Kivinen's mail "Issue #86: Add IPv6 mobility header
1097    message type as selector", 2003-10-14.  "ICMP and MH TSs for IKEv2"
1098    thread, Sep 2005.)
1099
1100 4.10.  Narrowing the Traffic Selectors
1101
1102    Section 2.9 describes how traffic selectors are negotiated when
1103    creating a CHILD_SA.  A more concise summary of the narrowing process
1104    is presented below.
1105
1106    o  If the responder's policy does not allow any part of the traffic
1107       covered by TSi/TSr, it responds with TS_UNACCEPTABLE.
1108
1109    o  If the responder's policy allows the entire set of traffic covered
1110       by TSi/TSr, no narrowing is necessary, and the responder can
1111       return the same TSi/TSr values.
1112
1113    o  Otherwise, narrowing is needed.  If the responder's policy allows
1114       all traffic covered by TSi[1]/TSr[1] (the first traffic selectors
1115       in TSi/TSr) but not entire TSi/TSr, the responder narrows to an
1116       acceptable subset of TSi/TSr that includes TSi[1]/TSr[1].
1117
1118
1119
1120
1121
1122 Eronen & Hoffman             Informational                     [Page 20]
1123 \f
1124 RFC 4718                  IKEv2 Clarifications              October 2006
1125
1126
1127    o  If the responder's policy does not allow all traffic covered by
1128       TSi[1]/TSr[1], but does allow some parts of TSi/TSr, it narrows to
1129       an acceptable subset of TSi/TSr.
1130
1131    In the last two cases, there may be several subsets that are
1132    acceptable (but their union is not); in this case, the responder
1133    arbitrarily chooses one of them and includes ADDITIONAL_TS_POSSIBLE
1134    notification in the response.
1135
1136 4.11.  SINGLE_PAIR_REQUIRED
1137
1138    The description of the SINGLE_PAIR_REQUIRED notify payload in
1139    Sections 2.9 and 3.10.1 is not fully consistent.
1140
1141    We do not attempt to describe this payload in this document either,
1142    since it is expected that most implementations will not have policies
1143    that require separate SAs for each address pair.
1144
1145    Thus, if only some part (or parts) of the TSi/TSr proposed by the
1146    initiator is (are) acceptable to the responder, most responders
1147    should simply narrow TSi/TSr to an acceptable subset (as described in
1148    the last two paragraphs of Section 2.9), rather than use
1149    SINGLE_PAIR_REQUIRED.
1150
1151 4.12.  Traffic Selectors Violating Own Policy
1152
1153    Section 2.9 describes traffic selector negotiation in great detail.
1154    One aspect of this negotiation that may need some clarification is
1155    that when creating a new SA, the initiator should not propose traffic
1156    selectors that violate its own policy.  If this rule is not followed,
1157    valid traffic may be dropped.
1158
1159    This is best illustrated by an example.  Suppose that host A has a
1160    policy whose effect is that traffic to 192.0.1.66 is sent via host B
1161    encrypted using Advanced Encryption Standard (AES), and traffic to
1162    all other hosts in 192.0.1.0/24 is also sent via B, but encrypted
1163    using Triple Data Encryption Standard (3DES).  Suppose also that host
1164    B accepts any combination of AES and 3DES.
1165
1166    If host A now proposes an SA that uses 3DES, and includes TSr
1167    containing (192.0.1.0-192.0.1.0.255), this will be accepted by host
1168    B.  Now, host B can also use this SA to send traffic from 192.0.1.66,
1169    but those packets will be dropped by A since it requires the use of
1170    AES for those traffic.  Even if host A creates a new SA only for
1171    192.0.1.66 that uses AES, host B may freely continue to use the first
1172    SA for the traffic.  In this situation, when proposing the SA, host A
1173    should have followed its own policy, and included a TSr containing
1174    ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead.
1175
1176
1177
1178 Eronen & Hoffman             Informational                     [Page 21]
1179 \f
1180 RFC 4718                  IKEv2 Clarifications              October 2006
1181
1182
1183    In general, if (1) the initiator makes a proposal "for traffic X
1184    (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator
1185    does not actually accept traffic X' with SA, and (3) the initiator
1186    would be willing to accept traffic X' with some SA' (!=SA), valid
1187    traffic can be unnecessarily dropped since the responder can apply
1188    either SA or SA' to traffic X'.
1189
1190    (References: "Question about "narrowing" ..." thread, Feb 2005.
1191    "IKEv2 needs a "policy usage mode"..." thread, Feb 2005.  "IKEv2
1192    Traffic Selectors?" thread, Feb 2005.  "IKEv2 traffic selector
1193    negotiation examples", 2004-08-08.)
1194
1195 4.13.  Traffic Selector Authorization
1196
1197    IKEv2 relies on information in the Peer Authorization Database (PAD)
1198    when determining what kind of IPsec SAs a peer is allowed to create.
1199    This process is described in [RFC4301] Section 4.4.3.  When a peer
1200    requests the creation of an IPsec SA with some traffic selectors, the
1201    PAD must contain "Child SA Authorization Data" linking the identity
1202    authenticated by IKEv2 and the addresses permitted for traffic
1203    selectors.
1204
1205    For example, the PAD might be configured so that authenticated
1206    identity "sgw23.example.com" is allowed to create IPsec SAs for
1207    192.0.2.0/24, meaning this security gateway is a valid
1208    "representative" for these addresses.  Host-to-host IPsec requires
1209    similar entries, linking, for example, "fooserver4.example.com" with
1210    192.0.1.66/32, meaning this identity a valid "owner" or
1211    "representative" of the address in question.
1212
1213    As noted in [RFC4301], "It is necessary to impose these constraints
1214    on creation of child SAs to prevent an authenticated peer from
1215    spoofing IDs associated with other, legitimate peers."  In the
1216    example given above, a correct configuration of the PAD prevents
1217    sgw23 from creating IPsec SAs with address 192.0.1.66 and prevents
1218    fooserver4 from creating IPsec SAs with addresses from 192.0.2.0/24.
1219
1220    It is important to note that simply sending IKEv2 packets using some
1221    particular address does not imply a permission to create IPsec SAs
1222    with that address in the traffic selectors.  For example, even if
1223    sgw23 would be able to spoof its IP address as 192.0.1.66, it could
1224    not create IPsec SAs matching fooserver4's traffic.
1225
1226    The IKEv2 specification does not specify how exactly IP address
1227    assignment using configuration payloads interacts with the PAD.  Our
1228    interpretation is that when a security gateway assigns an address
1229
1230
1231
1232
1233
1234 Eronen & Hoffman             Informational                     [Page 22]
1235 \f
1236 RFC 4718                  IKEv2 Clarifications              October 2006
1237
1238
1239    using configuration payloads, it also creates a temporary PAD entry
1240    linking the authenticated peer identity and the newly allocated inner
1241    address.
1242
1243    It has been recognized that configuring the PAD correctly may be
1244    difficult in some environments.  For instance, if IPsec is used
1245    between a pair of hosts whose addresses are allocated dynamically
1246    using Dynamic Host Configuration Protocol (DHCP), it is extremely
1247    difficult to ensure that the PAD specifies the correct "owner" for
1248    each IP address.  This would require a mechanism to securely convey
1249    address assignments from the DHCP server and link them to identities
1250    authenticated using IKEv2.
1251
1252    Due to this limitation, some vendors have been known to configure
1253    their PADs to allow an authenticated peer to create IPsec SAs with
1254    traffic selectors containing the same address that was used for the
1255    IKEv2 packets.  In environments where IP spoofing is possible (i.e.,
1256    almost everywhere) this essentially allows any peer to create IPsec
1257    SAs with any traffic selectors.  This is not an appropriate or secure
1258    configuration in most circumstances.  See [Aura05] for an extensive
1259    discussion about this issue, and the limitations of host-to-host
1260    IPsec in general.
1261
1262 5.  Rekeying and Deleting SAs
1263
1264 5.1.  Rekeying SAs with the CREATE_CHILD_SA Exchange
1265
1266    Continued from Section 4.1 of this document.
1267
1268  NEW-1.3.2 Rekeying IKE_SAs with the CREATE_CHILD_SA Exchange
1269
1270       The CREATE_CHILD_SA request for rekeying an IKE_SA is:
1271
1272           Initiator                                 Responder
1273          -----------                               -----------
1274           HDR, SK {SA, Ni, [KEi]} -->
1275
1276       The initiator sends SA offer(s) in the SA payload, a nonce in
1277       the Ni payload, and optionally a Diffie-Hellman value in the KEi
1278       payload.
1279
1280       The CREATE_CHILD_SA response for rekeying an IKE_SA is:
1281
1282                                      <--    HDR, SK {SA, Nr, [KEr]}
1283
1284
1285
1286
1287
1288
1289
1290 Eronen & Hoffman             Informational                     [Page 23]
1291 \f
1292 RFC 4718                  IKEv2 Clarifications              October 2006
1293
1294
1295       The responder replies (using the same Message ID to respond)
1296       with the accepted offer in an SA payload, a nonce in the Nr
1297       payload, and, optionally, a Diffie-Hellman value in the KEr
1298       payload.
1299
1300       The new IKE_SA has its message counters set to 0, regardless of
1301       what they were in the earlier IKE_SA.  The window size starts at
1302       1 for any new IKE_SA.  The new initiator and responder SPIs are
1303       supplied in the SPI fields of the SA payloads.
1304
1305  NEW-1.3.3 Rekeying CHILD_SAs with the CREATE_CHILD_SA Exchange
1306
1307       The CREATE_CHILD_SA request for rekeying a CHILD_SA is:
1308
1309           Initiator                                 Responder
1310          -----------                               -----------
1311           HDR, SK {N(REKEY_SA), [N+], SA,
1312               Ni, [KEi], TSi, TSr}  -->
1313
1314       The leading Notify payload of type REKEY_SA identifies the
1315       CHILD_SA being rekeyed, and it contains the SPI that the initiator
1316       expects in the headers of inbound packets.  In addition, the
1317       initiator sends SA offer(s) in the SA payload, a nonce in the Ni
1318       payload, optionally a Diffie-Hellman value in the KEi payload,
1319       and the proposed traffic selectors in the TSi and TSr payloads.
1320       The request can also contain Notify payloads that specify
1321       additional details for the CHILD_SA.
1322
1323       The CREATE_CHILD_SA response for rekeying a CHILD_SA is:
1324
1325                                      <--    HDR, SK {[N+], SA, Nr,
1326                                                   [KEr], TSi, TSr}
1327
1328       The responder replies with the accepted offer in an SA payload,
1329       and a Diffie-Hellman value in the KEr payload if KEi was
1330       included in the request and the selected cryptographic suite
1331       includes that group.
1332
1333       The traffic selectors for traffic to be sent on that SA are
1334       specified in the TS payloads in the response, which may be a
1335       subset of what the initiator of the CHILD_SA proposed.
1336
1337 5.2.  Rekeying the IKE_SA vs. Reauthentication
1338
1339    Rekeying the IKE_SA and reauthentication are different concepts in
1340    IKEv2.  Rekeying the IKE_SA establishes new keys for the IKE_SA and
1341    resets the Message ID counters, but it does not authenticate the
1342    parties again (no AUTH or EAP payloads are involved).
1343
1344
1345
1346 Eronen & Hoffman             Informational                     [Page 24]
1347 \f
1348 RFC 4718                  IKEv2 Clarifications              October 2006
1349
1350
1351    While rekeying the IKE_SA may be important in some environments,
1352    reauthentication (the verification that the parties still have access
1353    to the long-term credentials) is often more important.
1354
1355    IKEv2 does not have any special support for reauthentication.
1356    Reauthentication is done by creating a new IKE_SA from scratch (using
1357    IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify
1358    payloads), creating new CHILD_SAs within the new IKE_SA (without
1359    REKEY_SA notify payloads), and finally deleting the old IKE_SA (which
1360    deletes the old CHILD_SAs as well).
1361
1362    This means that reauthentication also establishes new keys for the
1363    IKE_SA and CHILD_SAs.  Therefore, while rekeying can be performed
1364    more often than reauthentication, the situation where "authentication
1365    lifetime" is shorter than "key lifetime" does not make sense.
1366
1367    While creation of a new IKE_SA can be initiated by either party
1368    (initiator or responder in the original IKE_SA), the use of EAP
1369    authentication and/or configuration payloads means in practice that
1370    reauthentication has to be initiated by the same party as the
1371    original IKE_SA.  IKEv2 base specification does not allow the
1372    responder to request reauthentication in this case; however, this
1373    functionality is added in [ReAuth].
1374
1375    (References: "Reauthentication in IKEv2" thread, Oct/Nov 2004.)
1376
1377 5.3.  SPIs When Rekeying the IKE_SA
1378
1379    Section 2.18 says that "New initiator and responder SPIs are supplied
1380    in the SPI fields".  This refers to the SPI fields in the Proposal
1381    structures inside the Security Association (SA) payloads, not the SPI
1382    fields in the IKE header.
1383
1384    (References: Tom Stiemerling's mail "Rekey IKE SA", 2005-01-24.
1385    Geoffrey Huang's reply, 2005-01-24.)
1386
1387 5.4.  SPI When Rekeying a CHILD_SA
1388
1389    Section 3.10.1 says that in REKEY_SA notifications, "The SPI field
1390    identifies the SA being rekeyed."
1391
1392    Since CHILD_SAs always exist in pairs, there are two different SPIs.
1393    The SPI placed in the REKEY_SA notification is the SPI the exchange
1394    initiator would expect in inbound ESP or AH packets (just as in
1395    Delete payloads).
1396
1397
1398
1399
1400
1401
1402 Eronen & Hoffman             Informational                     [Page 25]
1403 \f
1404 RFC 4718                  IKEv2 Clarifications              October 2006
1405
1406
1407 5.5.  Changing PRFs When Rekeying the IKE_SA
1408
1409    When rekeying the IKE_SA, Section 2.18 says that "SKEYSEED for the
1410    new IKE_SA is computed using SK_d from the existing IKE_SA as
1411    follows:
1412
1413       SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)"
1414
1415    If the old and new IKE_SA selected a different PRF, it is not totally
1416    clear which PRF should be used.
1417
1418    Since the rekeying exchange belongs to the old IKE_SA, it is the old
1419    IKE_SA's PRF that is used.  This also follows the principle that the
1420    same key (the old SK_d) should not be used with multiple
1421    cryptographic algorithms.
1422
1423    Note that this may work poorly if the new IKE_SA's PRF has a fixed
1424    key size, since the output of the PRF may not be of the correct size.
1425    This supports our opinion earlier in the document that the use of
1426    PRFs with a fixed key size is a bad idea.
1427
1428    (References: "Changing PRFs when rekeying the IKE_SA" thread, June
1429    2005.)
1430
1431 5.6.  Deleting vs. Closing SAs
1432
1433    The IKEv2 specification talks about "closing" and "deleting" SAs, but
1434    it is not always clear what exactly is meant.  However, other parts
1435    of the specification make it clear that when local state related to a
1436    CHILD_SA is removed, the SA must also be actively deleted with a
1437    Delete payload.
1438
1439    In particular, Section 2.4 says that "If an IKE endpoint chooses to
1440    delete CHILD_SAs, it MUST send Delete payloads to the other end
1441    notifying it of the deletion".  Section 1.4 also explains that "ESP
1442    and AH SAs always exist in pairs, with one SA in each direction.
1443    When an SA is closed, both members of the pair MUST be closed."
1444
1445 5.7.  Deleting a CHILD_SA Pair
1446
1447    Section 1.4 describes how to delete SA pairs using the Informational
1448    exchange: "To delete an SA, an INFORMATIONAL exchange with one or
1449    more delete payloads is sent listing the SPIs (as they would be
1450    expected in the headers of inbound packets) of the SAs to be deleted.
1451    The recipient MUST close the designated SAs."
1452
1453
1454
1455
1456
1457
1458 Eronen & Hoffman             Informational                     [Page 26]
1459 \f
1460 RFC 4718                  IKEv2 Clarifications              October 2006
1461
1462
1463    The "one or more delete payloads" phrase has caused some confusion.
1464    You never send delete payloads for the two sides of an SA in a single
1465    message.  If you have many SAs to delete at the same time (such as
1466    the nested example given in that paragraph), you include delete
1467    payloads for the inbound half of each SA in your Informational
1468    exchange.
1469
1470 5.8.  Deleting an IKE_SA
1471
1472    Since IKE_SAs do not exist in pairs, it is not totally clear what the
1473    response message should contain when the request deleted the IKE_SA.
1474
1475    Since there is no information that needs to be sent to the other side
1476    (except that the request was received), an empty Informational
1477    response seems like the most logical choice.
1478
1479    (References: "Question about delete IKE SA" thread, May 2005.)
1480
1481 5.9.  Who is the original initiator of IKE_SA
1482
1483    In the IKEv2 document, "initiator" refers to the party who initiated
1484    the exchange being described, and "original initiator" refers to the
1485    party who initiated the whole IKE_SA.  However, there is some
1486    potential for confusion because the IKE_SA can be rekeyed by either
1487    party.
1488
1489    To clear up this confusion, we propose that "original initiator"
1490    always refers to the party who initiated the exchange that resulted
1491    in the current IKE_SA.  In other words, if the "original responder"
1492    starts rekeying the IKE_SA, that party becomes the "original
1493    initiator" of the new IKE_SA.
1494
1495    (References: Paul Hoffman's mail "Original initiator in IKEv2",
1496    2005-04-21.)
1497
1498 5.10.  Comparing Nonces
1499
1500    Section 2.8 about rekeying says that "If redundant SAs are created
1501    though such a collision, the SA created with the lowest of the four
1502    nonces used in the two exchanges SHOULD be closed by the endpoint
1503    that created it."
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514 Eronen & Hoffman             Informational                     [Page 27]
1515 \f
1516 RFC 4718                  IKEv2 Clarifications              October 2006
1517
1518
1519    Here "lowest" uses an octet-by-octet (lexicographical) comparison
1520    (instead of, for instance, comparing the nonces as large integers).
1521    In other words, start by comparing the first octet; if they're equal,
1522    move to the next octet, and so on.  If you reach the end of one
1523    nonce, that nonce is the lower one.
1524
1525    (References: "IKEv2 rekeying question" thread, July 2005.)
1526
1527 5.11.  Exchange Collisions
1528
1529    Since IKEv2 exchanges can be initiated by both peers, it is possible
1530    that two exchanges affecting the same SA partly overlap.  This can
1531    lead to a situation where the SA state information is temporarily not
1532    synchronized, and a peer can receive a request it cannot process in a
1533    normal fashion.  Some of these corner cases are discussed in the
1534    specification, some are not.
1535
1536    Obviously, using a window size greater than one leads to infinitely
1537    more complex situations, especially if requests are processed out of
1538    order.  In this section, we concentrate on problems that can arise
1539    even with window size 1.
1540
1541    (References: "IKEv2: invalid SPI in DELETE payload" thread, Dec 2005/
1542    Jan 2006.  "Problem with exchanges collisions" thread, Dec 2005.)
1543
1544 5.11.1.  Simultaneous CHILD_SA Close
1545
1546    Probably the simplest case happens if both peers decide to close the
1547    same CHILD_SA pair at the same time:
1548
1549       Host A                      Host B
1550      --------                    --------
1551       send req1: D(SPIa) -->
1552                               <-- send req2: D(SPIb)
1553                               --> recv req1
1554                               <-- send resp1: ()
1555       recv resp1
1556       recv req2
1557       send resp2: () -->
1558                               --> recv resp2
1559
1560    This case is described in Section 1.4 and is handled by omitting the
1561    Delete payloads from the response messages.
1562
1563
1564
1565
1566
1567
1568
1569
1570 Eronen & Hoffman             Informational                     [Page 28]
1571 \f
1572 RFC 4718                  IKEv2 Clarifications              October 2006
1573
1574
1575 5.11.2.  Simultaneous IKE_SA Close
1576
1577    Both peers can also decide to close the IKE_SA at the same time.  The
1578    desired end result is obvious; however, in certain cases the final
1579    exchanges may not be fully completed.
1580
1581       Host A                      Host B
1582      --------                    --------
1583       send req1: D() -->
1584                               <-- send req2: D()
1585                               --> recv req1
1586
1587    At this point, host B should reply as usual (with empty Informational
1588    response), close the IKE_SA, and stop retransmitting req2.  This is
1589    because once host A receives resp1, it may not be able to reply any
1590    longer.  The situation is symmetric, so host A should behave the same
1591    way.
1592
1593       Host A                      Host B
1594      --------                    --------
1595                               <-- send resp1: ()
1596       send resp2: ()
1597
1598    Even if neither resp1 nor resp2 ever arrives, the end result is still
1599    correct: the IKE_SA is gone.  The same happens if host A never
1600    receives req2.
1601
1602 5.11.3.  Simultaneous CHILD_SA Rekeying
1603
1604    Another case that is described in the specification is simultaneous
1605    rekeying.  Section 2.8 says
1606
1607       "If the two ends have the same lifetime policies, it is possible
1608       that both will initiate a rekeying at the same time (which will
1609       result in redundant SAs).  To reduce the probability of this
1610       happening, the timing of rekeying requests SHOULD be jittered
1611       (delayed by a random amount of time after the need for rekeying is
1612       noticed).
1613
1614       This form of rekeying may temporarily result in multiple similar
1615       SAs between the same pairs of nodes.  When there are two SAs
1616       eligible to receive packets, a node MUST accept incoming packets
1617       through either SA.  If redundant SAs are created though such a
1618       collision, the SA created with the lowest of the four nonces used
1619       in the two exchanges SHOULD be closed by the endpoint that created
1620       it."
1621
1622
1623
1624
1625
1626 Eronen & Hoffman             Informational                     [Page 29]
1627 \f
1628 RFC 4718                  IKEv2 Clarifications              October 2006
1629
1630
1631    However, a better explanation on what impact this has on
1632    implementations is needed.  Assume that hosts A and B have an
1633    existing IPsec SA pair with SPIs (SPIa1,SPIb1), and both start
1634    rekeying it at the same time:
1635
1636       Host A                      Host B
1637      --------                    --------
1638       send req1: N(REKEY_SA,SPIa1),
1639          SA(..,SPIa2,..),Ni1,..  -->
1640                               <-- send req2: N(REKEY_SA,SPIb1),
1641                                      SA(..,SPIb2,..),Ni2,..
1642       recv req2 <--
1643
1644    At this point, A knows there is a simultaneous rekeying going on.
1645    However, it cannot yet know which of the exchanges will have the
1646    lowest nonce, so it will just note the situation and respond as
1647    usual.
1648
1649       send resp2: SA(..,SPIa3,..),Nr1,.. -->
1650                               --> recv req1
1651
1652    Now B also knows that simultaneous rekeying is going on.  Similarly
1653    as host A, it has to respond as usual.
1654
1655                               <-- send resp1: SA(..,SPIb3,..),Nr2,..
1656        recv resp1 <--
1657                               --> recv resp2
1658
1659    At this point, there are three CHILD_SA pairs between A and B (the
1660    old one and two new ones).  A and B can now compare the nonces.
1661    Suppose that the lowest nonce was Nr1 in message resp2; in this case,
1662    B (the sender of req2) deletes the redundant new SA, and A (the node
1663    that initiated the surviving rekeyed SA) deletes the old one.
1664
1665       send req3: D(SPIa1) -->
1666                               <-- send req4: D(SPIb2)
1667                               --> recv req3
1668                               <-- send resp4: D(SPIb1)
1669       recv req4 <--
1670       send resp4: D(SPIa3) -->
1671
1672    The rekeying is now finished.
1673
1674    However, there is a second possible sequence of events that can
1675    happen if some packets are lost in the network, resulting in
1676    retransmissions.  The rekeying begins as usual, but A's first packet
1677    (req1) is lost.
1678
1679
1680
1681
1682 Eronen & Hoffman             Informational                     [Page 30]
1683 \f
1684 RFC 4718                  IKEv2 Clarifications              October 2006
1685
1686
1687       Host A                      Host B
1688      --------                    --------
1689       send req1: N(REKEY_SA,SPIa1),
1690          SA(..,SPIa2,..),Ni1,..  -->  (lost)
1691                               <-- send req2: N(REKEY_SA,SPIb1),
1692                                      SA(..,SPIb2,..),Ni2,..
1693       recv req2 <--
1694       send resp2: SA(..,SPIa3,..),Nr1,.. -->
1695                               --> recv resp2
1696                               <-- send req3: D(SPIb1)
1697       recv req3 <--
1698       send resp3: D(SPIa1) -->
1699                               --> recv resp3
1700
1701    From B's point of view, the rekeying is now completed, and since it
1702    has not yet received A's req1, it does not even know that these was
1703    simultaneous rekeying.  However, A will continue retransmitting the
1704    message, and eventually it will reach B.
1705
1706       resend req1 -->
1707                                --> recv req1
1708
1709    What should B do in this point?  To B, it looks like A is trying to
1710    rekey an SA that no longer exists; thus failing the request with
1711    something non-fatal such as NO_PROPOSAL_CHOSEN seems like a
1712    reasonable approach.
1713
1714                                <-- send resp1: N(NO_PROPOSAL_CHOSEN)
1715       recv resp1 <--
1716
1717    When A receives this error, it already knows there was simultaneous
1718    rekeying, so it can ignore the error message.
1719
1720 5.11.4.  Simultaneous IKE_SA Rekeying
1721
1722    Probably the most complex case occurs when both peers try to rekey
1723    the IKE_SA at the same time.  Basically, the text in Section 2.8
1724    applies to this case as well; however, it is important to ensure that
1725    the CHILD_SAs are inherited by the right IKE_SA.
1726
1727    The case where both endpoints notice the simultaneous rekeying works
1728    the same way as with CHILD_SAs.  After the CREATE_CHILD_SA exchanges,
1729    three IKE_SAs exist between A and B; the one containing the lowest
1730    nonce inherits the CHILD_SAs.
1731
1732    However, there is a twist to the other case where one rekeying
1733    finishes first:
1734
1735
1736
1737
1738 Eronen & Hoffman             Informational                     [Page 31]
1739 \f
1740 RFC 4718                  IKEv2 Clarifications              October 2006
1741
1742
1743       Host A                      Host B
1744      --------                    --------
1745       send req1:
1746          SA(..,SPIa1,..),Ni1,.. -->
1747                               <-- send req2: SA(..,SPIb1,..),Ni2,..
1748                               --> recv req1
1749                               <-- send resp1: SA(..,SPIb2,..),Nr2,..
1750       recv resp1 <--
1751       send req3: D() -->
1752                               --> recv req3
1753
1754    At this point, host B sees a request to close the IKE_SA.  There's
1755    not much more to do than to reply as usual.  However, at this point
1756    host B should stop retransmitting req2, since once host A receives
1757    resp3, it will delete all the state associated with the old IKE_SA
1758    and will not be able to reply to it.
1759
1760                               <-- send resp3: ()
1761
1762 5.11.5.  Closing and Rekeying a CHILD_SA
1763
1764    A case similar to simultaneous rekeying can occur if one peer decides
1765    to close an SA and the other peer tries to rekey it:
1766
1767       Host A                      Host B
1768      --------                    --------
1769       send req1: D(SPIa) -->
1770                               <-- send req2: N(REKEY_SA,SPIb),SA,..
1771                               --> recv req1
1772
1773    At this point, host B notices that host A is trying to close an SA
1774    that host B is currently rekeying.  Replying as usual is probably the
1775    best choice:
1776
1777                               <-- send resp1: D(SPIb)
1778
1779    Depending on in which order req2 and resp1 arrive, host A sees either
1780    a request to rekey an SA that it is currently closing, or a request
1781    to rekey an SA that does not exist.  In both cases,
1782    NO_PROPOSAL_CHOSEN is probably fine.
1783
1784       recv req2
1785       recv resp1
1786       send resp2: N(NO_PROPOSAL_CHOSEN) -->
1787                               --> recv resp2
1788
1789
1790
1791
1792
1793
1794 Eronen & Hoffman             Informational                     [Page 32]
1795 \f
1796 RFC 4718                  IKEv2 Clarifications              October 2006
1797
1798
1799 5.11.6.  Closing a New CHILD_SA
1800
1801    Yet another case occurs when host A creates a CHILD_SA pair, but soon
1802    thereafter host B decides to delete it (possible because its policy
1803    changed):
1804
1805       Host A                      Host B
1806      --------                    --------
1807       send req1: [N(REKEY_SA,SPIa1)],
1808          SA(..,SPIa2,..),.. -->
1809                               --> recv req1
1810                        (lost) <-- send resp1: SA(..,SPIb2,..),..
1811
1812                               <-- send req2: D(SPIb2)
1813       recv req2
1814
1815    At this point, host A has not yet received message resp1 (and is
1816    retransmitting message req1), so it does not recognize SPIb in
1817    message req2.  What should host A do?
1818
1819    One option would be to reply with an empty Informational response.
1820    However, this same reply would also be sent if host A has received
1821    resp1, but has already sent a new request to delete the SA that was
1822    just created.  This would lead to a situation where the peers are no
1823    longer in sync about which SAs exist between them.  However, host B
1824    would eventually notice that the other half of the CHILD_SA pair has
1825    not been deleted.  Section 1.4 describes this case and notes that "a
1826    node SHOULD regard half-closed connections as anomalous and audit
1827    their existence should they persist", and continues that "if
1828    connection state becomes sufficiently messed up, a node MAY close the
1829    IKE_SA".
1830
1831    Another solution that has been proposed is to reply with an
1832    INVALID_SPI notification that contains SPIb.  This would explicitly
1833    tell host B that the SA was not deleted, so host B could try deleting
1834    it again later.  However, this usage is not part of the IKEv2
1835    specification and would not be in line with normal use of the
1836    INVALID_SPI notification where the data field contains the SPI the
1837    recipient of the notification would put in outbound packets.
1838
1839    Yet another solution would be to ignore req2 at this time and wait
1840    until we have received resp1.  However, this alternative has not been
1841    fully analyzed at this time; in general, ignoring valid requests is
1842    always a bit dangerous, because both endpoints could do it, leading
1843    to a deadlock.
1844
1845    This document recommends the first alternative.
1846
1847
1848
1849
1850 Eronen & Hoffman             Informational                     [Page 33]
1851 \f
1852 RFC 4718                  IKEv2 Clarifications              October 2006
1853
1854
1855 5.11.7.  Rekeying a New CHILD_SA
1856
1857    Yet another case occurs when a CHILD_SA is rekeyed soon after it has
1858    been created:
1859
1860       Host A                      Host B
1861      --------                    --------
1862       send req1: [N(REKEY_SA,SPIa1)],
1863          SA(..,SPIa2,..),..  -->
1864                        (lost) <-- send resp1: SA(..,SPIb2,..),..
1865
1866                               <-- send req2: N(REKEY_SA,SPIb2),
1867                                      SA(..,SPIb3,..),..
1868       recv req2 <--
1869
1870    To host A, this looks like a request to rekey an SA that does not
1871    exist.  Like in the simultaneous rekeying case, replying with
1872    NO_PROPOSAL_CHOSEN is probably reasonable:
1873
1874       send resp2: N(NO_PROPOSAL_CHOSEN) -->
1875       recv resp1
1876
1877 5.11.8.  Collisions with IKE_SA Rekeying
1878
1879    Another set of cases occurs when one peer starts rekeying the IKE_SA
1880    at the same time the other peer starts creating, rekeying, or closing
1881    a CHILD_SA.  Suppose that host B starts creating a CHILD_SA, and soon
1882    after, host A starts rekeying the IKE_SA:
1883
1884       Host A                      Host B
1885      --------                    --------
1886                               <-- send req1: SA,Ni1,TSi,TSr
1887       send req2: SA,Ni2,.. -->
1888                               --> recv req2
1889
1890    What should host B do at this point?  Replying as usual would seem
1891    like a reasonable choice:
1892
1893                               <-- send resp2: SA,Ni2,..
1894       recv resp2 <--
1895       send req3: D() -->
1896                               --> recv req3
1897
1898    Now, a problem arises: If host B now replies normally with an empty
1899    Informational response, this will cause host A to delete state
1900    associated with the IKE_SA.  This means host B should stop
1901    retransmitting req1.  However, host B cannot know whether or not host
1902    A has received req1.  If host A did receive it, it will move the
1903
1904
1905
1906 Eronen & Hoffman             Informational                     [Page 34]
1907 \f
1908 RFC 4718                  IKEv2 Clarifications              October 2006
1909
1910
1911    CHILD_SA to the new IKE_SA as usual, and the state information will
1912    then be out of sync.
1913
1914    It seems this situation is tricky to handle correctly.  Our proposal
1915    is as follows: if a host receives a request to rekey the IKE_SA when
1916    it has CHILD_SAs in "half-open" state (currently being created or
1917    rekeyed), it should reply with NO_PROPOSAL_CHOSEN.  If a host
1918    receives a request to create or rekey a CHILD_SA after it has started
1919    rekeying the IKE_SA, it should reply with NO_ADDITIONAL_SAS.
1920
1921    The case where CHILD_SAs are being closed is even worse.  Our
1922    recommendation is that if a host receives a request to rekey the
1923    IKE_SA when it has CHILD_SAs in "half-closed" state (currently being
1924    closed), it should reply with NO_PROPOSAL_CHOSEN.  And if a host
1925    receives a request to close a CHILD_SA after it has started rekeying
1926    the IKE_SA, it should reply with an empty Informational response.
1927    This ensures that at least the other peer will eventually notice that
1928    the CHILD_SA is still in "half-closed" state and will start a new
1929    IKE_SA from scratch.
1930
1931 5.11.9.  Closing and Rekeying the IKE_SA
1932
1933    The final case considered in this section occurs if one peer decides
1934    to close the IKE_SA while the other peer tries to rekey it.
1935
1936       Host A                      Host B
1937      --------                    --------
1938       send req1: SA(..,SPIa1,..),Ni1 -->
1939                               <-- send req2: D()
1940                               --> recv req1
1941       recv req2 <--
1942
1943    At this point, host B should probably reply with NO_PROPOSAL_CHOSEN,
1944    and host A should reply as usual, close the IKE_SA, and stop
1945    retransmitting req1.
1946
1947                               <-- send resp1: N(NO_PROPOSAL_CHOSEN)
1948       send resp2: ()
1949
1950    If host A wants to continue communication with B, it can now start a
1951    new IKE_SA.
1952
1953 5.11.10.  Summary
1954
1955    If a host receives a request to rekey:
1956
1957    o  a CHILD_SA pair that the host is currently trying to close: reply
1958       with NO_PROPOSAL_CHOSEN.
1959
1960
1961
1962 Eronen & Hoffman             Informational                     [Page 35]
1963 \f
1964 RFC 4718                  IKEv2 Clarifications              October 2006
1965
1966
1967    o  a CHILD_SA pair that the host is currently rekeying: reply as
1968       usual, but prepare to close redundant SAs later based on the
1969       nonces.
1970
1971    o  a CHILD_SA pair that does not exist: reply with
1972       NO_PROPOSAL_CHOSEN.
1973
1974    o  the IKE_SA, and the host is currently rekeying the IKE_SA: reply
1975       as usual, but prepare to close redundant SAs and move inherited
1976       CHILD_SAs later based on the nonces.
1977
1978    o  the IKE_SA, and the host is currently creating, rekeying, or
1979       closing a CHILD_SA: reply with NO_PROPOSAL_CHOSEN.
1980
1981    o  the IKE_SA, and the host is currently trying to close the IKE_SA:
1982       reply with NO_PROPOSAL_CHOSEN.
1983
1984    If a host receives a request to close:
1985
1986    o  a CHILD_SA pair that the host is currently trying to close: reply
1987       without Delete payloads.
1988
1989    o  a CHILD_SA pair that the host is currently rekeying: reply as
1990       usual, with Delete payload.
1991
1992    o  a CHILD_SA pair that does not exist: reply without Delete
1993       payloads.
1994
1995    o  the IKE_SA, and the host is currently rekeying the IKE_SA: reply
1996       as usual, and forget about our own rekeying request.
1997
1998    o  the IKE_SA, and the host is currently trying to close the IKE_SA:
1999       reply as usual, and forget about our own close request.
2000
2001    If a host receives a request to create or rekey a CHILD_SA when it is
2002    currently rekeying the IKE_SA: reply with NO_ADDITIONAL_SAS.
2003
2004    If a host receives a request to delete a CHILD_SA when it is
2005    currently rekeying the IKE_SA: reply without Delete payloads.
2006
2007 5.12.  Diffie-Hellman and Rekeying the IKE_SA
2008
2009    There has been some confusion whether doing a new Diffie-Hellman
2010    exchange is mandatory when the IKE_SA is rekeyed.
2011
2012    It seems that this case is allowed by the IKEv2 specification.
2013    Section 2.18 shows the Diffie-Hellman term (g^ir) in brackets.
2014    Section 3.3.3 does not contradict this when it says that including
2015
2016
2017
2018 Eronen & Hoffman             Informational                     [Page 36]
2019 \f
2020 RFC 4718                  IKEv2 Clarifications              October 2006
2021
2022
2023    the D-H transform is mandatory: although including the transform is
2024    mandatory, it can contain the value "NONE".
2025
2026    However, having the option to skip the Diffie-Hellman exchange when
2027    rekeying the IKE_SA does not add useful functionality to the
2028    protocol.  The main purpose of rekeying the IKE_SA is to ensure that
2029    the compromise of old keying material does not provide information
2030    about the current keys, or vice versa.  This requires performing the
2031    Diffie-Hellman exchange when rekeying.  Furthermore, it is likely
2032    that this option would have been removed from the protocol as
2033    unnecessary complexity had it been discussed earlier.
2034
2035    Given this, we recommend that implementations should have a hard-
2036    coded policy that requires performing a new Diffie-Hellman exchange
2037    when rekeying the IKE_SA.  In other words, the initiator should not
2038    propose the value "NONE" for the D-H transform, and the responder
2039    should not accept such a proposal.  This policy also implies that a
2040    successful exchange rekeying the IKE_SA always includes the KEi/KEr
2041    payloads.
2042
2043    (References: "Rekeying IKE_SAs with the CREATE_CHILD_SA exhange"
2044    thread, Oct 2005.  "Comments of
2045    draft-eronen-ipsec-ikev2-clarifications-02.txt" thread, Apr 2005.)
2046
2047 6.  Configuration Payloads
2048
2049 6.1.  Assigning IP Addresses
2050
2051    Section 2.9 talks about traffic selector negotiation and mentions
2052    that "In support of the scenario described in section 1.1.3, an
2053    initiator may request that the responder assign an IP address and
2054    tell the initiator what it is."
2055
2056    This sentence is correct, but its placement is slightly confusing.
2057    IKEv2 does allow the initiator to request assignment of an IP address
2058    from the responder, but this is done using configuration payloads,
2059    not traffic selector payloads.  An address in a TSi payload in a
2060    response does not mean that the responder has assigned that address
2061    to the initiator; it only means that if packets matching these
2062    traffic selectors are sent by the initiator, IPsec processing can be
2063    performed as agreed for this SA.  The TSi payload itself does not
2064    give the initiator permission to configure the initiator's TCP/IP
2065    stack with the address and use it as its source address.
2066
2067    In other words, IKEv2 does not have two different mechanisms for
2068    assigning addresses, but only one: configuration payloads.  In the
2069    scenario described in Section 1.1.3, both configuration and traffic
2070    selector payloads are usually included in the same message, and they
2071
2072
2073
2074 Eronen & Hoffman             Informational                     [Page 37]
2075 \f
2076 RFC 4718                  IKEv2 Clarifications              October 2006
2077
2078
2079    often contain the same information in the response message (see
2080    Section 6.3 of this document for some examples).  However, their
2081    semantics are still different.
2082
2083 6.2.  Requesting any INTERNAL_IP4/IP6_ADDRESS
2084
2085    When describing the INTERNAL_IP4/IP6_ADDRESS attributes, Section
2086    3.15.1 says that "In a request message, the address specified is a
2087    requested address (or zero if no specific address is requested)".
2088    The question here is whether "zero" means an address "0.0.0.0" or a
2089    zero-length string.
2090
2091    Earlier, the same section also says that "If an attribute in the
2092    CFG_REQUEST Configuration Payload is not zero-length, it is taken as
2093    a suggestion for that attribute".  Also, the table of configuration
2094    attributes shows that the length of INTERNAL_IP4_ADDRESS is either "0
2095    or 4 octets", and likewise, INTERNAL_IP6_ADDRESS is either "0 or 17
2096    octets".
2097
2098    Thus, if the client does not request a specific address, it includes
2099    a zero-length INTERNAL_IP4/IP6_ADDRESS attribute, not an attribute
2100    containing an all-zeroes address.  The example in 2.19 is thus
2101    incorrect, since it shows the attribute as
2102    "INTERNAL_ADDRESS(0.0.0.0)".
2103
2104    However, since the value is only a suggestion, implementations are
2105    recommended to ignore suggestions they do not accept; or in other
2106    words, to treat the same way a zero-length INTERNAL_IP4_ADDRESS,
2107    "0.0.0.0", and any other addresses the implementation does not
2108    recognize as a reasonable suggestion.
2109
2110 6.3.  INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET
2111
2112    Section 3.15.1 describes the INTERNAL_IP4_SUBNET as "The protected
2113    sub-networks that this edge-device protects.  This attribute is made
2114    up of two fields: the first is an IP address and the second is a
2115    netmask.  Multiple sub-networks MAY be requested.  The responder MAY
2116    respond with zero or more sub-network attributes."
2117    INTERNAL_IP6_SUBNET is defined in a similar manner.
2118
2119    This raises two questions: first, since this information is usually
2120    included in the TSr payload, what functionality does this attribute
2121    add?  And second, what does this attribute mean in CFG_REQUESTs?
2122
2123    For the first question, there seem to be two sensible
2124    interpretations.  Clearly TSr (in IKE_AUTH or CREATE_CHILD_SA
2125    response) indicates which subnets are accessible through the SA that
2126    was just created.
2127
2128
2129
2130 Eronen & Hoffman             Informational                     [Page 38]
2131 \f
2132 RFC 4718                  IKEv2 Clarifications              October 2006
2133
2134
2135    The first interpretation of the INTERNAL_IP4/6_SUBNET attributes is
2136    that they indicate additional subnets that can be reached through
2137    this gateway, but need a separate SA.  According to this
2138    interpretation, the INTERNAL_IP4/6_SUBNET attributes are useful
2139    mainly when they contain addresses not included in TSr.
2140
2141    The second interpretation is that the INTERNAL_IP4/6_SUBNET
2142    attributes express the gateway's policy about what traffic should be
2143    sent through the gateway.  The client can choose whether other
2144    traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is sent
2145    through the gateway or directly to the destination.  According to
2146    this interpretation, the attributes are useful mainly when TSr
2147    contains addresses not included in the INTERNAL_IP4/6_SUBNET
2148    attributes.
2149
2150    It turns out that these two interpretations are not incompatible, but
2151    rather two sides of the same principle: traffic to the addresses
2152    listed in the INTERNAL_IP4/6_SUBNET attributes should be sent via
2153    this gateway.  If there are no existing IPsec SAs whose traffic
2154    selectors cover the address in question, new SAs have to be created.
2155
2156    A couple of examples are given below.  For instance, if there are two
2157    subnets, 192.0.1.0/26 and 192.0.2.0/24, and the client's request
2158    contains the following:
2159
2160         CP(CFG_REQUEST) =
2161           INTERNAL_IP4_ADDRESS()
2162         TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
2163         TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)
2164
2165    Then a valid response could be the following (in which TSr and
2166    INTERNAL_IP4_SUBNET contain the same information):
2167
2168         CP(CFG_REPLY) =
2169           INTERNAL_IP4_ADDRESS(192.0.1.234)
2170           INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
2171           INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
2172         TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
2173         TSr = ((0, 0-65535, 192.0.1.0-192.0.1.63),
2174                (0, 0-65535, 192.0.2.0-192.0.2.255))
2175
2176    In these cases, the INTERNAL_IP4_SUBNET does not really carry any
2177    useful information.  Another possible reply would have been this:
2178
2179         CP(CFG_REPLY) =
2180           INTERNAL_IP4_ADDRESS(192.0.1.234)
2181           INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
2182           INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
2183
2184
2185
2186 Eronen & Hoffman             Informational                     [Page 39]
2187 \f
2188 RFC 4718                  IKEv2 Clarifications              October 2006
2189
2190
2191         TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
2192         TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)
2193
2194    This would mean that the client can send all its traffic through the
2195    gateway, but the gateway does not mind if the client sends traffic
2196    not included by INTERNAL_IP4_SUBNET directly to the destination
2197    (without going through the gateway).
2198
2199    A different situation arises if the gateway has a policy that
2200    requires the traffic for the two subnets to be carried in separate
2201    SAs.  Then a response like this would indicate to the client that if
2202    it wants access to the second subnet, it needs to create a separate
2203    SA:
2204
2205         CP(CFG_REPLY) =
2206           INTERNAL_IP4_ADDRESS(192.0.1.234)
2207           INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
2208           INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
2209         TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
2210         TSr = (0, 0-65535, 192.0.1.0-192.0.1.63)
2211
2212    INTERNAL_IP4_SUBNET can also be useful if the client's TSr included
2213    only part of the address space.  For instance, if the client requests
2214    the following:
2215
2216         CP(CFG_REQUEST) =
2217           INTERNAL_IP4_ADDRESS()
2218         TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
2219         TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)
2220
2221    Then the gateway's reply could be this:
2222
2223         CP(CFG_REPLY) =
2224           INTERNAL_IP4_ADDRESS(192.0.1.234)
2225           INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192)
2226           INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
2227         TSi = (0, 0-65535, 192.0.1.234-192.0.1.234)
2228         TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)
2229
2230    It is less clear what the attributes mean in CFG_REQUESTs, and
2231    whether other lengths than zero make sense in this situation (but for
2232    INTERNAL_IP6_SUBNET, zero length is not allowed at all!).  This
2233    document recommends that implementations should not include
2234    INTERNAL_IP4_SUBNET or INTERNAL_IP6_SUBNET attributes in
2235    CFG_REQUESTs.
2236
2237    For the IPv4 case, this document recommends using only netmasks
2238    consisting of some amount of "1" bits followed by "0" bits; for
2239
2240
2241
2242 Eronen & Hoffman             Informational                     [Page 40]
2243 \f
2244 RFC 4718                  IKEv2 Clarifications              October 2006
2245
2246
2247    instance, "255.0.255.0" would not be a valid netmask for
2248    INTERNAL_IP4_SUBNET.
2249
2250    It is also worthwhile to note that the contents of the INTERNAL_IP4/
2251    6_SUBNET attributes do not imply link boundaries.  For instance, a
2252    gateway providing access to a large company intranet using addresses
2253    from the 10.0.0.0/8 block can send a single INTERNAL_IP4_SUBNET
2254    attribute (10.0.0.0/255.0.0.0) even if the intranet has hundreds of
2255    routers and separate links.
2256
2257    (References: Tero Kivinen's mail "Intent of couple of attributes in
2258    Configuration Payload in IKEv2?", 2004-11-19.  Srinivasa Rao
2259    Addepalli's mail "INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET in
2260    IKEv2", 2004-09-10.  Yoav Nir's mail "Re: New I-D: IKEv2
2261    Clarifications and Implementation Guidelines", 2005-02-07.
2262    "Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread,
2263    April 2005.)
2264
2265 6.4.  INTERNAL_IP4_NETMASK
2266
2267    Section 3.15.1 defines the INTERNAL_IP4_NETMASK attribute and says
2268    that "The internal network's netmask.  Only one netmask is allowed in
2269    the request and reply messages (e.g., 255.255.255.0) and it MUST be
2270    used only with an INTERNAL_IP4_ADDRESS attribute".
2271
2272    However, it is not clear what exactly this attribute means, as the
2273    concept of "netmask" is not very well defined for point-to-point
2274    links (unlike multi-access links, where it means "you can reach hosts
2275    inside this netmask directly using layer 2, instead of sending
2276    packets via a router").  Even if the operating system's TCP/IP stack
2277    requires a netmask to be configured, for point-to-point links it
2278    could be just set to 255.255.255.255.  So, why is this information
2279    sent in IKEv2?
2280
2281    One possible interpretation would be that the host is given a whole
2282    block of IP addresses instead of a single address.  This is also what
2283    Framed-IP-Netmask does in [RADIUS], the IPCP "subnet mask" extension
2284    does in PPP [IPCPSubnet], and the prefix length in the IPv6 Framed-
2285    IPv6-Prefix attribute does in [RADIUS6].  However, nothing in the
2286    specification supports this interpretation, and discussions on the
2287    IPsec WG mailing list have confirmed it was not intended.  Section
2288    3.15.1 also says that multiple addresses are assigned using multiple
2289    INTERNAL_IP4/6_ADDRESS attributes.
2290
2291    Currently, this document's interpretation is the following:
2292    INTERNAL_IP4_NETMASK in a CFG_REPLY means roughly the same thing as
2293    INTERNAL_IP4_SUBNET containing the same information ("send traffic to
2294    these addresses through me"), but also implies a link boundary.  For
2295
2296
2297
2298 Eronen & Hoffman             Informational                     [Page 41]
2299 \f
2300 RFC 4718                  IKEv2 Clarifications              October 2006
2301
2302
2303    instance, the client could use its own address and the netmask to
2304    calculate the broadcast address of the link.  (Whether the gateway
2305    will actually deliver broadcast packets to other VPN clients and/or
2306    other nodes connected to this link is another matter.)
2307
2308    An empty INTERNAL_IP4_NETMASK attribute can be included in a
2309    CFG_REQUEST to request this information (although the gateway can
2310    send the information even when not requested).  However, it seems
2311    that non-empty values for this attribute do not make sense in
2312    CFG_REQUESTs.
2313
2314    Fortunately, Section 4 clearly says that a minimal implementation
2315    does not need to include or understand the INTERNAL_IP4_NETMASK
2316    attribute, and thus this document recommends that implementations
2317    should not use the INTERNAL_IP4_NETMASK attribute or assume that the
2318    other peer supports it.
2319
2320    (References: Charlie Kaufman's mail "RE: Proposed Last Call based
2321    revisions to IKEv2", 2004-05-27.  Email discussion with Tero Kivinen,
2322    Jan 2005.  Yoav Nir's mail "Re: New I-D: IKEv2 Clarifications and
2323    Implementation Guidelines", 2005-02-07.  "Clarifications open issue:
2324    INTERNAL_IP4_SUBNET/NETMASK" thread, April 2005.)
2325
2326 6.5.  Configuration Payloads for IPv6
2327
2328    IKEv2 also defines configuration payloads for IPv6.  However, they
2329    are based on the corresponding IPv4 payloads and do not fully follow
2330    the "normal IPv6 way of doing things".
2331
2332    A client can be assigned an IPv6 address using the
2333    INTERNAL_IP6_ADDRESS configuration payload.  A minimal exchange could
2334    look like this:
2335
2336         CP(CFG_REQUEST) =
2337           INTERNAL_IP6_ADDRESS()
2338           INTERNAL_IP6_DNS()
2339         TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
2340         TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
2341
2342         CP(CFG_REPLY) =
2343           INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
2344           INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
2345         TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)
2346         TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
2347
2348    In particular, IPv6 stateless autoconfiguration or router
2349    advertisement messages are not used; neither is neighbor discovery.
2350
2351
2352
2353
2354 Eronen & Hoffman             Informational                     [Page 42]
2355 \f
2356 RFC 4718                  IKEv2 Clarifications              October 2006
2357
2358
2359    The client can also send a non-empty INTERNAL_IP6_ADDRESS attribute
2360    in the CFG_REQUEST to request a specific address or interface
2361    identifier.  The gateway first checks if the specified address is
2362    acceptable, and if it is, returns that one.  If the address was not
2363    acceptable, the gateway will attempt to use the interface identifier
2364    with some other prefix; if even that fails, the gateway will select
2365    another interface identifier.
2366
2367    The INTERNAL_IP6_ADDRESS attribute also contains a prefix length
2368    field.  When used in a CFG_REPLY, this corresponds to the
2369    INTERNAL_IP4_NETMASK attribute in the IPv4 case (and indeed, was
2370    called INTERNAL_IP6_NETMASK in earlier versions of the IKEv2 draft).
2371    See the previous section for more details.
2372
2373    While this approach to configuring IPv6 addresses is reasonably
2374    simple, it has some limitations: IPsec tunnels configured using IKEv2
2375    are not fully-featured "interfaces" in the IPv6 addressing
2376    architecture [IPv6Addr] sense.  In particular, they do not
2377    necessarily have link-local addresses, and this may complicate the
2378    use of protocols that assume them, such as [MLDv2].  (Whether they
2379    are called "interfaces" in some particular operating system is a
2380    different issue.)
2381
2382    (References: "VPN remote host configuration IPv6 ?" thread, May 2004.
2383    "Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK" thread,
2384    April 2005.)
2385
2386 6.6.  INTERNAL_IP6_NBNS
2387
2388    Section 3.15.1 defines the INTERNAL_IP6_NBNS attribute for sending
2389    the IPv6 address of NetBIOS name servers.
2390
2391    However, NetBIOS is not defined for IPv6 and probably never will be.
2392    Thus, this attribute most likely does not make much sense.
2393
2394    (Pointed out by Bernard Aboba in the IP Configuration Security (ICOS)
2395    BoF at IETF62.)
2396
2397 6.7.  INTERNAL_ADDRESS_EXPIRY
2398
2399    Section 3.15.1 defines the INTERNAL_ADDRESS_EXPIRY attribute as
2400    "Specifies the number of seconds that the host can use the internal
2401    IP address.  The host MUST renew the IP address before this expiry
2402    time.  Only one of these attributes MAY be present in the reply."
2403
2404    Expiry times and explicit renewals are primarily useful in
2405    environments like DHCP, where the server cannot reliably know when
2406
2407
2408
2409
2410 Eronen & Hoffman             Informational                     [Page 43]
2411 \f
2412 RFC 4718                  IKEv2 Clarifications              October 2006
2413
2414
2415    the client has gone away.  However, in IKEv2 this is known, and the
2416    gateway can simply free the address when the IKE_SA is deleted.
2417
2418    Also, Section 4 says that supporting renewals is not mandatory.
2419    Given that this functionality is usually not needed, we recommend
2420    that gateways should not send the INTERNAL_ADDRESS_EXPIRY attribute.
2421    (And since this attribute does not seem to make much sense for
2422    CFG_REQUESTs, clients should not send it either.)
2423
2424    Note that according to Section 4, clients are required to understand
2425    INTERNAL_ADDRESS_EXPIRY if they receive it.  A minimum implementation
2426    would use the value to limit the lifetime of the IKE_SA.
2427
2428    (References: Tero Kivinen's mail "Comments of
2429    draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.
2430    "Questions about internal address" thread, April 2005.)
2431
2432 6.8.  Address Assignment Failures
2433
2434    If the responder encounters an error while attempting to assign an IP
2435    address to the initiator, it responds with an
2436    INTERNAL_ADDRESS_FAILURE notification as described in Section 3.10.1.
2437    However, there are some more complex error cases.
2438
2439    First, if the responder does not support configuration payloads at
2440    all, it can simply ignore all configuration payloads.  This type of
2441    implementation never sends INTERNAL_ADDRESS_FAILURE notifications.
2442    If the initiator requires the assignment of an IP address, it will
2443    treat a response without CFG_REPLY as an error.
2444
2445    A second case is where the responder does support configuration
2446    payloads, but only for particular type of addresses (IPv4 or IPv6).
2447    Section 4 says that "A minimal IPv4 responder implementation will
2448    ignore the contents of the CP payload except to determine that it
2449    includes an INTERNAL_IP4_ADDRESS attribute".  If, for instance, the
2450    initiator includes both INTERNAL_IP4_ADDRESS and INTERNAL_IP6_ADDRESS
2451    in the CFG_REQUEST, an IPv4-only responder can thus simply ignore the
2452    IPv6 part and process the IPv4 request as usual.
2453
2454    A third case is where the initiator requests multiple addresses of a
2455    type that the responder supports: what should happen if some (but not
2456    all) of the requests fail?  It seems that an optimistic approach
2457    would be the best one here: if the responder is able to assign at
2458    least one address, it replies with those; it sends
2459    INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned.
2460
2461    (References: "ikev2 and internal_ivpn_address" thread, June 2005.)
2462
2463
2464
2465
2466 Eronen & Hoffman             Informational                     [Page 44]
2467 \f
2468 RFC 4718                  IKEv2 Clarifications              October 2006
2469
2470
2471 7.  Miscellaneous Issues
2472
2473 7.1.  Matching ID_IPV4_ADDR and ID_IPV6_ADDR
2474
2475    When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr
2476    payloads, IKEv2 does not require this address to match anything in
2477    the TSi/TSr payloads.  For example, in a site-to-site VPN between two
2478    security gateways, the gateways could authenticate each other as
2479    ID_IPV4_ADDR(192.0.1.1) and ID_IPV4_ADDR(192.0.2.1), and then create
2480    a CHILD_SA for protecting traffic between 192.0.1.55/32 (a host
2481    behind the first security gateway) and 192.0.2.240/28 (a network
2482    behind the second security gateway).  The authenticated identities
2483    (IDi/IDr) are linked to the authorized traffic selectors (TSi/TSr)
2484    using "Child SA Authorization Data" in the Peer Authorization
2485    Database (PAD).
2486
2487    Furthermore, IKEv2 does not require that the addresses in
2488    ID_IPV4_ADDR/ID_IPV6_ADDR match the address in the IP header of the
2489    IKE packets.  However, other specifications may place additional
2490    requirements regarding this.  For example, [PKI4IPsec] requires that
2491    implementation must be capable of comparing the addresses in the
2492    ID_IPV4_ADDR/ID_IPV6_ADDR with the addresses in the IP header of the
2493    IKE packets, and this comparison must be enabled by default.
2494
2495    (References: "Identities types IP address,FQDN/user FQDN and DN and
2496    its usage in preshared key authentication" thread, Jan 2005.
2497    "Matching ID_IPV4_ADDR and ID_IPV6_ADDR" thread, May 2006.)
2498
2499 7.2.  Relationship of IKEv2 to RFC 4301
2500
2501    The IKEv2 specification refers to [RFC4301], but it never clearly
2502    defines the exact relationship.
2503
2504    However, there are some requirements in the specification that make
2505    it clear that IKEv2 requires [RFC4301].  In other words, an
2506    implementation that does IPsec processing strictly according to
2507    [RFC2401] cannot be compliant with the IKEv2 specification.
2508
2509    One such example can be found in Section 2.24: "Specifically, tunnel
2510    encapsulators and decapsulators for all tunnel-mode SAs created by
2511    IKEv2 [...]  MUST implement the tunnel encapsulation and
2512    decapsulation processing specified in [RFC4301] to prevent discarding
2513    of ECN congestion indications."
2514
2515    Nevertheless, the changes required to existing [RFC2401]
2516    implementations are not very large, especially since supporting many
2517    of the new features (such as Extended Sequence Numbers) is optional.
2518
2519
2520
2521
2522 Eronen & Hoffman             Informational                     [Page 45]
2523 \f
2524 RFC 4718                  IKEv2 Clarifications              October 2006
2525
2526
2527 7.3.  Reducing the Window Size
2528
2529    In IKEv2, the window size is assumed to be a (possibly configurable)
2530    property of a particular implementation and is not related to
2531    congestion control (unlike the window size in TCP, for instance).
2532
2533    In particular, it is not defined what the responder should do when it
2534    receives a SET_WINDOW_SIZE notification containing a smaller value
2535    than is currently in effect.  Thus, there is currently no way to
2536    reduce the window size of an existing IKE_SA.  However, when rekeying
2537    an IKE_SA, the new IKE_SA starts with window size 1 until it is
2538    explicitly increased by sending a new SET_WINDOW_SIZE notification.
2539
2540    (References: Tero Kivinen's mail "Comments of
2541    draft-eronen-ipsec-ikev2-clarifications-02.txt", 2005-04-05.)
2542
2543 7.4.  Minimum Size of Nonces
2544
2545    Section 2.10 says that "Nonces used in IKEv2 MUST be randomly chosen,
2546    MUST be at least 128 bits in size, and MUST be at least half the key
2547    size of the negotiated prf."
2548
2549    However, the initiator chooses the nonce before the outcome of the
2550    negotiation is known.  In this case, the nonce has to be long enough
2551    for all the PRFs being proposed.
2552
2553 7.5.  Initial Zero Octets on Port 4500
2554
2555    It is not clear whether a peer sending an IKE_SA_INIT request on port
2556    4500 should include the initial four zero octets.  Section 2.23 talks
2557    about how to upgrade to tunneling over port 4500 after message 2, but
2558    it does not say what to do if message 1 is sent on port 4500.
2559
2560        IKE MUST listen on port 4500 as well as port 500.
2561
2562        [...]
2563
2564        The IKE initiator MUST check these payloads if present and if
2565        they do not match the addresses in the outer packet MUST tunnel
2566        all future IKE and ESP packets associated with this IKE_SA over
2567        UDP port 4500.
2568
2569        To tunnel IKE packets over UDP port 4500, the IKE header has four
2570        octets of zero prepended and the result immediately follows the
2571        UDP header. [...]
2572
2573
2574
2575
2576
2577
2578 Eronen & Hoffman             Informational                     [Page 46]
2579 \f
2580 RFC 4718                  IKEv2 Clarifications              October 2006
2581
2582
2583    The very beginning of Section 2 says "... though IKE messages may
2584    also be received on UDP port 4500 with a slightly different format
2585    (see section 2.23)."
2586
2587    That "slightly different format" is only described in discussing what
2588    to do after changing to port 4500.  However, [RFC3948] shows clearly
2589    the format has the initial zeros even for initiators on port 4500.
2590    Furthermore, without the initial zeros, the processing engine cannot
2591    determine whether the packet is an IKE packet or an ESP packet.
2592
2593    Thus, all packets sent on port 4500 need the four-zero prefix;
2594    otherwise, the receiver won't know how to handle them.
2595
2596 7.6.  Destination Port for NAT Traversal
2597
2598    Section 2.23 says that "an IPsec endpoint that discovers a NAT
2599    between it and its correspondent MUST send all subsequent traffic to
2600    and from port 4500".
2601
2602    This sentence is misleading.  The peer "outside" the NAT uses source
2603    port 4500 for the traffic it sends, but the destination port is, of
2604    course, taken from packets sent by the peer behind the NAT.  This
2605    port number is usually dynamically allocated by the NAT.
2606
2607 7.7.  SPI Values for Messages outside an IKE_SA
2608
2609    The IKEv2 specification is not quite clear what SPI values should be
2610    used in the IKE header for the small number of notifications that are
2611    allowed to be sent outside an IKE_SA.  Note that such notifications
2612    are explicitly not Informational exchanges; Section 1.5 makes it
2613    clear that these are one-way messages that must not be responded to.
2614
2615    There are two cases when such a one-way notification can be sent:
2616    INVALID_IKE_SPI and INVALID_SPI.
2617
2618    In case of INVALID_IKE_SPI, the message sent is a response message,
2619    and Section 2.21 says that "If a response is sent, the response MUST
2620    be sent to the IP address and port from whence it came with the same
2621    IKE SPIs and the Message ID copied."
2622
2623    In case of INVALID_SPI, however, there are no IKE SPI values that
2624    would be meaningful to the recipient of such a notification.  Also,
2625    the message sent is now an INFORMATIONAL request.  A strict
2626    interpretation of the specification would require the sender to
2627    invent garbage values for the SPI fields.  However, we think this was
2628    not the intention, and using zero values is acceptable.
2629
2630    (References: "INVALID_IKE_SPI" thread, June 2005.)
2631
2632
2633
2634 Eronen & Hoffman             Informational                     [Page 47]
2635 \f
2636 RFC 4718                  IKEv2 Clarifications              October 2006
2637
2638
2639 7.8.  Protocol ID/SPI Fields in Notify Payloads
2640
2641    Section 3.10 says that the Protocol ID field in Notify payloads "For
2642    notifications that do not relate to an existing SA, this field MUST
2643    be sent as zero and MUST be ignored on receipt".  However, the
2644    specification does not clearly say which notifications are related to
2645    existing SAs and which are not.
2646
2647    Since the main purpose of the Protocol ID field is to specify the
2648    type of the SPI, our interpretation is that the Protocol ID field
2649    should be non-zero only when the SPI field is non-empty.
2650
2651    There are currently only two notifications where this is the case:
2652    INVALID_SELECTORS and REKEY_SA.
2653
2654 7.9.  Which message should contain INITIAL_CONTACT
2655
2656    The description of the INITIAL_CONTACT notification in Section 3.10.1
2657    says that "This notification asserts that this IKE_SA is the only
2658    IKE_SA currently active between the authenticated identities".
2659    However, neither Section 2.4 nor 3.10.1 says in which message this
2660    payload should be placed.
2661
2662    The general agreement is that INITIAL_CONTACT is best communicated in
2663    the first IKE_AUTH request, not as a separate exchange afterwards.
2664
2665    (References: "Clarifying the use of INITIAL_CONTACT in IKEv2" thread,
2666    April 2005.  "Initial Contact messages" thread, December 2004.
2667    "IKEv2 and Initial Contact" thread, September 2004 and April 2005.)
2668
2669 7.10.  Alignment of Payloads
2670
2671    Many IKEv2 payloads contain fields marked as "RESERVED", mostly
2672    because IKEv1 had them, and partly because they make the pictures
2673    easier to draw.  In particular, payloads in IKEv2 are not, in
2674    general, aligned to 4-octet boundaries.  (Note that payloads were not
2675    aligned to 4-octet boundaries in IKEv1 either.)
2676
2677    (References: "IKEv2: potential 4-byte alignment problem" thread, June
2678    2004.)
2679
2680 7.11.  Key Length Transform Attribute
2681
2682    Section 3.3.5 says that "The only algorithms defined in this document
2683    that accept attributes are the AES based encryption, integrity, and
2684    pseudo-random functions, which require a single attribute specifying
2685    key width."
2686
2687
2688
2689
2690 Eronen & Hoffman             Informational                     [Page 48]
2691 \f
2692 RFC 4718                  IKEv2 Clarifications              October 2006
2693
2694
2695    This is incorrect.  The AES-based integrity and pseudo-random
2696    functions defined in [IKEv2] always use a 128-bit key.  In fact,
2697    there are currently no integrity or PRF algorithms that use the key
2698    length attribute (and we recommend that they should not be defined in
2699    the future either).
2700
2701    For encryption algorithms, the situation is slightly more complex
2702    since there are three different types of algorithms:
2703
2704    o  The key length attribute is never used with algorithms that use a
2705       fixed length key, such as DES and IDEA.
2706
2707    o  The key length attribute is always included for the currently
2708       defined AES-based algorithms (Cipher Block Chaining (CBC), Counter
2709       (CTR) Mode, Counter with CBC-MAC (CCM), and Galois/Counter Mode
2710       (GCM)).  Omitting the key length attribute is not allowed; if the
2711       proposal does not contain it, the proposal has to be rejected.
2712
2713    o  For other algorithms, the key length attribute can be included but
2714       is not mandatory.  These algorithms include, e.g., RC5, CAST, and
2715       BLOWFISH.  If the key length attribute is not included, the
2716       default value specified in [RFC2451] is used.
2717
2718 7.12.  IPsec IANA Considerations
2719
2720    There are currently three different IANA registry files that contain
2721    important numbers for IPsec: ikev2-registry, isakmp-registry, and
2722    ipsec-registry.  Implementers should note that IKEv2 may use numbers
2723    different from those of IKEv1 for a particular algorithm.
2724
2725    For instance, an encryption algorithm can have up to three different
2726    numbers: the IKEv2 "Transform Type 1" identifier in ikev2-registry,
2727    the IKEv1 phase 1 "Encryption Algorithm" identifier in ipsec-
2728    registry, and the IKEv1 phase 2 "IPSEC ESP Transform Identifier"
2729    isakmp-registry.  Although some algorithms have the same number in
2730    all three registries, the registries are not identical.
2731
2732    Similarly, an integrity algorithm can have at least the IKEv2
2733    "Transform Type 3" identifier in ikev2-registry, the IKEv1 phase 2
2734    "IPSEC AH Transform Identifier" in isakmp-registry, and the IKEv1
2735    phase 2 ESP "Authentication Algorithm Security Association Attribute"
2736    identifier in isakmp-registry.  And there is also the IKEv1 phase 1
2737    "Hash Algorithm" list in ipsec-registry.
2738
2739    This issue needs special care also when writing a specification for
2740    how a new algorithm is used with IPsec.
2741
2742
2743
2744
2745
2746 Eronen & Hoffman             Informational                     [Page 49]
2747 \f
2748 RFC 4718                  IKEv2 Clarifications              October 2006
2749
2750
2751 7.13.  Combining ESP and AH
2752
2753    The IKEv2 specification contains some misleading text about how ESP
2754    and AH can be combined.
2755
2756    IKEv2 is based on [RFC4301], which does not include "SA bundles" that
2757    were part of [RFC2401].  While a single packet can go through IPsec
2758    processing multiple times, each of these passes uses a separate SA,
2759    and the passes are coordinated by the forwarding tables.  In IKEv2,
2760    each of these SAs has to be created using a separate CREATE_CHILD_SA
2761    exchange.  Thus, the text in Section 2.7 about a single proposal
2762    containing both ESP and AH is incorrect.
2763
2764    Moreover, the combination of ESP and AH (between the same endpoints)
2765    had already become largely obsolete in 1998 when RFC 2406 was
2766    published.  Our recommendation is that IKEv2 implementations should
2767    not support this combination, and implementers should not assume the
2768    combination can be made to work in an interoperable manner.
2769
2770    (References: "Rekeying SA bundles" thread, Oct 2005.)
2771
2772 8.  Implementation Mistakes
2773
2774    Some implementers at the early IKEv2 bakeoffs didn't do everything
2775    correctly.  This may seem like an obvious statement, but it is
2776    probably useful to list a few things that were clear in the document,
2777    but that some implementers didn't do.  All of these things caused
2778    interoperability problems.
2779
2780    o  Some implementations continued to send traffic on a CHILD_SA after
2781       it was rekeyed, even after receiving an DELETE payload.
2782
2783    o  After rekeying an IKE_SA, some implementations did not reset their
2784       message counters to zero.  One set the counter to 2, another did
2785       not reset the counter at all.
2786
2787    o  Some implementations could only handle a single pair of traffic
2788       selectors or would only process the first pair in the proposal.
2789
2790    o  Some implementations responded to a delete request by sending an
2791       empty INFORMATIONAL response and then initiated their own
2792       INFORMATIONAL exchange with the pair of SAs to delete.
2793
2794    o  Although this did not happen at the bakeoff, from the discussion
2795       there, it is clear that some people had not implemented message
2796       window sizes correctly.  Some implementations might have sent
2797
2798
2799
2800
2801
2802 Eronen & Hoffman             Informational                     [Page 50]
2803 \f
2804 RFC 4718                  IKEv2 Clarifications              October 2006
2805
2806
2807       messages that did not fit into the responder's message windows,
2808       and some implementations may not have torn down an SA if they did
2809       not ever receive a message that they know they should have.
2810
2811 9.  Security Considerations
2812
2813    This document does not introduce any new security considerations to
2814    IKEv2.  If anything, clarifying complex areas of the specification
2815    can reduce the likelihood of implementation problems that may have
2816    security implications.
2817
2818 10.  Acknowledgments
2819
2820    This document is mainly based on conversations on the IPsec WG
2821    mailing list.  The authors would especially like to thank Bernard
2822    Aboba, Jari Arkko, Vijay Devarapalli, William Dixon, Francis Dupont,
2823    Alfred Hoenes, Mika Joutsenvirta, Charlie Kaufman, Stephen Kent, Tero
2824    Kivinen, Yoav Nir, Michael Richardson, and Joel Snyder for their
2825    contributions.
2826
2827    In addition, the authors would like to thank all the participants of
2828    the first public IKEv2 bakeoff, held in Santa Clara in February 2005,
2829    for their questions and proposed clarifications.
2830
2831 11.  References
2832
2833 11.1.  Normative References
2834
2835    [IKEv2]       Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
2836                  Protocol", RFC 4306, December 2005.
2837
2838    [IKEv2ALG]    Schiller, J., "Cryptographic Algorithms for Use in the
2839                  Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
2840                  December 2005.
2841
2842    [PKCS1v20]    Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
2843                  Specifications Version 2.0", RFC 2437, October 1998.
2844
2845    [PKCS1v21]    Jonsson, J. and B. Kaliski, "Public-Key Cryptography
2846                  Standards (PKCS) #1: RSA Cryptography Specifications
2847                  Version 2.1", RFC 3447, February 2003.
2848
2849    [RFC2401]     Kent, S. and R. Atkinson, "Security Architecture for
2850                  the Internet Protocol", RFC 2401, November 1998.
2851
2852    [RFC4301]     Kent, S. and K. Seo, "Security Architecture for the
2853                  Internet Protocol", RFC 4301, December 2005.
2854
2855
2856
2857
2858 Eronen & Hoffman             Informational                     [Page 51]
2859 \f
2860 RFC 4718                  IKEv2 Clarifications              October 2006
2861
2862
2863 11.2.  Informative References
2864
2865    [Aura05]      Aura, T., Roe, M., and A. Mohammed, "Experiences with
2866                  Host-to-Host IPsec", 13th International Workshop on
2867                  Security Protocols, Cambridge, UK, April 2005.
2868
2869    [EAP]         Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
2870                  H. Levkowetz, "Extensible Authentication Protocol
2871                  (EAP)", RFC 3748, June 2004.
2872
2873    [HashUse]     Hoffman, P., "Use of Hash Algorithms in IKE and IPsec",
2874                  Work in Progress, July 2006.
2875
2876    [IPCPSubnet]  Cisco Systems, Inc., "IPCP Subnet Mask Support
2877                  Enhancements",  http://www.cisco.com/univercd/cc/td/
2878                  doc/product/software/ios121/121newft/121limit/121dc/
2879                  121dc3/ipcp_msk.htm, January 2003.
2880
2881    [IPv6Addr]    Hinden, R. and S. Deering, "IP Version 6 Addressing
2882                  Architecture", RFC 4291, February 2006.
2883
2884    [MIPv6]       Johnson, D., Perkins, C., and J. Arkko, "Mobility
2885                  Support in IPv6", RFC 3775, June 2004.
2886
2887    [MLDv2]       Vida, R. and L. Costa, "Multicast Listener Discovery
2888                  Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
2889
2890    [NAI]         Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
2891                  Network Access Identifier", RFC 4282, December 2005.
2892
2893    [PKI4IPsec]   Korver, B., "Internet PKI Profile of IKEv1/ISAKMP,
2894                  IKEv2, and PKIX", Work in Progress, April 2006.
2895
2896    [RADEAP]      Aboba, B. and P. Calhoun, "RADIUS (Remote
2897                  Authentication Dial In User Service) Support For
2898                  Extensible Authentication Protocol (EAP)", RFC 3579,
2899                  September 2003.
2900
2901    [RADIUS]      Rigney, C., Willens, S., Rubens, A., and W. Simpson,
2902                  "Remote Authentication Dial In User Service (RADIUS)",
2903                  RFC 2865, June 2000.
2904
2905    [RADIUS6]     Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6",
2906                  RFC 3162, August 2001.
2907
2908    [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
2909                  Requirement  Levels", RFC 2119, March 1997.
2910
2911
2912
2913
2914 Eronen & Hoffman             Informational                     [Page 52]
2915 \f
2916 RFC 4718                  IKEv2 Clarifications              October 2006
2917
2918
2919    [RFC2451]     Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
2920                  Algorithms", RFC 2451, November 1998.
2921
2922    [RFC2822]     Resnick, P., "Internet Message Format", RFC 2822,
2923                  April 2001.
2924
2925    [RFC3664]     Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
2926                  Internet Key Exchange Protocol (IKE)", RFC 3664,
2927                  January 2004.
2928
2929    [RFC3948]     Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and
2930                  M. Stenberg, "UDP Encapsulation of IPsec ESP Packets",
2931                  RFC 3948, January 2005.
2932
2933    [RFC4434]     Hoffman, P., "The AES-XCBC-PRF-128 Algorithm for the
2934                  Internet Key Exchange Protocol (IKE)", RFC 4434,
2935                  February 2006.
2936
2937    [RFC822]      Crocker, D., "Standard for the format of ARPA Internet
2938                  text messages", RFC 822, August 1982.
2939
2940    [ReAuth]      Nir, Y., "Repeated Authentication in Internet Key
2941                  Exchange (IKEv2) Protocol", RFC 4478, April 2006.
2942
2943    [SCVP]        Freeman, T., Housley, R., Malpani, A., Cooper, D., and
2944                  T. Polk, "Simple Certificate Validation Protocol
2945                  (SCVP)", Work in Progress, June 2006.
2946
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
2968
2969
2970 Eronen & Hoffman             Informational                     [Page 53]
2971 \f
2972 RFC 4718                  IKEv2 Clarifications              October 2006
2973
2974
2975 Appendix A.  Exchanges and Payloads
2976
2977    This appendix contains a short summary of the IKEv2 exchanges, and
2978    what payloads can appear in which message.  This appendix is purely
2979    informative; if it disagrees with the body of this document or the
2980    IKEv2 specification, the other text is considered correct.
2981
2982    Vendor-ID (V) payloads may be included in any place in any message.
2983    This sequence shows what are, in our opinion, the most logical places
2984    for them.
2985
2986    The specification does not say which messages can contain
2987    N(SET_WINDOW_SIZE).  It can possibly be included in any message, but
2988    it is not yet shown below.
2989
2990 A.1.  IKE_SA_INIT Exchange
2991
2992    request             --> [N(COOKIE)],
2993                            SA, KE, Ni,
2994                            [N(NAT_DETECTION_SOURCE_IP)+,
2995                             N(NAT_DETECTION_DESTINATION_IP)],
2996                            [V+]
2997
2998    normal response     <-- SA, KE, Nr,
2999    (no cookie)             [N(NAT_DETECTION_SOURCE_IP),
3000                             N(NAT_DETECTION_DESTINATION_IP)],
3001                            [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
3002                            [V+]
3003
3004 A.2.  IKE_AUTH Exchange without EAP
3005
3006    request             --> IDi, [CERT+],
3007                            [N(INITIAL_CONTACT)],
3008                            [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
3009                            [IDr],
3010                            AUTH,
3011                            [CP(CFG_REQUEST)],
3012                            [N(IPCOMP_SUPPORTED)+],
3013                            [N(USE_TRANSPORT_MODE)],
3014                            [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
3015                            [N(NON_FIRST_FRAGMENTS_ALSO)],
3016                            SA, TSi, TSr,
3017                            [V+]
3018
3019
3020
3021
3022
3023
3024
3025
3026 Eronen & Hoffman             Informational                     [Page 54]
3027 \f
3028 RFC 4718                  IKEv2 Clarifications              October 2006
3029
3030
3031    response            <-- IDr, [CERT+],
3032                            AUTH,
3033                            [CP(CFG_REPLY)],
3034                            [N(IPCOMP_SUPPORTED)],
3035                            [N(USE_TRANSPORT_MODE)],
3036                            [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
3037                            [N(NON_FIRST_FRAGMENTS_ALSO)],
3038                            SA, TSi, TSr,
3039                            [N(ADDITIONAL_TS_POSSIBLE)],
3040                            [V+]
3041
3042 A.3.  IKE_AUTH Exchange with EAP
3043
3044    first request       --> IDi,
3045                            [N(INITIAL_CONTACT)],
3046                            [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],
3047                            [IDr],
3048                            [CP(CFG_REQUEST)],
3049                            [N(IPCOMP_SUPPORTED)+],
3050                            [N(USE_TRANSPORT_MODE)],
3051                            [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
3052                            [N(NON_FIRST_FRAGMENTS_ALSO)],
3053                            SA, TSi, TSr,
3054                            [V+]
3055
3056    first response      <-- IDr, [CERT+], AUTH,
3057                            EAP,
3058                            [V+]
3059
3060                      / --> EAP
3061    repeat 1..N times |
3062                      \ <-- EAP
3063
3064    last request        --> AUTH
3065
3066    last response       <-- AUTH,
3067                            [CP(CFG_REPLY)],
3068                            [N(IPCOMP_SUPPORTED)],
3069                            [N(USE_TRANSPORT_MODE)],
3070                            [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
3071                            [N(NON_FIRST_FRAGMENTS_ALSO)],
3072                            SA, TSi, TSr,
3073                            [N(ADDITIONAL_TS_POSSIBLE)],
3074                            [V+]
3075
3076
3077
3078
3079
3080
3081
3082 Eronen & Hoffman             Informational                     [Page 55]
3083 \f
3084 RFC 4718                  IKEv2 Clarifications              October 2006
3085
3086
3087 A.4.  CREATE_CHILD_SA Exchange for Creating/Rekeying CHILD_SAs
3088
3089    request             --> [N(REKEY_SA)],
3090                            [N(IPCOMP_SUPPORTED)+],
3091                            [N(USE_TRANSPORT_MODE)],
3092                            [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
3093                            [N(NON_FIRST_FRAGMENTS_ALSO)],
3094                            SA, Ni, [KEi], TSi, TSr
3095
3096    response            <-- [N(IPCOMP_SUPPORTED)],
3097                            [N(USE_TRANSPORT_MODE)],
3098                            [N(ESP_TFC_PADDING_NOT_SUPPORTED)],
3099                            [N(NON_FIRST_FRAGMENTS_ALSO)],
3100                            SA, Nr, [KEr], TSi, TSr,
3101                            [N(ADDITIONAL_TS_POSSIBLE)]
3102
3103 A.5.  CREATE_CHILD_SA Exchange for Rekeying the IKE_SA
3104
3105    request             --> SA, Ni, [KEi]
3106
3107    response            <-- SA, Nr, [KEr]
3108
3109 A.6.  INFORMATIONAL Exchange
3110
3111    request             --> [N+],
3112                            [D+],
3113                            [CP(CFG_REQUEST)]
3114
3115    response            <-- [N+],
3116                            [D+],
3117                            [CP(CFG_REPLY)]
3118
3119
3120
3121
3122
3123
3124
3125
3126
3127
3128
3129
3130
3131
3132
3133
3134
3135
3136
3137
3138 Eronen & Hoffman             Informational                     [Page 56]
3139 \f
3140 RFC 4718                  IKEv2 Clarifications              October 2006
3141
3142
3143 Authors' Addresses
3144
3145    Pasi Eronen
3146    Nokia Research Center
3147    P.O. Box 407
3148    FIN-00045 Nokia Group
3149    Finland
3150
3151    EMail: pasi.eronen@nokia.com
3152
3153
3154    Paul Hoffman
3155    VPN Consortium
3156    127 Segre Place
3157    Santa Cruz, CA 95060
3158    USA
3159
3160    EMail: paul.hoffman@vpnc.org
3161
3162
3163
3164
3165
3166
3167
3168
3169
3170
3171
3172
3173
3174
3175
3176
3177
3178
3179
3180
3181
3182
3183
3184
3185
3186
3187
3188
3189
3190
3191
3192
3193
3194 Eronen & Hoffman             Informational                     [Page 57]
3195 \f
3196 RFC 4718                  IKEv2 Clarifications              October 2006
3197
3198
3199 Full Copyright Statement
3200
3201    Copyright (C) The Internet Society (2006).
3202
3203    This document is subject to the rights, licenses and restrictions
3204    contained in BCP 78, and except as set forth therein, the authors
3205    retain all their rights.
3206
3207    This document and the information contained herein are provided on an
3208    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
3209    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
3210    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
3211    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
3212    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
3213    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
3214
3215 Intellectual Property
3216
3217    The IETF takes no position regarding the validity or scope of any
3218    Intellectual Property Rights or other rights that might be claimed to
3219    pertain to the implementation or use of the technology described in
3220    this document or the extent to which any license under such rights
3221    might or might not be available; nor does it represent that it has
3222    made any independent effort to identify any such rights.  Information
3223    on the procedures with respect to rights in RFC documents can be
3224    found in BCP 78 and BCP 79.
3225
3226    Copies of IPR disclosures made to the IETF Secretariat and any
3227    assurances of licenses to be made available, or the result of an
3228    attempt made to obtain a general license or permission for the use of
3229    such proprietary rights by implementers or users of this
3230    specification can be obtained from the IETF on-line IPR repository at
3231    http://www.ietf.org/ipr.
3232
3233    The IETF invites any interested party to bring to its attention any
3234    copyrights, patents or patent applications, or other proprietary
3235    rights that may cover technology that may be required to implement
3236    this standard.  Please address the information to the IETF at
3237    ietf-ipr@ietf.org.
3238
3239 Acknowledgement
3240
3241    Funding for the RFC Editor function is provided by the IETF
3242    Administrative Support Activity (IASA).
3243
3244
3245
3246
3247
3248
3249
3250 Eronen & Hoffman             Informational                     [Page 58]
3251 \f