 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
| From: | Yoav Nir <ynir at checkpoint.com> |
| To: | Yaron Sheffer <yaronf at checkpoint.com>, IPsecme WG <ipsec at ietf.org> |
| Date: | 01/29/2009 02:12 AM |
| Subject: | Re: [IPsec] Bis issue #19: Motivation for including SPIs in the cookie |
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
Email secured by Check Point
_______________________________________________
IPsec mailing list
IPsec at ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec at ietf.org https://www.ietf.org/mailman/listinfo/ipsec