RFC 9242

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

📅 published May 2022, from ietf

Intermediate Exchange in IKEv2 (RFC 9242) 🎀

  • RFC number and title: RFC 9242, Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2) 💖
  • Author: V. Smyslov of ELVIS-PLUS ✨
  • Published by: the IETF, and it's a Standards Track document 🌸
  • Date: May 2022 📅
  • ISSN: 2070-1721
  • Obsoletes/Updates: the header doesn't list any RFCs it obsoletes or updates 🫶

Abstract ✨

okay so this doc defines a brand new exchange called the Intermediate Exchange for IKEv2 (Internet Key Exchange version 2) 🔐. It's built for moving big chunks of data while an IKEv2 Security Association (SA) is being set up 📦. The big motivating example is quantum-computer-resistant (QC-resistant) key exchange methods, which tend to have huge public keys 🧠. Because the Intermediate Exchange can use the existing IKE fragmentation mechanism (which can't be used in the very first IKEv2 exchange), it helps you dodge IP fragmentation for large IKE messages that need to go out before the IKEv2 SA exists 🙈. It's giving "problem solved" 💅

Status of This Memo 📜

this is an Internet Standards Track document 🌈

it's a product of the Internet Engineering Task Force (IETF) and it reflects the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✅. If you want more info on Internet Standards, check out Section 2 of RFC 7841 📚

info about this doc's current status, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc9242 🔗

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. 💜

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they're in effect on the publication date 📜. Please actually read these, bestie, because they explain your rights and restrictions for this document 🙈. Also, any Code Components pulled out of this document need to include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as described in the Revised BSD License ⚠️

Table of Contents 🗺️

   1.  Introduction
   2.  Terminology and Notation
   3.  Intermediate Exchange Details
     3.1.  Support for Intermediate Exchange Negotiation
     3.2.  Using Intermediate Exchange
     3.3.  The IKE_INTERMEDIATE Exchange Protection and Authentication
       3.3.1.  Protection of IKE_INTERMEDIATE Messages
       3.3.2.  Authentication of IKE_INTERMEDIATE Exchanges
     3.4.  Error Handling in the IKE_INTERMEDIATE Exchange
   4.  Interaction with Other IKEv2 Extensions
   5.  Security Considerations
   6.  IANA Considerations
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Appendix A.  Example of IKE_INTERMEDIATE Exchange
   Acknowledgements
   Author's Address

1. Introduction 🦋

okay so IKEv2, defined in [RFC7296], sends its messages over UDP 📡. If a message is bigger than the Path MTU (PMTU), IP fragmentation kicks in, and that has been shown to cause operational headaches in certain network setups and devices 😭. [RFC7383] goes deeper into the problem and also defines an IKEv2 extension called "IKE fragmentation" 🧩. That extension lets IKE messages get fragmented at the IKE level, which clears up the issues IP fragmentation causes 💖. The catch is that IKE fragmentation can't be used in the initial IKEv2 exchange (IKE_SA_INIT). Honestly, that's usually fine, because IKE_SA_INIT messages are normally small enough that they don't trigger IP fragmentation ✨

but the situation is changing, lowkey fast 👀. One example is needing to move a lot of data before an IKE SA exists, which happens when you use QC-resistant key exchange methods in IKEv2 🔮. Progress in quantum computing has people worried that classical Diffie-Hellman key exchange methods will become insecure in the relatively near future, so they should be swapped for QC-resistant ones 🧠. The problem is that most QC-resistant key exchange methods have large public keys. If those keys get sent in the IKE_SA_INIT exchange, IP fragmentation will probably happen, and then all the problems that come with it become basically unavoidable 💀

one possible fix is using TCP as the transport for IKEv2, as defined in [RFC8229]. But that approach has real drawbacks, and it's meant to be a last resort for when intermediate network devices completely block UDP transport 🙅‍♀️

this spec describes how to move a large amount of data in IKEv2 over UDP 🚀. To do that, it defines a new IKEv2 exchange called the "Intermediate Exchange," or "IKE_INTERMEDIATE." One or more of these exchanges may happen right after the IKE_SA_INIT exchange and before the IKE_AUTH exchange 🎀. The IKE_INTERMEDIATE messages can be fragmented with the IKE fragmentation mechanism, so they can carry large amounts of data that wouldn't fit in IKE_SA_INIT without causing IP fragmentation 🌈

