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

From: Yaron Sheffer <[email-masked]>
Date: Wed, 28 Jan 2009 00:49:48 +0200

Current text (sec. 2.6):

A good way to do this is to set the responder cookie to be:

Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)

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).

Tero:

The real reason to hash the SPIs to the cookie is to make sure that attacker cannot fetch 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.

Paul: Not done. This is interesting, but should be discussed on the list.

Email secured by Check Point

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Thu, 29 Jan 2009 09:09:53 +0200

Current text (sec. 2.6):

Tero:

I agree with Tero

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 29 Jan 2009 09:37:29 +0200

First, I would remove "responder knows that the cookie was generated since the last change to <secret>" since the responder can rollover the secret periodically, as explained in the following paragraph. Which version of <secret> is used simply doesn't matter.

Also, we talking of the initiator's SPI, not "the SPIs". And in principle, all 100 initiators behind the NAT can use the same SPIi. So an attacker can very well use the same SPIi repeatedly.

Thanks,
            Yaron

________________________________
From: Yoav Nir
Sent: Thursday, January 29, 2009 9:10
To: Yaron Sheffer; IPsecme WG
Subject: RE: Bis issue #19: Motivation for including SPIs in the cookie

Current text (sec. 2.6):

Tero:

I agree with Tero

---

From: Scott C Moonen <[email-masked]>
Date: Thu, 29 Jan 2009 08:00:01 -0500

> > The real reason to hash the SPIs to the cookie is to make sure that 
attacker cannot fetch one cookie from the other end . .
> I agree with Tero

Me too.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen

From:
Yoav Nir <[email-masked]>
To:
Yaron Sheffer <[email-masked]>, IPsecme WG <[email-masked]>
Date:
01/29/2009 02:12 AM
Subject:
Re: [IPsec] Bis issue #19: Motivation for including SPIs in the cookie

Current text (sec. 2.6):
A good way to do this is to set the responder cookie to be:
Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)
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). 
Tero:
The real reason to hash the SPIs to the cookie is to make sure that 
attacker cannot fetch 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. 
Paul: Not done. This is interesting, but should be discussed on the list. 

I agree with Tero

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 29 Jan 2009 16:47:31 +0200

Yaron Sheffer writes:
> Also, we talking of the initiator's SPI, not "the SPIs". And in
> principle, all 100 initiators behind the NAT can use the same SPIi.
> So an attacker can very well use the same SPIi repeatedly. 

If attacker uses same IP, and same SPIi, then initiator will simply
reject those duplicate messages as retransmissions of the previous
message, no special handing is done. If attacker uses several
different SPIis then unless the cookie contains SPIi then the cookie
will match for all SPIis attacker decides to use, and as the SPIi will
be different server will process all of the messages.

So to get the security right the SPIi needs to be included, but the
reason listed in the original text is not really the real reason. It
is the effect caused by inclusion of the SPIi to the cookie, not the
reason behind it.

> 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). 
> 
> Tero:
> 
> attacker cannot fetch 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. 
-- 
[email-masked]