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
In plain English — editorial summary, not part of the RFC
An Internet Key Exchange Protocol Version 2 (IKEv2) extension defined in RFC 8784 allows IPsec traffic to be protected against someone storing VPN communications and decrypting them later, when (and if) a Cryptographically Relevant Quantum Computer (CRQC) is available. The protection is achieved by means of a Post-quantum Preshared Key (PPK) that is mixed into the session keys calculation. However, this protection does not cover an initial IKEv2 Security Association (SA), which might be unacceptable in some scenarios. This specification defines an alternative way to provide protection against quantum computers, which is similar to the solution defined in RFC 8784, but it also protects the initial IKEv2 SA. RFC 8784 assumes that PPKs are static and thus they are only used when an initial IKEv2 SA is created. If a fresh PPK is available before the IKE SA expires, then the only way to use it is to delete the current IKE SA and create a new one from scratch, which is inefficient. This specification defines a way to use PPKs in active IKEv2 SAs for creating additional IPsec SAs and rekey operations.
Document record
- Document ID
- RFC9867
- Published
- November 2025
- Authors
- V. Smyslov
- Status
- PROPOSED STANDARD
- Stream
- IETF
- Area
- sec
- Pages
- 12
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 8784Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum SecurityCurrent
June 2020
- RFC 9954Hybrid Key Exchange in TLS 1.3Current
July 2026
- RFC 9763Related Certificates for Use in Multiple Authentications within a ProtocolCurrent
June 2025
- RFC 9980Post-Quantum Cryptography in OpenPGPCurrent
June 2026
- RFC 10024Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3Current
August 2026
- RFC 9370Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)Current
May 2023
- RFC 9242Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)Current
May 2022
- RFC 8247Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)Updated
September 2017
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?