I had tried to address this in the security considerations section of the draft. I have not submitted the next version yet, but here is the text
~~~ For post-quantum deployments where the responder is upgraded to support ML-KEM before any initiator, the initiator could enforce a hard requirement for using ML-KEM in the IKE_SA_INIT or the IKE_INTERMEDIATE before encrypting any data in any Child SA or fail the negotiation. This is the most straightforward protection against downgrades in cases where the responder is upgraded before any initiator. Otherwise, [RFC9370] supports Childless IKE SAs which can be followed by a Child SA after a FOLLOWUP_KE exchange with ML-KEM. Establishing a Childless IKE SA or a Child SA which does not encrypt any data and establishing a Child SA or rekeying the existing one with a FOLLOWUP_KE exchange with ML-KEM ensures that the initiator or responder can enforce a policy which requires ML-KEM for peers expected to support ML-KEM after learning their identity in IKE_AUTH. Although this approach would prevent downgrades where an adversary can force peers that support ML-KEM to use classical key exchanges, it assumes the initiator or responder know the identities of their peers that support ML-KEM. It also has the disadvantage that an adversary with a quantum computer that can decrypt the initial IKE SA has access to all the information exchanged over it, such as identities of the peers, configuration parameters, and all negotiated SA information (including traffic selectors), with the exception of the cryptographic keys used by the IPsec SAs which are established after the ML-KEM key exchange. ~~~ From: Jun Hu (Nokia) <[email protected]> Sent: Monday, July 21, 2025 10:07 AM To: Christopher Patton <[email protected]>; Valery Smyslov <[email protected]> Cc: Daniel Van Geest <[email protected]>; [email protected] Subject: [EXTERNAL] [IPsec] Re: Binding properties of draft-ietf-ipsecme-ikev2-mlkem-00 CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Clarifying question: How exactly would it work to disable weak KEs for peers that support strong KE? The peer doesn't identify itself until the IKE_AUTH exchange, at which point the sequence of KEs has already been negotiated and executed. Is it possible to abort due to insufficient KE parameters at this point? [HJ] as described in my previous email, in typical deployments, both peers either belong to or controlled by same organization, so at least one peer will be able to know remote peer’s capabilities without relying on IKE negotiation, and could have corresponding configuration to disable weak KEs toward that peer; another approach is like you mentioned, there is IPsec implementation could abort negotiation base on local policy config once learned peer’s IKEv2 ID
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
