File formats: **Also available: **XML file for editing **Status:**PROPOSED STANDARD **Author:**V. Smyslov Stream:IETF Source:ipsecme (sec)

Cite this RFC: TXT | XML | BibTeX

DOI: https://doi.org/10.17487/RFC9867

Discuss this RFC: Send questions or comments to the mailing list [ipsec@ietf.org](mailto:ipsec@ietf.org?subject=Question regarding RFC 9867)

Other actions: Submit Errata | Find IPR Disclosures from the IETF | View History of RFC 9867

Abstract

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.

For the definition of Status, see RFC 2026.

For the definition of Stream, see RFC 8729.