On Fri, 15 Jan 2016, Tero Kivinen wrote:
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.
We use random for the SPIi but use this latter described method for SPIr. This ensures an attacker cannot empty your entropy pool, or see the raw bytes of your entropy pool when you happened to use a bad PRNG like DUAL_EC or something. We use the same methods for IKEv1 and IKEv2.
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.
I did not know curve25519 also has that problem :/
I would recommend that we make sure our SPIs are unpredicatable and random instead of only being unique
See my above concern about an attacker depleting the entropy pool.
, 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).
We should, as NIST already requires it anyway. I am curious though why people re-use DH values. Is that really still needed on busy servers? This has never been in freeswan, openswan or libreswan and we have never heard people complain (and yes we do have big deployment servers too, but not on shitty 1995 hardware :) Paul _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
