{"draft":"draft-ietf-ipsecme-ikev2-qr-alt-10","doc_id":"RFC9867","title":"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","authors":["V. Smyslov"],"format":["HTML","TEXT","PDF","XML"],"page_count":"12","pub_status":"PROPOSED STANDARD","status":"PROPOSED STANDARD","source":"IP Security Maintenance and Extensions","abstract":"An Internet Key Exchange Protocol Version 2 (IKEv2) extension defined\r\nin RFC 8784 allows IPsec traffic to be protected against someone\r\nstoring VPN communications and decrypting them later, when (and if) a\r\nCryptographically Relevant Quantum Computer (CRQC) is available. The\r\nprotection is achieved by means of a Post-quantum Preshared Key (PPK)\r\nthat is mixed into the session keys calculation. However, this\r\nprotection does not cover an initial IKEv2 Security Association (SA),\r\nwhich might be unacceptable in some scenarios. This specification\r\ndefines an alternative way to provide protection against quantum\r\ncomputers, which is similar to the solution defined in RFC 8784, but\r\nit also protects the initial IKEv2 SA. \r\n\r\nRFC 8784 assumes that PPKs are static and thus they are only used\r\nwhen an initial IKEv2 SA is created. If a fresh PPK is available\r\nbefore the IKE SA expires, then the only way to use it is to delete\r\nthe current IKE SA and create a new one from scratch, which is\r\ninefficient. This specification defines a way to use PPKs in active\r\nIKEv2 SAs for creating additional IPsec SAs and rekey operations.","pub_date":"November 2025","keywords":["internet key exchange","quantum computer","post quantum","post-quantum","quantum safe","PPK"],"obsoletes":[],"obsoleted_by":[],"updates":[],"updated_by":[],"see_also":[],"doi":"10.17487\/RFC9867","errata_url":null}