idnits 2.17.1 draft-smyslov-ipsecme-ikev2-aux-02.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 (December 3, 2018) is 1971 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 139, 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 December 3, 2018 5 Expires: June 6, 2019 7 Intermediate Exchange in the IKEv2 Protocol 8 draft-smyslov-ipsecme-ikev2-aux-02 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 http://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 June 6, 2019. 37 Copyright Notice 39 Copyright (c) 2018 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 (http://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 INTERMEDIATE Exchange Protection and Authentication . 5 60 3.3.1. Protection of the INTERMEDIATE Messages . . . . . . . 5 61 3.3.2. Authentication of the INTERMEDIATE Exchanges . . . . 5 62 3.4. Error Handling in the INTERMEDIATE Exchange . . . . . . . 8 63 4. Interaction with other IKEv2 Extensions . . . . . . . . . . . 8 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 69 8.2. Informative References . . . . . . . . . . . . . . . . . 10 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 The Internet Key Exchange protocol version 2 (IKEv2) defined in 75 [RFC7296] uses UDP as a transport for its messages. If size of the 76 messages is large enough, IP fragmentation takes place, that may 77 interfere badly with some network devices. The problem is described 78 in more detail in [RFC7383], which also defines an extension to the 79 IKEv2 called IKE Fragmentation. This extension allows IKE messages 80 to be fragmented at IKE level, eliminating possible issues caused by 81 IP fragmentation. However, the IKE Fragmentation cannot be used in 82 the initial IKEv2 exchange, IKE_SA_INIT. This limitation in most 83 cases is not a problem, since the IKE_SA_INIT messages used to be 84 small enough not to cause IP fragmentation. 86 Recent progress in Quantum Computing has brought a concern that 87 classical Diffie-Hellman key exchange methods will become insecure in 88 a relatively near future and should be replaced with Quantum Computer 89 (QC) resistant ones. Currently most of QC-resistant key exchange 90 methods have large public keys. If these keys are exchanged in the 91 IKE_SA_INIT, then most probably IP fragmentation will take place, 92 therefore all the problems caused by it will become inevitable. 94 A possible solution to the problem would be to use TCP as a transport 95 for IKEv2, as defined in [RFC8229]. However this approach has 96 significant drawbacks and is intended to be a "last resort" when UDP 97 transport is completely blocked by intermediate network devices. 99 This document defines a new exchange for the IKEv2 protocol, called 100 Intermediate Exchange or INTERMEDIATE. One or more these exchanges 101 may take place right after the IKE_SA_INIT exchange and prior to the 102 IKE_AUTH exchange. The INTERMEDIATE exchange messages can be 103 fragmented using IKE Fragmentation mechanism, so these exchanges may 104 be used to transfer large amounts of data which don't fit into the 105 IKE_SA_INIT exchange without causing IP fragmentation. 107 While ability to transfer large public keys of QC-resistant key 108 exchange methods is a primary motivation for introducing of the 109 Intermediate Exchange, its application is not limited to this use 110 case. This exchange may be used whenever some data need to be 111 transferred before the IKE_AUTH exchange and for some reason the 112 IKE_SA_INIT exchange is not suited for this purpose. This document 113 defines the INTERMEDIATE exchange without tying it to any specific 114 use case. It is expected that separate specifications will define 115 for which purposes and how the INTERMEDIATE exchange is used in the 116 IKEv2. 118 2. Terminology and Notation 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 122 "OPTIONAL" in this document are to be interpreted as described in BCP 123 14 [RFC2119] [RFC8174] when, and only when, they appear in all 124 capitals, as shown here. 126 3. Intermediate Exchange Details 128 3.1. Support for Intermediate Exchange Negotiation 130 The initiator indicates its support for Intermediate Exchange by 131 including a notification of type INTERMEDIATE_EXCHANGE_SUPPORTED in 132 the IKE_SA_INIT request message. If the responder also supports this 133 exchange, it includes this notification in the response message. 135 Initiator Responder 136 ----------- ----------- 137 HDR, SAi1, KEi, Ni, 138 [N(INTERMEDIATE_EXCHANGE_SUPPORTED)] --> 139 <-- HDR, SAr1, KEr, Nr, [CERTREQ], 140 [N(INTERMEDIATE_EXCHANGE_SUPPORTED)] 142 The INTERMEDIATE_EXCHANGE_SUPPORTED is a Status Type IKEv2 143 notification. Its Notify Message Type is . Protocol ID 144 and SPI Size are both set to 0. This specification doesn't define 145 any data this notification may contain, so the Notification Data is 146 left empty. However, future enhancements of this specification may 147 override this. Implementations MUST ignore the non-empty 148 Notification Data if they don't understand its purpose. 150 3.2. Using Intermediate Exchange 152 If both peers indicated their support for the Intermediate Exchange, 153 the initiator may use one or more these exchanges to transfer 154 additional data. Using the INTERMEDIATE exchange is optional, the 155 initiator may find it unnecessary after completing the IKE_SA_INIT 156 exchange. 158 The Intermediate Exchange is denoted as INTERMEDIATE, its Exchange 159 Type is . 161 Initiator Responder 162 ----------- ----------- 163 HDR, ..., SK {...} --> 164 <-- HDR, ..., SK {...} 166 The initiator may use several INTERMEDIATE exchanges if necessary. 167 Since initiator's Window Size is initially set to one (Section 2.3 of 168 [RFC7296]), these exchanges MUST follow each other and MUST all be 169 completed before the IKE_AUTH exchange is initiated. The IKE SA MUST 170 NOT be considered as established until the IKE_AUTH exchange is 171 successfully completed. 173 The Message IDs for the INTERMEDIATE exchanges MUST be chosen 174 according to the standard IKEv2 rule, described in the Section 2.2. 175 of [RFC7296], i.e. it is set to 1 for the first INTERMEDIATE 176 exchange, 2 for the next (if any) and so on. The message ID for the 177 first pair of the IKE_AUTH messages is one more than the one that was 178 used in the last INTERMEDIATE exchange. 180 If the presence of NAT is detected in the IKE_SA_INIT exchange via 181 NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP 182 notifications, then the peers MUST switch to port 4500 immediately 183 once this exchange is completed, i.e. in the first INTERMEDIATE 184 exchange. 186 The content of the INTERMEDIATE exchange messages depends on the data 187 being transferred and will be defined by specifications utilizing 188 this exchange. However, since the main motivation for the 189 INTERMEDIATE exchange is to avoid IP fragmentation when large amount 190 of data need to be transferred prior to IKE_AUTH, the Encrypted 191 payload MUST be present in the INTERMEDIATE exchange messages and 192 payloads containing large data MUST be placed inside. This will 193 allow IKE Fragmentation [RFC7383] to take place, provided it is 194 supported by the peers and negotiated in the initial exchange. 196 3.3. The INTERMEDIATE Exchange Protection and Authentication 198 3.3.1. Protection of the INTERMEDIATE Messages 200 The keys SK_e[i/r] and SK_a[i/r] for the Encrypted payload in the 201 INTERMEDIATE exchanges are computed in a standard fashion, as defined 202 in the Section 2.14 of [RFC7296]. Every subsequent INTERMEDIATE 203 exchange uses the most recently calculated keys before this exchange 204 is started. The first INTERMEDIATE exchange always uses SK_e[i/r] 205 and SK_a[i/r] keys that were computed as result the IKE_SA_INIT 206 exchange. If this INTERMEDIATE exchange performs additional key 207 exchange resulting in the update of SK_e[i/r] and SK_a[i/r], then 208 these updated keys are used for encryption and authentication of next 209 INTERMEDIATE exchange, otherwise the current keys are used, and so 210 on. 212 3.3.2. Authentication of the INTERMEDIATE Exchanges 214 The data transferred in the INTERMEDIATE exchanges must be 215 authenticated in the IKE_AUTH exchange. For this purpose the 216 definition of the blob to be signed (or MAC'ed) from the Section 2.15 217 of [RFC7296] is modified as follows: 219 InitiatorSignedOctets = RealMsg1 | NonceRData | MACedIDForI [| IntAuth] 220 ResponderSignedOctets = RealMsg2 | NonceIData | MACedIDForR [| IntAuth] 222 IntAuth = IntAuth_1 | [| IntAuth_2 [| IntAuth_3]] ... 224 IntAuth_1 = IntAuth_1_I | IntAuth_1_R 225 IntAuth_2 = IntAuth_2_I | IntAuth_2_R 226 IntAuth_3 = IntAuth_3_I | IntAuth_3_R 227 ... 229 IntAuth_1_I = prf(SK_pi_1, [IntAuth_1_I_P |] IntAuth_1_I_A) 230 IntAuth_2_I = prf(SK_pi_2, [IntAuth_2_I_P |] IntAuth_2_I_A) 231 IntAuth_3_I = prf(SK_pi_3, [IntAuth_3_I_P |] IntAuth_3_I_A) 232 ... 234 IntAuth_1_R = prf(SK_pr_1, [IntAuth_1_R_P |] IntAuth_1_R_A) 235 IntAuth_2_R = prf(SK_pr_2, [IntAuth_2_R_P |] IntAuth_2_R_A) 236 IntAuth_3_R = prf(SK_pr_3, [IntAuth_3_R_P |] IntAuth_3_R_A) 237 ... 239 IntAuth_1_I/IntAuth_1_R, IntAuth_2_I/IntAuth_2_R, IntAuth_3_I/ 240 IntAuth_3_R, etc. represent the results of applying the negotiated 241 prf to the content of the INTERMEDIATE messages sent by the initiator 242 (IntAuth_*_I) and by the responder (IntAuth_*_R) in an order of 243 increasing Message IDs (i.e. in an order the INTERMEDIATE exchanges 244 took place). The prf is applied to the two chunks of data: optional 245 IntAuth_*_[I/R]_P and mandatory IntAuth_*_[I/R]_A. The IntAuth_*_[I/ 246 R]_A chunk lasts from the first octet of the IKE Header (not 247 including prepended four octets of zeros, if port 4500 is used) to 248 the last octet of the Encrypted Payload header. The IntAuth_*_[I/ 249 R]_P chunk is present if the Encrypted payload is not empty. It 250 consists of the not yet encrypted content of the Encrypted payload, 251 excluding Initialization Vector, Padding, Pad Length and Integrity 252 Checksum Data fields (see 3.14 of [RFC7296] for description of the 253 Encrypted payload). In other words, the IntAuth_*_[I/R]_P chunk is 254 the inner payloads of the Encrypted payload in plaintext form. 256 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^ 259 | IKE SA Initiator's SPI | | | 260 | | | | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I | 262 | IKE SA Responder's SPI | K | 263 | | E | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 265 | Next Payload | MjVer | MnVer | Exchange Type | Flags | H | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | 267 | Message ID | r A 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 269 | Length | | | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v | 271 | | | 272 ~ Unencrypted payloads (if any) ~ | 273 | | | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ | 275 | Next Payload |C| RESERVED | Payload Length | | | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E v 277 | Initialization Vector | n 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c ^ 279 | | r | 280 ~ Inner payloads (not yet encrypted) ~ P 281 | | P | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ l v 283 | Padding (0-255 octets) | Pad Length | d 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 285 ~ Integrity Checksum Data ~ | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v 288 Figure 1: Data to Authenticate in the INTERMEDIATE Exchange Messages 290 Figure 1 illustrates the layout of the IntAuth_*_[I/R]_P (denoted as 291 P) and the IntAuth_*_[I/R]_A (denoted as A) chunks in case the 292 Encrypted payload is not empty. 294 The calculations are applied to whole messages only, before possible 295 fragmentation. This ensures that the IntAuth will be the same 296 regardless of whether fragmentation takes place or not ([RFC7383] 297 allows sending first unfragmented message and then trying 298 fragmentation in case of no reply). 300 Each calculation of IntAuth_*_[I/R] uses its own key SK_p[i/r]_*, 301 which is the most recently updated SK_p[i/r] key available before the 302 corresponded INTERMEDIATE exchange is started. The first 303 INTERMEDIATE exchange always uses SK_p[i/r] key that was computed in 304 the IKE_SA_INIT as SK_p[i/r]_1. If the first INTERMEDIATE exchange 305 performs additional key exchange resulting in SK_p[i/r] update, then 306 this updated SK_p[i/r] is used as SK_p[i/r]_2, otherwise the original 307 SK_p[i/r] is used, and so on. Note, that if keys are updated then 308 for any given INTERMEDIATE exchange the keys SK_e[i/r] and SK_a[i/r] 309 used for its messages protection (see Section 3.3.1) and the keys 310 SK_p[i/r] for its authentication are always from the same generation. 312 3.4. Error Handling in the INTERMEDIATE Exchange 314 Since messages of the INTERMEDIATE exchange are not authenticated 315 until the IKE_AUTH exchange successfully completes, possible errors 316 need to be handled carefully. There is a trade-off between providing 317 a better diagnostics of the problem and a risk to become a part of 318 DoS attack. See Section 2.21.1 and 2.21.2 of [RFC7296] describe how 319 errors are handled in initial IKEv2 exchanges, these considerations 320 are applied to the INTERMEDIATE exchange too. 322 4. Interaction with other IKEv2 Extensions 324 The INTERMEDIATE exchanges MAY be used in the IKEv2 Session 325 Resumption [RFC5723] between the IKE_SESSION_RESUME and the IKE_AUTH 326 exchanges. 328 5. Security Considerations 330 The data that is transferred by means of the INTERMEDIATE exchanges 331 is not authenticated until the subsequent IKE_AUTH exchange is 332 completed. However, if the data is placed inside the Encrypted 333 payload, then it is protected from passive eavesdroppers. In 334 addition the peers can be certain that they receives messages from 335 the party he/she performed the IKE_SA_INIT with if they can 336 successfully verify the Integrity Checksum Data of the Encrypted 337 payload. 339 The main application for Intermediate Exchange is to transfer large 340 amount of data before IKE SA is set up without causing IP 341 fragmentation. For that reason it is expected that in most cases IKE 342 Fragmentation will be employed in the INTERMEDIATE exchanges. 343 Section 5 of [RFC7383] contains security considerations for IKE 344 Fragmentation. 346 Note, that if an attacker was able to break key exchange in real time 347 (e.g. by means of Quantum Computer), then the security of the 348 INTERMEDIATE exchange would degrade. In particular, such an attacker 349 would be able both to read data contained in the Encrypted payload 350 and to forge it. The forgery would become evident in the IKE_AUTH 351 exchange (provided the attacker cannot break employed authentication 352 mechanism), but the ability to inject forged the INTERMEDIATE 353 exchange messages with valid ICV would allow the attacker to mount 354 Denial-of-Service attack. Moreover, if in this situation the 355 negotiated prf was not secure against preimage attack with known key, 356 then the attacker could forge the INTERMEDIATE exchange messages 357 without later being detected in the IKE_AUTH exchange. To do this 358 the attacker should find the same IntAuth_*_[I|R] value for the 359 forged message as for original. 361 6. IANA Considerations 363 This document defines a new Exchange Type in the "IKEv2 Exchange 364 Types" registry: 366 INTERMEDIATE 368 This document also defines a new Notify Message Types in the "Notify 369 Message Types - Status Types" registry: 371 INTERMEDIATE_EXCHANGE_SUPPORTED 373 7. Acknowledgements 375 The idea to use an intermediate exchange between IKE_SA_INIT and 376 IKE_AUTH was first suggested by Tero Kivinen. Scott Fluhrer and 377 Daniel Van Geest identified a possible problem with authentication of 378 the INTERMEDIATE exchange and helped to resolve it. 380 8. References 382 8.1. Normative References 384 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 385 Requirement Levels", BCP 14, RFC 2119, 386 DOI 10.17487/RFC2119, March 1997, . 389 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 390 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 391 May 2017, . 393 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 394 Kivinen, "Internet Key Exchange Protocol Version 2 395 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 396 2014, . 398 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 399 (IKEv2) Message Fragmentation", RFC 7383, 400 DOI 10.17487/RFC7383, November 2014, . 403 8.2. Informative References 405 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 406 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 407 August 2017, . 409 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 410 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 411 DOI 10.17487/RFC5723, January 2010, . 414 Author's Address 416 Valery Smyslov 417 ELVIS-PLUS 418 PO Box 81 419 Moscow (Zelenograd) 124460 420 RU 422 Phone: +7 495 276 0211 423 Email: svan@elvis.ru