Skip to main content

Alternative Approach for Mixing Preshared Keys in IKEv2 for Post-quantum Security
draft-smyslov-ipsecme-ikev2-qr-alt-09

Document Type Replaced Internet-Draft (ipsecme WG)
Expired & archived
Author Valery Smyslov
Last updated 2024-03-14 (Latest revision 2023-10-19)
Replaced by draft-ietf-ipsecme-ikev2-qr-alt
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status (None)
Formats
Additional resources Mailing list discussion
Stream WG state Adopted by a WG
Document shepherd (None)
IESG IESG state Replaced by draft-ietf-ipsecme-ikev2-qr-alt
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:

Abstract

An Internet Key Exchange protocol version 2 (IKEv2) extension defined in RFC8784 allows IPsec traffic to be protected against someone storing VPN communications today and decrypting it later, when (and if) cryptographically relevant quantum computers are available. The protection is achieved by means of Post-quantum Preshared Key (PPK) which is mixed into the session keys calculation. However, this protection doesn't cover an initial IKEv2 SA, which might be unacceptable in some scenarios. This specification defines an alternative way to get protection against quantum computers, which is similar to the solution defined in RFC8784, but protects the initial IKEv2 SA too. Besides, RFC8784 assumes that PPKs are static and thus they are only used when an initial IKEv2 Security Association (SA) is created. If a fresh PPK is available before the IKE SA is expired, 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 also defines a way to use PPKs in active IKEv2 SA for creating additional IPsec SAs and for rekeys operations.

Authors

Valery Smyslov

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)