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