the Intermediate Exchange can carry large public keys for QC-resistant key exchange methods, but that's not its only job 💅. It can also send data before the IKE_AUTH exchange whenever that data is needed and IKE_SA_INIT just isn't the right place for it. This document doesn't tie the IKE_INTERMEDIATE exchange to any one use case. Instead, separate specs are expected to say what the exchange is used for and how it's used in IKEv2 📚. A few things need to be kept in mind when designing those specs:

  • The IKE_INTERMEDIATE exchange isn't for bulk transfer. This doc doesn't set a hard cap on how much data can be safely sent this way, since that depends on the application 🤷‍♀️. In most cases, though, the data is expected to be limited to tens of kilobytes (a few hundred kilobytes in extreme cases). That's believed not to cause network problems, and [RFC6928] is an example of experiments sending similar amounts of data in the first TCP flight 🧪. Also see Section 5 for the discussion of possible DoS attack vectors when the amount of data sent in the IKE_INTERMEDIATE exchange is too large 🚨
  • The IKE_INTERMEDIATE exchange is expected to carry only data needed to establish the IKE SA. It's not for data that can wait until after the SA is up 🙅‍♀️

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 🔠 (these are the BCP 14 key words, so they only count when they're in all caps ✨)

it's expected that you already know the terms used in the IKEv2 specification [RFC7296] 🧠. The notation for payloads in IKEv2 messages is defined in Section 1.2 of [RFC7296] 📖

3. Intermediate Exchange Details 🦋

3.1. Support for Intermediate Exchange Negotiation

the initiator shows that it supports the Intermediate Exchange by including a notification of type INTERMEDIATE_EXCHANGE_SUPPORTED in its IKE_SA_INIT request message 💌. If the responder supports it too, it includes the same notification in its response message 🫶

   Initiator                                 Responder
   -----------                               -----------
   HDR, SAi1, KEi, Ni,
   [N(INTERMEDIATE_EXCHANGE_SUPPORTED)] -->
                                      <-- HDR, SAr1, KEr, Nr, [CERTREQ],
                                    [N(INTERMEDIATE_EXCHANGE_SUPPORTED)]

INTERMEDIATE_EXCHANGE_SUPPORTED is a Status Type IKEv2 notification with Notify Message Type 16438 🔢. When it's sent, the Protocol ID and SPI Size fields in the Notify payload are both set to 0 🧾. This spec doesn't define any data this notification can carry, so the Notification Data is left empty. Future enhancements to this spec might change that, though 🔮

Heads up: Implementations MUST ignore non-empty Notification Data if they don't understand its purpose. Don't just crash on it 🙏

3.2. Using Intermediate Exchange

if both peers said they support the Intermediate Exchange, the initiator may use one or more of these exchanges to send additional data 🎁. Using the Intermediate Exchange is optional. The initiator may decide it's unnecessary even when both sides negotiated support for it 🤷‍♀️

the Intermediate Exchange is written as IKE_INTERMEDIATE, and its Exchange Type is 43 🏷️

   Initiator                                 Responder
   -----------                               -----------
   HDR, ..., SK {...}  -->
                                        <--  HDR, ..., SK {...}

the initiator may use several IKE_INTERMEDIATE exchanges if it needs to. Since the window size starts at 1 for both peers (Section 2.3 of [RFC7296]), these exchanges MUST be sequential and MUST all be completed before the IKE_AUTH exchange is initiated 🚦. The IKE SA MUST NOT be considered established until the IKE_AUTH exchange has been successfully completed ⏳

the Message IDs for IKE_INTERMEDIATE exchanges MUST be chosen using the standard IKEv2 rule described in Section 2.2 of [RFC7296] 🔢. In other words, the first IKE_INTERMEDIATE exchange uses Message ID 1, the next one (if there is one) uses 2, and so on. Implementations MUST verify that the Message IDs in the IKE_INTERMEDIATE messages they receive actually follow this rule 🕵️‍♀️. The Message ID for the first pair of IKE_AUTH messages is one more than the value used in the last IKE_INTERMEDIATE exchange 💅

if NAT is detected during the IKE_SA_INIT exchange through the NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP notifications, the peers switch to port 4500 in the first IKE_INTERMEDIATE exchange 🔀. They keep using that port for all later exchanges, as described in Section 2.23 of [RFC7296] 🌸

the content of IKE_INTERMEDIATE exchange messages depends on the data being transferred, and it will be defined by the specs that use this exchange 📋. But the whole point of IKE_INTERMEDIATE is avoiding IP fragmentation when big chunks of data need to move before the IKE_AUTH exchange. So the Encrypted payload MUST be present in IKE_INTERMEDIATE messages, and any payloads carrying large amounts of data MUST be placed inside it 📦. That lets IKE fragmentation [RFC7383] happen, as long as the peers support it and negotiated it in the initial exchange 🧩

Appendix A has an example of using an IKE_INTERMEDIATE exchange while creating an IKE SA 🎀

3.3.1. Protection of IKE_INTERMEDIATE Messages ✨

okay so the keys SK_e[i/r] and SK_a[i/r] that protect IKE_INTERMEDIATE exchanges get made the normal way, same as the standard recipe in Section 2.14 of [RFC7296] 🔐

every IKE_INTERMEDIATE exchange grabs the freshest IKE SA keys it can right before it starts 💅 so the very first one uses the SK_e[i/r] and SK_a[i/r] keys that came out of IKE_SA_INIT. if that first exchange does more key exchange and updates them, the second exchange gets the updated ones 🦋. if nothing changed, it just reuses the originals, and so on 🌸

once the last IKE_INTERMEDIATE exchange is done, whichever SK_e[i/r] and SK_a[i/r] are the newest get used to protect IKE_AUTH and everything after it 👑

3.3.2. Authentication of IKE_INTERMEDIATE Exchanges

the IKE_INTERMEDIATE messages must be authenticated in the IKE_AUTH exchange, and that happens by stuffing their content into the AUTH payload calculation 🧚

a lot of these messages are expected to get fragmented with the IKE fragmentation [RFC7383] mechanism 📦 per [RFC7383], once fragmentation is negotiated, the initiator can send a request unfragmented first, then turn fragmentation on and resend it fragmented if no response shows up after a few retransmissions 🫶. peers can also resend a fragmented message at different fragment sizes to do simple PMTU discovery 🔍

that behavior makes authentication kinda tricky 😭 you can't just hash the on-the-wire bytes into AUTH, because implementations usually don't know what form the peer actually received. so instead, the content gets added before encryption and possible fragmentation, which means the data being authenticated doesn't care how the messages were delivered 💜

if one or more IKE_INTERMEDIATE exchanges happened, the blob to be signed (or MACed) from Section 2.15 of [RFC7296] gets a glow-up 💖 it looks like this:

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])

