Subject: [IPsec] Issue #19: Motivation for including SPIs in the cookie

From: Yoav Nir <[email-masked]>
Date: Mon, 22 Sep 2008 18:16:00 +0300

Tero said:
>
>>    where <secret> is a randomly generated secret known only to the
>>    responder and periodically changed and | indicates concatenation.
>>    <VersionIDofSecret> should be changed whenever <secret> is
>>    regenerated.  The cookie can be recomputed when the IKE_SA_INIT
>>    arrives the second time and compared to the cookie in the received
>>    message.  If it matches, the responder knows that the cookie was
>>    generated since the last change to <secret> and that IPi must be  
>> the
>>    same as the source address it saw the first time.  Incorporating  
>> SPIi
>>    into the calculation ensures that if multiple IKE_SAs are being  
>> set
>>    up in parallel they will all get different cookies (assuming the
>>    initiator chooses unique SPIi's).  Incorporating Ni into the hash
>
> The real reason to hash the SPIs to the cookie is to make sure that
> attacker cannot fetch one one cookie from the other end, and then
> initiate 100 IKE_SA_INIT exchanges all with different initiator SPIs
> (and perhaps port numbers) so that the for the responder it looked
> like there is lots of machines behind one NAT box who are all trying
> to connect. As the cookie is tied to the SPIi the attacker cannot use
> cookie multiple times.

In my personal opinion, I think Tero is right, and the text should be  
updated according to this suggestion.
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec