Hi, it was pointed out to me in a private conversation that the way the PPK Confirmation field is computed in IKE_INTERMEDIATE is not appropriate for CREATE_CHILD_SA, since Nir is not yet known. The -04 version addresses this issue by omitting Nr from the calculation for this situation. It also clarifies the responder's behavior when using PPKs in CREATE_CHILD_SA is mandatory for the responder, but the initiator doesn't propose any PPK or proposes inappropriate ones (the responder sends back NO_PROPOSAL_CHOSEN).
Regards, Valery. > Internet-Draft draft-ietf-ipsecme-ikev2-qr-alt-04.txt is now available. It is > a work > item of the IP Security Maintenance and Extensions (IPSECME) WG of the IETF. > > Title: Mixing Preshared Keys in the IKE_INTERMEDIATE and in the > CREATE_CHILD_SA Exchanges of IKEv2 for Post-quantum Security > Author: Valery Smyslov > Name: draft-ietf-ipsecme-ikev2-qr-alt-04.txt > Pages: 12 > Dates: 2024-09-02 > > 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. > > This draft updates RFC8784 by extending use of PPKs. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-qr-alt/ > > There is also an HTMLized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-qr-alt-04 > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-ikev2-qr-alt-04 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > _______________________________________________ > IPsec mailing list -- ipsec@ietf.org > To unsubscribe send an email to ipsec-le...@ietf.org _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
