On Fri, 15 Jan 2016, Yoav Nir wrote:
They use the cookie mechanism to inject a prefix (Because the Initiator dutifully repeats the cookie that the MITM gave them) to control the hash of the entire packet to create a collision. They also rely on neither Initiator nor responder checking cookie lengths or even validating the cookies if a DoS attack is not underway. Maybe we should specify that in the anti-ddos draft.
So we added that patch to libreswan. It will now always verify the cookie even when it isnt sending out ddos cookies itself. We might tweak it a little bit with a timer to limit the damage attackers can do by sending many spoofed IKE_INIT packets with COOKIES that we'd be burning our hasher on.
AFAIK a second pre-image attack on SHA-1 where the second pre-image looks like a valid X509 certificate is still far. Even if it were not, what is the attack? the real Initiator fetches the wrong certificate and the authentication fails? This happens even if you don’t match the SHA-1.
Similarly for their proposed IKEv1 attack using the ID payload. Paul _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
