idnits 2.17.1 draft-smyslov-ipsecme-ikev2-aux-00.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 (January 25, 2018) is 2254 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 133, 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 January 25, 2018 5 Expires: July 29, 2018 7 Auxiliary Exchange in the IKEv2 Protocol 8 draft-smyslov-ipsecme-ikev2-aux-00 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 July 29, 2018. 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. Keying Material and Authentication . . . . . . . . . . . 4 60 3.4. IKE Fragmentation . . . . . . . . . . . . . . . . . . . . 5 61 4. Interaction with other IKEv2 Extensions . . . . . . . . . . . 5 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 8.2. Informative References . . . . . . . . . . . . . . . . . 7 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 The Internet Key Exchange protocol version 2 (IKEv2) defined in 73 [RFC7296] uses UDP as a transport for its messages. If size of the 74 messages is large enough, IP fragmentation may take place that may 75 interfere badly with some network devices. The problem is described 76 in more detail in [RFC7383], which also defines an extension to the 77 IKEv2 called IKE Fragmentation. This extension allows IKE messages 78 to be fragmented at IKE level, which eliminates possible issues 79 caused by IP fragmentation. However, the IKE Fragmentation cannot be 80 used in the initial IKEv2 exchange, IKE_SA_INIT. This limitation in 81 most cases is not a problem, since the IKE_SA_INIT messages used to 82 be small enough to not cause IP fragmentation. 84 Recent progress in Quantum Computing has brought a concern that 85 classical Diffie-Hellman key exchange methods will become insecure in 86 a relatively near future and should be replaced with Quantum Computer 87 (QC) resistant ones. Currently most of QC-resistant key exchange 88 methods have large public keys. If these keys are exchanged in the 89 IKE_SA_INIT, then most probably IP fragmentation would take place, 90 therefore all the problems caused by it would become inevitable. 92 A possible solution would be to use TCP as a transport for IKEv2, as 93 described in [RFC8229]. However this approach has significant 94 drawbacks and is intended to be a "last resort" when UDP transport is 95 blocked by intermediate network devices. 97 This document defines a new exchange for the IKEv2 protocol, called 98 Auxiliary Exchange or IKE_AUX. One or more these exchanges may take 99 place right after the IKE_SA_INIT exchange and prior to the IKE_AUTH 100 exchange. These exchanges may be used to exchange large amounts of 101 data, which don't fit into the IKE_SA_INIT exchange without causing 102 IP fragmentation. The IKE_AUX messages can be fragmented using IKE 103 Fragmentation mechanism. 105 While ability to transfer large public keys of QC-resistant methods 106 was a primary motivation for the Auxiliary Exchange, its application 107 is not limited to this use case. This exchange may be used whenever 108 large messages need to be exchanged before the IKE_AUTH exchange. It 109 is expected that separate specifications will define how and when the 110 IKE_AUX exchange is used in the IKEv2. 112 2. Terminology and Notation 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in BCP 117 14 [RFC2119] [RFC8174] when, and only when, they appear in all 118 capitals, as shown here. 120 3. Auxiliary Exchange Details 122 3.1. Support for Auxiliary Exchange Negotiation 124 The initiator indicates its support for Auxiliary Exchange by 125 including a notification of type AUX_EXCHANGE_SUPPORTED in the 126 IKE_SA_INIT request message. If the responder also supports this 127 exchange, it includes this notification in the response message. 129 Initiator Responder 130 ----------- ----------- 131 HDR, SAi1, KEi, Ni, 132 [N(AUX_EXCHANGE_SUPPORTED)] --> 133 <-- HDR, SAr1, KEr, Nr, [CERTREQ], 134 [N(AUX_EXCHANGE_SUPPORTED)] 136 The AUX_EXCHANGE_SUPPORTED is a Status Type IKEv2 notification. Its 137 Notify Message Type is . Protocol ID and SPI Size are 138 both set to 0. This specification doesn't define any data this 139 notification may contain, so the Notification Data is left empty. 140 However, other specifications may override this. Implementations 141 MUST ignore the non-empty Notification Data if they don't understand 142 its purpose. 144 3.2. Using Auxiliary Exchange 146 If both peers indicated their support for Auxiliary Exchange, the 147 initiator may use one or more these exchanges to transfer additional 148 data, which are not fit into the IKE_SA_INIT exchange. Using the 149 IKE_AUX exchange is optional, the initiator may find it unnecessary 150 after completing the IKE_SA_INIT exchange. 152 The Auxiliary Exchange is denoted as IKE_AUX, its Exchange Type is 153 . 155 Initiator Responder 156 ----------- ----------- 157 HDR, ..., SK {...} --> 158 <-- HDR, ..., SK {...} 160 The initiator may use several IKE_AUX exchanges if necessary. Since 161 initiator's Window Size is initially set to one (Section 2.3 of 162 [RFC7296]), These exchanges MUST follow each other and MUST all be 163 completed before the IKE_AUTH exchange is initiated. The IKE SA MUST 164 NOT be considered as established until the IKE_AUTH exchange is 165 successfully completed. 167 The Message IDs for the IKE_AUX exchanges MUST be chosen by the 168 standard IKEv2 rule, described in the Section 2.2. of [RFC7296], i.e. 169 it is set to 1 for the first IKE_AUX exchange, 2 for the next (if 170 any) and so on. The message ID for the first pair of the IKE_AUTH 171 messages is one more than the last IKE_AUX Message ID. 173 The content of the IKE_AUX messages depends on the data being 174 transferred and will be defined by specifications utilizing this 175 exchange. However, since the main motivation for IKE_AUX is to avoid 176 IP fragmentation when large amount of data need to be transferred 177 prior to IKE_AUTH, the Encrypted payload SHOULD be present in the 178 IKE_AUX messages and payloads containing large data SHOULD be placed 179 inside. This will allow IKE Fragmentation [RFC7383] to take place, 180 provided it is supported by the peers and negotiated in the initial 181 exchange. 183 3.3. Keying Material and Authentication 185 The keys SK_e and SK_a for the Encrypted payload in the IKE_AUX 186 exchanges are computed in a standard fashion, as defined in the 187 Section 2.14 of [RFC7296]. Note that this may be redefined by other 188 specifications utilizing the IKE_AUX exchange (e.g. in case the 189 IKE_AUX is used to exchange additional keys which must later be 190 stirred into the SKEYSEED). 192 The data transferred in the IKE_AUX exchanges must be authenticated 193 in the IKE_AUTH exchange. For this purpose the definition of the 194 blob to be signed (or MAC'ed) from the Section 2.15 of [RFC7296] is 195 modified as follows in case of at least one IKE_AUX exchange takes 196 place: 198 InitiatorSignedOctets = RealMessage1 | AUX_I | NonceRData | MACedIDForI 199 AUX_I = ICV_INIT_1 | ICV_INIT_2 | ICV_INIT_3 ... 201 ResponderSignedOctets = RealMessage2 | AUX_R | NonceIData | MACedIDForR 202 AUX_R = ICV_RESP_1 | ICV_RESP_2 | ICV_RESP_3 ... 204 ICV_INIT_1, ICV_INIT_2, ICV_INIT_3, etc. represent the content of the 205 Integrity Checksum Data field from the Encrypted payloads (or 206 Encrypted Fragment payloads) from all the IKE_AUX messages sent by 207 the initiator in an order of increasing MessageIDs (and increasing 208 Fragment Numbers for the same Message ID). ICV_RESP_1 | ICV_RESP_2 | 209 ICV_RESP_3 etc. are defined similarly for the messages sent by the 210 responder. 212 3.4. IKE Fragmentation 214 If both peers indicated their support for IKE Fragmentation, then 215 some additional restrictions are applied to ensure that the values of 216 Integrity Checksum Data is unambiguous. These restrictions MUST be 217 applied to the IKE_AUX exchanges only and MAY be lifted once all 218 these exchanges are over. 220 The responder MUST send the IKE_AUX response in the same form 221 (fragmented or not) as the request message. The initiator MUST NOT 222 switch from unfragmented to fragmented request in a single IKE_AUX 223 exchange - either the request is sent unfragmented and retransmitted 224 until unfragmented response is received (applicable if message size 225 is small and no IP fragmentation is expected), or the request is 226 fragmented from the beginning of exchange. The initiator MAY however 227 send either fragmented or unfragmented messages in different IKE_AUX 228 exchanges. The initiator SHOULD use IKE Fragmentation if the size of 229 request (or the expected size of response) is large enough to cause 230 IP fragmentation. The PMTU discovery for IKE Fragmentation as 231 defined in Section 2.5.2 of [RFC7383] MUST NOT be used for the 232 IKE_AUX exchanges. 234 4. Interaction with other IKEv2 Extensions 236 The IKE_AUTH exchanges may be used in the IKEv2 Session Resumption 237 [RFC5723] between the IKE_SESSION_RESUME and the IKE_AUTH exchanges. 239 5. Security Considerations 241 The data that is transferred by means of the IKE_AUX exchanges is not 242 authenticated until the subsequent IKE_AUTH exchange is completed. 243 However, if the data is placed inside the Encrypted payload, then it 244 is protected from passive eavesdroppers. In addition the peers can 245 be certain that they receives messages from the party he/she 246 performed the IKE_SA_INIT with if they can successfully verify the 247 Integrity Checksum Data of the Encrypted payload. 249 The main application for Auxiliary Exchange is to transfer large 250 amount of data before IKE SA is set up without causing IP 251 fragmentation. For that reason it is expected that in most cases IKE 252 Fragmentation will be employed in the IKE_AUX exchanges. Section 5 253 of [RFC7383] contains security considerations for IKE Fragmentation. 255 Note, that if an attacker was able to break key exchange from the 256 IKE_SA_INIT in real time (e.g. by means of Quantum Computer), then 257 the security of IKE_AUX would degrage. In particular, such an 258 attacker would be able both to read data contained in the Encrypted 259 payload and to forge it. THe forgery would become evident in the 260 IKE_AUTH exchange (provided the attacker caanot break employed 261 authentication mechanism), but the ability to inject forged IKE_AUX 262 messages with valid ICV would allow the attacker to mount Denial-of- 263 Service attack. 265 6. IANA Considerations 267 This document defines a new Exchange Type in the "IKEv2 Exchange 268 Types" registry: 270 IKE_AUX 272 This document also defines a new Notify Message Types in the "Notify 273 Message Types - Status Types" registry: 275 AUX_EXCHANGE_SUPPORTED 277 7. Acknowledgements 279 The idea to use an intermediate exchange between IKE_SA_INIT and 280 IKE_AUTH was first suggested by Tero Kivinen. 282 8. References 283 8.1. Normative References 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, 287 DOI 10.17487/RFC2119, March 1997, . 290 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 291 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 292 May 2017, . 294 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 295 Kivinen, "Internet Key Exchange Protocol Version 2 296 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 297 2014, . 299 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 300 (IKEv2) Message Fragmentation", RFC 7383, 301 DOI 10.17487/RFC7383, November 2014, . 304 8.2. Informative References 306 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 307 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 308 August 2017, . 310 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 311 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 312 DOI 10.17487/RFC5723, January 2010, . 315 Author's Address 317 Valery Smyslov 318 ELVIS-PLUS 319 PO Box 81 320 Moscow (Zelenograd) 124460 321 RU 323 Phone: +7 495 276 0211 324 Email: svan@elvis.ru