the big idea is that a brand new chunk called "IntAuth" gets tacked onto the string of octets that both peers sign (or MAC) 🎀 IntAuth is made of three bits: IntAuth_iN, IntAuth_rN, and IKE_AUTH_MID.

IKE_AUTH_MID is the Message ID field from the IKE Header of the first round of the IKE_AUTH exchange. it's a four-octet integer in network byte order, which is basically exactly how it looks on the wire 🌈

IntAuth_iN and IntAuth_rN are the cumulative result of running the negotiated Pseudorandom Function (PRF) over all the IKE_INTERMEDIATE exchange messages sent during IKE SA establishment, by the initiator and the responder respectively ⭐. after the first IKE_INTERMEDIATE exchange wraps up, peers get IntAuth_i1 by running the PRF on the content of the request, and IntAuth_r1 by running it on the content of the response. for every later exchange, after the nth one is done, peers recalculate: they run the PRF on the concatenation of IntAuth_[i/r](n-1) (from the previous IKE_INTERMEDIATE exchange) and the content of the request (for IntAuth_in) or response (for IntAuth_rn) from this exchange. once all the IKE_INTERMEDIATE exchanges are over, the final IntAuth_[i/r]N values (assuming N exchanges happened) get used in computing the AUTH payload 🥹

now for the A and P chunks 🧁 for the purpose of calculating the IntAuth_[i/r]* values, the content of the IKE_INTERMEDIATE messages is split into two chunks: the mandatory IntAuth_[i/r]*A, optionally followed by IntAuth_[i/r]*P.

the IntAuth_[i/r]*A chunk is the sequence of octets from the first octet of the IKE Header (not counting the four prepended octets of zeros, if UDP encapsulation or TCP encapsulation of ESP packets is used) up to the last octet of the generic header of the Encrypted payload. its scope is identical to the scope of Associated Data for AEAD algorithms in IKEv2 (see Section 5.1 of [RFC5282]), which is why it gets the "A" suffix 🫧 also, calculating IntAuth_[i/r]*A doesn't depend on whether an AEAD algorithm or a plain cipher is used in the IKE SA.

the IntAuth_[i/r]*P chunk shows up if the Encrypted payload isn't empty ✨ it's the content of the Encrypted payload that's fully formed but not yet encrypted. the Initialization Vector, Padding, Pad Length, and Integrity Checksum Data fields (see Section 3.14 of [RFC7296]) aren't part of the calculation. so basically, IntAuth_[i/r]*P is the inner payloads in plaintext form, hence the "P" suffix 🔐

                        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

      Figure 1: Data to Authenticate in the IKE_INTERMEDIATE Exchange
                                  Messages

