<?xmlversion="1.0" encoding="UTF-8"?>version='1.0' encoding='UTF-8'?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[ <!ENTITYrfc2119 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">nbsp " "> <!ENTITYrfc5282 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5282.xml">zwsp "​"> <!ENTITYrfc5723 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5723.xml">nbhy "‑"> <!ENTITYrfc6928 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6928.xml"> <!ENTITY rfc7296 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml"> <!ENTITY rfc7383 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7383.xml"> <!ENTITY rfc8174 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> <!ENTITY rfc8019 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8019.xml"> <!ENTITY rfc8229 SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8229.xml">wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" ipr="trust200902"docName="draft-ietf-ipsecme-ikev2-intermediate-10"> <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <?rfc toc="yes" ?> <?rfc symrefs="yes" ?> <?rfc sortrefs="no"?> <?rfc iprnotified="no" ?> <?rfc strict="yes" ?>docName="draft-ietf-ipsecme-ikev2-intermediate-10" obsoletes="" number="9242" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" consensus="true" symRefs="true" sortRefs="true" version="3"> <front> <title abbrev="Intermediate IKEv2 Exchange">Intermediate Exchange in theIKEv2 Protocol</title>Internet Key Exchange Protocol Version 2 (IKEv2)</title> <seriesInfo name="RFC" value="9242"/> <authorinitials='V.'initials="V" surname="Smyslov"fullname='Valery Smyslov'>fullname="Valery Smyslov"> <organization>ELVIS-PLUS</organization> <address> <postal> <street>PO Box 81</street> <city>Moscow (Zelenograd)</city> <code>124460</code><country>RU</country><country>Russian Federation</country> </postal> <phone>+7 495 276 0211</phone> <email>svan@elvis.ru</email> </address> </author><date/><date month="May" year="2022"/> <area>sec</area> <workgroup>ipsecme</workgroup> <keyword>IKE_INTERMEDIATE</keyword> <keyword>Quantum Computer resistant key exchange method</keyword> <keyword>Post-quantum</keyword> <abstract> <t> This document defines a new exchange, calledIntermediate Exchange,"Intermediate Exchange", for the Internet Key ExchangeprotocolProtocol Version 2 (IKEv2). This exchange can be used for transferring large amounts of data in the process of IKEv2 Security Association (SA) establishment. An example of the need to do this is usingQuantum Computer resistantkey exchange methods resistant to Quantum Computers (QCs) for IKE SA establishment.Introducing theThe Intermediate Exchangeallows re-usingmakes it possible to use the existing IKE fragmentationmechanism, that helpsmechanism (which cannot be used in the initial IKEv2 exchange), helping to avoid IP fragmentation of large IKEmessages, but cannotmessages if they need to beused in the initialsent before IKEv2exchange.SA is established. </t> </abstract> </front> <middle> <sectiontitle="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t> The Internet Key Exchangeprotocol versionProtocol Version 2 (IKEv2) defined in <xref target="RFC7296"/>format="default"/> uses UDP as a transport for its messages. If the size of a message is larger than thePMTU,Path MTU (PMTU), IP fragmentation takes place, which has been shown to cause operationalchallengechallenges in certain network configurations and devices. The problem is described in more detail in <xref target="RFC7383"/>,format="default"/>, which also defines an extension to IKEv2 calledIKE fragmentation."IKE fragmentation". This extension allows IKE messages to be fragmented at the IKE level, eliminating possible issues caused by IP fragmentation. However, IKE fragmentation cannot be used in the initial IKEv2 exchange (IKE_SA_INIT).This limitation inIn mostcasescases, this limitation is not a problem, since the IKE_SA_INIT messages are usually small enough not to cause IP fragmentation. </t> <!-- [rfced] Would "has caused concern" or "has led to concern" (rather than "has brought a concern") be a better choice of words here? Original: Recent progress in Quantum Computing has brought a concern that classical Diffie-Hellman key exchange methods will become insecure in a relatively near future and should be replaced with Quantum Computer (QC) resistant ones. double check on this. Do they mean they dont want any change? --> <t> However, the situation has been changing recently. One example of the need to transfer largeamountamounts of data before an IKE SA is created is usingQuantum Computer resistantthe QC-resistant key exchange methods in IKEv2. Recent progress inQuantum Computingquantum computing hasbrought aled to concern that classical Diffie-Hellman key exchange methods will become insecure inathe relatively near future and should be replaced withQuantum Computer (QC) resistantQC-resistant ones. Currently, most QC-resistant key exchange methods have large public keys. If these keys are exchanged in theIKE_SA_INIT,IKE_SA_INIT exchange, thenmost probablyIP fragmentation will probably takeplace, thereforeplace; therefore, all the problems caused by it will become inevitable. </t> <t> A possible solution tothethis problem would be to use TCP as a transport for IKEv2, as defined in <xref target="RFC8229"/>.format="default"/>. However, this approach has significant drawbacks and is intended to be a"last resort"last resort when UDP transport is completely blocked by intermediate network devices. </t> <t> This specification describes a way to transfer a large amount of data in IKEv2 using UDP transport. For thispurposepurpose, the document defines a new exchange fortheIKEv2protocol,calledIntermediate Exchange"Intermediate Exchange" orIKE_INTERMEDIATE."IKE_INTERMEDIATE". One or more of these exchanges may take place right after the IKE_SA_INIT exchange and prior to the IKE_AUTH exchange. The IKE_INTERMEDIATE exchange messages can be fragmented using the IKE fragmentation mechanism, so these exchanges may be used to transfer large amounts of datawhichthat don't fit into the IKE_SA_INIT exchange without causing IP fragmentation. </t> <t> The Intermediate Exchange can be used to transfer large public keys of QC-resistant key exchange methods, but its application is not limited to this use case. This exchange can also be used whenever some dataneedneeds to be transferred before the IKE_AUTH exchange and for some reason the IKE_SA_INIT exchange is not suited for this purpose. This document defines the IKE_INTERMEDIATE exchange without tying it to any specific use case. It is expected that separate specifications will define for which purposes and how the IKE_INTERMEDIATE exchange is used in IKEv2. Some considerations must be taken into account when designing such specifications:<list style="symbols"> <t></t> <ul spacing="normal"> <li> The IKE_INTERMEDIATE exchange is not intended for bulk transfer. This document doesn't set a hard cap on the amount of data that can be safely transferred using this mechanism, as it depends on its application.ButHowever, in most cases, it is anticipated thatin most casesthe amount of data will be limited to tens ofKbytes (fewkilobytes (a few hundredKbyteskilobytes in extreme cases), which is believed to cause no network problems (see <xref target="RFC6928"/>format="default"/> as an example of experiments with sending similar amounts of data in the first TCP flight). See also <xref target="security"/>format="default"/> for the discussion of possible DoS attack vectors when the amount of data sent in the IKE_INTERMEDIATE exchange is too large.</t> <t></li> <li> It is expected that the IKE_INTERMEDIATE exchange will only be used for transferring data that is needed to establish IKE SA and not for data that can besendsent later when this SA is established.</t> </list> </t></li> </ul> </section> <section anchor="mustshouldmay"title="Terminologynumbered="true" toc="default"> <name>Terminology andNotation">Notation</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xreftarget="RFC2119" />target="RFC2119"/> <xreftarget="RFC8174" />target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> <t> It is expected that readers are familiar with the terms used in the IKEv2 specification <xref target="RFC7296" format="default"/>. Notation for the payloads contained in IKEv2 messages is defined in <xref target="RFC7296" sectionFormat="of" section="1.2" />. </t> </section> <sectiontitle="Intermediatenumbered="true" toc="default"> <name>Intermediate ExchangeDetails">Details</name> <sectiontitle="Supportnumbered="true" toc="default"> <name>Support for Intermediate ExchangeNegotiation">Negotiation</name> <t> The initiator indicates its support for Intermediate Exchange by including a notification of type INTERMEDIATE_EXCHANGE_SUPPORTED in the IKE_SA_INIT request message. If the responder also supports this exchange, it includes this notification in the response message. </t><figure align="center"><artworkalign="left"><![CDATA[align="left" name="" type="" alt=""><![CDATA[ Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni, [N(INTERMEDIATE_EXCHANGE_SUPPORTED)] --> <-- HDR, SAr1, KEr, Nr, [CERTREQ], [N(INTERMEDIATE_EXCHANGE_SUPPORTED)] ]]></artwork></figure><t> The INTERMEDIATE_EXCHANGE_SUPPORTED is a Status Type IKEv2notification. Itsnotification with Notify Message Type 16438. When it is16438,sent, the Protocol ID and SPI Size fields in the Notify payload are both set to 0. This specification doesn't define any data that this notification may contain, so the Notification Data is left empty. However, future enhancements to this specification may override this. ImplementationsMUST<bcp14>MUST</bcp14> ignore non-empty Notification Data if they don't understand its purpose. </t> </section> <sectiontitle="Usingnumbered="true" toc="default"> <name>Using IntermediateExchange">Exchange</name> <t> If both peers indicated their support for the Intermediate Exchange, the initiator may use one or more these exchanges to transfer additional data. Using the Intermediate Exchange is optional; the initiator may find it unnecessary even when support for thisexchangedexchange has been negotiated. </t> <t> The Intermediate Exchange is denoted asIKE_INTERMEDIATE,IKE_INTERMEDIATE; its Exchange Type is 43. </t><figure align="center"><artworkalign="left"><![CDATA[align="left" name="" type="" alt=""><![CDATA[ Initiator Responder ----------- ----------- HDR, ..., SK {...} --> <-- HDR, ..., SK {...} ]]></artwork></figure><t> The initiator may use several IKE_INTERMEDIATE exchanges if necessary. Since window size is initially set toone1 for both peers(Section 2.3 of <xref(<xref target="RFC7296"/>),sectionFormat="of" section="2.3" format="default"/>), these exchangesMUST<bcp14>MUST</bcp14> be sequential andMUST<bcp14>MUST</bcp14> all be completed before the IKE_AUTH exchange is initiated. The IKE SAMUST NOT<bcp14>MUST NOT</bcp14> be considered as established until the IKE_AUTH exchange is successfully completed. </t> <t> The Message IDs for IKE_INTERMEDIATE exchangesMUST<bcp14>MUST</bcp14> be chosen according to the standard IKEv2 rule, described inthe Section 2.2. of<xref target="RFC7296"/>, i.e.sectionFormat="of" section="2.2" format="default"/>, i.e., it is set to 1 for the first IKE_INTERMEDIATE exchange, 2 for the next (ifany)any), and so on. ImplementationsMUST<bcp14>MUST</bcp14> verify that Message IDs in the IKE_INTERMEDIATE messages they receive actually follow this rule. The Message ID for the first pair oftheIKE_AUTH messages is one more than the value used in the last IKE_INTERMEDIATE exchange. </t> <t> If the presence of NAT is detected in the IKE_SA_INIT exchange via NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP notifications, then the peers switch to port 4500 in the first IKE_INTERMEDIATE exchange and use this port for all subsequent exchanges, as described inSection 2.23 of<xref target="RFC7296"/>.sectionFormat="of" section="2.23" format="default"/>. </t> <t> The content of the IKE_INTERMEDIATE exchange messages depends on the data being transferred and will be defined by specifications utilizing this exchange. However, since the main motivation for the IKE_INTERMEDIATE exchange is to avoid IP fragmentation when large amounts of data need to be transferred prior toIKE_AUTH,the IKE_AUTH exchange, the Encrypted payloadMUST<bcp14>MUST</bcp14> be present in the IKE_INTERMEDIATE exchangemessagesmessages, and payloads containing large amounts of dataMUST<bcp14>MUST</bcp14> be placed inside it. This will allow IKE fragmentation <xref target="RFC7383"/>format="default"/> to take place, provided it is supported by the peers and negotiated in the initial exchange. </t> <t> <xref target="example"/>format="default"/> contains an example of using an IKE_INTERMEDIATE exchange in creating an IKE SA. </t> </section> <sectiontitle="Thenumbered="true" toc="default"> <name>The IKE_INTERMEDIATE Exchange Protection andAuthentication">Authentication</name> <section anchor="protection"title="Protectionnumbered="true" toc="default"> <name>Protection oftheIKE_INTERMEDIATEMessages">Messages</name> <t> The keys SK_e[i/r] and SK_a[i/r] for the protection of IKE_INTERMEDIATE exchangesprotectionare computed in the standard fashion, as defined inthe Section 2.14 of<xref target="RFC7296"/>.sectionFormat="of" section="2.14" format="default"/>. </t> <t> Every subsequent IKE_INTERMEDIATE exchange uses the most recently calculated IKE SA keys before this exchange is started. So, the first IKE_INTERMEDIATE exchange always uses SK_e[i/r] and SK_a[i/r] keys that were computed as a result of the IKE_SA_INIT exchange. If additional key exchange is performed in the first IKE_INTERMEDIATE exchange, resulting in the update of SK_e[i/r] and SK_a[i/r], then these updated keys are used for protection of the second IKE_INTERMEDIATE exchange. Otherwise, the original SK_e[i/r] and SK_a[i/r] keys are used again, and so on. </t> <t> Once all the IKE_INTERMEDIATE exchanges are completed, the most recently calculated SK_e[i/r] and SK_a[i/r] keys are used for protection of the IKE_AUTH exchange and allthesubsequent exchanges. </t> </section> <sectiontitle="Authenticationnumbered="true" toc="default"> <name>Authentication oftheIKE_INTERMEDIATEExchanges">Exchanges</name> <t> The IKE_INTERMEDIATE messages must be authenticated in the IKE_AUTH exchange, which is performed by adding their content into the AUTH payload calculation. It is anticipated that in many usecasescases, IKE_INTERMEDIATE messages will be fragmented using the IKE fragmentation <xref target="RFC7383"/>format="default"/> mechanism. According to <xref target="RFC7383"/>,format="default"/>, when IKE fragmentation is negotiated, the initiator may first send a request message in unfragmented form, but later turn on IKE fragmentation andre-sendresend it fragmented if no response is received after a few retransmissions. In addition, peers mayre-sendresend a fragmented message using different fragment sizes to perform simple PMTU discovery. </t> <t> The requirement to support this behavior makes authentication challenging: it is not appropriate to add on-the-wire content of the IKE_INTERMEDIATE messages into the AUTH payload calculation, because implementations are generally unawareinof which form these messages are received by peers. Instead, a more complex scheme isused --used; authentication is performed by adding the content of these messages before their encryption and possible fragmentation, so that the data to be authenticated doesn't depend on the form the messages are delivered in. </t> <t> Ifanyone or more IKE_INTERMEDIATEexchangeexchanges took place, the definition of the blob to be signed (orMAC'ed)MACed) fromthe Section 2.15 of<xref target="RFC7296"/>sectionFormat="of" section="2.15" format="default"/> is modified as follows: </t><figure align="center"> <artwork align="left"><![CDATA[<!-- [rfced] Please let us know if the <artwork> in Section 3.3.2 should be updated to the <sourcecode> element. If so, let us know what "type" attribute should be entered from the list of permissiable types here: https://www.rfc-editor.org/materials/sourcecode-types.txt Note that it is permissable to leave the "type" attribute empty. tell her that the type attribute can allow readers to strip code from documents, but if no type is allowed and the content itself is not strictly "code", it is fine to leave as artwork. we updated to sourcecode --> <sourcecode><![CDATA[ InitiatorSignedOctets = RealMsg1 | NonceRData | MACedIDForI | IntAuth ResponderSignedOctets = RealMsg2 | NonceIData | MACedIDForR | IntAuth IntAuth = IntAuth_iN | IntAuth_rN | IKE_AUTH_MID IntAuth_i1 = prf(SK_pi1, IntAuth_i1A [| IntAuth_i1P]) IntAuth_i2 = prf(SK_pi2, IntAuth_i1 | IntAuth_i2A [| IntAuth_i2P]) IntAuth_i3 = prf(SK_pi3, IntAuth_i2 | IntAuth_i3A [| IntAuth_i3P]) ... IntAuth_iN = prf(SK_piN, IntAuth_iN-1 | IntAuth_iNA [| IntAuth_iNP]) IntAuth_r1 = prf(SK_pr1, IntAuth_r1A [| IntAuth_r1P]) IntAuth_r2 = prf(SK_pr2, IntAuth_r1 | IntAuth_r2A [| IntAuth_r2P]) IntAuth_r3 = prf(SK_pr3, IntAuth_r2 | IntAuth_r3A [| IntAuth_r3P]) ... IntAuth_rN = prf(SK_prN, IntAuth_rN-1 | IntAuth_rNA [| IntAuth_rNP])]]></artwork> </figure>]]></sourcecode> <t> The essence of this modification is that a new chunk calledIntAuth"IntAuth" is appended to the string of octets that is signed (orMAC'ed)MACed) by the peers. IntAuth consists of three parts: IntAuth_iN, IntAuth_rN, and IKE_AUTH_MID. </t> <t> The IKE_AUTH_MID chunk is a value of the Message ID field from the IKE Header of the first round of the IKE_AUTH exchange. It is represented as afour octetfour-octet integer in network byte order (in other words, exactly as it appears on the wire). </t> <t> The IntAuth_iN and IntAuth_rN chunkseachrepresent the cumulative result of applying the negotiatedprfPseudorandom Function (PRF) to all IKE_INTERMEDIATE exchange messages sent during IKE SA establishment by the initiator and theresponderresponder, respectively. After the first IKE_INTERMEDIATE exchange iscompletedcomplete, peers calculate the IntAuth_i1 value by applying the negotiatedprfPRF to the content of the request message from this exchange and calculate the IntAuth_r1 value by applying the negotiatedprfPRF to the content of the response message. For everyfollowingsubsequent IKE_INTERMEDIATE exchange (ifany)any), peersre-calculaterecalculate these values asfollows. Afterfollows: after then-thnth exchange iscompletedcomplete, they compute IntAuth_[i/r]n by applying the negotiatedprfPRF to the concatenation of IntAuth_[i/r](n-1) (computed for the previous IKE_INTERMEDIATE exchange) and the content of the request (for IntAuth_in) or response (for IntAuth_rn) messages from this exchange. After all IKE_INTERMEDIATE exchanges areoverover, the resulted IntAuth_[i/r]N values (assuming N exchanges took place) are used inthecomputing the AUTH payload. </t> <t> For the purpose of calculating the IntAuth_[i/r]*valuesvalues, the content of the IKE_INTERMEDIATE messages is represented as two chunks of data: mandatoryIntAuth_[i/r]*AIntAuth_[i/r]*A, optionally followed by IntAuth_[i/r]*P. </t> <t> The IntAuth_[i/r]*A chunk consists of the sequence of octets from the first octet of the IKE Header (not including the prepended four octets of zeros, if UDP encapsulation or TCP encapsulation of ESP packets is used) to the last octet of the generic header of the Encrypted payload. The scope of IntAuth_[i/r]*A is identical to the scope of Associated Data defined for the use of AEAD algorithms in IKEv2 (seeSection 5.1 of<xref target="RFC5282"/>),sectionFormat="of" section="5.1" format="default"/>), which is stressed by using the "A" suffix in its name.Note,Note that calculation of IntAuth_[i/r]*A doesn't depend on whether an AEAD algorithm or a plain cipher is used in IKE SA. </t> <t> The IntAuth_[i/r]*P chunk is present if the Encrypted payload is not empty. It consists of the content of the Encrypted payload that is fullyformed,formed but not yet encrypted. The Initialization Vector,thePadding,thePadLengthLength, andtheIntegrity Checksum Data fields (seeSection 3.14 of<xref target="RFC7296"/>)sectionFormat="of" section="3.14" format="default"/>) are not included into the calculation. In other words, the IntAuth_[i/r]*P chunk is the inner payloads of the Encrypted payload in plaintext form, which is stressed by using the "P" suffix in its name. </t> <figurealign="center" anchor="layout" title="Dataanchor="layout"> <name>Data to Authenticate in the IKE_INTERMEDIATE ExchangeMessages">Messages</name> <artworkalign="left"><![CDATA[align="left" name="" type="" alt=""><![CDATA[ 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^ | IKE SA Initiator's SPI | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I | | IKE SA Responder's SPI | K | | | E | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Next Payload | MjVer | MnVer | Exchange Type | Flags | H | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | | Message ID | r A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Adjusted Length | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v | | | | ~ Unencrypted payloads (if any) ~ | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ | | Next Payload |C| RESERVED | Adjusted Payload Length | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | v | | | ~ Initialization Vector ~ E | | E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c ^ | | r | ~ Inner payloads (not yet encrypted) ~ P | | P | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ l v | Padding (0-255 octets) | Pad Length | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | ~ Integrity Checksum Data ~ | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v ]]></artwork> </figure> <t> <xref target="layout"/>format="default"/> illustrates the layout of the IntAuth_[i/r]*A (denoted as A) and the IntAuth_[i/r]*P (denoted as P) chunks in case the Encrypted payload is not empty. </t> <t> For the purpose of prfcalculationcalculation, the Length field in the IKE Header and the Payload Length field in the Encrypted payload header are adjusted so that they don't count the lengths of Initialization Vector, Integrity Checksum Data,PaddingPadding, and Pad Length fields. In other words, the Length field in the IKE Header (denoted as Adjusted Length in <xref target="layout"/>)format="default"/>) is set to the sum of the lengths of IntAuth_[i/r]*A and IntAuth_[i/r]*P, and the Payload Length field in the Encrypted payload header (denoted as Adjusted Payload Length in <xref target="layout"/>)format="default"/>) is set to the length of IntAuth_[i/r]*P plus the size of the Encrypted payload header (four octets). </t> <t> The prf calculationsMUST<bcp14>MUST</bcp14> be applied to whole messages only, before possible IKE fragmentation. This ensures that the IntAuth will be the same regardless of whether or not IKE fragmentation takesplace or not.place. If the message was received in fragmented form, itMUST<bcp14>MUST</bcp14> be reconstructed before calculating the prf as if it were received unfragmented. While reconstructing, the RESERVED field in the reconstructed Encrypted payload headerMUST<bcp14>MUST</bcp14> be set to the value of the RESERVED field in the Encrypted Fragment payload header from the first fragment (with the Fragment Number field set to 1). </t> <t> Note that it is possible to avoid actual reconstruction of the message by incrementally calculating prf on decrypted (or ready to be encrypted) fragments. However, care must be taken to properly replace the content of the Next Header and the Length fields so that the result of computing the prf is the same as if it were computed on the reconstructed message. </t> <t> Each calculation of IntAuth_[i/r]* uses its own keys SK_p[i/r]*, which are the most recently updated SK_p[i/r] keys available before the corresponded IKE_INTERMEDIATE exchange is started. The first IKE_INTERMEDIATE exchange always uses the SK_p[i/r] keys that were computed in the IKE_SA_INIT exchange as SK_p[i/r]1. If the first IKE_INTERMEDIATE exchange performs additional key exchange resulting in an SK_p[i/r] update, thenthisthese updated SK_p[i/r] keys are used asSK_p[i/r]2, otherwiseSK_p[i/r]2; otherwise, the original SK_p[i/r] keys are used, and so on. Note that if keys are updated, then for any given IKE_INTERMEDIATEexchangeexchange, the keys SK_e[i/r] and SK_a[i/r] used for protection of its messages (see <xref target="protection"/>)format="default"/>) and thekeyskey SK_p[i/r] for its authentication are always from the same generation. </t> </section> </section> <sectiontitle="Errornumbered="true" toc="default"> <name>Error Handling in the IKE_INTERMEDIATEExchange">Exchange</name> <t> Since messages of the IKE_INTERMEDIATE exchange are not authenticated until the IKE_AUTH exchange successfully completes, possible errors need to be handled with care. There is a trade-off between providing better diagnostics of the problem and risk of becoming part of a DoS attack.Section 2.21.1Sections <xref target="RFC7296" sectionFormat="bare" section="2.21.1" /> and2.21.2 of<xref target="RFC7296" sectionFormat="bare" section="2.21.2" /> of <xref target="RFC7296" format="default"/> describe how errors are handled in initial IKEv2 exchanges; these considerations are also applied to the IKE_INTERMEDIATE exchange witha qualification,the qualification that not all error notifications may appear in the IKE_INTERMEDIATE exchange (for example, errors concerning authentication are generally only applicable to the IKE_AUTH exchange). </t> </section> </section> <section anchor="interaction"title="Interactionnumbered="true" toc="default"> <name>Interaction withotherOther IKEv2Extensions">Extensions</name> <t> The IKE_INTERMEDIATE exchangesMAY<bcp14>MAY</bcp14> be used during the IKEv2 Session Resumption <xref target="RFC5723"/>format="default"/> between the IKE_SESSION_RESUME and the IKE_AUTH exchanges. To be able to useitit, peersMUST<bcp14>MUST</bcp14> negotiate support forintermediate exchangeIntermediate Exchange by including INTERMEDIATE_EXCHANGE_SUPPORTED notifications in the IKE_SESSION_RESUME messages.Note,Note that a flag denoting whether peers supported the IKE_INTERMEDIATE exchange is not stored in the resumption ticket and is determined each time from the IKE_SESSION_RESUME exchange. </t> </section> <section anchor="security"title="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t> The data that is transferred by means of the IKE_INTERMEDIATE exchanges is not authenticated until the subsequent IKE_AUTH exchange iscompleted.complete. However, if the data is placed inside the Encrypted payload, then it is protected from passive eavesdroppers. In addition, the peers can be certain that they receive messages from the party they performed the IKE_SA_INIT exchange with if they can successfully verify the Integrity Checksum Data of the Encrypted payload. </t> <t> The main application for the Intermediate Exchange is to transfer large amounts of data before an IKE SA is set up, without causing IP fragmentation. For thatreasonreason, it is expected thatin most casesIKE fragmentation will be employed intheIKE_INTERMEDIATEexchanges. Section 5 ofexchanges in most cases. <xref target="RFC7383"/>sectionFormat="of" section="5" format="default"/> contains security considerations for IKE fragmentation. </t> <t> Since authentication ofthepeers occurs only in the IKE_AUTH exchange, a malicious initiator may use the Intermediate Exchange to mountDenial of Servicea DoS attack on the responder. In thiscasecase, it starts creating an IKE SA, negotiates using the IntermediateExchangesExchanges, and transfers a lot of data to the responder that may also requiresomecomputationally expensive processing.ThenThen, it aborts the SA establishment before the IKE_AUTH exchange. Specifications utilizing the Intermediate ExchangeMUST NOT<bcp14>MUST NOT</bcp14> allow an unlimited number of these exchanges to take placeonat the initiator's discretion. It is recommended that these specificationsarebe defined in such away,way that the responder would know (possibly via negotiation with the initiator) the exact number of these exchanges that need to take place. In otherwords:words, after the IKE_SA_INIT exchange is complete, it is preferred that both the initiator and the responder knowafter the IKE_SA_INIT is completedthe exact number oftheIKE_INTERMEDIATE exchanges they have to perform; it isallowedpossible that some IKE_INTERMEDIATE exchanges are optional and are performedonat the initiator's discretion, butin this caseif a specification defines optional use of IKE_INTERMEDIATE, then the maximum number ofoptionalthese exchanges must be hard capped by the corresponding specification. In addition, <xref target="RFC8019"/>format="default"/> provides guidelines for the responder of how to deal with DoS attacks during IKE SA establishment. </t> <t> Note that if an attacker was able to break the key exchange in real time(e.g.(e.g., by means of aQuantum Computer),quantum computer), then the security of the IKE_INTERMEDIATE exchange would degrade. In particular, such an attacker would be ablebothto both read data contained in the Encrypted payload andtoforge it. The forgery would become evident in the IKE_AUTH exchange (provided the attacker cannot break the employed authentication mechanism), but the ability to inject forged IKE_INTERMEDIATE exchange messages with a validICVIntegrity Check Value (ICV) would allow the attacker to mount aDenial-of-ServiceDoS attack. Moreover,ifin thissituationsituation, if the negotiatedprfPRF was not secure against a second preimage attack with known key, then the attacker could forge the IKE_INTERMEDIATE exchange messages without later being detected in the IKE_AUTH exchange. To dothisthis, the attacker would find the same IntAuth_[i/r]* value for the forged message as for the original. </t> </section> <section anchor="iana"title="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t>This document defines a new Exchange Type in the "IKEv2 Exchange Types" registry:</t><figure align="center"> <artwork align="left"><![CDATA[ 43 IKE_INTERMEDIATE ]]></artwork> </figure><table align="left" anchor="IKE_INTERMEDIATE"> <name>IKEv2 Exchange Types</name> <thead> <tr> <th>Value</th> <th>Exchange Type</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>43</td> <td>IKE_INTERMEDIATE</td> <td>RFC 9242</td> </tr> </tbody> </table> <t>This document also defines a new Notify Message Type in the "IKEv2 Notify Message Types - Status Types" registry:</t><figure align="center"> <artwork align="left"><![CDATA[ 16438 INTERMEDIATE_EXCHANGE_SUPPORTED ]]></artwork> </figure> </section> <section anchor="interop" title="Implementation Status"> <t> [Note to RFC Editor: please, remove this section before publishing RFC.] </t> <t> At the time of writing the -05 version of the draft there were at least three independent interoperable implementations of this specification from the following vendors: <list style="symbols"> <t>ELVIS-PLUS</t> <t>strongSwan</t> <t>libreswan (only one IKE_INTERMEDIATE exchange is supported)</t> </list> </t> </section> <section title="Acknowledgements"> <t> The idea to use an intermediate exchange between IKE_SA_INIT and IKE_AUTH was first suggested by Tero Kivinen. He also helped with writing an example of using IKE_INTERMEDIATE exchange (shown in <xref target="example" />). Scott Fluhrer and Daniel Van Geest identified a possible problem with authentication of the IKE_INTERMEDIATE exchange and helped to resolve it. Author is grateful to Tobias Brunner who raised good questions concerning authentication of the IKE_INTERMEDIATE exchange and proposed how to make the size of authentication chunk constant regardless of the number of exchanges. Author is also grateful to Paul Wouters and to Benjamin Kaduk who suggested a lot of text improvements for the document. </t><table align="left" anchor="INTERMEDIATE_EXCHANGE_SUPPORTED"> <name>IKEv2 Notify Message Types - Status Types</name> <thead> <tr> <th>Value</th> <th>NOTIFY MESSAGES - STATUS TYPES</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>16438</td> <td>INTERMEDIATE_EXCHANGE_SUPPORTED</td> <td>RFC 9242</td> </tr> </tbody> </table> </section> </middle> <back><references title='Normative References'> &rfc2119; &rfc8174; &rfc7296; &rfc7383;<references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7383.xml"/> </references> <references> <name>Informative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5282.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5723.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6928.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8019.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8229.xml"/> </references><references title='Informative References'> &rfc5282; &rfc5723; &rfc6928; &rfc8019; &rfc8229;</references> <section anchor="example"title="Examplenumbered="true" toc="default"> <name>Example of IKE_INTERMEDIATEexchange">Exchange</name> <t> This appendix contains an example of the messages using IKE_INTERMEDIATE exchanges. This appendix is purely informative; if it disagrees with the body of this document, the other text is considered correct. </t> <t> In thisexampleexample, there is one IKE_SA_INIT exchange and two IKE_INTERMEDIATE exchanges, followed by the IKE_AUTH exchange to authenticate all initial exchanges. The xxx in the HDR(xxx,MID=yyy) indicates theexchange type,Exchange Type, and yyytellsindicates themessage idMessage ID used for that exchange. The keys used for each SK {} payload are indicated in the parenthesis after the SK. Otherwise, the payload notation is the same as is used in <xref target="RFC7296"/>.format="default"/>. </t><figure align="center"><artworkalign="left"><![CDATA[align="left" name="" type="" alt=""><![CDATA[ Initiator Responder ----------- ----------- HDR(IKE_SA_INIT,MID=0), SAi1, KEi, Ni, N(INTERMEDIATE_EXCHANGE_SUPPORTED) --> <-- HDR(IKE_SA_INIT,MID=0), SAr1, KEr, Nr, [CERTREQ], N(INTERMEDIATE_EXCHANGE_SUPPORTED) ]]></artwork></figure><t> At thispointpoint, peers calculate SK_* and store them as SK_*1. SK_e[i/r]1 and SK_a[i/r]1 will be used to protect the first IKE_INTERMEDIATEexchangeexchange, and SK_p[i/r]1 will be used for its authentication. </t><figure align="center"><artworkalign="left"><![CDATA[align="left" name="" type="" alt=""><![CDATA[ Initiator Responder ----------- ----------- HDR(IKE_INTERMEDIATE,MID=1), SK(SK_ei1,SK_ai1) {...} --> <Calculate IntAuth_i1 = prf(SK_pi1, ...)> <-- HDR(IKE_INTERMEDIATE,MID=1), SK(SK_er1,SK_ar1) {...} <Calculate IntAuth_r1 = prf(SK_pr1, ...)> ]]></artwork></figure><t> Ifafter completing this IKE_INTERMEDIATE exchangethe SK_*1 keys are updated (e.g., as a result of a new keyexchange),exchange) after completing this IKE_INTERMEDIATE exchange, then the peers store the updated keys asSK_*2, otherwiseSK_*2; otherwise, they use SK_*1 as SK_*2. SK_e[i/r]2 and SK_a[i/r]2 will be used to protect the second IKE_INTERMEDIATEexchangeexchange, and SK_p[i/r]2 will be used for its authentication. </t><figure align="center"><artworkalign="left"><![CDATA[align="left" name="" type="" alt=""><![CDATA[ Initiator Responder ----------- ----------- HDR(IKE_INTERMEDIATE,MID=2), SK(SK_ei2,SK_ai2) {...} --> <Calculate IntAuth_i2 = prf(SK_pi2, ...)> <-- HDR(IKE_INTERMEDIATE,MID=2), SK(SK_er2,SK_ar2) {...} <Calculate IntAuth_r2 = prf(SK_pr2, ...)> ]]></artwork></figure><t> Ifafter completing the second IKE_INTERMEDIATE exchangethe SK_*2 keys are updated (e.g., as a result of a new keyexchange),exchange) after completing the second IKE_INTERMEDIATE exchange, then the peers store the updated keys asSK_*3, otherwiseSK_*3; otherwise, they use SK_*2 as SK_*3. SK_e[i/r]3 and SK_a[i/r]3 will be used to protect the IKE_AUTH exchange, SK_p[i/r]3 will be used for authentication, and SK_d3 will be used for derivation of other keys(e.g.(e.g., for Child SAs). </t><figure align="center"><artworkalign="left"><![CDATA[align="left" name="" type="" alt=""><![CDATA[ Initiator Responder ----------- ----------- HDR(IKE_AUTH,MID=3), SK(SK_ei3,SK_ai3) {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} --> <-- HDR(IKE_AUTH,MID=3), SK(SK_er3,SK_ar3) {IDr, [CERT,] AUTH, SAr2, TSi, TSr} ]]></artwork></figure><t> In thisexampleexample, two IKE_INTERMEDIATE exchanges tookplace, thereforeplace; therefore, SK_*3 keys would be used as SK_* keys for further cryptographic operations in the context of the created IKE SA, as defined in <xref target="RFC7296"/>.format="default"/>. </t> </section> <section numbered="false" toc="default"> <name>Acknowledgements</name> <t> The idea to use an Intermediate Exchange between the IKE_SA_INIT and IKE_AUTH exchanges was first suggested by <contact fullname="Tero Kivinen"/>. He also helped to write the example IKE_INTERMEDIATE exchange shown in <xref target="example" format="default"/>. <contact fullname="Scott Fluhrer"/> and <contact fullname="Daniel Van Geest"/> identified a possible problem with authentication of the IKE_INTERMEDIATE exchange and helped to resolve it. The author is grateful to <contact fullname="Tobias Brunner"/>, who raised good questions concerning authentication of the IKE_INTERMEDIATE exchange and proposed how to make the size of authentication chunks constant regardless of the number of exchanges. The author is also grateful to <contact fullname="Paul Wouters"/> and <contact fullname="Benjamin Kaduk"/>, who suggested a lot of text improvements for the document. </t> </section> </back> </rfc>