[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cookie verification


  My interpretation of the IKE RFC agrees with Sami's analysis.
  In IKE, the responder needs to store state from the very first message
  received from the initiator -- at the very least, SAi_b. 
  Storing the responder's cookie along with this state isn't
  that much additional overhead (in proportion to the overhead of
  storing other required info). Having done so, a responder
  can verify cookies received in subsequent messages by a 
  direct comparison to the saved value. So even though the 
  cookie text in RFC 2409 matches what's in the Photuris draft,
  IKE really doesn't use cookies for anti-clogging. 
  
  I have written a prototype IKE implemantation in Java and
  even though I have a verifyCookie() method, I never need to
  call it for the reason stated above. 
  
  vipul
  
> Bronislav,
> 
> > Sami - excellent overview! That's exactly what I was looking for,
> > thank you very much!
> > In summary - because in the current IKE the cookies are not fully "baked"
> yet :)
> > - any random or pseudo-random values will  work just fine - and with some
> future
> > standardization in this area - the value of intelligent cookies in IKE can
> be
> > enhanced.
> 
> I must add a disclaimer to my post -- it was intended to convey my
> personal interpretation of the specifications.  It would be nice if
> someone with more authority on the subject would give a clean
> description of cookies and whether my analysis is correct :)
> 
> It would be interesting to know if there is anything real to be
> gained by using more "intelligent" cookies, like the ones I described
> in the post (they are actually used by our implementation).
> 
> > Until this is the case - all RFC2408 MUSTs about cookie generation should
> be
> > interpreted as MAY, right?
> 
> In my interpretation, yes.  The cookie requirements in ISAKMP were
> lifted almost word-for-word from Photuris, which uses the cookies
> usefully to prevent state creation in denial-of-service attacks.
> I must stress that as far as I understand, ISAKMP *could* use a
> similar mechanism (indeed, there is a note of a "header exchange"
> which is not elaborated further), although IKE does not (currently)
> take advantage of it.
> 
> As far as I see it, the only real requirement for IKE is that the
> cookies must be unpredictable to an outsider;  the method of creating
> them by hashing "stuff" (including IP addresses) fulfills that goal.
> 
> Sami
> 
> --
> Sami Vaarala (sami.vaarala@netseal.com)
> NetSeal Technologies
> http://www.netseal.com/
> 
>