Figure 1 shows where the A chunk (IntAuth_[i/r]*A, marked as A) and the P chunk (IntAuth_[i/r]*P, marked as P) land when the Encrypted payload isn't empty 🗺️

for the prf calculation, the Length field in the IKE Header and the Payload Length field in the Encrypted payload header get adjusted so they don't count the Initialization Vector, Integrity Checksum Data, Padding, and Pad Length fields 🙈 so the IKE Header Length (the "Adjusted Length" in Figure 1) gets set to the sum of the IntAuth_[i/r]*A and IntAuth_[i/r]*P lengths, and the Encrypted payload's Payload Length (the "Adjusted Payload Length" in Figure 1) gets set to the length of IntAuth_[i/r]*P plus the size of the Encrypted payload header (four octets) 💅

bestie, this part is serious 👑 the prf calculations MUST be applied to whole messages only, before possible IKE fragmentation. that way the IntAuth comes out the same whether or not fragmentation happened 🫶 if the message was received in fragmented form, it MUST be reconstructed before calculating the prf, as if it had arrived unfragmented 🧩 and while reconstructing, the RESERVED field in the reconstructed Encrypted payload header MUST 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).

ngl, you don't have to literally rebuild the message 🪄 you can incrementally calculate the prf on decrypted (or ready-to-be-encrypted) fragments instead. but care must be taken to properly replace the content of the Next Header and the Length fields, so that the prf result matches what you'd get on the reconstructed message ⚠️

last thing, each IntAuth_[i/r]* calculation uses its own SK_p[i/r]* keys, which are the most recently updated SK_p[i/r] keys available right before the corresponding IKE_INTERMEDIATE exchange starts 🌷 the first IKE_INTERMEDIATE exchange always uses the SK_p[i/r] keys computed in IKE_SA_INIT as SK_p[i/r]1. if the first one does additional key exchange that updates SK_p[i/r], then those updated keys become SK_p[i/r]2. otherwise the original SK_p[i/r] keys get reused, and so on 💜 and if keys do get updated, then for any given IKE_INTERMEDIATE exchange, the keys SK_e[i/r] and SK_a[i/r] that protect its messages (see Section 3.3.1) and the key SK_p[i/r] used for its authentication always come from the same generation 🦋

3.4. Error Handling in the IKE_INTERMEDIATE Exchange 🎀

Okay bestie, messages in the IKE_INTERMEDIATE exchange aren't authenticated until IKE_AUTH successfully completes 😭, so errors need to be handled with care. There's a real trade-off here: better diagnostics on one side, and the risk of becoming part of a DoS attack on the other 💅. Sections 2.21.1 and 2.21.2 of [RFC7296] explain how errors work in the initial IKEv2 exchanges, and those same considerations also apply to IKE_INTERMEDIATE. The one twist is that not all error notifications may show up in IKE_INTERMEDIATE. Errors about authentication are generally only relevant to IKE_AUTH, obviously 🙈

4. Interaction with Other IKEv2 Extensions ✨

Okay so, IKE_INTERMEDIATE exchanges MAY be used during the IKEv2 Session Resumption [RFC5723], between IKE_SESSION_RESUME and IKE_AUTH. To use it, peers MUST negotiate support for Intermediate Exchange by including INTERMEDIATE_EXCHANGE_SUPPORTED notifications in the IKE_SESSION_RESUME messages 🧚. Also, whether peers supported IKE_INTERMEDIATE is not stored in the resumption ticket. It gets figured out fresh every time from the IKE_SESSION_RESUME exchange, so no stale info 💜

5. Security Considerations 🔥

This part is serious, so let's get into it 🫶 The data moved by IKE_INTERMEDIATE exchanges is not authenticated until the subsequent IKE_AUTH exchange is complete. BUT if the data sits inside the Encrypted payload, it's protected from passive eavesdroppers 👀 Plus, peers can be certain they're getting messages from the party they did the IKE_SA_INIT exchange with, as long as they can successfully verify the Integrity Checksum Data of the Encrypted payload.

The main point of Intermediate Exchange is moving large amounts of data before an IKE SA is set up, without causing IP fragmentation ✨ Because of that, IKE fragmentation is expected to be used in IKE_INTERMEDIATE exchanges in most cases. Section 5 of [RFC7383] has the security considerations for IKE fragmentation.

