Subject: [IPsec] Issue #191 - The danger of predictable SPIs

From: Tero Kivinen <[email-masked]>
Date: Fri, 1 Oct 2010 12:17:57 +0300

Yoav Nir writes:
> Alternatively it would simplify things immensely if we mandate that
> SPIs be random for implementations that support QCD (possibly only
> on the gateway side). Can we do it without having to "update RFC
> 4306"?

Yes I think we can do that, as this is requirement for only those
hosts who support QCD. I.e. we can add text which says, that if you
support QCD and enable it, then you MUST use random SPI for your IKE
SA.

There is no requirement for us to require random SPI for other hosts,
so this do not break interoperability.

> At least one IKEv2 implementation chooses IKE SPIs in a very
> predictable manner. It starts with 0x0000000000001000 and increments
> by one for each successive IKE SA. Assuming not too many SAs, and
> QCD secrets not being replaced very often, it should be possible to
> create a dictionary of SPI pairs to QCD tokens by simply sending the
> likely pairs to the implementation, and getting the INVALID IKE SPI
> notification along with the QCD token. Throttling and rate limiting
> helps a little, but not if the pool of possible SPI pairs is small.

I would expect such implementation will change their SPI generation
code when they implement QCD. 

> Fortunately, to thwart this enumeration attack, it's enough for
> either the token taker or token maker to do the right thing and use
> random IKE SPIs. I suggest addressing the issue by requiring good
> random IKE SPIs for token makers. Please send comments to the list. 

That makes sense, as the token maker is the one who wants protection
against attackers guessing the tokens, so he wants to use random SPI.
-- 
[email-masked]