Hi Yoav,
What does IPsec community think of it? Should we fix the protocol
to thwart this attack completely? Is the recommendation to move the COOKIE to the end of the message enough to
achive that?
Will this change break many existing implementations?
As far as I can tell, the cookie hash algorithm is an implementation decision
of the responder and (despite what's implied in the paper) is never specified
in the protocol. It would be much simpler to add a section to the new 4307bis
saying that this hash is security-critical, and recommending SHA-256 or
stronger.
The SLOTH paper does not depend at all on the hash used to break the cookie.
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.
The initiator cannot validate the cookie - it is an opaque blob for him. Should
he reject
the cookie if its length is more than 64 bytes? Possibly. I don't know.
It's a bit strange to check an opaque object...
What about the responder - he doesn't see any cookie in this attack - the
attacker
sends the crafted cookie only to the initiator and sends a crafted
IKE_SA_INIT message w/o cookie to the responder (as far as I understand the
attack).
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
