Valery Smyslov writes: > 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.
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. I have already sent an email to the authors of the paper about this and I think they agree on that. The problem is that RFC7296 does not require SPIs to be random or unpredictable. RFC7296 just requires them to be unique, so there is nothing wrong in the implementation which would use fixed SPIi of 0x0000 0000 0000 0001 for all IKE SAs (and would only support one IKE SA). Fortunately I have not seen any implementations doing that, I think all implementations I have seen use random IKEv2 SPIi. In the IKEv1 things were different as the SPIi and SPIr were actually cookies, and they were sometimes generated using hashing of the addresses etc and some random secret, and then there might have been some kind of secret generation counter or similar. > 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). 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. Also this attack do require that the user use the groups with small subgroups, like groups 22-24 (and their previous paper the authors of this paper said that curve25519 has one small subgroup with size of 8, see page 9 of [1]) so they can make the g^xy' same as g^x'y by forcing both ends to use same small subgroup and trying so many times that the g^xy' and g^x'y happened to be same. If the size of subgroup is less than then there is good change that will happen with few tries. > 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? I would recommend that we make sure our SPIs are unpredicatable and random instead of only being unique, and that we always do small subgroup checks regardless whether we reuse the private Diffie-Hellman values or not for those groups that have small subgroups (22-24, curve25519). [1] https://alfredo.pironti.eu/research/sites/default/files/ndss15.pdf -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
