Intermediate Exchange in the IKEv2 Protocol
draft-ietf-ipsecme-ikev2-intermediate-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 9242.
|
|
|---|---|---|---|
| Author | Valery Smyslov | ||
| Last updated | 2019-12-16 (Latest revision 2019-07-24) | ||
| Replaces | draft-smyslov-ipsecme-ikev2-aux | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Associated WG milestone |
|
||
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 9242 (Proposed Standard) | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-ipsecme-ikev2-intermediate-03
Meeting Information
WGs info
LPWAN
SCHC
Data / Time
- Date: Thursday Nov 9th, 2023;
- Time: 17:00 local time (CET), 8:00AM Pacific, 11:00AM Eastern, Midnight 0:00 China
Meeting Information
The joint SCHC session will take place during Thursday Session IV on Nov 9th, 2023; that's from 17:00 to 18:30 local time (CET == UTC+1). The meeting will take place in rooms Berlin 3/4.
-
Chairs
o Alexander Pelov <a@ackl.io> (in-person chair)
o Pascal Thubert <pthubert@cisco.com> (remote chair)
o Laurent Toutain (in-person delegate) -
Responsible AD
o Eric Vyncke -
Room: Berlin 3/4
#x27;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 the IKE_INTERMEDIATE 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 first IKE_INTERMEDIATE 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 last IKE_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 IKE_INTERMEDIATE exchange. 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 Smyslov Expires June 18, 2020 [Page 4] Internet-Draft Intermediate IKEv2 Exchange December 2019 amount of data need to be transferred prior to IKE_AUTH, the Encrypted payload MUST be present in the IKE_INTERMEDIATE exchange messages and payloads containing large data MUST 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. The IKE_INTERMEDIATE Exchange Protection and Authentication 3.3.1. Protection of the IKE_INTERMEDIATE Messages The keys SK_e[i/r] and SK_a[i/r] for the Encrypted payload in the IKE_INTERMEDIATE exchanges are computed in a standard fashion, as defined in the Section 2.14 of [RFC7296]. 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 the first IKE_INTERMEDIATE 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 the next IKE_INTERMEDIATE exchange, otherwise the current keys are used, and so on. 3.3.2. Authentication of the IKE_INTERMEDIATE Exchanges The content of the IKE_INTERMEDIATE 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 = RealMsg1 | NonceRData | MACedIDForI [| IntAuth] ResponderSignedOctets = RealMsg2 | NonceIData | MACedIDForR [| IntAuth] IntAuth = IntAuth_1 | [| IntAuth_2 [| IntAuth_3]] ... IntAuth_1 = IntAuth_1_I | IntAuth_1_R IntAuth_2 = IntAuth_2_I | IntAuth_2_R IntAuth_3 = IntAuth_3_I | IntAuth_3_R... IntAuth_1_I = prf(SK_pi_1, IntAuth_1_I_A [| IntAuth_1_I_P]) IntAuth_2_I = prf(SK_pi_2, IntAuth_2_I_A [| IntAuth_2_I_P]) IntAuth_3_I = prf(SK_pi_3, IntAuth_3_I_A [| IntAuth_3_I_P]) ... IntAuth_1_R = prf(SK_pr_1, IntAuth_1_R_A [| IntAuth_1_R_P]) IntAuth_2_R = prf(SK_pr_2, IntAuth_2_R_A [| IntAuth_2_R_P]) IntAuth_3_R = prf(SK_pr_3, IntAuth_3_R_A [| IntAuth_3_R_P]) ... Smyslov Expires June 18, 2020 [Page 5] Internet-Draft Intermediate IKEv2 Exchange December 2019 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 the IKE_INTERMEDIATE messages sent by the initiator (IntAuth_*_I) and by the responder (IntAuth_*_R) in an order of increasing Message IDs (i.e. in an order the IKE_INTERMEDIATE exchanges took place). The prf is applied to the two chunks of data: mandatory IntAuth_*_[I/R]_A and optional IntAuth_*_[I/R]_P. The IntAuth_*_[I/R]_A chunk lasts from the first octet of the IKE Header (not including prepended four octets of zeros, if port 4500 is used) to the last octet of the Encrypted Payload header. The IntAuth_*_[I/R]_P chunk is present if the Encrypted payload is not 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, the IntAuth_*_[I/R]_P chunk is the inner payloads of the Encrypted payload in plaintext form. Smyslov Expires June 18, 2020 [Page 6] Internet-Draft Intermediate IKEv2 Exchange December 2019 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 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E v | Initialization Vector | n +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c ^ | | r | ~ Inner payloads (not yet encrypted) ~ P | | P | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ l v | Padding (0-255 octets) | Pad Length | d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ Integrity Checksum Data ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v Figure 1: Data to Authenticate in the IKE_INTERMEDIATE Exchange Messages Figure 1 illustrates the layout of the IntAuth_*_[I/R]_P (denoted as P) and the IntAuth_*_[I/R]_A (denoted as A) chunks in case the Encrypted payload is not empty. For the purpose of prf calculation 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 and Padding (along with Pad Length field). In other words, the Length field in the IKE header (denoted as Adjusted Length in Figure 1) 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 Smyslov Expires June 18, 2020 [Page 7] Internet-Draft Intermediate IKEv2 Exchange December 2019 in Figure 1) is set to the length of IntAuth_*_[I/R]_P plus the size of the Payload header (four octets). The prf calculations MUST be applied to whole messages only, before possible IKE Fragmentation. This ensures that the IntAuth will be the same regardless of whether IKE Fragmentation takes place or not. This is important since [RFC7383] allows sending first unfragmented message and then resending it in fragmented form in case of no reply is received. If the message was received in fragmented form, it should be reconstructed before calculating prf as if it were received unfragmented. The RESERVED field in the recontructed Encrypted Payload header MUST be set to the value of the RESERVED field in the Encrypted Fragment payload header from the first fragment (that with Fragment Number equal to 1). 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 prf is the same as if it were computed on reconstructed message. 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 SK_p[i/r] keys that were computed in the IKE_SA_INIT as SK_p[i/r]_1. If the first IKE_INTERMEDIATE exchange performs additional key exchange resulting in SK_p[i/r] update, then this updated SK_p[i/r] are used as SK_p[i/ r]_2, otherwise the original SK_p[i/r] are used, and so on. Note, that if keys are updated then for any given IKE_INTERMEDIATE exchange the keys SK_e[i/r] and SK_a[i/r] used for its messages protection (see Section 3.3.1) and the keys SK_p[i/r] for its authentication are always from the same generation. 3.4. Error Handling in the IKE_INTERMEDIATE Exchange 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 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 also applied to the IKE_INTERMEDIATE exchange. Smyslov Expires June 18, 2020 [Page 8] Internet-Draft Intermediate IKEv2 Exchange December 2019 4. Interaction with other IKEv2 Extensions The IKE_INTERMEDIATE exchanges MAY be used during the IKEv2 Session Resumption [RFC5723] between the IKE_SESSION_RESUME and the IKE_AUTH exchanges. To be able to use it peers MUST negotiate support for intermediate exchange by including INTERMEDIATE_EXCHANGE_SUPPORTED notifications in the IKE_SESSION_RESUME messages. Note, that a flag 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. 5. Security Considerations The data that is transferred by means of the IKE_INTERMEDIATE 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 for Intermediate 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 the IKE_INTERMEDIATE 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 of the IKE_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 forged the IKE_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 forge the IKE_INTERMEDIATE exchange messages without later being detected in the IKE_AUTH exchange. To do this the attacker should find the same IntAuth_*_[I|R] value for the forged message as for original. Smyslov Expires June 18, 2020 [Page 9] Internet-Draft Intermediate IKEv2 Exchange December 2019 6. IANA Considerations This document defines a new Exchange Type in the "IKEv2 Exchange Types" registry: 43 IKE_INTERMEDIATE This document also defines a new Notify Message Types in the "Notify Message Types - Status Types" registry: 16438 INTERMEDIATE_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 of the IKE_INTERMEDIATE exchange and helped to resolve it. Author is also grateful to Tobias Brunner for raising good points concerning authentication of the IKE_INTERMEDIATE exchange. 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>. Smyslov Expires June 18, 2020 [Page 10] Internet-Draft Intermediate IKEv2 Exchange December 2019 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 Smyslov Expires June 18, 2020 [Page 11]