Hi Chris, It is a valid concern and thank you for bringing it up.
I think this scenario fails in the downgrades described in the paper you cited and is also discussed in sections 4.3.1 and 4.3.2 of https://ethz.ch/content/dam/ethz/special-interest/infk/inst-infsec/appliedcrypto/education/theses/semester-project_eduarda-assuncao.pdf . In a way, the IKE_INTERMEDIATE key exchange does not introduce a new issue here which was discussed in https://www.mnm-team.org/pub/Publikationen/gggh21b/PDF-Version/gggh21b.pdf as well. FWIW, such downgrades exist in TLS 1.2, but not 1.3 that includes data from both sides in the transcript. I remember that when the WG started the design discussions that brought RFC9370, it decided that IKEv2 needs to remain secure against passive attackers, but the goal did not include active scenarios. I consider this downgrade to fall in that category. 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. 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. 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. From: Christopher Patton <cpatton=40cloudflare....@dmarc.ietf.org> Sent: Tuesday, May 20, 2025 11:07 AM To: Valery Smyslov <smyslov.i...@gmail.com> Cc: ipsec@ietf.org 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. Hi Valery, thanks for the quick reply! I assume that SK_I and SK_E are long-term shared secrets used for authentication? Just to clarify, because in RFC 7296 those secrets are called PSKs, while SK_* are session keys. Correct, I mean PSK. This looks like combination of downgrade and UKS (unknown key share) attacks. I believe it is feasible. However, there are some additional prerequisites for it to happen: 1. Both initiator and responder are configured to allow ECDH-only key exchange (using ML-KEM is optional for both). In other words, they _both_ don’t care whether ML-KEM is used or not. In case of initiator this is explicitly indicated in the IKE_SA_INIT message (an AKE* transform in SA payload includes NONE as a valid choice). Thus, they intentionally allows to put themselves under attack if ECDH is breakable. 2. The responder accepts initiator’s identity ID_E and does have an associated key SK_E to verify it. In other words, E is a legitimate user whose long-term key is compromised. Note, that in this case the attacker can just impersonate it, even if ECDH is not breakable and/or ML-KEM is used. The possible mitigation is to use less restrictive policy for either initiator or responder or both. Since the victim of this attack is initiator, it is reasonable for she/he to require use ML-KEM in this case. It seems to me that both of these prerequisites are realistic: 1. When deploying a new protocol feature like this, in my experience there is usually a period of time where graceful fallback is an operational requirement. In particular, an ECDH+ML-KEM initiator may still need to talk to ECDH-only responders or vice versa. 2. If a responder having multiple users is a realistic deployment scenario, then I think one user impersonating another to the responder would be a realistic threat? I agree that mandatory-ML-KEM would probably work, but I'm worried it might not be realistic, given 1., until the ecosystem has transitioned to ECDH+ML-KEM. We have some time, since the attack is not actually exploitable until "Q-day" (i.e., if/when a large enough quantum computer is built that can break ECDH). But we can't wait forever. it would be useful if there were other levers we could pull. Any ideas? Do you think the working group would be open to a breaking change for the draft that mitigates this attack? In any case, I think it ought to be spelled out in security considerations. Chris P.
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
