RFC 9242: Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)

Status of This Memo

This is an Internet Standards Track document.¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9242.¶

Copyright Notice

Copyright (c) 2022 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

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.¶

It is expected that readers are familiar with the terms used in the IKEv2 specification [RFC7296]. Notation for the payloads contained in IKEv2 messages is defined in Section 1.2 of [RFC7296].¶

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 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.¶

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 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.¶

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 that reason, it is expected that IKE fragmentation will be employed in IKE_INTERMEDIATE exchanges in most cases. Section 5 of [RFC7383] contains security considerations for IKE fragmentation.¶

Since authentication of peers occurs only in the IKE_AUTH exchange, a malicious initiator may use the Intermediate Exchange to mount a DoS attack on the responder. In this case, it starts creating an IKE SA, negotiates using the Intermediate Exchanges, and transfers a lot of data to the responder that may also require computationally expensive processing. Then, it aborts the SA establishment before the IKE_AUTH exchange. Specifications utilizing the Intermediate Exchange MUST NOT allow an unlimited number of these exchanges to take place at the initiator's discretion. It is recommended that these specifications be defined in such a way that the responder would know (possibly via negotiation with the initiator) the exact number of these exchanges that need to take place. In other words, after the IKE_SA_INIT exchange is complete, it is preferred that both the initiator and the responder know the exact number of IKE_INTERMEDIATE exchanges they have to perform; it is possible that some IKE_INTERMEDIATE exchanges are optional and are performed at the initiator's discretion, but if a specification defines optional use of IKE_INTERMEDIATE, then the maximum number of these exchanges must be hard capped by the corresponding specification. In addition, [RFC8019] provides guidelines for the responder of how to deal with DoS attacks during IKE SA establishment.¶

Note that if an attacker was able to break the key exchange in real time (e.g., by means of a quantum computer), then the security of the IKE_INTERMEDIATE exchange would degrade. In particular, such an attacker would be able to both read data contained in the Encrypted payload and forge 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 valid Integrity Check Value (ICV) would allow the attacker to mount a DoS attack. Moreover, in this situation, if the negotiated PRF 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 do this, the attacker would find the same IntAuth_[i/r]* value for the forged message as for the original.¶

6. IANA Considerations

This document defines a new Exchange Type in the "IKEv2 Exchange Types" registry:¶

This document also defines a new Notify Message Type in the "IKEv2 Notify Message Types - Status Types" registry:¶

Appendix A. Example of IKE_INTERMEDIATE Exchange

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.¶

In this example, 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 the Exchange Type, and yyy indicates the Message 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 [RFC7296].¶

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)

At this point, 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_INTERMEDIATE exchange, and SK_p[i/r]1 will be used for its authentication.¶

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, ...)>

If the SK_*1 keys are updated (e.g., as a result of a new key exchange) after completing this IKE_INTERMEDIATE exchange, then the peers store the updated keys as SK_*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_INTERMEDIATE exchange, and SK_p[i/r]2 will be used for its authentication.¶

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, ...)>

If the SK_*2 keys are updated (e.g., as a result of a new key exchange) after completing the second IKE_INTERMEDIATE exchange, then the peers store the updated keys as SK_*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., for Child SAs).¶

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}

In this example, two IKE_INTERMEDIATE exchanges took place; 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 [RFC7296].¶

Author's Address