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

Re: cookie verification

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.

Until this is the case - all RFC2408 MUSTs about cookie generation should be
interpreted as MAY, right?

Sami Vaarala wrote:

> Bronislav Kavsan wrote:
> > RFC 2408 in Section 2.5.3 contains few MUSTs as well as recommendations
> > for cookie generation. I am not clear on the "verification of cookie"
> > part, which is the whole reason for not simply selecting a random number
> > for cookies value.
> >
> > Could someone explain the "standard" technique of generation and
> > especially subsequent verification of cookies? Does anyone uses this
> > technique and verifies other vendor cookies?
>
> Yes, RFC 2408 is extremely vague about the purpose, creation, and
> verification
> of cookies.  (It is also vague about a lot of other things, but let's not
> get
> into that now ;-).
>
> For exchanges without an initial stateless phase (ie all the IKE exchanges),
> the cookie creation method makes no difference, as long as the cookie
> generation
> mechanism is *unpredictable* to an outsider (to serve the weak source IP
> authentication function).  Cookie verification then equals comparison to a
> cookie
> value stored in some sort of exchange state.
>
> Creating cookies using a hash with public and private data (as suggested by
> RFC 2408)
> is good since you do not have to waste random numbers for each cookie
> (indeed,
> random numbers are a scarce resource :). Otherwise, use your favorite
> pseudo-random
> number generator.
>
> However, cookies CAN be made more intelligent, see the Photuris RFC (RFC
> 2522)
> for an example of how cookies can be used for a stateless beginning in an
> exchange.  A responder will not have to store any state until the source IP
> of the initiator has been weakly authenticated.
>
> ISAKMP *could* take use of such stateless exchanges; none of the IKE
> exchanges is "stateless", though, and the stateless nature of cookies is
> academic for IKE.
> (In IKE you need to store data from the first initiator message in order to
> participate in the exchange later).
>
> It is possible to write a cookie generation function that allows us to:
>   (1) verify that a cookie was created by us
>   (2) determine the approximate age of the cookie (eg with a 1 second
> resolution
>       up to 15 minutes)
>   (3) determine the role for which the cookie was created (initiator vs.
> responder,
>       main mode vs. aggressive mode, source and dest IP address/ports, etc)
> without storing any cookie-per-cookie state, and by using one hash and one
> DES
> operation per cookie verification and creation.
>
> This extra information can be used to eg defend against replay/reflection
> attacks
> in a exchange-neutral manner (ie the message is dropped even before IKE
> exchange
> code is invoked).  Having said that, it does not PREVENT such attacks
> indefinitely.
> It only serves as extra protection for some period of time after completion
> of an
> exchange (and can trivially block interleaved reflections).
>
> It would be good to include a better discussion of the cookie security
> function
> in a future ISAKMP specification.  I would also like to see pseudo-code for
> a
> basic implementation, and an example of a stateless application.
>
> Sami
>
> --
> Sami Vaarala (sami.vaarala@netseal.com)
> NetSeal Technologies
> http://www.netseal.com/
Follow-Ups: References: