Hi Tero,
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.
They also assume that everything before the cookie is fixed, i.e. that
the IKEv2 HDR is also fixed. IKEv2 HDR contains the SPIi and SPIr. The
SPIr in the first message is all zeros, but the SPIi is selected by
the initiator to be random. If the SPIi from the initiator is
unpredictable, i.e. not fixed constant, then this changes the attack
from offline 2^77 hash collision attack against SHA1 to online 2^77
hash collision attack, i.e. the attacker needs to fix SHA1 hash
collision during the negotiation, without any precalculations.
Ah, that's right.
I have already sent an email to the authors of the paper about this
and I think they agree on that.
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:
There is no point of changing the cookie location, as this attack does
not really work. If attacker are able to do hash collision attacks
during the exchange against the hash we are using then I think the
hash needs to be considered broken. I do not think even NSA can find
SHA-1 hash collision during the few seconds they have time during the
exchange.
That's right, however I have an impression that we are close
to the safety margins here. IKE SPI is relatively short and even
if it is chosen at random it is often generated using non-cryptographically
strong RNG, for example by invocation rand(), so that the
attacker may have a chance to predict it. This makes me
think that with a progress in hash analysys the attack may
become practical. Moving COOKIE to the end of the message would make
the attack much more difficult, probably infeasible. And note,
that this change wouldn't violate RFC 7296, since it explicitely
allows payloads to appear in the message in any order.
However, I understand that it may break some existing implementations,
and taking into considerations that the attack seems to be
impractical currently, I tend to agree with Tero that
we may do nothing right now. Probably postpone it to
some future protocol update.
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
