Network Working Group V. Smyslov Internet-Draft ELVIS-PLUS Intended status: Standards TrackJuly 27,December 3, 2018 Expires:January 28,June 6, 2019AuxiliaryIntermediate Exchange in the IKEv2 Protocoldraft-smyslov-ipsecme-ikev2-aux-01draft-smyslov-ipsecme-ikev2-aux-02 Abstract This documents defines a new exchange, calledAuxiliaryIntermediate Exchange, for the Internet Key Exchange protocol Version 2 (IKEv2). This exchange can be used for transferring large amount of data in the process of IKEv2 Security Association (SA) establishment. IntroducingAuxiliaryIntermediate Exchange allowsto re-usere-using existing IKE Fragmentation mechanism, that helps to avoid IP fragmentation of large IKE messages, but cannot be used in the initial IKEv2 exchange. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire onJanuary 28,June 6, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 3.AuxiliaryIntermediate Exchange Details . . . . . . . . . . . . . . . ..3 3.1. Support forAuxiliaryIntermediate Exchange Negotiation . . . . . ..3 3.2. UsingAuxiliaryIntermediate Exchange . . . . . . . . . . . . . . ..4 3.3.IKE_AUXThe INTERMEDIATE Exchange Protection and Authentication .. . . . . . . . . 45 3.3.1. Protection ofIKE_AUXthe INTERMEDIATE Messages . . . . . . .. . . . 45 3.3.2. Authentication ofIKE_AUXthe INTERMEDIATE Exchanges . . . .. . . . .5 3.4. Error Handling inIKE_AUX . . . . . . . . .the INTERMEDIATE Exchange . . . . . . .78 4. Interaction with other IKEv2 Extensions . . . . . . . . . . .78 5. Security Considerations . . . . . . . . . . . . . . . . . . .78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . .89 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .89 8. References . . . . . . . . . . . . . . . . . . . . . . . . .89 8.1. Normative References . . . . . . . . . . . . . . . . . .89 8.2. Informative References . . . . . . . . . . . . . . . . .910 Author's Address . . . . . . . . . . . . . . . . . . . . . . . .910 1. Introduction The Internet Key Exchange protocol version 2 (IKEv2) defined in [RFC7296] uses UDP as a transport for its messages. If size of the messages is large enough, IP fragmentation takesplaceplace, that may interfere badly with some network devices. The problem is described in more detail in [RFC7383], which also defines an extension to the IKEv2 called IKE Fragmentation. This extension allows IKE messages to be fragmented at IKE level, eliminating possible issues caused by IP fragmentation. However, the IKE Fragmentation cannot be used in the initial IKEv2 exchange, IKE_SA_INIT. This limitation in most cases is not a problem, since the IKE_SA_INIT messages used to be small enoughtonot to cause IP fragmentation. 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. Currently most of QC-resistant key exchange methods have large public keys. If these keys are exchanged in the IKE_SA_INIT, then most probably IP fragmentationwouldwill take place, therefore all the problems caused by itwouldwill become inevitable. A possible solution to the problem would be to use TCP as a transport for IKEv2, asdescribeddefined in [RFC8229]. However this approach has significant drawbacks and is intended to be a "last resort" when UDP transport is completely blocked by intermediate network devices. This document defines a new exchange for the IKEv2 protocol, calledAuxiliaryIntermediate Exchange orIKE_AUX.INTERMEDIATE. One or more these exchanges may take place right after the IKE_SA_INIT exchange and prior to the IKE_AUTH exchange.TheseThe INTERMEDIATE exchange messages can be fragmented using IKE Fragmentation mechanism, so these exchanges may be used toexchangetransfer large amounts ofdata,data which don't fit into the IKE_SA_INIT exchange without causing IP fragmentation.The IKE_AUX messages can be fragmented using IKE Fragmentation mechanism.While ability to transfer large public keys of QC-resistant key exchange methodswasis a primary motivation for introducing of theAuxiliaryIntermediate Exchange, its application is not limited to this use case. This exchange may be used whenever some data need 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 INTERMEDIATE exchange without tying it to any specific use case. It is expected that separate specifications will definehowfor which purposes andwhenhow theIKE_AUXINTERMEDIATE exchange is used in the IKEv2. 2. Terminology and Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3.AuxiliaryIntermediate Exchange Details 3.1. Support forAuxiliaryIntermediate Exchange Negotiation The initiator indicates its support forAuxiliaryIntermediate Exchange by including a notification of typeAUX_EXCHANGE_SUPPORTEDINTERMEDIATE_EXCHANGE_SUPPORTED in the IKE_SA_INIT request message. If the responder also supports this exchange, it includes this notification in the response message. Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni,[N(AUX_EXCHANGE_SUPPORTED)][N(INTERMEDIATE_EXCHANGE_SUPPORTED)] --> <-- HDR, SAr1, KEr, Nr, [CERTREQ],[N(AUX_EXCHANGE_SUPPORTED)][N(INTERMEDIATE_EXCHANGE_SUPPORTED)] TheAUX_EXCHANGE_SUPPORTEDINTERMEDIATE_EXCHANGE_SUPPORTED is a Status Type IKEv2 notification. Its Notify Message Type is <TBA by IANA>. Protocol ID and SPI Size are both set to 0. This specification doesn't define any data this notification may contain, so the Notification Data is left empty. However, future enhancements of this specification may override this. Implementations MUST ignore the non-empty Notification Data if they don't understand its purpose. 3.2. UsingAuxiliaryIntermediate Exchange If both peers indicated their support for theAuxiliaryIntermediate Exchange, the initiator may use one or more these exchanges to transfer additional data. Using theIKE_AUXINTERMEDIATE exchange is optional, the initiator may find it unnecessary after completing the IKE_SA_INIT exchange. TheAuxiliaryIntermediate Exchange is denoted asIKE_AUX,INTERMEDIATE, its Exchange Type is <TBA by IANA>. Initiator Responder ----------- ----------- HDR, ..., SK {...} --> <-- HDR, ..., SK {...} The initiator may use severalIKE_AUXINTERMEDIATE exchanges if necessary. Since initiator's Window Size is initially set to one (Section 2.3 of [RFC7296]), these exchanges MUST follow each other and MUST all be completed before the IKE_AUTH exchange is initiated. The IKE SA MUST NOT be considered as established until the IKE_AUTH exchange is successfully completed. The Message IDs for theIKE_AUXINTERMEDIATE exchanges MUST be chosen according to the standard IKEv2 rule, described in the Section 2.2. of [RFC7296], i.e. it is set to 1 for the firstIKE_AUXINTERMEDIATE exchange, 2 for the next (if any) and so on. The message ID for the first pair of the IKE_AUTH messages is one more than the one that was used in the lastIKE_AUX Message ID.INTERMEDIATE exchange. 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 MUST switch to port 4500 immediately once this exchange is completed, i.e. in the first INTERMEDIATE exchange. The content of theIKE_AUXINTERMEDIATE exchange messages depends on the data being transferred and will be defined by specifications utilizing this exchange. However, since the main motivation forIKE_AUXthe INTERMEDIATE exchange is to avoid IP fragmentation when large amount of data need to be transferred prior to IKE_AUTH, the Encrypted payloadSHOULDMUST be present in theIKE_AUXINTERMEDIATE exchange messages and payloads containing large dataSHOULDMUST be placed inside. This will allow IKE Fragmentation [RFC7383] to take place, provided it is supported by the peers and negotiated in the initial exchange. 3.3.IKE_AUXThe INTERMEDIATE Exchange Protection and Authentication 3.3.1. Protection ofIKE_AUXthe INTERMEDIATE Messages The keys SK_e[i/r] and SK_a[i/r] for the Encrypted payload in theIKE_AUXINTERMEDIATE exchanges are computed in a standard fashion, as defined in the Section 2.14 of [RFC7296]. Every subsequentIKE_AUXINTERMEDIATE exchange uses the most recently calculated keys before this exchange is started. The firstIKE_AUXINTERMEDIATE exchange always uses SK_e[i/r] and SK_a[i/r] keys that were computed as result the IKE_SA_INIT exchange. If thisIKE_AUXINTERMEDIATE exchange performs additional key exchange resulting in the update of SK_e[i/r] and SK_a[i/r], then these updated keys are used for encryption and authentication of nextIKE_AUXINTERMEDIATE exchange, otherwise the current keys are used, and so on. 3.3.2. Authentication ofIKE_AUXthe INTERMEDIATE Exchanges The data transferred in theIKE_AUXINTERMEDIATE exchanges must be authenticated in the IKE_AUTH exchange. For this purpose the definition of the blob to be signed (or MAC'ed) from the Section 2.15 of [RFC7296] is modified as follows: InitiatorSignedOctets =RealMessage1 | AUX_IRealMsg1 | NonceRData | MACedIDForIAUX_I = [AUX_PRF_I_1 [| AUX_PRF_I_2[|AUX_PRF_I_3]]] ... AUX_PRF_I_1IntAuth] ResponderSignedOctets =prf(SK_pi_1, IKE_AUX_I_1_HRealMsg2 | NonceIData | MACedIDForR [|IKE_AUX_I_1_E]) AUX_PRF_I_2IntAuth] IntAuth =prf(SK_pi_2, IKE_AUX_I_2_HIntAuth_1 | [|IKE_AUX_I_2_E]) AUX_PRF_I_3 = prf(SK_pi_3, IKE_AUX_I_3_HIntAuth_2 [|IKE_AUX_I_3_E])IntAuth_3]] ...ResponderSignedOctetsIntAuth_1 =RealMessage2IntAuth_1_I |AUX_RIntAuth_1_R IntAuth_2 = IntAuth_2_I |NonceIDataIntAuth_2_R IntAuth_3 = IntAuth_3_I |MACedIDForR AUX_RIntAuth_3_R ... IntAuth_1_I =[AUX_PRF_R_1 [| AUX_PRF_R_2 [| AUX_PRF_R_3]]]prf(SK_pi_1, [IntAuth_1_I_P |] IntAuth_1_I_A) IntAuth_2_I = prf(SK_pi_2, [IntAuth_2_I_P |] IntAuth_2_I_A) IntAuth_3_I = prf(SK_pi_3, [IntAuth_3_I_P |] IntAuth_3_I_A) ...AUX_PRF_R_1IntAuth_1_R = prf(SK_pr_1,IKE_AUX_R_1_H [| IKE_AUX_R_1_E]) AUX_PRF_R_2[IntAuth_1_R_P |] IntAuth_1_R_A) IntAuth_2_R = prf(SK_pr_2,IKE_AUX_R_2_H [| IKE_AUX_R_2_E]) AUX_PRF_R_3[IntAuth_2_R_P |] IntAuth_2_R_A) IntAuth_3_R = prf(SK_pr_3,IKE_AUX_R_3_H [| IKE_AUX_R_3_E])[IntAuth_3_R_P |] IntAuth_3_R_A) ...AUX_PRF_I_1/AUX_PRF_R_1, AUX_PRF_I_2/AUX_PRF_R_2, AUX_PRF_I_3/ AUX_PRF_R_1,IntAuth_1_I/IntAuth_1_R, IntAuth_2_I/IntAuth_2_R, IntAuth_3_I/ IntAuth_3_R, etc. represent the results of applying the negotiated prf to the content of theIKE_AUXINTERMEDIATE messages sent by the initiator(AUX_PRF_I_*)(IntAuth_*_I) and by the responder(AUX_PRF_R_*)(IntAuth_*_R) in an order of increasingMessageIDsMessage IDs (i.e. in an order theIKE_AUXINTERMEDIATE exchanges took place). The prf is applied to the two chunks of data:IKE_AUX_[I/ R]_*_Hoptional IntAuth_*_[I/R]_P andoptionally IKE_AUX_[I/R]_*_E.mandatory IntAuth_*_[I/R]_A. TheIKE_AUX_[I/R]_*_HIntAuth_*_[I/ R]_A chunk lasts from the first octet of the IKE Header (not including prepended four octets of zeros, ifany)port 4500 is used) to the last octet of the Encrypted Payloadheader (or to the end of the message in case the Encrypted payload is not present).header. TheIKE_AUX_[I/R]_*_EIntAuth_*_[I/ R]_P chunk iscomputedpresent if the Encrypted payload ispresent andnot empty. It consists of the not yet encrypted content of the Encrypted payload, excluding Initialization Vector, Padding, Pad Length and Integrity Checksum Data fields (see 3.14 of [RFC7296] for description of the Encrypted payload). In other words, theIKE_AUX_[I/R]_*_EIntAuth_*_[I/R]_P chunk is the inner payloads of the Encrypted payload in plaintext form. 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 | rHA +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Length | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v | | | | ~ Unencrypted payloads (if any) ~ | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ | | Next Payload |C| RESERVED | Payload Length | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E v | Initialization Vector | n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c ^ | | r | ~ Inner payloads (not yet encrypted) ~EP | | P | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ l v | Padding (0-255 octets) | Pad Length | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ Integrity Checksum Data ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v Figure 1: Data to Authenticate inIKE_AUXthe INTERMEDIATE Exchange Messages Figure 1 illustrates the layout of theIKE_AUX_*_*_HIntAuth_*_[I/R]_P (denoted asH)P) and theIKE_AUX_*_*_EIntAuth_*_[I/R]_A (denoted asE)A) chunks in case the Encrypted payload ispresent in the message. Note, that while the Encrypted payload isnotrequired to be present in the IKE_AUX messages, the intended purpose of this exchange is to allow transferring large amount of data utilizing IKE fragmentation, so in most cases the Encrypted payload will be present.empty. The calculations are applied to whole messages only, before possible fragmentation. This ensures that theAUX_I/AUX_RIntAuth will be the same regardless of whether fragmentation takes place or not ([RFC7383] allows sending first unfragmented message and then trying fragmentation in case of no reply). Each calculation ofAUX_PRF_[I/R]_*IntAuth_*_[I/R] uses its own key SK_p[i/r]_*, which is the most recently updated SK_p[i/r] key available before the correspondedIKE_AUXINTERMEDIATE exchange is started. The firstIKE_AUXINTERMEDIATE exchange always uses SK_p[i/r] key that was computed in the IKE_SA_INIT as SK_p[i/r]_1. If the firstIKE_AUXINTERMEDIATE exchange performs additional key exchange resulting in SK_p[i/r] update, then this updated SK_p[i/r] is used as SK_p[i/r]_2, otherwise the original SK_p[i/r] is used, and so on. Note, that if keys are updated then for any givenIKE_AUXINTERMEDIATE exchange the keys SK_e[i/r] and SK_a[i/r] used forIKE_AUXits messages protection (see Section 3.3.1) and the keys SK_p[i/r] fortheirits authentication are always from the same generation. 3.4. Error Handling inIKE_AUXthe INTERMEDIATE Exchange SinceIKE_AUXmessages of the INTERMEDIATE exchange are not authenticated until the IKE_AUTH exchange successfully completes, possible errors need to be handled carefully. There is a trade-off between providing a better diagnostics of the problem and a risk to become a part of DoS attack. See Section 2.21.1 and 2.21.2 of [RFC7296] describe how errors are handled in initial IKEv2 exchanges, these considerations are applied toan IKE_AUXthe INTERMEDIATE exchange too. 4. Interaction with other IKEv2 Extensions TheIKE_AUTHINTERMEDIATE exchangesmayMAY be used in the IKEv2 Session Resumption [RFC5723] between the IKE_SESSION_RESUME and the IKE_AUTH exchanges. 5. Security Considerations The data that is transferred by means of theIKE_AUXINTERMEDIATE exchanges is not authenticated until the subsequent IKE_AUTH exchange is completed. 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 receives messages from the party he/she performed the IKE_SA_INIT with if they can successfully verify the Integrity Checksum Data of the Encrypted payload. The main application forAuxiliaryIntermediate Exchange is to transfer large amount of data before IKE SA is set up without causing IP fragmentation. For that reason it is expected that in most cases IKE Fragmentation will be employed in theIKE_AUXINTERMEDIATE exchanges. Section 5 of [RFC7383] contains security considerations for IKE Fragmentation. Note, that if an attacker was able to break key exchange in real time (e.g. by means of Quantum Computer), then the security ofIKE_AUXthe INTERMEDIATE exchange would degrade. In particular, such an attacker would be able both to read data contained in the Encrypted payload and to forge it. The forgery would become evident in the IKE_AUTH exchange (provided the attacker cannot break employed authentication mechanism), but the ability to inject forgedIKE_AUXthe INTERMEDIATE exchange messages with valid ICV would allow the attacker to mount Denial-of-Service attack. Moreover, if in this situation the negotiated prf was not secure against preimage attack with known key, then the attacker could forgeIKE_AUXthe INTERMEDIATE exchange messages without later being detected in the IKE_AUTH exchange. To do this the attacker should find the sameAUX_PRF_*_*IntAuth_*_[I|R] value for the forged message as for original. 6. IANA Considerations This document defines a new Exchange Type in the "IKEv2 Exchange Types" registry: <TBA>IKE_AUXINTERMEDIATE This document also defines a new Notify Message Types in the "Notify Message Types - Status Types" registry: <TBA>AUX_EXCHANGE_SUPPORTEDINTERMEDIATE_EXCHANGE_SUPPORTED 7. Acknowledgements The idea to use an intermediate exchange between IKE_SA_INIT and IKE_AUTH was first suggested by Tero Kivinen. Scott Fluhrer and Daniel Van Geest identified a possible problem with authentication ofIKE_AUXthe INTERMEDIATE exchange and helped to resolve it. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc- editor.org/info/rfc2119>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <https://www.rfc-editor.org/info/rfc7296>. [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation", RFC 7383, DOI 10.17487/RFC7383, November 2014, <https://www.rfc- editor.org/info/rfc7383>. 8.2. Informative References [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, August 2017, <https://www.rfc-editor.org/info/rfc8229>. [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, DOI 10.17487/RFC5723, January 2010, <https://www.rfc- editor.org/info/rfc5723>. Author's Address Valery Smyslov ELVIS-PLUS PO Box 81 Moscow (Zelenograd) 124460 RU Phone: +7 495 276 0211 Email: svan@elvis.ru