Hi Michael, > Christopher Patton <[email protected]> wrote: > >> Christopher Patton <[email protected]> wrote: > So consider what > >> happens if both peers support the extension and the > attacker > >> rewrites the initiator IKE_INIT_SA to drop the > notification. The > >> responder will notify anyway (2.), which will prompt > the initiator > >> to sign the entire IKE_INIT_SA exchange (3.) The > responder however > >> expects the initiator to sign a different string, > since it did not > >> see a notification from the client. This will cause > the IKE_AUTH > >> exchange to fail, which is how we detect the attack. > >> > >> What prevents the on-path active attacker from removing the > >> responders' Notify? > > > If the attacker also removes the responder's notification, then they > > will fallback to IKE v2's existing authentication logic. However, this > > logic is sufficient to detect the attack in this case. Namely, the > > responder will sign a different message (the unmodified responder > > IKE_INIT_SA) than the initiator expects (the attacker-modified > > IKE_INIT_SA) and the attack will be detected. > > Right, and then they negotiate a quantum-unsafe algorithm (or group 1...).
No, the authentication will fail in this case regardless of negotiated KE method (even if an attacker forced peers to use a weak one). To be able to force peers to not use this extension, the attacker has to remove the new notification from both the IKE_SA_INIT request and the IKE_SA_INIT response. If the attacker does this, then both peers will use the current IKEv2 authentication logic - the initiator will sign only the IKE_SA_INIT request and the responder will sign only the IKE_SA_INIT response. Note, that each peer will sign unmodified IKE_SA_INIT message (with the new notify), but will verify the modified one (w/o the new notify). For negotiation to succeed the initiator must be able to forge _both_ signatures, otherwise the modification of IKE_SA_INIT messages will be detected either by initiator or by the responder. And if it can forge both signatures (e.g., _both_ peers use weak _authentication_ algorithm or _both_ authentication keys are compromised) then no defense is possible. But if at least one authentication key is not compromised (no matter which - initiator's or responder's) and the authentication scheme used with this key cannot be broken by the attacker in real time (e.g., PQ signature) then any attempt to force peers not to use this extension when they support it will cause IKE_AUTH to fail with AUTHENTICATION_FAILED. > And the on-path attacker can now do the impersonation attack, signing the new > sequence of messages. No, unless it can forge _both_ signatures. Regards, Valery. > We might be better off to just make a (series) of new authentication > algorithms. > It's a bit more tedious, because we have to do a new one for every algorithm > we care about, but it might be easier for administrators to configure, and > perhaps diagnose. > > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
