RFC 9370
Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)
Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2) 🎀
Okay bestie, the title block first 💅 This is RFC 9370, a Standards Track document from May 2023 (ISSN 2070-1721). It updates RFC 7296, which is the original IKEv2 spec, and the header doesn't list anything it obsoletes. The main authors are CJ. Tjhai and M. Tomlinson from Post-Quantum, G. Bartlett from Quantum Secret, S. Fluhrer from Cisco Systems, D. Van Geest from ISARA Corporation, O. Garcia-Morchon from Philips, and V. Smyslov from ELVIS-PLUS. The whole crew is post-quantum-obsessed and I'm here for it 🌈
Abstract ✨
So this doc is about letting IKEv2 do multiple key exchanges while it's building a shared secret during a Security Association (SA) setup 🦋
It uses the IKE_INTERMEDIATE exchange when peers are setting up an IKE SA and runs several key exchanges in that phase. There's also a brand new exchange, IKE_FOLLOWUP_KE, that does the same job when the IKE SA is being rekeyed or when extra Child SAs are being created 🔥
It also updates RFC 7296 in a few glow-up ways. Transform Type 4 goes from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)". A field in the Key Exchange Payload gets renamed from "Diffie-Hellman Group Num" to "Key Exchange Method". The IANA registry for that transform type gets a rename too, from "Transform Type 4 - Diffie-Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange Method Transform IDs". All of this generalizes which key exchange algorithms IKEv2 can use 👑
Status of This Memo 🌸
This is an Internet Standards Track document ✨
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841.
For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9370 🧚
Copyright Notice 💜
Copyright (c) 2023 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) as they stand on the publication date. Please actually read these, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License 🫶
Table of Contents 🍓
1. Introduction
1.1. Problem Description
1.2. Proposed Extension
1.3. Document Organization
2. Multiple Key Exchanges
2.1. Design Overview
2.2. Protocol Details
2.2.1. IKE_SA_INIT Round: Negotiation
2.2.2. IKE_INTERMEDIATE Round: Additional Key Exchanges
2.2.3. IKE_AUTH Exchange
2.2.4. CREATE_CHILD_SA Exchange
2.2.5. Interaction with IKEv2 Extensions
3. IANA Considerations
4. Security Considerations
5. References
5.1. Normative References
5.2. Informative References
Appendix A. Sample Multiple Key Exchanges
A.1. IKE_INTERMEDIATE Exchanges Carrying Additional Key Exchange
Payloads
A.2. No Additional Key Exchange Used
A.3. Additional Key Exchange in the CREATE_CHILD_SA Exchange
Only
A.4. No Matching Proposal for Additional Key Exchanges
Appendix B. Design Criteria
Appendix C. Alternative Design
Acknowledgements
Authors' Addresses1. Introduction ✨
1.1. Problem Description 💖
IKEv2, as specified in [RFC7296], uses the Diffie-Hellman (DH) or the Elliptic Curve Diffie-Hellman (ECDH) algorithm to set up a shared secret between an initiator and a responder. From here on we'll just call them "(EC)DH" together 🦋
Here's the tea. (EC)DH security depends on how hard it is to solve a discrete logarithm problem in multiplicative groups (or elliptic curve groups, respectively), as long as the group order is big enough. Solving that is still infeasible with today's computers, but it's believed that general-purpose quantum computers will be able to crack it. That would mean IKEv2 is compromised 😭 There's a whole family of cryptosystems that are conjectured to resist quantum attacks, though. That family is called "post-quantum cryptography" (or "PQC"). People also call it "quantum-safe cryptography" (or "QSC") or "quantum-resistant cryptography" (or "QRC") ✨
Being able to do one or more post-quantum key exchanges alongside an (EC)DH key exchange is essential, so the final shared key stays resistant to quantum-computer attacks 🔥 Right now there's no post-quantum key exchange as well-studied as (EC)DH. So running several key exchanges, with different post-quantum algorithms plus the well-established classical ones, handles this worry. The overall security ends up at least as strong as each individual primitive 💅
1.2. Proposed Extension 🌈
This doc describes a way to do multiple successive key exchanges in IKEv2. It lets you bring PQC into IKEv2 while staying backward compatible, so you can derive a set of IKE keys that's resistant to quantum-computer attacks 👑 This extension lets peers negotiate one or more PQC algorithms to exchange data on top of the existing (EC)DH key exchange data. It's believed that using more than one post-quantum algorithm really matters, because lots of these algorithms are relatively new. You might need to hedge the security risk with key exchange data from several distinct PQC algorithms 🦋
IKE peers do multiple successive key exchanges to set up an IKE SA. Each exchange produces a shared secret, and the secrets get combined so that:
(a) the final shared secret is computed from all of the component key exchange secrets;
(b) unless both peers support and agree to use the additional key exchanges introduced in this specification, the final shared secret equivalent to the shared secret specified in [RFC7296] is obtained; and
(c) if any part of the component key exchange method is a post-quantum algorithm, the final shared secret is post-quantum secure.
Some post-quantum key exchange payloads can be bigger than the standard maximum transmission unit (MTU) size, so there could be IP-layer fragmentation issues 🙈 To allow those bigger payloads, this mechanism relies on the IKE_INTERMEDIATE exchange from [RFC9242]. The key exchange kicks off with a smaller, possibly classical primitive like (EC)DH. Then, before the IKE_AUTH exchange, one or more IKE_INTERMEDIATE exchanges happen, and each one carries an additional key exchange. Since the IKE_INTERMEDIATE exchange is encrypted, the IKE fragmentation protocol from [RFC7383] can be used 🧚 The IKE SK_* values get updated after each exchange, as described in Section 2.2.2, so the final IKE SA keys depend on all the key exchanges. That means the keys are secure as long as any one of the key exchanges is secure ✨
This extension is mainly aimed at IKE SAs because of that fragmentation issue. It also applies to CREATE_CHILD_SA exchanges, which Section 2.2.4 covers for creating and rekeying Child SAs and for rekeying IKE SAs 💜
Heads up: think of this approach as a long-term solution for upgrading IKEv2 to support post-quantum algorithms. A short-term way to make the IKEv2 key exchange quantum secure is to use post-quantum pre-shared keys, as specified in [RFC8784] 🍓
Also, doing multiple successive key exchanges where the resulting session keys depend on all of them isn't only about quantum computers. It works even when every key exchange is a classical (EC)DH primitive, for example when policy requirements make multiple key exchanges essential 🌸
This spec doesn't try to handle key exchanges with KE payloads longer than 64 KB, because the current IKE payload format doesn't allow it. As of writing, a bunch of key exchanges seem to exist that won't need that. [BEYOND-64K] talks about approaches for exchanging huge payloads if that ever becomes a requirement 🫶
1.3. Document Organization 🎀
Here's the roadmap. Section 2 describes how multiple key exchanges happen between two IKE peers and how keying material is derived for both SAs and Child SAs. Section 3 covers IANA considerations for the namespaces this document introduces, and Section 4 covers security considerations. In the Appendices, Appendix A illustrates some examples of multiple key exchanges. Appendix B summarizes design criteria and alternative approaches that were considered, and Appendix C explains why those approaches were later discarded 💅
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 🦋
2.1. Design Overview 🎀
Okay so bestie, most post-quantum key agreement algorithms are still super new 🌱, which means they're not fully trusted yet, ngl. There are also tons of proposed ones with different trade-offs that rely on different hard problems 🧩. The worry is that some of those hard problems could turn out to be easier to crack than anyone expected, so the key agreement might not be as secure as we want 😬. A hybrid solution fixes this vibe: you run multiple key exchanges and the calculated shared key depends on all of them. It combines a classical key exchange with a post-quantum one, and it leaves the door open for combining with multiple post-quantum key exchanges too 🦋.
To use IKE fragmentation [RFC7383] for key exchanges that have long public keys, this spec uses the IKE_INTERMEDIATE exchange defined in [RFC9242] ✨. Plain IKE_SA_INIT messages don't have any built-in fragmentation support within IKE. They can include a relatively short KE payload, though. So the additional key exchanges happen using IKE_INTERMEDIATE messages that follow the IKE_SA_INIT exchange. That way the standard IKE fragmentation mechanisms (which can't be used in IKE_SA_INIT) are available for the potentially huge Key Exchange payloads carrying post-quantum algorithm data 📦💅.
Note that this document assumes each key exchange method takes one round trip and eats exactly one IKE_INTERMEDIATE exchange. This assumption works for all classic key exchange methods defined so far and for all post-quantum methods currently known 🙌. For hypothetical future key exchange methods that need multiple round trips to finish, a separate document should define how those methods get split into several IKE_INTERMEDIATE exchanges 🔮.
To keep the overhead low, only the key shares that are agreed upon actually get exchanged 🤏. To negotiate additional key exchanges, seven new Transform Types are defined, and these transforms and Transform Type 4 share the same Transform IDs 🍓.
It's assumed that new Transform Type 4 identifiers will be assigned later for various post-quantum key exchanges [IKEV2TYPE4ID]. This spec doesn't make a distinction between classical (EC)DH and post-quantum key exchanges, or between post-quantum algorithms that are true key exchanges and ones that act as key transport mechanisms. The protocol treats them all equivalently, periodt 💜. This document also renames a field in the Key Exchange Payload from "Diffie-Hellman Group Num" to "Key Exchange Method", and renames Transform Type 4 from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)". The matching IANA registry rename is described in Section 3 🗂️.
Because the newly defined transforms share the same registry of possible Transform IDs as Transform Type 4, additional key exchanges can be of any type, either post-quantum or classical (EC)DH. That means any combination of the defined key exchange methods can happen 🌈. It also means IKE peers can do a single post-quantum key exchange in IKE_SA_INIT with no additional key exchanges, as long as IP fragmentation isn't an issue and hybrid key exchange isn't needed 👑.
The SA payload in the IKE_SA_INIT message includes one or more newly defined transforms that represent the extra key exchange policy the initiator requires 📝. The responder follows the usual IKEv2 negotiation rules: it selects a single transform of each type and returns all of them in the IKE_SA_INIT response message 🫶.
If additional key exchanges get negotiated, the initiator and the responder then perform one or more IKE_INTERMEDIATE exchanges. After that, the IKE_AUTH exchange authenticates the peers and completes IKE SA establishment 🔐.
Initiator Responder
---------------------------------------------------------------------
<-- IKE_SA_INIT (additional key exchanges negotiation) -->
<-- {IKE_INTERMEDIATE (additional key exchange)} -->
...
<-- {IKE_INTERMEDIATE (additional key exchange)} -->
<-- {IKE_AUTH} -->2.2. Protocol Details 🦋
In the simplest case, the initiator starts a single key exchange (and has no interest in supporting multiple), and it isn't worried about possible fragmentation of the IKE_SA_INIT messages 🌸. That's because either the key exchange it selects is small enough not to fragment, or the initiator is confident that fragmentation will be handled either by IP fragmentation or by transport via TCP.
In this case, the initiator performs the IKE_SA_INIT for a single key exchange using a Transform Type 4 (possibly with a post-quantum algorithm) and includes the initiator KE payload 💖. If the responder accepts the policy, it responds with an IKE_SA_INIT response, and IKE continues as usual ✨.
If the initiator wants to negotiate multiple key exchanges, then the initiator uses the protocol behavior listed below 👀.
2.2.1. IKE_SA_INIT Round: Negotiation
Okay bestie, so multiple key exchanges get negotiated through the standard IKEv2 SA payload 💖 and to make that work, seven brand new transform types are defined ✨: ADDKE1 (IANA-assigned value 6), ADDKE2 (7), ADDKE3 (8), ADDKE4 (9), ADDKE5 (10), ADDKE6 (11), and ADDKE7 (12). They're collectively called "Additional Key Exchange (ADDKE) Transform Types" in this doc, and they act a little differently from the existing IKEv2 Transform Types 🦋. They signal extra key exchange methods that the peers agree to run in a series of IKE_INTERMEDIATE exchanges right after the IKE_SA_INIT exchange. Iconic, honestly 👑.
The key exchange method negotiated via Transform Type 4 always happens in the IKE_SA_INIT exchange, as defined in [RFC7296]. Extra key exchanges negotiated through the new transforms MUST take place in a series of IKE_INTERMEDIATE exchanges after IKE_SA_INIT, done in the order of their Transform Type values. That way the key exchange for ADDKE i always goes before the one for ADDKE i + 1 🧚. Each additional key exchange method MUST be fully completed before the next one starts. No skipping ahead, periodt 💅.
Now here's the vibe check: ADDKE Transform Types aren't tied to any one kind of key exchange, and they don't have their own per-type Transform ID registries. Instead, they all share one registry for Transform IDs, namely "Transform Type 4 - Key Exchange Method Transform IDs" 🌸. All key exchange algorithms, classical or post-quantum, should be added to this registry. This gives peers lots of flexibility to mix and match the key exchange methods however they like 🎀.
When the initiator builds a proposal, it adds transforms for the IKE_SA_INIT exchange using Transform Type 4. Usually those are classical (EC)DH key exchange methods, but that's not a requirement 🙈. Additional key exchange methods get proposed using the ADDKE Transform Types. All of these are optional, so the initiator can pick any of them to propose extra key exchange methods. If none of the ADDKE Transform Types show up in the proposal, then it's just standard IKEv2 as defined in [RFC7296] 💜. But if the initiator includes any ADDKE Transform Type, the responder MUST select one of the algorithms proposed using that type. And no, this isn't a new rule. It's already specified in Section 2.7 of [RFC7296], so we're just reminding everyone 🫶. A Transform ID NONE MAY be added to those transform types that contain key exchange methods the initiator considers optional under its local policy.
The responder does the negotiation with the standard IKEv2 procedure in Section 3.3 of [RFC7296]. But for the ADDKE Transform Types, the responder's choice MUST NOT contain duplicated algorithms (ones with an identical Transform ID and attributes), except for the Transform ID of NONE. An algorithm is represented as a transform. Sometimes a transform comes with attributes that define the algorithm's details. In that case, two transforms can share a Transform ID but still have different attributes. Also, the order of the attributes doesn't change whether two algorithms are equal, so ID=alg1, ATTR1=attr1, ATTR2=attr2 and ID=alg1, ATTR2=attr2, ATTR1=attr1 define the same algorithm 🍓. If the responder can't pick non-duplicated algorithms for each proposed key exchange (because the proposal has too few choices, or local policy restricts the proposed algorithms), then the responder MUST reject the message with an error notification of type NO_PROPOSAL_CHOSEN 💀. If the responder's message contains one or more duplicated choices, the initiator should log the error and MUST treat the exchange as failed. The initiator MUST NOT initiate any IKE_INTERMEDIATE (or IKE_FOLLOWUP_KE) exchanges, so no new SA is created 😭. If this happens in the CREATE_CHILD_SA exchange, the initiator MAY delete the IKE SA the invalid message came in on, by sending a Delete payload.
If the responder selects NONE for some ADDKE Transform Types (as long as the initiator proposed them), then any matching additional key exchanges MUST NOT take place 🙅♀️. So if the initiator includes NONE in all of the ADDKE Transform Types and the responder picks NONE for every one of them, then no IKE_INTERMEDIATE exchanges for additional key exchanges happen between the peers. Just a heads up: IKE_INTERMEDIATE exchanges might still happen for other reasons ✨.
The initiator MAY propose ADDKE Transform Types that aren't consecutive, like proposing only ADDKE2 and ADDKE5. The responder MUST treat all of the omitted ADDKE transforms as if they were proposed with Transform ID NONE 🌈.
Here's an example of the SA payload in the initiator's IKE_SA_INIT request message. The abbreviation "KE" is used for the Key Exchange transform, which this document renames from the Diffie-Hellman Group transform 🎀. The notations PQ_KEM_1, PQ_KEM_2, and PQ_KEM_3 stand in for Transform IDs that haven't been defined yet, for some popular post-quantum key exchange methods 🔮.
SA Payload
|
+--- Proposal #1 ( Proto ID = IKE(1), SPI Size = 8,
| 9 transforms, SPI = 0x35a1d6f22564f89d )
|
+-- Transform ENCR ( ID = ENCR_AES_GCM_16 )
| +-- Attribute ( Key Length = 256 )
|
+-- Transform KE ( ID = 4096-bit MODP Group )
|
+-- Transform PRF ( ID = PRF_HMAC_SHA2_256 )
|
+-- Transform ADDKE2 ( ID = PQ_KEM_1 )
|
+-- Transform ADDKE2 ( ID = PQ_KEM_2 )
|
+-- Transform ADDKE3 ( ID = PQ_KEM_1 )
|
+-- Transform ADDKE3 ( ID = PQ_KEM_2 )
|
+-- Transform ADDKE5 ( ID = PQ_KEM_3 )
|
+-- Transform ADDKE5 ( ID = NONE )In this example, the initiator wants the initial key exchange to use a 4096-bit MODP Group, followed by two mandatory additional key exchanges (ADDKE2 and ADDKE3 Transform Types) using PQ_KEM_1 and PQ_KEM_2 in any order, followed by an additional key exchange (ADDKE5 Transform Type) using PQ_KEM_3 that may be omitted 🥰.
The responder might send back the following SA payload, which says it agrees to do two additional key exchanges, PQ_KEM_2 followed by PQ_KEM_1, and that it doesn't want to also do PQ_KEM_3 💅.
SA Payload
|
+--- Proposal #1 ( Proto ID = IKE(1), SPI Size = 8,
| 6 transforms, SPI = 0x8df52b331a196e7b )
|
+-- Transform ENCR ( ID = ENCR_AES_GCM_16 )
| +-- Attribute ( Key Length = 256 )
|
+-- Transform KE ( ID = 4096-bit MODP Group )
|
+-- Transform PRF ( ID = PRF_HMAC_SHA2_256 )
|
+-- Transform ADDKE2 ( ID = PQ_KEM_2 )
|
+-- Transform ADDKE3 ( ID = PQ_KEM_1 )
|
+-- Transform ADDKE5 ( ID = NONE )If the initiator puts any ADDKE Transform Types into the SA payload of the IKE_SA_INIT request message, then it MUST also negotiate the use of the IKE_INTERMEDIATE exchange, as described in [RFC9242], by including an INTERMEDIATE_EXCHANGE_SUPPORTED notification in that same message 🦋. If the responder agrees to use additional key exchanges while setting up the initial IKE SA, it MUST also return this notification in the IKE_SA_INIT response message. That confirms IKE_INTERMEDIATE is supported and will be used to carry the additional key exchange data 🫧. If the IKE_INTERMEDIATE exchange isn't negotiated, then the peers MUST treat any ADDKE Transform Types in the IKE_SA_INIT messages as unknown transform types and skip the proposals they show up in. If no other proposals are in the SA payload, the peers carry on as if no proposal was chosen (so the responder sends a NO_PROPOSAL_CHOSEN notification) 😵💫.
Initiator Responder
---------------------------------------------------------------------
HDR, SAi1(.. ADDKE*...), KEi, Ni,
N(INTERMEDIATE_EXCHANGE_SUPPORTED) --->
HDR, SAr1(.. ADDKE*...), KEr, Nr,
[CERTREQ],
<--- N(INTERMEDIATE_EXCHANGE_SUPPORTED)It's possible for an attacker to send a response to the initiator's IKE_SA_INIT request before the legitimate responder does. ⚠️ If the initiator goes ahead and creates the IKE SA using that response, the attempt will fail. Implementers may wish to consider the strategies described in Section 2.4 of [RFC7296] for handling this kind of attack 🛡️.
2.2.2. IKE_INTERMEDIATE Round: Additional Key Exchanges
For each additional key exchange agreed to in the IKE_SA_INIT exchange, the initiator and responder run an IKE_INTERMEDIATE exchange, as described in [RFC9242] 🔁.
Initiator Responder
---------------------------------------------------------------------
HDR, SK {KEi(n)} -->
<-- HDR, SK {KEr(n)}The initiator sends its key exchange data in the KEi(n) payload. This message is protected with the current SK_ei/SK_ai keys 🔐. The notation KEi(n) means the n-th IKE_INTERMEDIATE KE payload from the initiator, where "n" counts up sequentially starting from 1.
When the responder gets that, it sends back the key exchange payload KEr(n), where KEr(n) means the n-th IKE_INTERMEDIATE KE payload from the responder 💫. Just like the request, this message is protected, this time with the current SK_er/SK_ar keys.
The "Diffie-Hellman Group Num" field (now called "Key Exchange Method") in the KEi(n) and KEr(n) payloads MUST match the n-th negotiated additional key exchange 🎯.
Once this exchange is done, both sides compute updated keying material 🧁:
SKEYSEED(n) = prf(SK_d(n-1), SK(n) | Ni | Nr)Here, SK(n) is the shared secret that comes out of this exchange. Ni and Nr are the nonces from the IKE_SA_INIT exchange. SK_d(n-1) is the last generated SK_d, which is derived from IKE_SA_INIT for the first use of IKE_INTERMEDIATE and otherwise comes from the previous IKE_INTERMEDIATE exchange. The rest of the keying material, SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, and SK_pr, gets generated from SKEYSEED(n) like this:
{SK_d(n) | SK_ai(n) | SK_ar(n) | SK_ei(n) | SK_er(n) | SK_pi(n) |
SK_pr(n)} = prf+ (SKEYSEED(n), Ni | Nr | SPIi | SPIr)Both the initiator and the responder use these updated key values in the next exchange, which is either IKE_INTERMEDIATE or IKE_AUTH 🌸✨
2.2.3. IKE_AUTH Exchange ✨
okay so once every IKE_INTERMEDIATE exchange is done, the initiator and responder do an IKE_AUTH exchange 🔐 it's the standard IKE one from [RFC7296], just with the AUTH payload calculation tweak from [RFC9242]. no drama, just the familiar flow 💅
2.2.4. CREATE_CHILD_SA Exchange 🎀
the CREATE_CHILD_SA exchange is the IKEv2 move for making new Child SAs, rekeying those Child SAs, and rekeying the IKE SA itself 🦋 when you're creating or rekeying Child SAs, the peers may optionally do a key exchange to sprinkle in some fresh entropy 🌸 for an IKE SA rekey though, the key exchange is mandatory 😭 and peers that support this spec may want to use multiple key exchanges in these situations 💜
using multiple key exchanges with a CREATE_CHILD_SA exchange is negotiated the same way as the initial IKE exchange, so go check Section 2.2.1 🫶 if the initiator puts any ADDKE Transform Types in the SA payload (along with Transform Type 4), and the responder agrees to do extra key exchanges, then those extra exchanges happen in a series of brand new IKE_FOLLOWUP_KE exchanges right after the CREATE_CHILD_SA exchange ✨ IKE_FOLLOWUP_KE was made specifically for carrying the data of the additional key exchanges that come after the one in CREATE_CHILD_SA 🧚 its Exchange Type value is 44.
the key exchange negotiated via Transform Type 4 always happens in the CREATE_CHILD_SA exchange, per the IKEv2 spec [RFC7296] 👑 the additional key exchanges go in order of their Transform Type values, so the key exchange negotiated using Additional Key Exchange i always comes before the one for Additional Key Exchange i + 1 🌈 each additional key exchange method MUST be fully completed before the next one is started 🚨 also, this doc assumes each key exchange method uses exactly one IKE_FOLLOWUP_KE exchange 🍓 for methods that need multiple round trips, a separate document should define how they get split up across several IKE_FOLLOWUP_KE exchanges 💖
after an IKE SA is created, the window size may be greater than one, so multiple concurrent exchanges could be running at the same time 🌸 which means it's super important to link each IKE_FOLLOWUP_KE exchange to its CREATE_CHILD_SA exchange 🔥 once the IKE SA exists, all IKE exchanges are independent, and IKEv2 doesn't have a built-in way to link one exchange to another 🙈 so a brand new status notification called ADDITIONAL_KEY_EXCHANGE was introduced just for this 💅 its Notify Message Type value is 16441, and both the Protocol ID and SPI Size are set to 0 ✨ the data in this notification is a blob that only the responder understands, so the responder can tell which exchanges go together 🦋 for the initiator, the contents are just an opaque blob 🫧
the responder MUST include this notification in a CREATE_CHILD_SA or IKE_FOLLOWUP_KE response message whenever the next IKE_FOLLOWUP_KE exchange is expected, and it has to fill it with some data that lets the current exchange be linked to the next one 🚨 the initiator MUST send this notification back intact in the request message of the next IKE_FOLLOWUP_KE exchange 🚨
here's an example of a CREATE_CHILD_SA exchange followed by three additional key exchanges 👀
Initiator Responder
---------------------------------------------------------------------
HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} -->
<-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr,
N(ADDITIONAL_KEY_EXCHANGE)(link1)}
HDR(IKE_FOLLOWUP_KE), SK {KEi(1),
N(ADDITIONAL_KEY_EXCHANGE)(link1)} -->
<-- HDR(IKE_FOLLOWUP_KE), SK {KEr(1),
N(ADDITIONAL_KEY_EXCHANGE)(link2)}
HDR(IKE_FOLLOWUP_KE), SK {KEi(2),
N(ADDITIONAL_KEY_EXCHANGE)(link2)} -->
<-- HDR(IKE_FOLLOWUP_KE), SK {KEr(2),
N(ADDITIONAL_KEY_EXCHANGE)(link3)}
HDR(IKE_FOLLOWUP_KE), SK {KEi(3),
N(ADDITIONAL_KEY_EXCHANGE)(link3)} -->
<-- HDR(IKE_FOLLOWUP_KE), SK {KEr(3)}the field formerly called "Diffie-Hellman Group Num" (now called "Key Exchange Method") in the KEi(n) and KEr(n) payloads MUST match the n-th negotiated additional key exchange 🎯
sometimes life happens 😭 like a reboot, and the initiator can lose its state, forget it was in the middle of additional key exchanges, and never send the remaining IKE_FOLLOWUP_KE exchanges 💀 the responder MUST handle this gracefully and delete the associated state if it doesn't get the next expected IKE_FOLLOWUP_KE request after some reasonable amount of time ⏳ since computational resources and the key exchange algorithm in use vary so much, there's no normative guidance on how long that timeout should be 🙈 generally speaking though, 5-20 seconds of waiting time should be appropriate in most cases ⭐
it can also take too long for the initiator to prepare and send the next IKE_FOLLOWUP_KE request, or the network can drop the request and make it get retransmitted 🌧️ in that case the message might show up at the responder after it already deleted the state, following the advice above 😬 if the responder gets an IKE_FOLLOWUP_KE message for which it has no key exchange state, it MUST send back a brand new error notification called "STATE_NOT_FOUND" 🚨 this error is not fatal to the IKE SA 💜 its Notify Message Type value is 47, its Protocol ID and SPI Size are both set to 0, and the data is empty 🍓 if the initiator gets this notification in response to an IKE_FOLLOWUP_KE exchange doing an additional key exchange, it MUST cancel that exchange and MUST treat the whole series of exchanges started from the CREATE_CHILD_SA exchange as having failed 💔 most of the time this happens because the responder deleted the state too early (the gap between IKE_FOLLOWUP_KE exchanges looked too long from its side, maybe because of a temporary network failure) 🌩️ after getting this notification, the initiator MAY start a new CREATE_CHILD_SA exchange, which may eventually be followed by IKE_FOLLOWUP_KE exchanges, to retry the failed attempt 🔁 but if the initiator keeps getting STATE_NOT_FOUND notifications after several retries, it MUST treat this as a fatal error and delete the IKE SA by sending a DELETE payload 🛑
the peers might start rekeying the IKE SA or a Child SA at the exact same time, which is called "simultaneous rekeying" 👯♀️ Sections 2.8.1 and 2.8.2 of [RFC7296] explain how IKEv2 handles this 🤓 the basic rule is: if two identical new IKE SAs (or two pairs of Child SAs) get created in a simultaneous rekey, one of them should be deleted 🗑️ which one gets deleted depends on comparing the values of four nonces used in the colliding CREATE_CHILD_SA exchanges 🔍 the IKE SA (or pair of Child SAs) created by the exchange with the smallest nonce should be deleted by the initiator of that exchange 🫶
with multiple key exchanges, the SAs aren't created yet when CREATE_CHILD_SA finishes 🥺 they only get created after the whole series of IKE_FOLLOWUP_KE exchanges is done ✨ so if additional key exchanges were negotiated in the CREATE_CHILD_SA exchange that has the smallest nonce, there's nothing to delete yet 🌸 the initiator of that exchange just stops the rekeying process, and it MUST NOT initiate the IKE_FOLLOWUP_KE exchange 🛑
most rekey collisions get sorted out in the CREATE_CHILD_SA exchange itself 💅 but sometimes, because of packet loss, one peer gets a CREATE_CHILD_SA message asking it to rekey an SA it's already in the middle of rekeying (so the CREATE_CHILD_SA exchange it started already finished, and its series of IKE_FOLLOWUP_KE exchanges is still going) 😵💫 in that case, a TEMPORARY_FAILURE notification MUST be sent in response to that request 🚫
if multiple key exchanges were negotiated in the CREATE_CHILD_SA exchange, the resulting keys get computed like this 🧮
in the case of an IKE SA rekey:
SKEYSEED = prf(SK_d, SK(0) | Ni | Nr | SK(1) | ... SK(n))in the case of a Child SA creation or rekey:
KEYMAT = prf+ (SK_d, SK(0) | Ni | Nr | SK(1) | ... SK(n))in both cases, SK_d comes from the existing IKE SA, SK(0), Ni, and Nr are the shared key and nonces from the CREATE_CHILD_SA exchange, and SK(1)...SK(n) are the shared keys from the additional key exchanges 🌈
2.2.5. Interaction with IKEv2 Extensions 🦋
it's believed that this spec doesn't need any changes to the IKEv2 extensions defined so far 🫶 in particular, the IKE SA resumption mechanism defined in [RFC5723] can be used to resume IKE SAs created using this spec ✨
2.2.5.1. Interaction with Childless IKE SA 🦋
okay so bestie, this part is about a sneaky combo: setting up IKE SAs with post-quantum algorithms without ever using IKE_INTERMEDIATE exchanges 🔥. Instead, you lean on IKE_FOLLOWUP_KE exchanges. The IKE SA that comes out of IKE_SA_INIT can get rekeyed right away with CREATE_CHILD_SA, and those extra key exchanges ride on IKE_FOLLOWUP_KE messages 💖.
But here's the catch 💀. If the classical key exchange method is used in IKE_SA_INIT, the very first Child SA created in IKE_AUTH has zero resistance against quantum threats. Not me... that's giving vulnerable 🙈. So if the peers' local policy says every Child SA has to be post-quantum secure, they can skip creating that first Child SA by adopting [RFC6023] ✨. In that case the initiator sends two kinds of proposals in the IKE_SA_INIT request: one with ADDKE Transform Types and one without them 🌸. The responder picks the one without ADDKE and includes a CHILDLESS_IKEV2_SUPPORTED notification in the IKE_SA_INIT response 🎀.
If the initiator supports the childless IKE SA extension, both peers run the modified IKE_AUTH exchange from [RFC6023], and no Child SA gets created in that exchange 🧚. Then the peers should immediately rekey the IKE SA and create the Child SAs afterwards, all with additional key exchanges through CREATE_CHILD_SA 👑.
It's also possible for the initiator to send proposals with no ADDKE Transform Types at all in IKE_SA_INIT. Lowkey risky though 😭. The responder then has no clue whether the initiator supports this extension, and it may not be efficient. The responder has to wait for the next CREATE_CHILD_SA request just to figure out whether the request fits its local policy 🙈.
Also, support for childless IKE SA isn't negotiated. The responder is the one that indicates support for this mode, which means the responder can't force the initiator to use it 🫶. So it's totally possible the initiator doesn't support this extension and sends an IKE_AUTH request per [RFC7296] instead of [RFC6023] 💅. In that case, the responder may reply with a non-fatal error, like the NO_PROPOSAL_CHOSEN notify message type 🌈.
One more important thing 🚨. If the initial IKE SA is used to carry sensitive information, that information is not protected by the additional key exchanges, even though those might use post-quantum algorithms 💜. So in this setup, the peers have to use a post-quantum algorithm in Transform Type 4 to actually mitigate the quantum risk ⭐.
3. IANA Considerations 🎀
okay so this section is the registry housekeeping, and it's kinda a lot, but it's giving organized 💅.
First up, this document adds a new exchange type to the "IKEv2 Exchange Types" registry ✨:
44 IKE_FOLLOWUP_KENext, Transform Type 4 gets a glow-up 🦋. It's renamed in the "Transform Type Values" registry from "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" 🌸. The IKEv2 registry that used to be called "Transform Type 4 - Diffie-Hellman Group Transform IDs" is also renamed, this time to "Transform Type 4 - Key Exchange Method Transform IDs" 💖.
This document also adds the following Transform Types to the "Transform Type Values" registry. Iconic 👑:
+======+====================================+===============+
| Type | Description | Used In |
+======+====================================+===============+
| 6 | Additional Key Exchange 1 (ADDKE1) | (optional in |
| | | IKE, AH, ESP) |
+------+------------------------------------+---------------+
| 7 | Additional Key Exchange 2 (ADDKE2) | (optional in |
| | | IKE, AH, ESP) |
+------+------------------------------------+---------------+
| 8 | Additional Key Exchange 3 (ADDKE3) | (optional in |
| | | IKE, AH, ESP) |
+------+------------------------------------+---------------+
| 9 | Additional Key Exchange 4 (ADDKE4) | (optional in |
| | | IKE, AH, ESP) |
+------+------------------------------------+---------------+
| 10 | Additional Key Exchange 5 (ADDKE5) | (optional in |
| | | IKE, AH, ESP) |
+------+------------------------------------+---------------+
| 11 | Additional Key Exchange 6 (ADDKE6) | (optional in |
| | | IKE, AH, ESP) |
+------+------------------------------------+---------------+
| 12 | Additional Key Exchange 7 (ADDKE7) | (optional in |
| | | IKE, AH, ESP) |
+------+------------------------------------+---------------+
Table 1: "Transform Type Values" RegistryNext, this document defines a new Notify Message Type in the "IKEv2 Notify Message Types - Status Types" registry 🧚:
16441 ADDITIONAL_KEY_EXCHANGEIt also defines a new Notify Message Type in the "IKEv2 Notify Message Types - Error Types" registry 🙈:
47 STATE_NOT_FOUNDIANA has added the following instructions for designated experts for the "Transform Type 4 - Key Exchange Method Transform IDs" subregistry 🫶. Here's the vibe: when adding new Key Exchange (KE) methods, the following considerations must be applied. A KE method must take exactly one round-trip (one IKEv2 exchange), and at the end of that exchange, both peers must be able to derive the shared secret ✨. Also, any public value the peers exchange during a KE method must fit into a single IKEv2 payload. If a KE method doesn't meet these restrictions, then there must be documentation on how that KE method is used in IKEv2 📝.
IANA also completed some other changes 🌈. It's assumed that [RFC9370] refers to this specification.
- A reference to [RFC9370] got added to what used to be the "Transform Type 4 - Diffie-Hellman Group Transform IDs" registry 💜.
- The Note on that same registry was replaced with the following notes 🍓:
This registry was originally named "Transform Type 4 - Diffie-Hellman Group Transform IDs" and was referenced using that name in a number of RFCs published prior to [RFC9370], which gave it the current title.
This registry is used by the "Key Exchange Method (KE)" transform type and by all "Additional Key Exchange (ADDKE)" transform types.
To find out requirement levels for Key Exchange Methods for IKEv2, see [RFC8247].
- [RFC9370] got appended to the Reference column of Transform Type 4 in the "Transform Type Values" registry 🎀.
- These notes got added to the "Transform Type Values" registry 💅:
"Key Exchange Method (KE)" transform type was originally named "Diffie-Hellman Group (D-H)" and was referenced by that name in a number of RFCs published prior to [RFC9370], which gave it the current title.
All "Additional Key Exchange (ADDKE)" entries use the same "Transform Type 4 - Key Exchange Method Transform IDs" registry as the "Key Exchange Method (KE)" entry.
4. Security Considerations 🔐
okay so this extension is basically built to fight off two baddies in IKEv2 💅. First, it wants to keep the (EC)DH key exchange from getting cracked by Shor's algorithm, and it has to stay backward compatible while doing it 🔥. Second, it guards against the chance that existing or future PQC key exchange algorithms get compromised 🫶. For the first one, it lets you build a shared secret from multiple key exchanges, usually one classical (EC)DH plus one post-quantum algorithm. For the second, you can run multiple key exchanges that use post-quantum algorithms to form the shared key ✨.
Okay, so here's the plot twist 🎀. Key exchange methods (Transform Type 4) are the ones Shor's algorithm wrecks. The Encryption Algorithm (Transform Type 1), the Pseudorandom Function (Transform Type 2), and the Integrity Algorithm (Transform Type 3) are not susceptible to Shor's algorithm 🧚. They aren't totally off the hook, though. They're susceptible to Grover's attack [GROVER], which lets a quantum computer brute-force a key search with quadratically fewer steps than the classical version. The fix is kind of simple: just increase the key length 💜. People used to think you had to double the key length of these algorithms, but a bunch of factors suggest it's pretty unlikely to actually get that quadratic speedup from Grover's algorithm 🙈. NIST [NISTPQCFAQ] says current applications can keep using AES with a minimum key length of 128 bits. Still, if your data has to stay secure for many years to come, you might want to consider longer key sizes for the algorithms in Transform Types 1-3 🌸.
SKEYSEED gets calculated from the shared SK(x), using an algorithm defined in Transform Type 2 🦋. A quantum attacker might learn the value of SK(x) if it came from a classical key exchange. But other SK(x) values generated with a post-quantum algorithm keep the final SKEYSEED safe 🛡️. Big asterisk though: all of this assumes the algorithm defined in Transform Type 2 is quantum resistant 👀.
The order of the additional key exchanges should not really matter, since only the final shared secret is what counts 🤷♀️. BUT, because the running shared secret gets stronger with every extra key exchange, an implementer may want to do the most secure method first (by some metrics) and then the less secure ones after that 💅.
The main goal of this document is to stop a passive attacker from pulling off a "harvest-and-decrypt" attack 😤. That's where attackers record messages exchanged today and then decrypt them once they have access to cryptographically relevant quantum computers. The hybrid nature of the key exchange is what prevents this attack 🔐. Other attacks involving an active attacker with a quantum computer are not completely solved by this document, and there are two reasons for that 🙃:
- The first reason is that the authentication step stays classical 🧐. The authenticity of the SAs established under IKEv2 is protected by a pre-shared key or digital signature algorithms. A pre-shared key, as long as it's long enough, is post-quantum secure, but the other algorithms are not. Also, in implementations where scalability is a requirement, the pre-shared key method may not be suitable. Post-quantum authenticity can be provided by using a post-quantum digital signature 🖋️.
- Secondly, post-quantum algorithms are there to provide resistance to attacks mounted in the future, so it's worth noting that 🕰️. The current threat is that encrypted sessions get eavesdropped on and archived, to be decrypted by quantum computers at some point down the road. Until quantum computers actually exist, there's no point in attacking a connection's authenticity, because there's no way to exploit it. Those attacks only happen at connection time, for example by mounting an on-path attack. So there's less urgency for post-quantum authenticity compared to post-quantum confidentiality 💜.
Doing multiple key exchanges while establishing an IKE SA makes the responder more open to DoS attacks 😬. That's because it needs more resources before the initiator has been authenticated. This is especially true for post-quantum key exchange methods, since a lot of them are more memory and/or CPU intensive than the classical counterparts 🥵.
Responders can check out the recommendations in [RFC8019] for dealing with that increased DoS-attack susceptibility 🛡️. Another option: the responder only agrees to create an initial IKE SA without doing additional key exchanges, if the initiator includes that option in its proposals 🙌. Then the peers immediately rekey the initial IKE SA with the CREATE_CHILD_SA exchange, and the additional key exchanges happen via IKE_FOLLOWUP_KE exchanges. In this setup, by the time the resource-intensive stuff is needed, the peers have already authenticated each other ✅.
Heads up: with hybrid post-quantum key exchanges, this scenario leaves the initial IKE SA (and the initial Child SA, if one is created) unprotected against quantum computers 😭. The rekeyed IKE SA (and any Child SAs created over it) do get full protection 🫶.
This is similar to the scenario described in [RFC8784] 🌈. Depending on the arrangement and the peers' policy, this scenario may or may not be appropriate 🤔. For example, in the G-IKEv2 protocol [G-IKEV2], the cryptographic materials are sent from the group controller to the group members when the initial IKE SA is created 🧚.
5. References 📚
5.1. Normative References
these are the must-read refs, bestie, so here they are exactly as written 🎀:
[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>.
[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>.
[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>.
[RFC9242] Smyslov, V., "Intermediate Exchange in the Internet Key
Exchange Protocol Version 2 (IKEv2)", RFC 9242,
DOI 10.17487/RFC9242, May 2022,
<https://www.rfc-editor.org/info/rfc9242>.5.2. Informative References
and these are the nice-to-know ones 💖:
[BEYOND-64K]
Tjhai, CJ., Heider, T., and V. Smyslov, "Beyond 64KB Limit
of IKEv2 Payloads", Work in Progress, Internet-Draft,
draft-tjhai-ikev2-beyond-64k-limit-03, 28 July 2022,
<https://datatracker.ietf.org/doc/html/draft-tjhai-ikev2-beyond-64k-limit-03>.
[G-IKEV2] Smyslov, V. and B. Weis, "Group Key Management using
IKEv2", Work in Progress, Internet-Draft, draft-ietf-
ipsecme-g-ikev2-09, 19 April 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-g-ikev2-09>.
[GROVER] Grover, L., "A fast quantum mechanical algorithm for
database search", Proc. of the Twenty-Eighth Annual ACM
Symposium on the Theory of Computing (STOC), pp. 212-219,
DOI 10.48550/arXiv.quant-ph/9605043, May 1996,
<https://doi.org/10.48550/arXiv.quant-ph/9605043>.
[IKEV2TYPE4ID]
IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters:
Transform Type 4 - Diffie-Hellman Group Transform IDs",
<https://www.iana.org/assignments/ikev2-parameters/>.
[NISTPQCFAQ]
NIST, "Post-Quantum Cryptography Standard", January 2023,
<https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs>.
[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>.
[RFC6023] Nir, Y., Tschofenig, H., Deng, H., and R. Singh, "A
Childless Initiation of the Internet Key Exchange Version
2 (IKEv2) Security Association (SA)", RFC 6023,
DOI 10.17487/RFC6023, October 2010,
<https://www.rfc-editor.org/info/rfc6023>.
[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>.
[RFC8019] Nir, Y. and V. Smyslov, "Protecting Internet Key Exchange
Protocol Version 2 (IKEv2) Implementations from
Distributed Denial-of-Service Attacks", RFC 8019,
DOI 10.17487/RFC8019, November 2016,
<https://www.rfc-editor.org/info/rfc8019>.
[RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault,
"Algorithm Implementation Requirements and Usage Guidance
for the Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 8247, DOI 10.17487/RFC8247, September 2017,
<https://www.rfc-editor.org/info/rfc8247>.
[RFC8784] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov,
"Mixing Preshared Keys in the Internet Key Exchange
Protocol Version 2 (IKEv2) for Post-quantum Security",
RFC 8784, DOI 10.17487/RFC8784, June 2020,
<https://www.rfc-editor.org/info/rfc8784>.Appendix A. Sample Multiple Key Exchanges 🌈
this appendix has some examples of multiple key exchanges, bestie 🧚. They're not normative, so think of them as vibes and illustrations rather than rules. They walk through some message flow scenarios that may come up when you're setting up an IKE or Child SA. Heads up: some payloads that aren't relevant to multiple key exchanges may get left out for brevity ✨.
A.1. IKE_INTERMEDIATE Exchanges Carrying Additional Key Exchange Payloads ✨
okay bestie, this example is all about the initiator going "let's do EXTRA key exchanges!!" 💖 It proposes three sets of additional key exchanges, and every single set is optional 🫶 So the responder is totally allowed to pick NONE for some or all of them, whether that's because it doesn't support the methods or because it just decides not to do the extra exchange 💅
Initiator Responder
---------------------------------------------------------------------
HDR(IKE_SA_INIT), SAi1(.. ADDKE*...), --->
KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED),
N(INTERMEDIATE_EXCHANGE_SUPPORTED)
Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519)
Transform ADDKE1 (ID = PQ_KEM_1)
Transform ADDKE1 (ID = PQ_KEM_2)
Transform ADDKE1 (ID = NONE)
Transform ADDKE2 (ID = PQ_KEM_3)
Transform ADDKE2 (ID = PQ_KEM_4)
Transform ADDKE2 (ID = NONE)
Transform ADDKE3 (ID = PQ_KEM_5)
Transform ADDKE3 (ID = PQ_KEM_6)
Transform ADDKE3 (ID = NONE)
<--- HDR(IKE_SA_INIT), SAr1(.. ADDKE*...),
KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED),
N(INTERMEDIATE_EXCHANGE_SUPPORTED)
Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519)
Transform ADDKE1 (ID = PQ_KEM_2)
Transform ADDKE2 (ID = NONE)
Transform ADDKE3 (ID = PQ_KEM_5)
HDR(IKE_INTERMEDIATE), SK {KEi(1)(PQ_KEM_2)} -->
<--- HDR(IKE_INTERMEDIATE), SK {KEr(1)(PQ_KEM_2)}
HDR(IKE_INTERMEDIATE), SK {KEi(2)(PQ_KEM_5)} -->
<--- HDR(IKE_INTERMEDIATE), SK {KEr(2)(PQ_KEM_5)}
HDR(IKE_AUTH), SK{ IDi, AUTH, SAi2, TSi, TSr } --->
<--- HDR(IKE_AUTH), SK{ IDr, AUTH, SAr2,
TSi, TSr }In this particular example, the responder decides to do two extra key exchanges 🦋 It picks PQ_KEM_2, NONE, and PQ_KEM_5 for the first, second, and third additional key exchanges, in that order. As per [RFC7296], a set of keying materials gets derived, specifically SK_d, SK_a[i/r], and SK_e[i/r]. Then both peers do an IKE_INTERMEDIATE exchange carrying the PQ_KEM_2 payload, which is protected with the SK_e[i/r] and SK_a[i/r] keys 🔐 Once that's done, the SKEYSEED gets updated using SK(1), which is the PQ_KEM_2 shared secret, like this:
SKEYSEED(1) = prf(SK_d, SK(1) | Ni | Nr)Then the updated SKEYSEED value is used to derive the next batch of keying materials:
{SK_d(1) | SK_ai(1) | SK_ar(1) | SK_ei(1) | SK_er(1) | SK_pi(1) |
SK_pr(1)} = prf+ (SKEYSEED(1), Ni | Nr | SPIi | SPIr)As per [RFC9242], both peers compute IntAuth_i1 and IntAuth_r1 using the SK_pi(1) and SK_pr(1) keys, respectively. These values are required in the IKE_AUTH phase of the exchange 🎀
Next up is the second IKE_INTERMEDIATE exchange. This time the peers use SK_e[i/r](1) and SK_a[i/r](1) to protect the PQ_KEM_5 payload. After that one wraps up, the keying materials get updated again:
SKEYSEED(2) = prf(SK_d(1), SK(2) | Ni | Nr)
{SK_d(2) | SK_ai(2) | SK_ar(2) | SK_ei(2) | SK_er(2) | SK_pi(2) |
SK_pr(2)} = prf+ (SKEYSEED(2), Ni | Nr | SPIi | SPIr)In this update, SK(2) is the shared secret from the third additional key exchange, which is PQ_KEM_5 🌈 Then both peers compute the values of IntAuth_[i/r]2 using the SK_p[i/r](2) keys.
After the second IKE_INTERMEDIATE exchange is done, both peers move on to the IKE_AUTH exchange phase 🚀 As defined in [RFC9242], the IntAuth_[i/r]2 values get used to compute IntAuth, and that is what goes into calculating the InitiatorSignedOctets and ResponderSignedOctets blobs (see Section 3.3.2 of [RFC9242]) 💜
A.2. No Additional Key Exchange Used 🙈
this one is the "nobody's doing extra stuff" plot twist 💀 The initiator proposes two sets of optional additional key exchanges, but the responder doesn't support any of them. So the responder picks NONE for each set. That means the IKE_INTERMEDIATE exchange never happens and everything just skips straight to the IKE_AUTH phase ✨ The resulting keying materials end up being the same ones you'd get with [RFC7296], which is honestly very iconic for backwards vibes 🍓
Initiator Responder
---------------------------------------------------------------------
HDR(IKE_SA_INIT), SAi1(.. ADDKE*...), --->
KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED),
N(INTERMEDIATE_EXCHANGE_SUPPORTED)
Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519)
Transform ADDKE1 (ID = PQ_KEM_1)
Transform ADDKE1 (ID = PQ_KEM_2)
Transform ADDKE1 (ID = NONE)
Transform ADDKE2 (ID = PQ_KEM_3)
Transform ADDKE2 (ID = PQ_KEM_4)
Transform ADDKE2 (ID = NONE)
<--- HDR(IKE_SA_INIT), SAr1(.. ADDKE*...),
KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED),
N(INTERMEDIATE_EXCHANGE_SUPPORTED)
Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519)
Transform ADDKE1 (ID = NONE)
Transform ADDKE2 (ID = NONE)
HDR(IKE_AUTH), SK{ IDi, AUTH, SAi2, TSi, TSr } --->
<--- HDR(IKE_AUTH), SK{ IDr, AUTH, SAr2,
TSi, TSr }A.3. Additional Key Exchange in the CREATE_CHILD_SA Exchange Only 🧚
ooh this one's a glow-up 🌸 The initiator doesn't propose extra key exchanges for establishing the IKE SA, but they're still required in order to establish a Child SA. To get a fully quantum-resistant IPsec SA, the responder includes a CHILDLESS_IKEV2_SUPPORTED notification in its IKE_SA_INIT response message. The initiator understands and supports that notification, so it exchanges a modified IKE_AUTH message with the responder and rekeys the IKE SA right away with additional key exchanges 🔥 Any Child SA has to be created afterward through a subsequent CREATE_CHILD_SA exchange 💅
Initiator Responder
---------------------------------------------------------------------
HDR(IKE_SA_INIT), SAi1, --->
KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED)
<--- HDR(IKE_SA_INIT), SAr1,
KEr(Curve25519), Nr, N(IKEV2_FRAG_SUPPORTED),
N(CHILDLESS_IKEV2_SUPPORTED)
HDR(IKE_AUTH), SK{ IDi, AUTH } --->
<--- HDR(IKE_AUTH), SK{ IDr, AUTH }
HDR(CREATE_CHILD_SA),
SK{ SAi(.. ADDKE*...), Ni, KEi(Curve25519) } --->
Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519)
Transform ADDKE1 (ID = PQ_KEM_1)
Transform ADDKE1 (ID = PQ_KEM_2)
Transform ADDKE2 (ID = PQ_KEM_5)
Transform ADDKE2 (ID = PQ_KEM_6)
Transform ADDKE2 (ID = NONE)
<--- HDR(CREATE_CHILD_SA), SK{ SAr(.. ADDKE*...),
Nr, KEr(Curve25519),
N(ADDITIONAL_KEY_EXCHANGE)(link1) }
Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519)
Transform ADDKE1 (ID = PQ_KEM_2)
Transform ADDKE2 (ID = PQ_KEM_5)
HDR(IKE_FOLLOWUP_KE), SK{ KEi(1)(PQ_KEM_2), --->
N(ADDITIONAL_KEY_EXCHANGE)(link1) }
<--- HDR(IKE_FOLLOWUP_KE), SK{ KEr(1)(PQ_KEM_2),
N(ADDITIONAL_KEY_EXCHANGE)(link2) }
HDR(IKE_FOLLOWUP_KE), SK{ KEi(2)(PQ_KEM_5), --->
N(ADDITIONAL_KEY_EXCHANGE)(link2) }
<--- HDR(IKE_FOLLOWUP_KE), SK{ KEr(2)(PQ_KEM_5) }A.4. No Matching Proposal for Additional Key Exchanges 😭
last one, and it's a bit of a drama 🎭 The initiator proposes the combo of PQ_KEM_1, PQ_KEM_2, PQ_KEM_3, and PQ_KEM_4 as the additional key exchanges. It says that either PQ_KEM_1 or PQ_KEM_2 must be used to establish an IKE SA, but the ADDKE2 Transform Type is optional. So the responder can either pick PQ_KEM_3 or PQ_KEM_4, or skip that key exchange by choosing NONE. Even though the responder supports the optional PQ_KEM_3 and PQ_KEM_4 methods, it doesn't support either of the PQ_KEM_1 or PQ_KEM_2 mandatory methods 💔 That means it responds with a NO_PROPOSAL_CHOSEN notification, and that's the end of that story 🥀
Initiator Responder
---------------------------------------------------------------------
HDR(IKE_SA_INIT), SAi1(.. ADDKE*...), --->
KEi(Curve25519), Ni, N(IKEV2_FRAG_SUPPORTED),
N(INTERMEDIATE_EXCHANGE_SUPPORTED)
Proposal #1
Transform ECR (ID = ENCR_AES_GCM_16,
256-bit key)
Transform PRF (ID = PRF_HMAC_SHA2_512)
Transform KE (ID = Curve25519)
Transform ADDKE1 (ID = PQ_KEM_1)
Transform ADDKE1 (ID = PQ_KEM_2)
Transform ADDKE2 (ID = PQ_KEM_3)
Transform ADDKE2 (ID = PQ_KEM_4)
Transform ADDKE2 (ID = NONE)
<--- HDR(IKE_SA_INIT), N(NO_PROPOSAL_CHOSEN)Appendix B. Design Criteria ✨
okay bestie, so the extension was built around a list of design criteria, and every single one is giving purpose 💅 let's go through them 🎀
1) Need for PQC in IPsec 🌸
Quantum computers might become feasible in the near future, and that's a real threat to our classical public key cryptography 😭 PQC is a family of public key cryptography that is believed to be resistant to these computers, so it needs to be integrated into the IPsec protocol suite to restore confidentiality and authenticity 🔐
2) Hybrid 🦋
There's currently no post-quantum key exchange that is trusted as much as (EC)DH is trusted for defending against conventional (non-quantum) adversaries 👀 So a hybrid post-quantum algorithm gets introduced alongside the well-established primitives. This works because the overall security is at least as strong as each individual primitive 💖
3) Focus on post-quantum confidentiality 🌙
A passive attacker can store all the encrypted IPsec traffic they monitor today and decrypt it once a quantum computer exists in the future 💀 The consequences can be serious and won't be visible for years. An attacker, on the other hand, can only perform active attacks, like impersonating the communicating peers, once a quantum computer is available sometime in the future. So this specification focuses on confidentiality because the problem is urgent 🚨 It presents a defense against the serious attack described above, but it does not address authentication, because authentication is less urgent at this stage 🙈
4) Limit the amount of exchanged data 🍓
The protocol design should keep the amount of exchanged data, such as public keys, as small as possible 🧚 That's true even if the initiator and the responder need to agree on a hybrid group, or if multiple public keys need to be exchanged.
5) Not post-quantum specific 🌈
Any cryptographic algorithm could potentially be broken in the future by currently unknown or impractical attacks, and quantum computers are merely the most concrete example of this 🔮 The design does not categorize algorithms as "post-quantum" or "non-post-quantum", and it doesn't create assumptions about the properties of the algorithms. That means if algorithms with different properties become necessary later, this extension can be used unchanged to make migrating to those algorithms easier ✨
6) Limited amount of changes 🎀
A key goal is to limit the number of changes needed when enabling a post-quantum handshake. That makes adoption quicker and easier for existing implementations 🫶
7) Localized changes 🦋
Another key requirement is keeping protocol changes limited in scope. In particular, changes to the exchanged messages and to the state machine should stay small, so they can be easily implemented 💜
8) Deterministic operation 👑
This requirement means the hybrid post-quantum exchange, and therefore the computed keys, will be based on algorithms that both client and server wish to support 🤝
9) Fragmentation support 💅
Some PQC algorithms could be pretty bulky and might require fragmentation 🥹 So a design goal is adapting and adopting an existing fragmentation method, or designing a new one, that allows the key shares to be fragmented ✂️
10) Backward compatibility and interoperability 🫶
This is a fundamental requirement. It makes sure that hybrid post-quantum IKEv2 and standard IKEv2 implementations as per [RFC7296] can still interoperate 🌸
11) Compliance with USA Federal Information Processing Standards (FIPS) 🇺🇸
IPsec is widely used in Federal Information Systems, so FIPS certification is an important requirement 📋 At the time of writing, none of the algorithms believed to be post-quantum is FIPS compliant yet 😬 Still, this post-quantum algorithm can be combined with a FIPS-compliant key establishment method, so the overall design remains FIPS compliant [NISTPQCFAQ] ✅
12) Ability to use this method with multiple classical (EC)DH key exchanges 🌈
Sometimes peers have no single, mutually trusted key exchange algorithm, for example because of local policy restrictions 🙃 Being able to combine two (or more) key exchange methods, in a way where the resulting shared key depends on all of them, lets peers still communicate in that situation. Main character energy for the win 👑⭐
Appendix C. Alternative Design ✨
okay bestie, this is my favourite bit 🦋 it's the "things we tried and said nope to" tour. This section gives an overview of a bunch of alternative approaches that got considered and later discarded. Here they are 💅
- Sending the classical and post-quantum key exchanges as a single transform 🧩
A method to combine the various key exchanges into a single large KE payload was considered. This effort is documented in a previous version of this document (draft-tjhai-ipsecme-hybrid-qske-ikev2-01). This method allows us to cleanly apply hybrid key exchanges during the Child SA. However, it does add considerable complexity and requires an independent fragmentation solution. ngl that's a lot of moving parts 😭
- Sending post-quantum proposals and policies in the KE payload only 🚨
With the objective of not introducing unnecessary notify payloads, a method to communicate the hybrid post-quantum proposal in the KE payload during the first pass of the protocol exchange was considered. Unfortunately, this design is susceptible to the following downgrade attack. Consider the scenario where there is an on-path attacker sitting between an initiator and a responder. Through the SAi payload, the initiator proposes using a hybrid post-quantum group and, as a fallback, a Diffie-Hellman group; and through the KEi payload, the initiator proposes a list of hybrid post-quantum proposals and policies. The on-path attacker intercepts this traffic and replies with N(INVALID_KE_PAYLOAD), suggesting a downgrade to the fallback Diffie-Hellman group instead. The initiator then resends the same SAi payload and the KEi payload containing the public value of the fallback Diffie-Hellman group. Note that the attacker may forward the second IKE_SA_INIT message only to the responder. Therefore, at this point in time, the responder will not have the information that the initiator prefers the hybrid group.
Of course, it is possible for the responder to have a policy to reject an IKE_SA_INIT message that (a) offers a hybrid group but does not offer the corresponding public value in the KEi payload and (b) the responder has not specifically acknowledged that it does not support the requested hybrid group. However, the checking of this policy introduces unnecessary protocol complexity. Therefore, in order to fully prevent any downgrade attacks, using a KE payload alone is not sufficient, and the initiator MUST always indicate its preferred post-quantum proposals and policies in a notify payload in the subsequent IKE_SA_INIT messages following an N(INVALID_KE_PAYLOAD) response. 🔐
- New payload types to negotiate hybrid proposals and to carry post-quantum public values 🆕
Semantically, it makes sense to use a new payload type, which mimics the SA payload, to carry a hybrid proposal. Likewise, another new payload type that mimics the KE payload could be used to transport hybrid public value. Although, in theory, a new payload type could be made backward compatible by not setting its critical flag as per Section 2.5 of [RFC7296], it is believed that it may not be that simple in practice. Since the original release of IKEv2 in RFC 4306, no new payload type has ever been proposed; therefore, this creates a potential risk of having a backward-compatibility issue from nonconformant IKEv2 implementations. Since there appears to be no other compelling advantages apart from a semantic one, the existing Transform Type and notify payloads are used instead. 🙈
- Hybrid public value payload 🎁
One way to transport the negotiated hybrid public payload, which contains one classical Diffie-Hellman public value and one or more post-quantum public values, is to bundle these into a single KE payload. Alternatively, these could also be transported in a single new hybrid public value payload. However, following the same reasoning as above may not be a good idea from a backward-compatibility perspective. Using a single KE payload would require encoding or formatting to be defined so that both peers are able to compose and extract the individual public values. However, it is believed that it is cleaner to send the hybrid public values in multiple KE payloads: one for each group or algorithm. Furthermore, at this point in the protocol exchange, both peers should have indicated support for handling multiple KE payloads. ✨
- Fragmentation 🧵
The handling of large IKE_SA_INIT messages has been one of the most challenging tasks. A number of approaches have been considered, and the two prominent ones that have been discarded are outlined as follows.
- Fragmenting the whole message as a byte stream
The first approach is to treat the entire IKE_SA_INIT message as a stream of bytes, which is then split into a number of fragments, each of which is wrapped onto a payload that will fit into the size of the network MTU. The payload that wraps each fragment has a new payload type, and it is envisaged that this new payload type will not cause a backward-compatibility issue because, at this stage of the protocol, both peers should have indicated support of fragmentation in the first pass of the IKE_SA_INIT exchange. The negotiation of fragmentation is performed using a notify payload, which also defines supporting parameters, such as the size of fragment in octets and the fragment identifier. The new payload that wraps each fragment of the messages in this exchange is assigned the same fragment identifier. Furthermore, it also has other parameters, such as a fragment index and total number of fragments. This approach has been discarded due to its blanket approach to fragmentation. In cases where only a few payloads need to be fragmented, this approach appears to be overly complicated. 🫠
- Fragmenting an individual payload using a spare bit
Another idea that has been discarded is fragmenting an individual payload without introducing a new payload type. The idea is to use the 9-th bit (the bit after the critical flag in the RESERVED field) in the generic payload header as a flag to mark that this payload is fragmented. As an example, if a KE payload is to be fragmented, it may look as follows.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C|F| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diffie-Hellman Group Number | Fragment Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Index | Total Fragments |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total KE Payload Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Fragmented KE Payload ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Example of How to Fragment a KE PayloadWhen the flag F is set, the current KE payload is a fragment of a larger KE payload. The Payload Length field denotes the size of this payload fragment in octets: including the size of the generic payload header. The 2-octet RESERVED field following Diffie-Hellman Group Number was to be used as a fragment identifier to help the assembly and disassembly of fragments. The Fragment Index and Total Fragments fields are self-explanatory. The Total KE Payload Data Length indicates the size of the assembled KE payload data in octets. Finally, the actual fragment is carried in Fragment KE Payload field.
This approach has been discarded because it is believed that the working group may not want to use the RESERVED field to change the format of a packet, and that implementers may not like the added complexity from checking the fragmentation flag in each received payload. More importantly, fragmenting the messages in this way may leave the system to be more prone to denial-of-service (DoS) attacks. This issue can be solved using IKE_INTERMEDIATE [RFC9242] to transport the large post-quantum key exchange payloads and using the generic IKEv2 fragmentation protocol [RFC7383]. 🛡️
- Group sub-identifier 🔢
As discussed before, each group identifier is used to distinguish a post-quantum algorithm. Further classification could be made on a particular post-quantum algorithm by assigning an additional value alongside the group identifier. This sub-identifier value may be used to assign different security-parameter sets to a given post-quantum algorithm. However, this level of detail does not fit the principles of the document where it should deal with generic hybrid key exchange protocol and not a specific ciphersuite. Furthermore, there are enough Diffie-Hellman group identifiers should this be required in the future. 🌈
Acknowledgements 🫶
The authors would like to thank Frederic Detienne and Olivier Pelerin for their comments and suggestions, including the idea to negotiate the post-quantum algorithms using the existing KE payload. The authors are also grateful to Tobias Heider and Tobias Guggemos for valuable comments. Thanks to Paul Wouters for reviewing the document. 💜
Authors' Addresses 💌
Cen Jung Tjhai Post-Quantum Email: cjt@post-quantum.com
Martin Tomlinson Post-Quantum Email: mt@post-quantum.com
Graham Bartlett Quantum Secret Email: graham.ietf@gmail.com
Scott Fluhrer Cisco Systems Email: sfluhrer@cisco.com
Daniel Van Geest ISARA Corporation Email: daniel.vangeest.ietf@gmail.com
Oscar Garcia-Morchon Philips Email: oscar.garcia-morchon@philips.com
Valery Smyslov ELVIS-PLUS Email: svan@elvis.ru
📦 where this page comes from
- ietf: rfc9370 2023-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms