On Oct 20, 2010, at 5:01 PM, Stephen Kent wrote:
> At 4:37 PM +0200 10/20/10, Yoav Nir wrote:
>> 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
>
> Why not allow either peer (or both) to add a sizeable nonce as a separate
> 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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
