[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cookie verification
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/
References: