However, thank you for bringing in the SLOTH attack.
As fas as I understand from the paper
http://www.mitls.org/downloads/transcript-collisions.pdf it is based
on the ability for an attacker to find collisions in a weak hashes
(md5 and sha1). In particular the authors uses chosen-prefix collision
attacks
to break some security protocols. They mostly focused on breaking TLS,
but Section VI contains description of a possible attack on IKEv2.
As far as I understnd the attack on IKEv2 it is based on the cookie
request
feature. The attacker makes a cookie request to the initiator
with the cookie crafted in such a way, that the hash of the
IKE_SA_INIT message
containing this cookie would collide with the hash of the IKE_SA_INIT
message
containing attacker-chosen KE payload. It would allow the attacker
to impersonate the initiator.
If I got it right the ability for an attacker to quickly find a hash
collision
is based (besides using weak hashes) on presumption that the cookie is
always the very first payload in the message,
as depicted in the Section 2.6 in the RFC 7296. So it is
presumed that the cookie always preceedes any unpredictable
for the attacker values in the message, that allows to perform
an effective chosen-prefix attack on a hash.
So, I think that we can completely thwart this attack (regardless
on the possible weakness of the used hashes) if we make
a recommendation for implementers to put the cookie at the
end of the message. RFC 7296 doesn't imply any restrictions
on the payloads order. However the Section 2.6 states:
If the IKE_SA_INIT response
includes the COOKIE notification, the initiator MUST then retry the
IKE_SA_INIT request, and include the COOKIE notification containing
the received data as the first payload, and all other payloads
unchanged.
It's a bit unclear for me whether this MUST is concerned with the
requirement to retry request only, in which case it is only
a recommendation to place the COOKIE before other payloads,
or the MUST is also applied to the text that COOKIE is the first
payload (that would be unfortunate).
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?
Regards,
Valery Smyslov.
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 experience with TLS is that making small protocol changes to protect
against weak algorithms is not a good long-term strategy. It's just a
challenge for researchers to come up with better attacks.
I believe the hash-and-URL mechanism is not used in practice. But if it
is, that's another place where we have hardcoded SHA-1, and maybe we
should start worrying about it.
Thanks,
Yaron
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
