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
