I fleshed out the details of this approach a bit in https://github.com/csosto-pk/pq-mlkem-ikev2/issues/5#issuecomment-2896485221
Basically you don’t do IKE_INTERMEDIATE at all, you do all classical and immediately rekey the SA and the Child SA (if already negotiated) with IKE_FOLLOWUP_KE which means that your SKEYSEED and SKEYMAT and all other keys that protect data are quantum-resistant. We do all that because at the time of IKE_FOLLOWUP_KE we have the full identity of the peer and thus can enforce the config that says “I expect Peer X to be upgraded and thus must use ML-KEM”. Note the messages and rekeys etc are already supported in RFC9370, we are not doing anything exotic. We just use the new configuration flag to enforce the “use ML-KEM requirement” by using the right messages. I think this is a simpler approach than introducing a new notification N(MAC more things) which both peers need to support. Feedback from the whole WG is welcome. From: Christopher Patton <[email protected]> Sent: Tuesday, May 20, 2025 2:36 PM To: Kampanakis, Panos <[email protected]> Cc: Valery Smyslov <[email protected]>; [email protected] Subject: RE: [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. Hi Panos, Regardless, it is a valid point. I think it is out of scope to address this in the draft as I consider it a general IKEv2 issue which the WG can tackle in separate work. I agree the problem is not specific to draft-ietf-ipsecme-ikev2-mlkem and that the ideal solution is more general. However, speaking as a potential implementer, I believe the solution ought to be a prerequisite for this draft. The reason is that I think there are extenuating circumstances: The transition to PQ key exchange is well underway in most of the IETF and beyond, and I'm worried that the lack of downgrade resilience will hinder progress for IPSec. In particular, if a draft were created that extended IKEv2 to have stronger downgrade resilience, then I think draft-ietf-ipsecme-ikev2-mlkem ought to depend on it. Such an extension might look like this: The initiator's IKE_INIT_SA message indicates support for an extension wherein, when selected by the responder, each host signs/MAC all key exchange messages, including those sent by its peer. (This seems like it would be necessary for downgrade resilience, though perhaps not sufficient.) We would then make negotiation of ML-KEM in an intermediate exchange contingent on selection of this downgrade resilience extension. Or perhaps we could specify something broader? Of course, unless marked as mandatory by the initiator, this extension is itself vulnerable to downgrade attack. This means there would still be a transition period where most responders don't yet support the extension and thus some initiators would leave it as optional for a period of time. However the time horizon for this transition is the same as for the transition to mandatory-ML-KEM, so I don't think adding it as a dependency costs us any time. The upside is that we provide downgrade resilience for the broader ecosystem. It is a great idea to add a discussion in the Sec Considerations section. I will do that. Please review the text when it is out. I'd be happy to! On the specifics, I agree that saying that the responder can choose to go ML-KEM-as-mandatory won’t always be possible in the migration phase. RFC8784 addressed this downgrade scenario by introducing a “peer PPK_ID-based mandatory_or_not PQ PPK flag” configuration. That way, the initiator or responder know if it is mandatory to use the PPK with the PPK_ID for quantum resistance. draft-ietf-ipsecme-ikev2-mlkem does not negotiate a separate identifier which the peers can use to know if ML-KEM is mandatory. So, I think the most elegant approach is for those worried about such downgrades, to force a new Child SA creation or rekey or IKE SA rekey by using a IKE_FOLLOWUP_KE and make use of a mandatory-ML-KEM-peer configuration. IKE_FOLLOWUP_KE has authenticated peers and thus the responder can enforce a “mandatory to use ML-KEM for that peer” configuration. Wildcard scenarios could be used for such identities to prevent large config. Thoughts on this solution are welcome. IKE_FOLLOWUP_KE is defined in RFC 9370 (Multiple Exchanges), correct? How are the peers authenticated in these messages? The attacker knows all session keys at this point, so I imagine they would need something like another AUTH exchange. Best, Chris P.
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
