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...).
And the on-path attacker can now do the impersonation attack, signing the new
sequence of messages.
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
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