Now the spicy bit 💀 Since peers only authenticate in the IKE_AUTH exchange, a malicious initiator can use Intermediate Exchange to DoS the responder. It starts creating an IKE SA, negotiates using the Intermediate Exchanges, and dumps a ton of data on the responder, which may also need computationally expensive processing. Then it aborts the SA establishment before IKE_AUTH. So specifications that use Intermediate Exchange MUST NOT allow an unlimited number of these exchanges to happen at the initiator's discretion 🚫 It's recommended that these specifications are defined so the responder knows the exact number of these exchanges that need to happen (possibly via negotiation with the initiator). In other words, after IKE_SA_INIT is complete, it's preferred that both the initiator and the responder know the exact number of IKE_INTERMEDIATE exchanges they have to perform. Some IKE_INTERMEDIATE exchanges are allowed to be optional and performed at the initiator's discretion, but if a specification defines optional use of IKE_INTERMEDIATE, the maximum number of those exchanges must be hard capped by that specification. Also, [RFC8019] gives the responder guidelines for dealing with DoS attacks during IKE SA establishment 🛡️

Note that if an attacker could break the key exchange in real time (e.g., with a quantum computer), the security of IKE_INTERMEDIATE would degrade 😱 Specifically, that attacker could both read data in the Encrypted payload and forge it. The forgery would become evident in IKE_AUTH (provided the attacker can't break the authentication mechanism in use), but the ability to inject forged IKE_INTERMEDIATE messages with a valid Integrity Check Value (ICV) would let the attacker mount a DoS attack. Moreover, in this situation, if the negotiated PRF was not secure against a second preimage attack with known key, the attacker could forge IKE_INTERMEDIATE messages without being detected later in IKE_AUTH. To do that, 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:

+=======+==================+===========+
| Value | Exchange Type    | Reference |
+=======+==================+===========+
| 43    | IKE_INTERMEDIATE | RFC 9242  |
+-------+------------------+-----------+

     Table 1: IKEv2 Exchange Types

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

+=======+=================================+===========+
| Value | NOTIFY MESSAGES - STATUS TYPES  | Reference |
+=======+=================================+===========+
| 16438 | INTERMEDIATE_EXCHANGE_SUPPORTED | RFC 9242  |
+-------+---------------------------------+-----------+

    Table 2: IKEv2 Notify Message Types - Status Types

7. References 📚

7.1. Normative References

7.2. Informative References

Appendix A. Example of IKE_INTERMEDIATE Exchange 🦋

This appendix has an example of the messages used in IKE_INTERMEDIATE exchanges. It's purely informative, so if it ever disagrees with the body of this document, the body wins 💖

In this example there's one IKE_SA_INIT exchange and two IKE_INTERMEDIATE exchanges, followed by the IKE_AUTH exchange to authenticate all the initial exchanges. The xxx in HDR(xxx,MID=yyy) is the Exchange Type, and yyy is the Message ID used for that exchange. The keys used for each SK {} payload are shown in parentheses after the SK. Otherwise, the payload notation is the same as 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 this IKE_INTERMEDIATE exchange is complete, 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 the second IKE_INTERMEDIATE exchange is complete, 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, so the SK_*3 keys would be used as the SK_* keys for further cryptographic operations in the context of the created IKE SA, as defined in [RFC7296] 🌈

Acknowledgements ✨

Okay bestie, this is the thank-you section 🫶 The idea to use an Intermediate Exchange between the IKE_SA_INIT and IKE_AUTH exchanges was first suggested by Tero Kivinen 💡 He also helped write the example IKE_INTERMEDIATE exchange in Appendix A, so he's literally part of why that example exists 🎀

Scott Fluhrer and Daniel Van Geest spotted a possible problem with authentication of the IKE_INTERMEDIATE exchange and helped fix it 🔥 Honestly, the people who find the sneaky bugs are my favorites 💅

The author is so grateful to Tobias Brunner 🌸 He asked really good questions about authentication of the IKE_INTERMEDIATE exchange, and he also proposed how to keep the size of authentication chunks constant no matter how many exchanges there are. Iconic behavior 👑

The author also thanks Paul Wouters and Benjamin Kaduk, who suggested a lot of text improvements for the document ✨ Basically, they made the writing better so everyone can actually read it 🦋

Author's Address 🧚

Valery Smyslov
ELVIS-PLUS
PO Box 81
Moscow (Zelenograd)
124460
Russian Federation
Phone: +7 495 276 0211
Email: svan@elvis.ru
📦 where this page comes from