[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Cookie Requirements
Chris Trobridge writes:
> RFC2408 Para 2.5.3 states that cookie generation must ensure that cookies
> depend on specific parties, that only cookies should not be acceptable by
> other than the issuer. It then goes on to outline a method based on hashing
> IP addresses, UDP ports, a local secret and time/day to produce the cookie.
>
> I don't see what advantage this has over choosing a suitably strong random
> value.
The cookie generation method in ISAKMP consumes random bits more slowly.
This frugality is useful in environments where high-entropy random bits
are hard to produce, quickly or at all.
[...]
> I'm not sure about the second argument either. I can see that it must not
> be possible for an attacker to be able to guess the cookie generated in
> response to a spoofed negotiation request (as with TCP). I'm not sure why
> this requires a local secret for verification. The only reason I can think
> of is if cookies aren't stored locally (initially?) and hence there would
> have to be some means of verifying them. Even then I'm not sure how it
> would help as you'd still need to know the time/date when the cookie was
> created.
Caching the generation time and a pointer to (the correct version of) the
local secret could still save space vs. caching the entire cookie.
-Lewis http://www.cs.umass.edu/~lmccarth
--
"we have to yet really seriously debate the constitutional issues and
whether or not we're willing to give up more freedom in order to have
more security" -- U.S. Secretary of Defense William Cohen, 3 Feb 1999
References: