RFC 9867
Mixing Preshared Keys in the IKE_INTERMEDIATE and CREATE_CHILD_SA Exchanges of the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-Quantum Security
RFC 9867: Mixing Preshared Keys in the IKE_INTERMEDIATE and CREATE_CHILD_SA Exchanges of the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-Quantum Security 🎀
Okay bestie, this one comes from the IETF (Internet Engineering Task Force) 🌸. It was written by V. Smyslov of ELVIS-PLUS, it's a Standards Track document (so it's official protocol stuff, not a vibe check 💅), and it was published in November 2025 with ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates ✨.
Abstract 💖
Okay so, RFC 8784 is an IKEv2 extension that protects IPsec traffic against someone storing VPN communications now and decrypting them later, when (and if) a Cryptographically Relevant Quantum Computer (CRQC) is available 😭. It does this by mixing a Post-quantum Preshared Key (PPK) into the session keys calculation. The catch is that it doesn't cover the initial IKEv2 Security Association (SA), and in some scenarios that's a total dealbreaker 💀. This spec gives you an alternative that's similar to RFC 8784 but also protects the initial IKEv2 SA 🦋.
RFC 8784 treats PPKs as static, so they only get used when an initial IKEv2 SA is created. If a fresh PPK shows up before the IKE SA expires, the only option is to delete the current IKE SA and build a new one from scratch, which is honestly inefficient 🙈. This specification defines how to use PPKs in active IKEv2 SAs to create additional IPsec SAs and do rekey operations 🧚.
Status of This Memo 📜
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9867.
Copyright Notice 🔒
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
Table of Contents 🗂️
1. Introduction
2. Terminology and Notation
3. Protocol Description
3.1. Creating Initial IKE SA
3.1.1. Computing IKE SA Keys
3.2. Using PPKs in the CREATE_CHILD_SA Exchange
3.2.1. Computing Keys
4. Security Considerations
5. IANA Considerations
6. References
6.1. Normative References
6.2. Informative References
Appendix A. Comparison of this Specification with RFC 8784
Acknowledgements
Author's Address1. Introduction ✨
The Internet Key Exchange Protocol Version 2 (IKEv2), defined in [RFC7296], is what IPsec uses for authenticated key exchange 🔐. There's an extension to IKEv2 for mixing preshared keys for post-quantum security, and it's defined in [RFC8784]. This extension lets today's IPsec traffic be protected against future quantum computers 🔮. The trick is using a Post-quantum Preshared Key (PPK) that gets mixed into the session keys calculation.
When this extension was being developed, the IPsecME WG consensus was that protecting IPsec traffic mattered more than protecting IKE traffic 🎀. The thinking was that the information sent over the IKE SA (including the peers' identities) was less important, and extending protection to the initial IKE SA would need serious changes to the core IKEv2 protocol. Minimizing those changes was one of the goals 💅. It was also decided that an immediate rekey of the initial IKE SA would add this protection to the new IKE SA, although it wouldn't protect the identity of the peers 👑.
But sometimes you really want that protection for the IKE SA from the very beginning, right when the initial IKE SA is created 😤. One example is the Group Key Management protocol using IKEv2, defined in [RFC9838]. In that protocol, the group policy and session keys go from a Group Controller/Key Server (GCKS) to the Group Members (GMs) as soon as an initial IKE SA is created. The session keys get extra protection from a key derived from SK_d, so they're immune to quantum computers if PPKs [RFC8784] are used. But the other sensitive data, including the group policy, isn't protected 😭.
There's another problem with PPKs as defined in [RFC8784]. That approach assumes PPKs are static entities that change very infrequently, so PPKs only get used once, when an initial IKE SA is established 🙈. That's a real limitation if PPKs change relatively often, for example through Quantum Key Distribution (QKD) 🧚. If a fresh PPK shows up before the IKE SA expires, there's no way to use it except deleting the IKE SA and recreating a new one from scratch with the fresh PPK 💀.
Some time after [RFC8784] defined the protocol extension for mixing preshared keys in IKEv2 for post-quantum security, a new IKE_INTERMEDIATE exchange for IKEv2 [RFC9242] was developed 🌈. Its main motivation was letting multiple key exchanges be used in IKEv2 (which is defined in [RFC9370]), but the IKE_INTERMEDIATE exchange itself can be used for other purposes too ✨.
This specification defines using PPKs in the IKE_INTERMEDIATE exchange of IKEv2 for post-quantum security. That gives you full protection against quantum computers for the initial IKE SA 🦋👑.
This specification also defines using PPKs in the CREATE_CHILD_SA exchange, for creating additional IPsec SAs and for rekeying IKE and IPsec SAs 🫶. Implementations can use fresh PPKs without deleting the IKE SA and creating it from scratch again 🎀.
This specification does not replace the approach defined in [RFC8784]. Both approaches for using PPKs in IKEv2 can be used depending on the circumstances (see Appendix A) 💖.
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 🧠.
This document uses the terms defined in [RFC7296]. In particular, readers should be familiar with the terms "initiator" and "responder" as used in that document 🫶.
The approach defined in [RFC8784] is referred to as "using PPKs in the IKE_AUTH exchange" or simply "using PPKs in IKE_AUTH" throughout this document 🌸.
3. Protocol Description ✨
3.1. Creating Initial IKE SA ✨
okay so the IKE initiator 💅 supports the IKE_INTERMEDIATE exchange and wants a PPK to protect the initial IKE SA 🔐. It sends the INTERMEDIATE_EXCHANGE_SUPPORTED notification and a notification of type USE_PPK_INT in the IKE_SA_INIT request. If the responder also supports IKE_INTERMEDIATE and is down to use PPK for initial IKE SA protection, it sends both of those notifications back in the IKE_SA_INIT response 🦋
Initiator Responder
------------------------------------------------------------------
HDR, SAi1, KEi, Ni,
N(INTERMEDIATE_EXCHANGE_SUPPORTED),
N(USE_PPK_INT) --->
<--- HDR, SAr1, KEr, Nr, [CERTREQ,]
N(INTERMEDIATE_EXCHANGE_SUPPORTED),
N(USE_PPK_INT)The USE_PPK_INT is a Status Type IKEv2 notification 🎀. Its Notify Message Type is 16445, the Protocol ID is set to 0, and there's no SPI, so the SPI Size is set to 0 too. This spec doesn't define any data that the notification may contain, so the Notification Data is left empty. Future extensions of this specification may make use of it though 👀 Implementations MUST ignore any data in the notification that they do not understand.
Note that this negotiation is totally independent from using PPKs as specified in [RFC8784] 🫶 An initiator that supports both PPKs in IKE_AUTH [RFC8784] and IKE_INTERMEDIATE MAY include both the USE_PPK_INT and USE_PPK notifications if it's configured to do so. Here's the tea though: if the responder supports both specs and is configured to use PPKs, it has to pick one 💅 so it MUST return either a USE_PPK_INT or a USE_PPK notification in the response but not both.
If the initiator didn't propose this extension in the IKE_SA_INIT request, and the responder's policy mandates protecting the initial IKE SA with a PPK, the responder MUST return the NO_PROPOSAL_CHOSEN notification. no vibes, just rules 🙅♀️
If the negotiation was successful, the initiator includes one or more PPK_IDENTITY_KEY notifications in the IKE_INTERMEDIATE request 🍓 Each one carries a PPK identity the initiator thinks is a good fit for the IKE SA being created.
The PPK_IDENTITY_KEY is a Status Type IKEv2 notification too ✨ Its Notify Message Type is 16446, and the Protocol ID and SPI Size fields are both set to 0. The Notification Data format looks like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ PPK_ID ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ PPK Confirmation +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: PPK_IDENTITY_KEY Notification Data FormatHere's what the fields mean 🧚
PPK_ID(variable): this is thePPK_IDfrom Section 5.1 of [RFC8784]. The receiver can figure out its length by subtracting 8 (the length of PPK Confirmation) from the Notification Data length 🧮- PPK Confirmation (8 octets): this is how the responder checks whether it has the same PPK as the initiator for a given
PPK_ID🔍 It holds the first 8 octets of a string computed asprf( PPK, Ni | Nr | SPIi | SPIr ), where:"prf"is the negotiated PRF;PPKis the key value for a specifiedPPK_ID;Ni,Nr,SPIi,SPIrare the nonces and IKE SPIs for the SA being established.
If a series of IKE_INTERMEDIATE exchanges happens, the PPK_IDENTITY_KEY notification(s) MUST be sent in the last one, i.e., in the IKE_INTERMEDIATE exchange immediately preceding the IKE_AUTH exchange. If that exchange also carries other payloads for some other purpose, the notification(s) MAY be piggybacked with these payloads. Also, future IKEv2 extensions that use IKE_INTERMEDIATE might let one or more of these exchanges happen after the PPK one, when those extensions get negotiated 🌈
Initiator Responder
------------------------------------------------------------------
HDR, SK { ... N(PPK_IDENTITY_KEY, PPK_ID_1)
[, N(PPK_IDENTITY_KEY, PPK_ID_2)] ...
[, N(PPK_IDENTITY_KEY, PPK_ID_n)]} --->Depending on what the responder can do and what its policy says, these situations are possible 👑
- If the responder has a PPK whose ID is among the IDs the initiator sent, and that PPK matches the initiator's PPK (based on the PPK Confirmation field), then the responder picks this PPK and sends its identity back in the
PPK_IDENTITYnotification. ThePPK_IDENTITYnotification is defined in [RFC8784].
Initiator Responder
---------------------------------------------------------------
<--- HDR, SK { ... N(PPK_IDENTITY, PPK_ID_i)}In this case, the IKE_AUTH exchange is done as defined in IKEv2 [RFC7296]. The IKE SA keys get computed using the PPK, as described in Section 3.1.1. If the responder returns a PPK identity that the initiator didn't propose, the initiator MUST treat this as fatal and abort the IKE SA establishment. big no no 🙅♀️
- If the responder doesn't have a PPK with an ID matching any of the IDs the initiator sent, or it has some of the proposed PPKs but their values don't match the initiator's (based on the PPK Confirmation field), and using PPK is mandatory for the responder, then it MUST return an
AUTHENTICATION_FAILEDnotification and abort creating the IKE SA. 💀
Initiator Responder
---------------------------------------------------------------
<--- HDR, SK {... N(AUTHENTICATION_FAILED)}- If the responder doesn't have any PPKs the initiator proposed, or it has only some of them but their values mismatch the initiator's (based on the PPK Confirmation field), and using PPK is optional for the responder, then it doesn't include any
PPK_IDENTITYnotification in the response 🥺
Initiator Responder
---------------------------------------------------------------
<--- HDR, SK {...}In this case, the initiator can't reach quantum computer resistance using the proposed PPKs. If this is a requirement for the initiator, then it MUST abort creating the IKE SA. Otherwise, the initiator carries on with the IKE_AUTH exchange as described in IKEv2 [RFC7296] ✨
Table 1 sums up the logic above for the responder 📋
+===========+=============+========+===========+====================+
|Received | Supports |Has one | PPK is | Action |
|USE_PPK_INT| USE_PPK_INT |of the | mandatory | |
| | |proposed| for | |
| | |PPKs | initial | |
| | | | IKE SA | |
+===========+=============+========+===========+====================+
|No | * |* | No | [RFC8784] (if |
| | | | | proposed) or |
| | | | | standard IKEv2 |
| | | | | protocol |
+-----------+-------------+--------+-----------+--------------------+
|No | Yes |* | Yes | Send |
| | | | | NO_PROPOSAL_CHOSEN |
+-----------+-------------+--------+-----------+--------------------+
|Yes | Yes |Yes | * | Section 3.1, |
| | | | | Paragraph 14, Item |
| | | | | 1 (use this |
| | | | | extension) |
+-----------+-------------+--------+-----------+--------------------+
|Yes | Yes |No | Yes | Section 3.1, |
| | | | | Paragraph 14, Item |
| | | | | 2 (abort |
| | | | | negotiation) |
+-----------+-------------+--------+-----------+--------------------+
|Yes | Yes |No | No | Section 3.1, |
| | | | | Paragraph 14, Item |
| | | | | 3 (standard IKEv2 |
| | | | | protocol) |
+-----------+-------------+--------+-----------+--------------------+
Table 1: Responder's BehaviorHere's a sneaky one 👀 The responder picks a PPK before it knows who the initiator is. So it's possible the responder agrees to use some PPK during IKE_INTERMEDIATE, and then in IKE_AUTH it finds out that PPK isn't linked to the initiator's identity in its local policy. The responder does have that PPK, it's just not on the list for this initiator 🙈 In that case, the responder SHOULD abort negotiation and return the AUTHENTICATION_FAILED notification to be consistent with its policy. However, the responder MAY continue creating the IKE SA using the negotiated "wrong" PPK if that's acceptable according to its local policy. it's giving "your call, bestie" 💜
3.1.1. Computing IKE SA Keys
Okay so once the PPK gets negotiated in the IKE_INTERMEDIATE exchange, the IKE SA keys get recalculated 🔄✨. Heads up, bestie: if the IKE SA keys also get recalculated because of other stuff happening in that same IKE_INTERMEDIATE exchange (like what's defined in [RFC9370]), then applying the PPK MUST be done after all of them. That way, recalculating with the PPK is the very last thing before the keys get used in the next exchange 💅. Future IKEv2 extensions that use the IKE_INTERMEDIATE exchange may update this requirement once they're negotiated 🌸.
The IKE SA keys are computed differently from how PPKs get used in IKE_AUTH, so pay attention 🎀. A new SKEYSEED' value is computed from the negotiated PPK and the most recently computed SK_d key. The PPK gets applied to SK_d exactly how [RFC8784] specifies it, and that result becomes SKEYSEED' 🦋:
SKEYSEED' = prf+ (PPK, SK_d)Then SKEYSEED' is used to recalculate all the SK_* keys, as defined in Section 2.14 of [RFC7296] 💖:
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr}
= prf+ (SKEYSEED', Ni | Nr | SPIi | SPIr )In that formula, Ni and Nr are nonces from the IKE_SA_INIT exchange, and SPIi and SPIr are the SPIs of the IKE SA being created. Also, SK_d, SK_pi, and SK_pr are not individually recalculated using the PPK, as defined in [RFC8784] 🙈. The resulting keys then get used in the IKE_AUTH exchange and in the created IKE SA ✨.
3.2. Using PPKs in the CREATE_CHILD_SA Exchange
Here's the vibe: if a fresh PPK is available to both peers while an IKE SA is already active, peers MAY use that fresh PPK without building a whole new IKE SA from scratch 🫶. This comes in handy when they need to create extra IPsec SAs or rekey existing SAs. In this case, the PPK can be used to create additional IPsec SAs and to rekey both IKE and IPsec SAs. It doesn't matter whether the current IKE SA was made with a PPK (no matter how: in IKE_AUTH, in IKE_INTERMEDIATE, or in CREATE_CHILD_SA) or without one 👑.
If the initiator wants to use a PPK in the CREATE_CHILD_SA exchange, it includes one or more PPK_IDENTITY_KEY notifications. Those contain the PPK identities the initiator thinks are appropriate for the SA being created in the CREATE_CHILD_SA request 🍓. The PPK Confirmation field holds the first 8 octets of a string computed as prf( PPK, Ni | SPIi | SPIr ). Here, Ni is the initiator's nonce from the CREATE_CHILD_SA request, and SPIi/SPIr are the SPIs of the current IKE SA. If the responder supports using PPKs in the CREATE_CHILD_SA exchange and is configured and ready to do it, it sends back the PPK_IDENTITY notification containing the ID of the selected PPK. The figures below show what that looks like 🧚.
Initiator Responder
------------------------------------------------------------------
HDR, SK {[N(REKEY_SA),] SA, Ni, [KEi,] TSi, TSr,
N(PPK_IDENTITY_KEY, PPK_ID_1)
[, N(PPK_IDENTITY_KEY, PPK_ID_2)] ...
[, N(PPK_IDENTITY_KEY, PPK_ID_n)]} --->
<--- HDR, SK {SA, Nr [KEr,] TSi, TSr,
N(PPK_IDENTITY, PPK_ID_i)}Figure 2: CREATE_CHILD_SA Exchange for Creating or Rekeying Child SAs
Initiator Responder
------------------------------------------------------------------
HDR, SK {SA, Ni, KEi,
N(PPK_IDENTITY_KEY, PPK_ID_1)
[, N(PPK_IDENTITY_KEY, PPK_ID_2)] ...
[, N(PPK_IDENTITY_KEY, PPK_ID_n)]} --->
<--- HDR, SK {SA, Nr, KEr,
N(PPK_IDENTITY, PPK_ID_i)}Figure 3: CREATE_CHILD_SA Exchange for Rekeying IKE SA
Now for the "what if it doesn't work" part 😭. If the responder doesn't support using PPKs in the CREATE_CHILD_SA exchange (or isn't configured for it), or it doesn't have a PPK with an ID matching any of the IDs the initiator sent, or it has some of the proposed PPKs but their values don't match the initiator's (based on the PPK Confirmation field), then it won't include any PPK_IDENTITY notifications in the response. The new SA then gets created the regular way, as defined in IKEv2 [RFC7296]. If that's not okay for the initiator, it can immediately delete this SA 🙅♀️.
If using PPKs in CREATE_CHILD_SA is mandatory for the responder, things get stricter 🔥. If the initiator doesn't include any PPK_IDENTITY_KEY notifications in the request, or the responder doesn't have a PPK with an ID matching any of the IDs the initiator sent, or the responder has some of the proposed PPKs but their values don't match the initiator's (based on the PPK Confirmation field), then the responder MUST return the NO_PROPOSAL_CHOSEN notification. No vibes allowed here, periodt 💀.
Otherwise, the new SA is created using the selected PPK 🌈.
3.2.1. Computing Keys
To calculate session keys for the new SA, the current SK_d key gets mixed with the selected PPK first ✨:
SK_d' = prf+ (PPK, SK_d)The resulting SK_d' then gets used instead of SK_d in all the formulas for computing keys for the new SA (Sections 2.17 and 2.18 of [RFC7296] and Section 2.2.4 of [RFC9370]) 💜.
Also, if the PPK that was used for the IKE SA establishment hasn't changed, there's no point in using it again in the CREATE_CHILD_SA exchange 🙃.
4. Security Considerations 🔐
Security considerations for using Post-quantum Preshared Keys in the IKEv2 protocol are discussed in [RFC8784]. Unlike using PPKs in IKE_AUTH, this specification makes even the initial IKE SA quantum secure 🌟. On top of that, a PPK gets mixed into the SK_* keys calculation before the IKE_AUTH exchange starts. Since the PPK is also used in authentication, this exchange stays quantum secure even against an active attacker 😱.
This specification relies on the IKE_INTERMEDIATE exchange. Please refer to [RFC9242] for a discussion of related security issues 📚.
Section 4 of [RFC9370] discusses the potential impact of a CRQC being accessible on the various cryptographic primitives used in IKEv2. It's worth repeating here that it is believed the security of symmetric key cryptographic primitives will not be affected by a CRQC 🛡️.
5. IANA Considerations 🦋
Per this document, IANA has added the following Notify Message Types in the "IKEv2 Notify Message Status Types" registry 📝:
16445 USE_PPK_INT
16446 PPK_IDENTITY_KEY6. References 📚
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
[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>.
[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>.6.2. Informative References
[RFC9838] Smyslov, V. and B. Weis, "Group Key Management Using the
Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 9838, DOI 10.17487/RFC9838, November 2025,
<https://www.rfc-editor.org/info/rfc9838>.
[RFC9370] Tjhai, CJ., Tomlinson, M., Bartlett, G., Fluhrer, S., Van
Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple
Key Exchanges in the Internet Key Exchange Protocol
Version 2 (IKEv2)", RFC 9370, DOI 10.17487/RFC9370, May
2023, <https://www.rfc-editor.org/info/rfc9370>.Appendix A. Comparison of this Specification with RFC 8784 🌸
This specification isn't meant to replace using PPKs in IKE_AUTH as defined in [RFC8784] 🙅♀️. Instead, it's for situations where that approach doesn't meet the requirements, like needing to make the initial IKE SA quantum-secure, or needing to choose between several available PPKs. But if the peers support both using PPKs in IKE_AUTH and this specification, the latter may also be used in situations where using PPKs in IKE_AUTH is enough (for example, when the initial IKE SA doesn't need to be quantum-protected) 🧠.
The approach in this document has the following advantages 🏆:
- The main advantage of using a PPK in the
IKE_INTERMEDIATEexchange instead of theIKE_AUTHexchange is that it letsIKE_AUTHbe fully protected. That means the ID payloads and any other sensitive content sent inIKE_AUTHare protected against quantum computers. The same goes for the sensitive data sent in theGSA_AUTHexchange in the G-IKEv2 protocol [RFC9838] 💖. - Besides
IKE_AUTHbeing fully protected, the initial IKE SA is also fully protected. That's a big deal when sensitive information gets transferred over the initial IKE SA. Examples include theCREATE_CHILD_SAexchange of IKEv2 and theGSA_REGISTRATIONexchange of G-IKEv2 [RFC9838] 🔐. - Because the PPK exchange happens as a separate exchange before
IKE_AUTH, the initiator can propose several PPKs and the responder can pick one. That isn't possible when the PPK exchange happens inIKE_AUTH. This feature could simplify PPK rollover 🔄. - With this specification, the initiator doesn't need to calculate the content of the AUTH payload twice (with and without the PPK) to support a situation where using a PPK is optional for both sides 🙌.
The main downside of the approach in this document is that it always requires an additional round trip (the IKE_INTERMEDIATE exchange) to set up the IKE SA and the initial IPsec SA 😩. However, if the IKE_INTERMEDIATE exchange has to be used for some other purpose anyway, the PPK-related payloads can be piggybacked with other payloads, which gets rid of this penalty 🎉.
Acknowledgements 🫶
The author would like to thank Paul Wouters for valuable comments. Huge thanks to Tero Kivinen, who did a thorough review of the document and proposed a lot of text improvements, and who also pointed out the problem of mismatched preshared keys 👑. Thanks to Rebecca Guthrie for providing comments and proposals for the document, and to Mikhail Borodin for discovering the problem of calculating PPK Confirmation in CREATE_CHILD_SA 💜.
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
- ietf: rfc9867 2025-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms