[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cookie verification
Hi,
The use of IKE Cookie in a draft
http://www.ietf.org/internet-drafts/draft-matsuura-sign-mode-01.txt
is better in terms of statelessness.
Bronislav Kavsan <bkavsan@ire-ma.com> wrote:
>>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/
>>
>>
>>
--^^--
Kanta
Follow-Ups:
References: