idnits 2.17.1 draft-ietf-ipsecme-ikev2-intermediate-07.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 (August 3, 2021) is 994 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 528, 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 August 3, 2021 5 Expires: February 4, 2022 7 Intermediate Exchange in the IKEv2 Protocol 8 draft-ietf-ipsecme-ikev2-intermediate-07 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 amount of data in the 15 process of IKEv2 Security Association (SA) establishment. 16 Introducing Intermediate Exchange allows re-using existing IKE 17 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 February 4, 2022. 37 Copyright Notice 39 Copyright (c) 2021 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 . . . . . . . . . . . 9 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 68 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 71 9.2. Informative References . . . . . . . . . . . . . . . . . 11 72 Appendix A. Example of IKE_INTERMEDIATE exchange . . . . . . . . 11 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 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 the 82 IKEv2 called IKE fragmentation. This extension allows IKE messages 83 to be fragmented at IKE level, eliminating possible issues caused by 84 IP fragmentation. However, the IKE fragmentation cannot be used in 85 the initial IKEv2 exchange (IKE_SA_INIT). This limitation in most 86 cases is not a problem, since the IKE_SA_INIT messages used to be 87 small 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 IKE SA is created is 91 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 of 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 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 IKE fragmentation mechanism, so these exchanges may be used to 112 transfer large amounts of data which don't fit into the IKE_SA_INIT 113 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 the 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 this notification may contain, so the Notification Data is left 156 empty. However, future enhancements of this specification may 157 override this. Implementations MUST ignore the non-empty 158 Notification 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 already 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. The Message ID for the 187 first pair of the IKE_AUTH messages is one more than the value used 188 in the last IKE_INTERMEDIATE exchange. 190 If the presence of NAT is detected in the IKE_SA_INIT exchange via 191 NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP 192 notifications, then the peers MUST switch to port 4500 and send all 193 IKE_INTERMEDIATE exchanges using port 4500. 195 The content of the IKE_INTERMEDIATE exchange messages depends on the 196 data being transferred and will be defined by specifications 197 utilizing this exchange. However, since the main motivation for the 198 IKE_INTERMEDIATE exchange is to avoid IP fragmentation when large 199 amount of data need to be transferred prior to IKE_AUTH, the 200 Encrypted payload MUST be present in the IKE_INTERMEDIATE exchange 201 messages and payloads containing large data MUST be placed inside it. 202 This will allow IKE fragmentation [RFC7383] to take place, provided 203 it is supported by the peers and negotiated in the initial exchange. 205 Appendix A contains an example of using IKE_INTERMEDIATE exchange in 206 creating IKE SA. 208 3.3. The IKE_INTERMEDIATE Exchange Protection and Authentication 210 3.3.1. Protection of the IKE_INTERMEDIATE Messages 212 The keys SK_e[i/r] and SK_a[i/r] for the IKE_INTERMEDIATE exchanges 213 protection are computed in a standard fashion, as defined in the 214 Section 2.14 of [RFC7296]. 216 Every subsequent IKE_INTERMEDIATE exchange uses the most recently 217 calculated IKE SA keys before this exchange is started. So, the 218 first IKE_INTERMEDIATE exchange always uses SK_e[i/r] and SK_a[i/r] 219 keys that were computed as a result of the IKE_SA_INIT exchange. If 220 additional key exchange is performed in the first IKE_INTERMEDIATE 221 exchange resulting in the update of SK_e[i/r] and SK_a[i/r], then 222 these updated keys are used for protection of the second 223 IKE_INTERMEDIATE exchange, otherwise the original SK_e[i/r] and 224 SK_a[i/r] keys are used again, and so on. 226 Once all the IKE_INTERMEDIATE exchanges are completed, the most 227 recently calculated SK_e[i/r] and SK_a[i/r] keys are used for 228 protection of the IKE_AUTH and all the subsequent exchanges. 230 3.3.2. Authentication of the IKE_INTERMEDIATE Exchanges 232 The IKE_INTERMEDIATE messages must be authenticated in the IKE_AUTH 233 exchange, which is performed by adding their content into the AUTH 234 payload calculation. It is anticipated that in many use cases 235 IKE_INTERMEDIATE messages will be fragmented using IKE fragmentation 236 [RFC7383] mechanism. According to [RFC7383], when IKE fragmentation 237 is negotiated, initiator may first send request message in 238 unfragmented form, but later turn IKE fragmentation on and re-send it 239 fragmented if no response is received after few retransmissions. In 240 addition, peers may re-send fragmented message using different 241 fragment sizes to perform simple PMTU discovery. 243 The requirement to support this behavior makes authentication 244 challenging: it is not appropriate to add on-the-wire content of the 245 IKE_INTERMEDIATE messages into the AUTH payload calculation, because 246 peers generally are unaware in which form other side has received 247 them. Instead, a more complex scheme is used - authentication is 248 performed by adding content of these messages before their encryption 249 and possible fragmentation, so that data to be authenticated doesn't 250 depend on the form the messages are delivered in. 252 If any IKE_INTERMEDIATE exchange took place, the definition of the 253 blob to be signed (or MAC'ed) from the Section 2.15 of [RFC7296] is 254 modified as follows: 256 InitiatorSignedOctets = RealMsg1 | NonceRData | MACedIDForI | IntAuth 257 ResponderSignedOctets = RealMsg2 | NonceIData | MACedIDForR | IntAuth 259 IntAuth = IntAuth_1 [| IntAuth_2 [| IntAuth_3 ... ]] 261 IntAuth_1 = IntAuth_1_I | IntAuth_1_R 262 IntAuth_2 = IntAuth_2_I | IntAuth_2_R 263 IntAuth_3 = IntAuth_3_I | IntAuth_3_R 264 ... 266 IntAuth_1_I = prf(SK_pi_1, IntAuth_1_I_A [| IntAuth_1_I_P]) 267 IntAuth_2_I = prf(SK_pi_2, IntAuth_2_I_A [| IntAuth_2_I_P]) 268 IntAuth_3_I = prf(SK_pi_3, IntAuth_3_I_A [| IntAuth_3_I_P]) 269 ... 271 IntAuth_1_R = prf(SK_pr_1, IntAuth_1_R_A [| IntAuth_1_R_P]) 272 IntAuth_2_R = prf(SK_pr_2, IntAuth_2_R_A [| IntAuth_2_R_P]) 273 IntAuth_3_R = prf(SK_pr_3, IntAuth_3_R_A [| IntAuth_3_R_P]) 274 ... 276 IntAuth_1_I/IntAuth_1_R, IntAuth_2_I/IntAuth_2_R, IntAuth_3_I/ 277 IntAuth_3_R, etc. represent the results of applying the negotiated 278 prf to the content of the IKE_INTERMEDIATE messages sent by the 279 initiator (IntAuth_*_I) and by the responder (IntAuth_*_R) in an 280 order of increasing their Message IDs (i.e. in an order the 281 IKE_INTERMEDIATE exchanges took place). The prf is applied to the 282 the concatenation of two chunks of data: mandatory IntAuth_*_[I/R]_A 283 optionally followed by IntAuth_*_[I/R]_P. The IntAuth_*_[I/R]_A 284 chunk lasts from the first octet of the IKE Header (not including 285 prepended four octets of zeros, if port 4500 is used) to the last 286 octet of the Encrypted payload header. The IntAuth_*_[I/R]_P chunk 287 is present if the Encrypted payload is not empty. It consists of the 288 content of the Encrypted payload that is fully formed, but not yet 289 encrypted. The Initialization Vector, the Padding, the Pad Length 290 and the Integrity Checksum Data fields (see Section 3.14 of 291 [RFC7296]) are not included into the calculation. In other words, 292 the IntAuth_*_[I/R]_P chunk is the inner payloads of the Encrypted 293 payload in plaintext form. 295 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^ 298 | IKE SA Initiator's SPI | | | 299 | | | | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I | 301 | IKE SA Responder's SPI | K | 302 | | E | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 304 | Next Payload | MjVer | MnVer | Exchange Type | Flags | H | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | 306 | Message ID | r A 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 308 | Adjusted Length | | | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v | 310 | | | 311 ~ Unencrypted payloads (if any) ~ | 312 | | | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ | 314 | Next Payload |C| RESERVED | Adjusted Payload Length | | | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | v 316 | | | 317 ~ Initialization Vector ~ E 318 | | E 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c ^ 320 | | r | 321 ~ Inner payloads (not yet encrypted) ~ P 322 | | P | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ l v 324 | Padding (0-255 octets) | Pad Length | d 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 326 | | | 327 ~ Integrity Checksum Data ~ | 328 | | | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v 331 Figure 1: Data to Authenticate in the IKE_INTERMEDIATE Exchange 332 Messages 334 Figure 1 illustrates the layout of the IntAuth_*_[I/R]_P (denoted as 335 P) and the IntAuth_*_[I/R]_A (denoted as A) chunks in case the 336 Encrypted payload is not empty. 338 For the purpose of prf calculation the Length field in the IKE header 339 and the Payload Length field in the Encrypted payload header are 340 adjusted so that they don't count the lengths of Initialization 341 Vector, Integrity Checksum Data, Padding and Pad Length fields. In 342 other words, the Length field in the IKE header (denoted as Adjusted 343 Length in Figure 1) is set to the sum of the lengths of IntAuth_*_[I/ 344 R]_A and IntAuth_*_[I/R]_P, and the Payload Length field in the 345 Encrypted payload header (denoted as Adjusted Payload Length in 346 Figure 1) is set to the length of IntAuth_*_[I/R]_P plus the size of 347 the Encrypted payload header (four octets). 349 The prf calculations MUST be applied to whole messages only, before 350 possible IKE fragmentation. This ensures that the IntAuth will be 351 the same regardless of whether IKE fragmentation takes place or not. 352 If the message was received in fragmented form, it MUST be 353 reconstructed before calculating prf as if it were received 354 unfragmented. While reconstructing, the RESERVED field in the 355 reconstructed Encrypted payload header MUST be set to the value of 356 the RESERVED field in the Encrypted Fragment payload header from the 357 first fragment (with Fragment Number field set to 1). 359 Note that it is possible to avoid actual reconstruction of the 360 message by incrementally calculating prf on decrypted (or ready to be 361 encrypted) fragments. However care must be taken to properly replace 362 the content of the Next Header and the Length fields so that the 363 result of computing prf is the same as if it were computed on 364 reconstructed message. 366 Each calculation of IntAuth_*_[I/R] uses its own keys SK_p[i/r]_*, 367 which are the most recently updated SK_p[i/r] keys available before 368 the corresponded IKE_INTERMEDIATE exchange is started. The first 369 IKE_INTERMEDIATE exchange always uses SK_p[i/r] keys that were 370 computed in the IKE_SA_INIT as SK_p[i/r]_1. If the first 371 IKE_INTERMEDIATE exchange performs additional key exchange resulting 372 in SK_p[i/r] update, then this updated SK_p[i/r] are used as SK_p[i/ 373 r]_2, otherwise the original SK_p[i/r] are used, and so on. Note, 374 that if keys are updated then for any given IKE_INTERMEDIATE exchange 375 the keys SK_e[i/r] and SK_a[i/r] used for its messages protection 376 (see Section 3.3.1) and the keys SK_p[i/r] for its authentication are 377 always from the same generation. 379 3.4. Error Handling in the IKE_INTERMEDIATE Exchange 381 Since messages of the IKE_INTERMEDIATE exchange are not authenticated 382 until the IKE_AUTH exchange successfully completes, possible errors 383 need to be handled with care. There is a trade-off between providing 384 a better diagnostics of the problem and a risk to become a part of 385 DoS attack. See Section 2.21.1 and 2.21.2 of [RFC7296] describe how 386 errors are handled in initial IKEv2 exchanges, these considerations 387 are also applied to the IKE_INTERMEDIATE exchange. 389 4. Interaction with other IKEv2 Extensions 391 The IKE_INTERMEDIATE exchanges MAY be used during the IKEv2 Session 392 Resumption [RFC5723] between the IKE_SESSION_RESUME and the IKE_AUTH 393 exchanges. To be able to use it peers MUST negotiate support for 394 intermediate exchange by including INTERMEDIATE_EXCHANGE_SUPPORTED 395 notifications in the IKE_SESSION_RESUME messages. Note, that a flag 396 whether peers supported the IKE_INTERMEDIATE exchange is not stored 397 in the resumption ticket and is determined each time from the 398 IKE_SESSION_RESUME exchange. 400 5. Security Considerations 402 The data that is transferred by means of the IKE_INTERMEDIATE 403 exchanges is not authenticated until the subsequent IKE_AUTH exchange 404 is completed. However, if the data is placed inside the Encrypted 405 payload, then it is protected from passive eavesdroppers. In 406 addition the peers can be certain that they receives messages from 407 the party they performed the IKE_SA_INIT with if they can 408 successfully verify the Integrity Checksum Data of the Encrypted 409 payload. 411 The main application for Intermediate Exchange is to transfer large 412 amount of data before IKE SA is set up without causing IP 413 fragmentation. For that reason it is expected that in most cases IKE 414 fragmentation will be employed in the IKE_INTERMEDIATE exchanges. 415 Section 5 of [RFC7383] contains security considerations for IKE 416 fragmentation. 418 Note, that if an attacker was able to break key exchange in real time 419 (e.g. by means of Quantum Computer), then the security of the 420 IKE_INTERMEDIATE exchange would degrade. In particular, such an 421 attacker would be able both to read data contained in the Encrypted 422 payload and to forge it. The forgery would become evident in the 423 IKE_AUTH exchange (provided the attacker cannot break employed 424 authentication mechanism), but the ability to inject forged the 425 IKE_INTERMEDIATE exchange messages with valid ICV would allow the 426 attacker to mount Denial-of-Service attack. Moreover, if in this 427 situation the negotiated prf was not secure against preimage attack 428 with known key, then the attacker could forge the IKE_INTERMEDIATE 429 exchange messages without later being detected in the IKE_AUTH 430 exchange. To do this the attacker should find the same 431 IntAuth_*_[I|R] value for the forged message as for original. 433 6. IANA Considerations 435 This document defines a new Exchange Type in the "IKEv2 Exchange 436 Types" registry: 438 43 IKE_INTERMEDIATE 440 This document also defines a new Notify Message Type in the "Notify 441 Message Types - Status Types" registry: 443 16438 INTERMEDIATE_EXCHANGE_SUPPORTED 445 7. Implementation Status 447 [Note to RFC Editor: please, remove this section before publishing 448 RFC.] 450 At the time of writing the -05 version of the draft there were at 451 least three independent interoperable implementations of this 452 specifications from the following vendors: 454 o ELVIS-PLUS 456 o strongSwan 458 o libreswan (only one IKE_INTERMEDIATE exchange is supported) 460 8. Acknowledgements 462 The idea to use an intermediate exchange between IKE_SA_INIT and 463 IKE_AUTH was first suggested by Tero Kivinen. He also helped with 464 writing an example of using IKE_INTERMEDIATE exchange (shown in 465 Appendix A). Scott Fluhrer and Daniel Van Geest identified a 466 possible problem with authentication of the IKE_INTERMEDIATE exchange 467 and helped to resolve it. Author is also grateful to Tobias Brunner 468 for raising good points concerning authentication of the 469 IKE_INTERMEDIATE exchange and to Paul Wouters who suggested text 470 improvements for the document. 472 9. References 474 9.1. Normative References 476 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 477 Requirement Levels", BCP 14, RFC 2119, 478 DOI 10.17487/RFC2119, March 1997, 479 . 481 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 482 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 483 May 2017, . 485 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 486 Kivinen, "Internet Key Exchange Protocol Version 2 487 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 488 2014, . 490 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 491 (IKEv2) Message Fragmentation", RFC 7383, 492 DOI 10.17487/RFC7383, November 2014, 493 . 495 9.2. Informative References 497 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 498 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 499 August 2017, . 501 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 502 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 503 DOI 10.17487/RFC5723, January 2010, 504 . 506 Appendix A. Example of IKE_INTERMEDIATE exchange 508 This appendix contains an example of the messages using 509 IKE_INTERMEDIATE exchange. This appendix is purely informative; if 510 it disagrees with the body of this document, the other text is 511 considered correct. 513 In this example there is one IKE_SA_INIT exchange, two 514 IKE_INTERMEDIATE exchanges followed by the IKE_AUTH exchange to 515 authenticate all initial exchanges. The xxx in the HDR(xxx,MID=yyy) 516 indicates the exchange type, and yyy tells the message id used for 517 that exchange. The keys used for each SK {} payload are indicated in 518 the parenthesis after the SK. Otherwise payload notation is same as 519 is used in [RFC7296]. 521 Initiator Responder 522 ----------- ----------- 523 HDR(IKE_SA_INIT,MID=0), 524 SAi1, KEi, Ni, 525 N(INTERMEDIATE_EXCHANGE_SUPPORTED) --> 527 <-- HDR(IKE_SA_INIT,MID=0), 528 SAr1, KEr, Nr, [CERTREQ], 529 N(INTERMEDIATE_EXCHANGE_SUPPORTED) 531 At this point peers calculate SK_* and store them as SK_*_1. SK_e[i/ 532 r]_1 and SK_a[i/r]_1 will be used to protect the first 533 IKE_INTERMEDIATE exchange and SK_p[i/r]_1 will be used for its 534 authentication. 536 Initiator Responder 537 ----------- ----------- 538 HDR(IKE_INTERMEDIATE,MID=1), 539 SK(SK_ei_1,SK_ai_1) {...} --> 541 543 <-- HDR(IKE_INTERMEDIATE,MID=1), 544 SK(SK_er_1,SK_ar_1) {...} 546 548 If after completing this IKE_INTERMEDIATE exchange SK_*_1 keys are 549 updated (e.g., as a result of a new key exchange), then peers store 550 updated keys as SK_*_2, otherwise they use SK_*_1 as SK_*_2. SK_e[i/ 551 r]_2 and SK_a[i/r]_2 will be used to protect the second 552 IKE_INTERMEDIATE exchange and SK_p[i/r]_2 will be used for its 553 authentication. 555 Initiator Responder 556 ----------- ----------- 557 HDR(IKE_INTERMEDIATE,MID=2), 558 SK(SK_ei_2,SK_ai_2) {...} --> 560 562 <-- HDR(IKE_INTERMEDIATE,MID=2), 563 SK(SK_er_2,SK_ar_2) {...} 565 567 If after completing the second IKE_INTERMEDIATE exchange SK_*_2 keys 568 are updated (e.g., as a result of a new key exchange), then peers 569 store updated keys as SK_*_3, otherwise they use SK_*_2 as SK_*_3. 570 SK_e[i/r]_3 and SK_a[i/r]_3 will be used to protect the IKE_AUTH 571 exchange, SK_p[i/r]_3 will be used for authentication and SK_d_3 will 572 be used for derivation of other keys (e.g. for Child SAs). 574 Initiator Responder 575 ----------- ----------- 576 HDR(IKE_AUTH,MID=3), 577 SK(SK_ei_3,SK_ai_3) 578 {IDi, [CERT,] [CERTREQ,] 579 [IDr,] AUTH, SAi2, TSi, TSr} --> 580 <-- HDR(IKE_AUTH,MID=3), 581 SK(SK_er_3,SK_ar_3) 582 {IDr, [CERT,] AUTH, SAr2, TSi, TSr} 584 In this example two IKE_INTERMEDIATE exchanges took place, therefore 585 SK_*_3 keys would be used as SK_* keys for further cryptographic 586 operations in the context of the created IKE SA, as defined in 587 [RFC7296]. 589 Author's Address 591 Valery Smyslov 592 ELVIS-PLUS 593 PO Box 81 594 Moscow (Zelenograd) 124460 595 RU 597 Phone: +7 495 276 0211 598 Email: svan@elvis.ru