Hi Chris,
[snipped]
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?
While I agree that these prerequisites are not unrealistic, I think
that by Q-day (the day we believe the CRQC exists) all hosts must be
already switched to the mode when PQ algorithms are mandatory, with no
exception for “old” systems. And before this day the attack is impossible.
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.
For the particular attack you described no breaking changes to the
protocol are needed to defend. I can propose the following modification.
What the attacker does in this attack – modifies initiator’s
IKE_SA_INIT making it looking like initiator does not propose any PQ KE methods
at all.
Note, that an attacker does not have access to responder’s long-term
authentication key and we can exploit this to detect this modification.
My idea is that responder can hash the received IKE_SA_INIT message
(actually, do a negotiated prf with some fixed or known key, since
hash is not negotiated in IKEv2) and include the result into the
response IKE_SA_INIT using some new status notification.
Responder’s IKE_SA_INIT message is directly included into the data the
responder authenticates, thus the attacker cannot change it unless
responder’s private key is compromised or the attacker can break the
authentication algorithm.
When the initiator receives the IKE_SA_INIT response, it can check
whether the content of this notification matches the IKE_SA_INIT message it
sent.
If not – the attack is detected. Initiator that does not support this
extension will just ignore the unknown notification.
Note that this does not protect against situation when responder’s
long-term key is compromised and initiator’s one is not.
But in this case if the responder selects the hybrid key exchange and
the attacker then modifies its selection as if only ECDH is selected, then the
protocol will stuck –
the responder will expect IKE_INTERMEDIATE as next exchange and won’t
accept IKE_AUTH that the attacker will initiate.
I’m not sure if the attacker can fix this situation (it seems to me
the answer is no, because even if it in between actively modifying
all IKE messages, eventually it will have to authenticate all these
messages on behalf on initiator, which seems
infeasible, since we assume that initiator’s key is not compromised).
And if both peers’ long-term keys are compromised and the attacker can
break ECDH, then no defense is possible.
Your opinion, will this defense work?
Regards,
Valery.
Chris P.
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
