idnits 2.17.1 draft-smyslov-ipsecme-ikev2-aux-01.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 (July 27, 2018) is 2093 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 136, 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 July 27, 2018 5 Expires: January 28, 2019 7 Auxiliary Exchange in the IKEv2 Protocol 8 draft-smyslov-ipsecme-ikev2-aux-01 10 Abstract 12 This documents defines a new exchange, called Auxiliary Exchange, for 13 the Internet Key Exchange protocol Version 2 (IKEv2). This exchange 14 can be used for transferring large amount of data in the process of 15 IKEv2 Security Association (SA) establishment. Introducing Auxiliary 16 Exchange allows to re-use existing IKE Fragmentation mechanism, that 17 helps to avoid IP fragmentation of large IKE messages, but cannot be 18 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 January 28, 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. Auxiliary Exchange Details . . . . . . . . . . . . . . . . . 3 57 3.1. Support for Auxiliary Exchange Negotiation . . . . . . . 3 58 3.2. Using Auxiliary Exchange . . . . . . . . . . . . . . . . 4 59 3.3. IKE_AUX Protection and Authentication . . . . . . . . . . 4 60 3.3.1. Protection of IKE_AUX Messages . . . . . . . . . . . 4 61 3.3.2. Authentication of IKE_AUX Exchanges . . . . . . . . . 5 62 3.4. Error Handling in IKE_AUX . . . . . . . . . . . . . . . . 7 63 4. Interaction with other IKEv2 Extensions . . . . . . . . . . . 7 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 8.2. Informative References . . . . . . . . . . . . . . . . . 9 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 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 to not 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 would take place, 92 therefore all the problems caused by it would become inevitable. 94 A possible solution to the problem would be to use TCP as a transport 95 for IKEv2, as described in [RFC8229]. However this approach has 96 significant drawbacks and is intended to be a "last resort" when UDP 97 transport is blocked by intermediate network devices. 99 This document defines a new exchange for the IKEv2 protocol, called 100 Auxiliary Exchange or IKE_AUX. One or more these exchanges may take 101 place right after the IKE_SA_INIT exchange and prior to the IKE_AUTH 102 exchange. These exchanges may be used to exchange large amounts of 103 data, which don't fit into the IKE_SA_INIT exchange without causing 104 IP fragmentation. The IKE_AUX messages can be fragmented using IKE 105 Fragmentation mechanism. 107 While ability to transfer large public keys of QC-resistant key 108 exchange methods was a primary motivation for the Auxiliary Exchange, 109 its application is not limited to this use case. This exchange may 110 be used whenever some data need to be transferred before the IKE_AUTH 111 exchange and for some reason the IKE_SA_INIT exchange is not suited 112 for this purpose. It is expected that separate specifications will 113 define how and when the IKE_AUX exchange is used in the IKEv2. 115 2. Terminology and Notation 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in BCP 120 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 3. Auxiliary Exchange Details 125 3.1. Support for Auxiliary Exchange Negotiation 127 The initiator indicates its support for Auxiliary Exchange by 128 including a notification of type AUX_EXCHANGE_SUPPORTED in the 129 IKE_SA_INIT request message. If the responder also supports this 130 exchange, it includes this notification in the response message. 132 Initiator Responder 133 ----------- ----------- 134 HDR, SAi1, KEi, Ni, 135 [N(AUX_EXCHANGE_SUPPORTED)] --> 136 <-- HDR, SAr1, KEr, Nr, [CERTREQ], 137 [N(AUX_EXCHANGE_SUPPORTED)] 139 The AUX_EXCHANGE_SUPPORTED is a Status Type IKEv2 notification. Its 140 Notify Message Type is . Protocol ID and SPI Size are 141 both set to 0. This specification doesn't define any data this 142 notification may contain, so the Notification Data is left empty. 143 However, future enhancements of this specification may override this. 145 Implementations MUST ignore the non-empty Notification Data if they 146 don't understand its purpose. 148 3.2. Using Auxiliary Exchange 150 If both peers indicated their support for the Auxiliary Exchange, the 151 initiator may use one or more these exchanges to transfer additional 152 data. Using the IKE_AUX exchange is optional, the initiator may find 153 it unnecessary after completing the IKE_SA_INIT exchange. 155 The Auxiliary Exchange is denoted as IKE_AUX, its Exchange Type is 156 . 158 Initiator Responder 159 ----------- ----------- 160 HDR, ..., SK {...} --> 161 <-- HDR, ..., SK {...} 163 The initiator may use several IKE_AUX exchanges if necessary. Since 164 initiator's Window Size is initially set to one (Section 2.3 of 165 [RFC7296]), these exchanges MUST follow each other and MUST all be 166 completed before the IKE_AUTH exchange is initiated. The IKE SA MUST 167 NOT be considered as established until the IKE_AUTH exchange is 168 successfully completed. 170 The Message IDs for the IKE_AUX exchanges MUST be chosen according to 171 the standard IKEv2 rule, described in the Section 2.2. of [RFC7296], 172 i.e. it is set to 1 for the first IKE_AUX exchange, 2 for the next 173 (if any) and so on. The message ID for the first pair of the 174 IKE_AUTH messages is one more than the last IKE_AUX Message ID. 176 The content of the IKE_AUX messages depends on the data being 177 transferred and will be defined by specifications utilizing this 178 exchange. However, since the main motivation for IKE_AUX is to avoid 179 IP fragmentation when large amount of data need to be transferred 180 prior to IKE_AUTH, the Encrypted payload SHOULD be present in the 181 IKE_AUX messages and payloads containing large data SHOULD be placed 182 inside. This will allow IKE Fragmentation [RFC7383] to take place, 183 provided it is supported by the peers and negotiated in the initial 184 exchange. 186 3.3. IKE_AUX Protection and Authentication 188 3.3.1. Protection of IKE_AUX Messages 190 The keys SK_e[i/r] and SK_a[i/r] for the Encrypted payload in the 191 IKE_AUX exchanges are computed in a standard fashion, as defined in 192 the Section 2.14 of [RFC7296]. Every subsequent IKE_AUX exchange 193 uses the most recently calculated keys before this exchange is 194 started. The first IKE_AUX exchange always uses SK_e[i/r] and 195 SK_a[i/r] keys that were computed as result the IKE_SA_INIT exchange. 196 If this IKE_AUX exchange performs additional key exchange resulting 197 in the update of SK_e[i/r] and SK_a[i/r], then these updated keys are 198 used for encryption and authentication of next IKE_AUX exchange, 199 otherwise the current keys are used, and so on. 201 3.3.2. Authentication of IKE_AUX Exchanges 203 The data transferred in the IKE_AUX exchanges must be authenticated 204 in the IKE_AUTH exchange. For this purpose the definition of the 205 blob to be signed (or MAC'ed) from the Section 2.15 of [RFC7296] is 206 modified as follows: 208 InitiatorSignedOctets = RealMessage1 | AUX_I | NonceRData | MACedIDForI 209 AUX_I = [AUX_PRF_I_1 [| AUX_PRF_I_2 [| AUX_PRF_I_3]]] ... 210 AUX_PRF_I_1 = prf(SK_pi_1, IKE_AUX_I_1_H [| IKE_AUX_I_1_E]) 211 AUX_PRF_I_2 = prf(SK_pi_2, IKE_AUX_I_2_H [| IKE_AUX_I_2_E]) 212 AUX_PRF_I_3 = prf(SK_pi_3, IKE_AUX_I_3_H [| IKE_AUX_I_3_E]) 213 ... 215 ResponderSignedOctets = RealMessage2 | AUX_R | NonceIData | MACedIDForR 216 AUX_R = [AUX_PRF_R_1 [| AUX_PRF_R_2 [| AUX_PRF_R_3]]] ... 217 AUX_PRF_R_1 = prf(SK_pr_1, IKE_AUX_R_1_H [| IKE_AUX_R_1_E]) 218 AUX_PRF_R_2 = prf(SK_pr_2, IKE_AUX_R_2_H [| IKE_AUX_R_2_E]) 219 AUX_PRF_R_3 = prf(SK_pr_3, IKE_AUX_R_3_H [| IKE_AUX_R_3_E]) 220 ... 222 AUX_PRF_I_1/AUX_PRF_R_1, AUX_PRF_I_2/AUX_PRF_R_2, AUX_PRF_I_3/ 223 AUX_PRF_R_1, etc. represent the results of applying the negotiated 224 prf to the content of the IKE_AUX messages sent by the initiator 225 (AUX_PRF_I_*) by the responder (AUX_PRF_R_*) in an order of 226 increasing MessageIDs (i.e. in an order the IKE_AUX exchanges took 227 place). The prf is applied to the two chunks of data: IKE_AUX_[I/ 228 R]_*_H and optionally IKE_AUX_[I/R]_*_E. The IKE_AUX_[I/R]_*_H chunk 229 lasts from the first octet of the IKE Header (not including prepended 230 four octets of zeros, if any) to the last octet of the Encrypted 231 Payload header (or to the end of the message in case the Encrypted 232 payload is not present). The IKE_AUX_[I/R]_*_E chunk is computed if 233 the Encrypted payload is present and consists of the not yet 234 encrypted content of the Encrypted payload, excluding Initialization 235 Vector, Padding, Pad Length and Integrity Checksum Data fields (see 236 3.14 of [RFC7296] for description of the Encrypted payload). In 237 other words, the IKE_AUX_[I/R]_*_E chunk is the inner payloads of the 238 Encrypted payload in plaintext form. 240 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^ 243 | IKE SA Initiator's SPI | | | 244 | | | | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I | 246 | IKE SA Responder's SPI | K | 247 | | E | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 249 | Next Payload | MjVer | MnVer | Exchange Type | Flags | H | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | 251 | Message ID | r H 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 253 | Length | | | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v | 255 | | | 256 ~ Unencrypted payloads (if any) ~ | 257 | | | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ | 259 | Next Payload |C| RESERVED | Payload Length | | | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E v 261 | Initialization Vector | n 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c ^ 263 | | r | 264 ~ Inner payloads (not yet encrypted) ~ E 265 | | P | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ l v 267 | Padding (0-255 octets) | Pad Length | d 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 269 ~ Integrity Checksum Data ~ | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v 272 Figure 1: Data to Authenticate in IKE_AUX Exchange 274 Figure 1 illustrates the layout of the IKE_AUX_*_*_H (denoted as H) 275 and the IKE_AUX_*_*_E (denoted as E) chunks in case the Encrypted 276 payload is present in the message. Note, that while the Encrypted 277 payload is not required to be present in the IKE_AUX messages, the 278 intended purpose of this exchange is to allow transferring large 279 amount of data utilizing IKE fragmentation, so in most cases the 280 Encrypted payload will be present. 282 The calculations are applied to whole messages only, before possible 283 fragmentation. This ensures that the AUX_I/AUX_R will be the same 284 regardless of whether fragmentation takes place or not ([RFC7383] 285 allows sending first unfragmented message and then trying 286 fragmentation in case of no reply). 288 Each calculation of AUX_PRF_[I/R]_* uses its own key SK_p[i/r]_*, 289 which is the most recently updated SK_p[i/r] key available before the 290 corresponded IKE_AUX exchange is started. The first IKE_AUX exchange 291 always uses SK_p[i/r] key that was computed in the IKE_SA_INIT as 292 SK_p[i/r]_1. If the first IKE_AUX exchange performs additional key 293 exchange resulting in SK_p[i/r] update, then this updated SK_p[i/r] 294 is used as SK_p[i/r]_2, otherwise the original SK_p[i/r] is used, and 295 so on. Note, that if keys are updated then for any given IKE_AUX 296 exchange the keys SK_e[i/r] and SK_a[i/r] used for IKE_AUX messages 297 protection (see Section 3.3.1) and the keys SK_p[i/r] for their 298 authentication are always from the same generation. 300 3.4. Error Handling in IKE_AUX 302 Since IKE_AUX messages are not authenticated until the IKE_AUTH 303 exchange successfully completes, possible errors need to be handled 304 carefully. There is a trade-off between providing a better 305 diagnostics of the problem and a risk to become a part of DoS attack. 306 See Section 2.21.1 and 2.21.2 of [RFC7296] describe how errors are 307 handled in initial IKEv2 exchanges, these considerations are applied 308 to an IKE_AUX exchange too. 310 4. Interaction with other IKEv2 Extensions 312 The IKE_AUTH exchanges may be used in the IKEv2 Session Resumption 313 [RFC5723] between the IKE_SESSION_RESUME and the IKE_AUTH exchanges. 315 5. Security Considerations 317 The data that is transferred by means of the IKE_AUX exchanges is not 318 authenticated until the subsequent IKE_AUTH exchange is completed. 319 However, if the data is placed inside the Encrypted payload, then it 320 is protected from passive eavesdroppers. In addition the peers can 321 be certain that they receives messages from the party he/she 322 performed the IKE_SA_INIT with if they can successfully verify the 323 Integrity Checksum Data of the Encrypted payload. 325 The main application for Auxiliary Exchange is to transfer large 326 amount of data before IKE SA is set up without causing IP 327 fragmentation. For that reason it is expected that in most cases IKE 328 Fragmentation will be employed in the IKE_AUX exchanges. Section 5 329 of [RFC7383] contains security considerations for IKE Fragmentation. 331 Note, that if an attacker was able to break key exchange in real time 332 (e.g. by means of Quantum Computer), then the security of IKE_AUX 333 would degrade. In particular, such an attacker would be able both to 334 read data contained in the Encrypted payload and to forge it. The 335 forgery would become evident in the IKE_AUTH exchange (provided the 336 attacker cannot break employed authentication mechanism), but the 337 ability to inject forged IKE_AUX messages with valid ICV would allow 338 the attacker to mount Denial-of-Service attack. Moreover, if in this 339 situation the negotiated prf was not secure against preimage attack 340 with known key, then the attacker could forge IKE_AUX messages 341 without later being detected in the IKE_AUTH exchange. To do this 342 the attacker should find the same AUX_PRF_*_* value for the forged 343 message as for original. 345 6. IANA Considerations 347 This document defines a new Exchange Type in the "IKEv2 Exchange 348 Types" registry: 350 IKE_AUX 352 This document also defines a new Notify Message Types in the "Notify 353 Message Types - Status Types" registry: 355 AUX_EXCHANGE_SUPPORTED 357 7. Acknowledgements 359 The idea to use an intermediate exchange between IKE_SA_INIT and 360 IKE_AUTH was first suggested by Tero Kivinen. Scott Fluhrer and 361 Daniel Van Geest identified a possible problem with authentication of 362 IKE_AUX exchange and helped to resolve it. 364 8. References 366 8.1. Normative References 368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 369 Requirement Levels", BCP 14, RFC 2119, 370 DOI 10.17487/RFC2119, March 1997, . 373 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 374 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 375 May 2017, . 377 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 378 Kivinen, "Internet Key Exchange Protocol Version 2 379 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 380 2014, . 382 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 383 (IKEv2) Message Fragmentation", RFC 7383, 384 DOI 10.17487/RFC7383, November 2014, . 387 8.2. Informative References 389 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 390 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 391 August 2017, . 393 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 394 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 395 DOI 10.17487/RFC5723, January 2010, . 398 Author's Address 400 Valery Smyslov 401 ELVIS-PLUS 402 PO Box 81 403 Moscow (Zelenograd) 124460 404 RU 406 Phone: +7 495 276 0211 407 Email: svan@elvis.ru