Subject: [IPsec] Ticket #195 - Protection against SPI enumeration

From: Yoav Nir <[email-masked]>
Date: Wed, 20 Oct 2010 16:37:42 +0200

Yaron: 10.3: of course, it is possible that *both* implementations generate predictable/short SPI values

Hi all. 

I think this one was solved together with ticket #191 ("The danger of predictable SPIs"), but requiring that the token maker randomize IKE SPIs.

Unless somebody (like Yaron) objects within the next few days, I will close this issue as well.

And yes, Yaron, I have made the language about the PRNG less "wimpy".

Yoav

---

From: Stephen Kent <[email-masked]>
Date: Wed, 20 Oct 2010 11:01:28 -0400

At 4:37 PM +0200 10/20/10, Yoav Nir wrote:
>I think this one was solved together with ticket #191 ("The danger 
>of predictable SPIs"), but requiring that the token maker randomize 
>IKE SPIs.
>

Why not allow either peer (or both) to add a sizeable nonce as a separate
source of unpredictable data?

Steve

---

From: Yoav Nir <[email-masked]>
Date: Wed, 20 Oct 2010 23:05:25 +0200

> source of unpredictable data?

Where would that nonce be used?

The QCD token is first sent from the token maker to the token taker in the IKE_AUTH exchange. Certainly we could add a nonce there, but what happens to the nonce then?

The other time a QCD token is sent, is after the token maker has lost state. It receives an IKE request, and in reply, it sends back an identical QCD token. With this scheme, it has to be able to generate the token based on the IKE request alone. The only data that doesn't change for all requests from a particular IKE SA are the IKE SPIs (and with no mobility, the IP addresses). So the QCD token can only depend on the IKE SPIs (and maybe the IP addresses).

Still, I can think of two ways to incorporate a nonce:

The first is to have the token maker keep a persistent database of all the IKE SAs and their associated nonces (although in that case, we'd probably call it a "salt"). Then when the request arrives, it retrieves the nonce for this IKE SA and calculates the token. With an unknown IKE SPI, it generates random garbage so as not to let on that this is not a real IKE SA. But that would require a lot of persistent storage, and we might as well store the real IKE SA if we have access to that.

The other way is to modify the protocol to something like this:
 - the (rebooted) token maker receives an unknown request
 - It sends just a N(UNKNOWN_IKE_SPI)
 - The token taker sends an unprotected QCD_TOKEN_REQUEST with the nonce and the SPIs
 - The token maker sends back the real QCD token, only if the IKE SPI is really unknown.

This could work, but it adds a round trip, and requires that the nonce be sent in the clear. I don't think it's worth it.

Yoav