idnits 2.17.00 (12 Aug 2021) /tmp/idnits51598/draft-ietf-ipsecme-ikev2-intermediate-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (5 March 2022) is 70 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CERTREQ' is mentioned on line 624, but not defined Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Smyslov 3 Internet-Draft ELVIS-PLUS 4 Intended status: Standards Track 5 March 2022 5 Expires: 6 September 2022 7 Intermediate Exchange in the IKEv2 Protocol 8 draft-ietf-ipsecme-ikev2-intermediate-10 10 Abstract 12 This document defines a new exchange, called Intermediate Exchange, 13 for the Internet Key Exchange protocol Version 2 (IKEv2). This 14 exchange can be used for transferring large amounts of data in the 15 process of IKEv2 Security Association (SA) establishment. An example 16 of the need to do this is using Quantum Computer resistant key 17 exchange methods for IKE SA establishment. Introducing the 18 Intermediate Exchange allows re-using the existing IKE fragmentation 19 mechanism, that helps to avoid IP fragmentation of large IKE 20 messages, but cannot be used in the initial IKEv2 exchange. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 6 September 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 4 57 3. Intermediate Exchange Details . . . . . . . . . . . . . . . . 4 58 3.1. Support for Intermediate Exchange Negotiation . . . . . . 4 59 3.2. Using Intermediate Exchange . . . . . . . . . . . . . . . 4 60 3.3. The IKE_INTERMEDIATE Exchange Protection and 61 Authentication . . . . . . . . . . . . . . . . . . . . . 5 62 3.3.1. Protection of the IKE_INTERMEDIATE Messages . . . . . 5 63 3.3.2. Authentication of the IKE_INTERMEDIATE Exchanges . . 6 64 3.4. Error Handling in the IKE_INTERMEDIATE Exchange . . . . . 10 65 4. Interaction with other IKEv2 Extensions . . . . . . . . . . . 11 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 72 9.2. Informative References . . . . . . . . . . . . . . . . . 14 73 Appendix A. Example of IKE_INTERMEDIATE exchange . . . . . . . . 14 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 76 1. Introduction 78 The Internet Key Exchange protocol version 2 (IKEv2) defined in 79 [RFC7296] uses UDP as a transport for its messages. If the size of a 80 message is larger than the PMTU, IP fragmentation takes place, which 81 has been shown to cause operational challenge in certain network 82 configurations and devices. The problem is described in more detail 83 in [RFC7383], which also defines an extension to IKEv2 called IKE 84 fragmentation. This extension allows IKE messages to be fragmented 85 at the IKE level, eliminating possible issues caused by IP 86 fragmentation. However, IKE fragmentation cannot be used in the 87 initial IKEv2 exchange (IKE_SA_INIT). This limitation in most cases 88 is not a problem, since the IKE_SA_INIT messages are usually small 89 enough not to cause IP fragmentation. 91 However, the situation has been changing recently. One example of 92 the need to transfer large amount of data before an IKE SA is created 93 is using Quantum Computer resistant key exchange methods in IKEv2. 94 Recent progress in Quantum Computing has brought a concern that 95 classical Diffie-Hellman key exchange methods will become insecure in 96 a relatively near future and should be replaced with Quantum Computer 97 (QC) resistant ones. Currently, most QC-resistant key exchange 98 methods have large public keys. If these keys are exchanged in the 99 IKE_SA_INIT, then most probably IP fragmentation will take place, 100 therefore all the problems caused by it will become inevitable. 102 A possible solution to the problem would be to use TCP as a transport 103 for IKEv2, as defined in [RFC8229]. However, this approach has 104 significant drawbacks and is intended to be a "last resort" when UDP 105 transport is completely blocked by intermediate network devices. 107 This specification describes a way to transfer a large amount of data 108 in IKEv2 using UDP transport. For this purpose the document defines 109 a new exchange for the IKEv2 protocol, called Intermediate Exchange 110 or IKE_INTERMEDIATE. One or more these exchanges may take place 111 right after the IKE_SA_INIT exchange and prior to the IKE_AUTH 112 exchange. The IKE_INTERMEDIATE exchange messages can be fragmented 113 using the IKE fragmentation mechanism, so these exchanges may be used 114 to transfer large amounts of data which don't fit into the 115 IKE_SA_INIT exchange without causing IP fragmentation. 117 The Intermediate Exchange can be used to transfer large public keys 118 of QC-resistant key exchange methods, but its application is not 119 limited to this use case. This exchange can also be used whenever 120 some data need to be transferred before the IKE_AUTH exchange and for 121 some reason the IKE_SA_INIT exchange is not suited for this purpose. 122 This document defines the IKE_INTERMEDIATE exchange without tying it 123 to any specific use case. It is expected that separate 124 specifications will define for which purposes and how the 125 IKE_INTERMEDIATE exchange is used in IKEv2. Some considerations must 126 be taken into account when designing such specifications: 128 * The IKE_INTERMEDIATE exchange is not intended for bulk transfer. 129 This document doesn't set a hard cap on the amount of data that 130 can be safely transferred using this mechanism, as it depends on 131 its application. But it is anticipated that in most cases the 132 amount of data will be limited to tens of Kbytes (few hundred 133 Kbytes in extreme cases), which is believed to cause no network 134 problems (see [RFC6928] as an example of experiments with sending 135 similar amounts of data in the first TCP flight). See also 136 Section 5 for the discussion of possible DoS attack vectors when 137 amount of data sent in IKE_INTERMEDIATE is too large. 139 * It is expected that the IKE_INTERMEDIATE exchange will only be 140 used for transferring data that is needed to establish IKE SA and 141 not for data that can be send later when this SA is established. 143 2. Terminology and Notation 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in BCP 148 14 [RFC2119] [RFC8174] when, and only when, they appear in all 149 capitals, as shown here. 151 It is expected that readers are familiar with the terms used in the 152 IKEv2 specification [RFC7296]. 154 3. Intermediate Exchange Details 156 3.1. Support for Intermediate Exchange Negotiation 158 The initiator indicates its support for Intermediate Exchange by 159 including a notification of type INTERMEDIATE_EXCHANGE_SUPPORTED in 160 the IKE_SA_INIT request message. If the responder also supports this 161 exchange, it includes this notification in the response message. 163 Initiator Responder 164 ----------- ----------- 165 HDR, SAi1, KEi, Ni, 166 [N(INTERMEDIATE_EXCHANGE_SUPPORTED)] --> 167 <-- HDR, SAr1, KEr, Nr, [CERTREQ], 168 [N(INTERMEDIATE_EXCHANGE_SUPPORTED)] 170 The INTERMEDIATE_EXCHANGE_SUPPORTED is a Status Type IKEv2 171 notification. Its Notify Message Type is 16438, Protocol ID and SPI 172 Size are both set to 0. This specification doesn't define any data 173 that this notification may contain, so the Notification Data is left 174 empty. However, future enhancements to this specification may 175 override this. Implementations MUST ignore non-empty Notification 176 Data if they don't understand its purpose. 178 3.2. Using Intermediate Exchange 180 If both peers indicated their support for the Intermediate Exchange, 181 the initiator may use one or more these exchanges to transfer 182 additional data. Using the Intermediate Exchange is optional; the 183 initiator may find it unnecessary even when support for this 184 exchanged has been negotiated. 186 The Intermediate Exchange is denoted as IKE_INTERMEDIATE, its 187 Exchange Type is 43. 189 Initiator Responder 190 ----------- ----------- 191 HDR, ..., SK {...} --> 192 <-- HDR, ..., SK {...} 194 The initiator may use several IKE_INTERMEDIATE exchanges if 195 necessary. Since window size is initially set to one for both peers 196 (Section 2.3 of [RFC7296]), these exchanges MUST be sequential and 197 MUST all be completed before the IKE_AUTH exchange is initiated. The 198 IKE SA MUST NOT be considered as established until the IKE_AUTH 199 exchange is successfully completed. 201 The Message IDs for IKE_INTERMEDIATE exchanges MUST be chosen 202 according to the standard IKEv2 rule, described in the Section 2.2. 203 of [RFC7296], i.e. it is set to 1 for the first IKE_INTERMEDIATE 204 exchange, 2 for the next (if any) and so on. Implementations MUST 205 verify that Message IDs in the IKE_INTERMEDIATE messages they receive 206 actually follow this rule. The Message ID for the first pair of the 207 IKE_AUTH messages is one more than the value used in the last 208 IKE_INTERMEDIATE exchange. 210 If the presence of NAT is detected in the IKE_SA_INIT exchange via 211 NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP 212 notifications, then the peers switch to port 4500 in the first 213 IKE_INTERMEDIATE exchange and use this port for all subsequent 214 exchanges, as described in Section 2.23 of [RFC7296]. 216 The content of the IKE_INTERMEDIATE exchange messages depends on the 217 data being transferred and will be defined by specifications 218 utilizing this exchange. However, since the main motivation for the 219 IKE_INTERMEDIATE exchange is to avoid IP fragmentation when large 220 amounts of data need to be transferred prior to IKE_AUTH, the 221 Encrypted payload MUST be present in the IKE_INTERMEDIATE exchange 222 messages and payloads containing large data MUST be placed inside it. 223 This will allow IKE fragmentation [RFC7383] to take place, provided 224 it is supported by the peers and negotiated in the initial exchange. 226 Appendix A contains an example of using an IKE_INTERMEDIATE exchange 227 in creating an IKE SA. 229 3.3. The IKE_INTERMEDIATE Exchange Protection and Authentication 231 3.3.1. Protection of the IKE_INTERMEDIATE Messages 233 The keys SK_e[i/r] and SK_a[i/r] for the IKE_INTERMEDIATE exchanges 234 protection are computed in the standard fashion, as defined in the 235 Section 2.14 of [RFC7296]. 237 Every subsequent IKE_INTERMEDIATE exchange uses the most recently 238 calculated IKE SA keys before this exchange is started. So, the 239 first IKE_INTERMEDIATE exchange always uses SK_e[i/r] and SK_a[i/r] 240 keys that were computed as a result of the IKE_SA_INIT exchange. If 241 additional key exchange is performed in the first IKE_INTERMEDIATE 242 exchange, resulting in the update of SK_e[i/r] and SK_a[i/r], then 243 these updated keys are used for protection of the second 244 IKE_INTERMEDIATE exchange. Otherwise, the original SK_e[i/r] and 245 SK_a[i/r] keys are used again, and so on. 247 Once all the IKE_INTERMEDIATE exchanges are completed, the most 248 recently calculated SK_e[i/r] and SK_a[i/r] keys are used for 249 protection of the IKE_AUTH and all the subsequent exchanges. 251 3.3.2. Authentication of the IKE_INTERMEDIATE Exchanges 253 The IKE_INTERMEDIATE messages must be authenticated in the IKE_AUTH 254 exchange, which is performed by adding their content into the AUTH 255 payload calculation. It is anticipated that in many use cases 256 IKE_INTERMEDIATE messages will be fragmented using IKE fragmentation 257 [RFC7383] mechanism. According to [RFC7383], when IKE fragmentation 258 is negotiated, the initiator may first send a request message in 259 unfragmented form, but later turn on IKE fragmentation and re-send it 260 fragmented if no response is received after a few retransmissions. 261 In addition, peers may re-send fragmented message using different 262 fragment sizes to perform simple PMTU discovery. 264 The requirement to support this behavior makes authentication 265 challenging: it is not appropriate to add on-the-wire content of the 266 IKE_INTERMEDIATE messages into the AUTH payload calculation, because 267 implementations are generally unaware in which form these messages 268 are received by peers. Instead, a more complex scheme is used -- 269 authentication is performed by adding content of these messages 270 before their encryption and possible fragmentation, so that data to 271 be authenticated doesn't depend on the form the messages are 272 delivered in. 274 If any IKE_INTERMEDIATE exchange took place, the definition of the 275 blob to be signed (or MAC'ed) from the Section 2.15 of [RFC7296] is 276 modified as follows: 278 InitiatorSignedOctets = RealMsg1 | NonceRData | MACedIDForI | IntAuth 279 ResponderSignedOctets = RealMsg2 | NonceIData | MACedIDForR | IntAuth 281 IntAuth = IntAuth_iN | IntAuth_rN | IKE_AUTH_MID 283 IntAuth_i1 = prf(SK_pi1, IntAuth_i1A [| IntAuth_i1P]) 284 IntAuth_i2 = prf(SK_pi2, IntAuth_i1 | IntAuth_i2A [| IntAuth_i2P]) 285 IntAuth_i3 = prf(SK_pi3, IntAuth_i2 | IntAuth_i3A [| IntAuth_i3P]) 286 ... 287 IntAuth_iN = prf(SK_piN, IntAuth_iN-1 | IntAuth_iNA [| IntAuth_iNP]) 289 IntAuth_r1 = prf(SK_pr1, IntAuth_r1A [| IntAuth_r1P]) 290 IntAuth_r2 = prf(SK_pr2, IntAuth_r1 | IntAuth_r2A [| IntAuth_r2P]) 291 IntAuth_r3 = prf(SK_pr3, IntAuth_r2 | IntAuth_r3A [| IntAuth_r3P]) 292 ... 293 IntAuth_rN = prf(SK_prN, IntAuth_rN-1 | IntAuth_rNA [| IntAuth_rNP]) 295 The essence of this modification is that a new chunk called IntAuth 296 is appended to the string of octets that is signed (or MAC'ed) by the 297 peers. IntAuth consists of three parts: IntAuth_iN, IntAuth_rN, and 298 IKE_AUTH_MID. 300 The IKE_AUTH_MID chunk is a value of the Message ID field from the 301 IKE Header of the first round of the IKE_AUTH exchange. It is 302 represented as a four octet integer in network byte order (in other 303 words, exactly as it appears on the wire). 305 The IntAuth_iN and IntAuth_rN chunks each represent the cumulative 306 result of applying the negotiated prf to all IKE_INTERMEDIATE 307 exchange messages sent during IKE SA establishment by the initiator 308 and the responder respectively. After the first IKE_INTERMEDIATE 309 exchange is completed peers calculate the IntAuth_i1 value by 310 applying the negotiated prf to the content of the request message 311 from this exchange and calculate the IntAuth_r1 value by applying the 312 negotiated prf to the content of the response message. For every 313 following IKE_INTERMEDIATE exchange (if any) peers re-calculate these 314 values as follows. After the n-th exchange is completed they compute 315 IntAuth_[i/r]n by applying the negotiated prf to the concatenation of 316 IntAuth_[i/r](n-1) (computed for the previous IKE_INTERMEDIATE 317 exchange) and the content of the request (for IntAuth_in) or response 318 (for IntAuth_rn) messages from this exchange. After all 319 IKE_INTERMEDIATE exchanges are over the resulted IntAuth_[i/r]N 320 values (assuming N exchanges took place) are used in the computing 321 the AUTH payload. 323 For the purpose of calculating the IntAuth_[i/r]* values the content 324 of the IKE_INTERMEDIATE messages is represented as two chunks of 325 data: mandatory IntAuth_[i/r]*A optionally followed by IntAuth_[i/ 326 r]*P. 328 The IntAuth_[i/r]*A chunk consists of the sequence of octets from the 329 first octet of the IKE Header (not including prepended four octets of 330 zeros, if UDP encapsulation or TCP encapsulation of ESP packets is 331 used) to the last octet of the generic header of the Encrypted 332 payload. The scope of IntAuth_[i/r]*A is identical to the scope of 333 Associated Data defined for use of AEAD algorithms in IKEv2 (see 334 Section 5.1 of [RFC5282]), which is stressed by using "A" suffix in 335 its name. Note, that calculation of IntAuth_[i/r]*A doesn't depend 336 on whether an AEAD algorithm or a plain cipher is used in IKE SA. 338 The IntAuth_[i/r]*P chunk is present if the Encrypted payload is not 339 empty. It consists of the content of the Encrypted payload that is 340 fully formed, but not yet encrypted. The Initialization Vector, the 341 Padding, the Pad Length and the Integrity Checksum Data fields (see 342 Section 3.14 of [RFC7296]) are not included into the calculation. In 343 other words, the IntAuth_[i/r]*P chunk is the inner payloads of the 344 Encrypted payload in plaintext form, which is stressed by using "P" 345 suffix in its name. 347 1 2 3 348 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^ 350 | IKE SA Initiator's SPI | | | 351 | | | | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I | 353 | IKE SA Responder's SPI | K | 354 | | E | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 356 | Next Payload | MjVer | MnVer | Exchange Type | Flags | H | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | 358 | Message ID | r A 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 360 | Adjusted Length | | | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v | 362 | | | 363 ~ Unencrypted payloads (if any) ~ | 364 | | | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ | 366 | Next Payload |C| RESERVED | Adjusted Payload Length | | | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | v 368 | | | 369 ~ Initialization Vector ~ E 370 | | E 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c ^ 372 | | r | 373 ~ Inner payloads (not yet encrypted) ~ P 374 | | P | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ l v 376 | Padding (0-255 octets) | Pad Length | d 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 378 | | | 379 ~ Integrity Checksum Data ~ | 380 | | | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v 383 Figure 1: Data to Authenticate in the IKE_INTERMEDIATE Exchange 384 Messages 386 Figure 1 illustrates the layout of the IntAuth_[i/r]*A (denoted as A) 387 and the IntAuth_[i/r]*P (denoted as P) chunks in case the Encrypted 388 payload is not empty. 390 For the purpose of prf calculation the Length field in the IKE Header 391 and the Payload Length field in the Encrypted payload header are 392 adjusted so that they don't count the lengths of Initialization 393 Vector, Integrity Checksum Data, Padding and Pad Length fields. In 394 other words, the Length field in the IKE Header (denoted as Adjusted 395 Length in Figure 1) is set to the sum of the lengths of IntAuth_[i/ 396 r]*A and IntAuth_[i/r]*P, and the Payload Length field in the 397 Encrypted payload header (denoted as Adjusted Payload Length in 398 Figure 1) is set to the length of IntAuth_[i/r]*P plus the size of 399 the Encrypted payload header (four octets). 401 The prf calculations MUST be applied to whole messages only, before 402 possible IKE fragmentation. This ensures that the IntAuth will be 403 the same regardless of whether IKE fragmentation takes place or not. 404 If the message was received in fragmented form, it MUST be 405 reconstructed before calculating the prf as if it were received 406 unfragmented. While reconstructing, the RESERVED field in the 407 reconstructed Encrypted payload header MUST be set to the value of 408 the RESERVED field in the Encrypted Fragment payload header from the 409 first fragment (with Fragment Number field set to 1). 411 Note that it is possible to avoid actual reconstruction of the 412 message by incrementally calculating prf on decrypted (or ready to be 413 encrypted) fragments. However, care must be taken to properly 414 replace the content of the Next Header and the Length fields so that 415 the result of computing the prf is the same as if it were computed on 416 the reconstructed message. 418 Each calculation of IntAuth_[i/r]* uses its own keys SK_p[i/r]*, 419 which are the most recently updated SK_p[i/r] keys available before 420 the corresponded IKE_INTERMEDIATE exchange is started. The first 421 IKE_INTERMEDIATE exchange always uses the SK_p[i/r] keys that were 422 computed in the IKE_SA_INIT as SK_p[i/r]1. If the first 423 IKE_INTERMEDIATE exchange performs additional key exchange resulting 424 in SK_p[i/r] update, then this updated SK_p[i/r] are used as SK_p[i/ 425 r]2, otherwise the original SK_p[i/r] are used, and so on. Note that 426 if keys are updated, then for any given IKE_INTERMEDIATE exchange the 427 keys SK_e[i/r] and SK_a[i/r] used for protection of its messages (see 428 Section 3.3.1) and the keys SK_p[i/r] for its authentication are 429 always from the same generation. 431 3.4. Error Handling in the IKE_INTERMEDIATE Exchange 433 Since messages of the IKE_INTERMEDIATE exchange are not authenticated 434 until the IKE_AUTH exchange successfully completes, possible errors 435 need to be handled with care. There is a trade-off between providing 436 better diagnostics of the problem and risk of becoming part of DoS 437 attack. Section 2.21.1 and 2.21.2 of [RFC7296] describe how errors 438 are handled in initial IKEv2 exchanges; these considerations are also 439 applied to the IKE_INTERMEDIATE exchange with a qualification, that 440 not all error notifications may appear in the IKE_INTERMEDIATE 441 exchange (for example, errors concerning authentication are generally 442 only applicable to the IKE_AUTH exchange). 444 4. Interaction with other IKEv2 Extensions 446 The IKE_INTERMEDIATE exchanges MAY be used during the IKEv2 Session 447 Resumption [RFC5723] between the IKE_SESSION_RESUME and the IKE_AUTH 448 exchanges. To be able to use it peers MUST negotiate support for 449 intermediate exchange by including INTERMEDIATE_EXCHANGE_SUPPORTED 450 notifications in the IKE_SESSION_RESUME messages. Note, that a flag 451 whether peers supported the IKE_INTERMEDIATE exchange is not stored 452 in the resumption ticket and is determined each time from the 453 IKE_SESSION_RESUME exchange. 455 5. Security Considerations 457 The data that is transferred by means of the IKE_INTERMEDIATE 458 exchanges is not authenticated until the subsequent IKE_AUTH exchange 459 is completed. However, if the data is placed inside the Encrypted 460 payload, then it is protected from passive eavesdroppers. In 461 addition, the peers can be certain that they receive messages from 462 the party they performed the IKE_SA_INIT with if they can 463 successfully verify the Integrity Checksum Data of the Encrypted 464 payload. 466 The main application for the Intermediate Exchange is to transfer 467 large amounts of data before an IKE SA is set up, without causing IP 468 fragmentation. For that reason it is expected that in most cases IKE 469 fragmentation will be employed in the IKE_INTERMEDIATE exchanges. 470 Section 5 of [RFC7383] contains security considerations for IKE 471 fragmentation. 473 Since authentication of the peers occurs only in the IKE_AUTH 474 exchange, malicious initiator may use the Intermediate Exchange to 475 mount Denial of Service attack on responder. In this case it starts 476 creating IKE SA, negotiates using the Intermediate Exchanges and 477 transfers a lot of data to the responder that may also require some 478 computationally expensive processing. Then it aborts the SA 479 establishment before the IKE_AUTH exchange. Specifications utilizing 480 the Intermediate Exchange MUST NOT allow unlimited number of these 481 exchanges to take place on initiator's discretion. It is recommended 482 that these specifications are defined in such a way, that the 483 responder would know (possibly via negotiation with the initiator) 484 the exact number of these exchanges that need to take place. In 485 other words: it is preferred that both the initiator and the 486 responder know after the IKE_SA_INIT is completed the exact number of 487 the IKE_INTERMEDIATE exchanges they have to perform; it is allowed 488 that some IKE_INTERMEDIATE exchanges are optional and are performed 489 on the initiator's discretion, but in this case the maximum number of 490 optional exchanges must be hard capped by the corresponding 491 specification. In addition, [RFC8019] provides guidelines for the 492 responder of how to deal with DoS attacks during IKE SA 493 establishment. 495 Note that if an attacker was able to break the key exchange in real 496 time (e.g. by means of a Quantum Computer), then the security of the 497 IKE_INTERMEDIATE exchange would degrade. In particular, such an 498 attacker would be able both to read data contained in the Encrypted 499 payload and to forge it. The forgery would become evident in the 500 IKE_AUTH exchange (provided the attacker cannot break the employed 501 authentication mechanism), but the ability to inject forged 502 IKE_INTERMEDIATE exchange messages with valid ICV would allow the 503 attacker to mount a Denial-of-Service attack. Moreover, if in this 504 situation the negotiated prf was not secure against second preimage 505 attack with known key, then the attacker could forge the 506 IKE_INTERMEDIATE exchange messages without later being detected in 507 the IKE_AUTH exchange. To do this the attacker would find the same 508 IntAuth_[i/r]* value for the forged message as for original. 510 6. IANA Considerations 512 This document defines a new Exchange Type in the "IKEv2 Exchange 513 Types" registry: 515 43 IKE_INTERMEDIATE 517 This document also defines a new Notify Message Type in the "IKEv2 518 Notify Message Types - Status Types" registry: 520 16438 INTERMEDIATE_EXCHANGE_SUPPORTED 522 7. Implementation Status 524 [Note to RFC Editor: please, remove this section before publishing 525 RFC.] 527 At the time of writing the -05 version of the draft there were at 528 least three independent interoperable implementations of this 529 specification from the following vendors: 531 * ELVIS-PLUS 533 * strongSwan 535 * libreswan (only one IKE_INTERMEDIATE exchange is supported) 537 8. Acknowledgements 539 The idea to use an intermediate exchange between IKE_SA_INIT and 540 IKE_AUTH was first suggested by Tero Kivinen. He also helped with 541 writing an example of using IKE_INTERMEDIATE exchange (shown in 542 Appendix A). Scott Fluhrer and Daniel Van Geest identified a 543 possible problem with authentication of the IKE_INTERMEDIATE exchange 544 and helped to resolve it. Author is grateful to Tobias Brunner who 545 raised good questions concerning authentication of the 546 IKE_INTERMEDIATE exchange and proposed how to make the size of 547 authentication chunk constant regardless of the number of exchanges. 548 Author is also grateful to Paul Wouters and to Benjamin Kaduk who 549 suggested a lot of text improvements for the document. 551 9. References 553 9.1. Normative References 555 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 556 Requirement Levels", BCP 14, RFC 2119, 557 DOI 10.17487/RFC2119, March 1997, 558 . 560 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 561 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 562 May 2017, . 564 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 565 Kivinen, "Internet Key Exchange Protocol Version 2 566 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 567 2014, . 569 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 570 (IKEv2) Message Fragmentation", RFC 7383, 571 DOI 10.17487/RFC7383, November 2014, 572 . 574 9.2. Informative References 576 [RFC5282] Black, D. and D. McGrew, "Using Authenticated Encryption 577 Algorithms with the Encrypted Payload of the Internet Key 578 Exchange version 2 (IKEv2) Protocol", RFC 5282, 579 DOI 10.17487/RFC5282, August 2008, 580 . 582 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 583 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 584 DOI 10.17487/RFC5723, January 2010, 585 . 587 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 588 "Increasing TCP's Initial Window", RFC 6928, 589 DOI 10.17487/RFC6928, April 2013, 590 . 592 [RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange 593 Protocol Version 2 (IKEv2) Implementations from 594 Distributed Denial-of-Service Attacks", RFC 8019, 595 DOI 10.17487/RFC8019, November 2016, 596 . 598 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 599 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 600 August 2017, . 602 Appendix A. Example of IKE_INTERMEDIATE exchange 604 This appendix contains an example of the messages using 605 IKE_INTERMEDIATE exchanges. This appendix is purely informative; if 606 it disagrees with the body of this document, the other text is 607 considered correct. 609 In this example there is one IKE_SA_INIT exchange and two 610 IKE_INTERMEDIATE exchanges, followed by the IKE_AUTH exchange to 611 authenticate all initial exchanges. The xxx in the HDR(xxx,MID=yyy) 612 indicates the exchange type, and yyy tells the message id used for 613 that exchange. The keys used for each SK {} payload are indicated in 614 the parenthesis after the SK. Otherwise, the payload notation is the 615 same as is used in [RFC7296]. 617 Initiator Responder 618 ----------- ----------- 619 HDR(IKE_SA_INIT,MID=0), 620 SAi1, KEi, Ni, 621 N(INTERMEDIATE_EXCHANGE_SUPPORTED) --> 623 <-- HDR(IKE_SA_INIT,MID=0), 624 SAr1, KEr, Nr, [CERTREQ], 625 N(INTERMEDIATE_EXCHANGE_SUPPORTED) 627 At this point peers calculate SK_* and store them as SK_*1. SK_e[i/ 628 r]1 and SK_a[i/r]1 will be used to protect the first IKE_INTERMEDIATE 629 exchange and SK_p[i/r]1 will be used for its authentication. 631 Initiator Responder 632 ----------- ----------- 633 HDR(IKE_INTERMEDIATE,MID=1), 634 SK(SK_ei1,SK_ai1) {...} --> 636 638 <-- HDR(IKE_INTERMEDIATE,MID=1), 639 SK(SK_er1,SK_ar1) {...} 641 643 If after completing this IKE_INTERMEDIATE exchange the SK_*1 keys are 644 updated (e.g., as a result of a new key exchange), then the peers 645 store the updated keys as SK_*2, otherwise they use SK_*1 as SK_*2. 646 SK_e[i/r]2 and SK_a[i/r]2 will be used to protect the second 647 IKE_INTERMEDIATE exchange and SK_p[i/r]2 will be used for its 648 authentication. 650 Initiator Responder 651 ----------- ----------- 652 HDR(IKE_INTERMEDIATE,MID=2), 653 SK(SK_ei2,SK_ai2) {...} --> 655 657 <-- HDR(IKE_INTERMEDIATE,MID=2), 658 SK(SK_er2,SK_ar2) {...} 660 662 If after completing the second IKE_INTERMEDIATE exchange the SK_*2 663 keys are updated (e.g., as a result of a new key exchange), then the 664 peers store the updated keys as SK_*3, otherwise they use SK_*2 as 665 SK_*3. SK_e[i/r]3 and SK_a[i/r]3 will be used to protect the 666 IKE_AUTH exchange, SK_p[i/r]3 will be used for authentication, and 667 SK_d3 will be used for derivation of other keys (e.g. for Child SAs). 669 Initiator Responder 670 ----------- ----------- 671 HDR(IKE_AUTH,MID=3), 672 SK(SK_ei3,SK_ai3) 673 {IDi, [CERT,] [CERTREQ,] 674 [IDr,] AUTH, SAi2, TSi, TSr} --> 675 <-- HDR(IKE_AUTH,MID=3), 676 SK(SK_er3,SK_ar3) 677 {IDr, [CERT,] AUTH, SAr2, TSi, TSr} 679 In this example two IKE_INTERMEDIATE exchanges took place, therefore 680 SK_*3 keys would be used as SK_* keys for further cryptographic 681 operations in the context of the created IKE SA, as defined in 682 [RFC7296]. 684 Author's Address 686 Valery Smyslov 687 ELVIS-PLUS 688 PO Box 81 689 Moscow (Zelenograd) 690 124460 691 Russian Federation 692 Phone: +7 495 276 0211 693 Email: svan@elvis.ru