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