[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cookie verification
Kanta,
> 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.
Indeed it is: the first message does not require a responder
to store state. An approach similar to this one (with
regards to re-sending the data in the first message later)
could work for other IKE modes as well, without making the
exchanges longer. I wonder if this could be done easily
using a "standard transform" to a given stateful mode?
As an aside, how do you prevent an attacker from doing a
"cookie jar" attack? A malicious initiator can initiate
new exchanges by sending the first message and receiving
the second message of each exchange, and then calculate
the appropriate third messages corresponding to each new
exchange -- without sending them immediately. After
collecting eg 1000 valid responses, he can send them all
at once to swamp the responder.
Admittedly, the attacker will have to do a roughly equal
amount of work, but over a longer period of time (and thus
he will not be swamped). The responder can not know how
old each of the messages are, so he will accept them.
(The local secret for cookie generation can, of course,
be changed once in a while, but that interval may be
long enough to pull the attack off?)
If the responder cookie in the draft included time, the
responder could roughly estimate the age of the cookie
(and thus the exchange) upon receiving the third message,
and refuse to participate if the cookie is older than eg
15 seconds.
As I said earlier, our cookie generation method allows us
to determine the age of the cookie with quite a good
resolution. If applied to this draft, upon receiving the
third message the responder would verify the cookie and
determine its age (eg resolution of a second). It would
then ignore the message if it was older than what we're
willing to accept.
If you'd be interested I could document the cookie generation
method we're using -- perhaps this would be useful for your
draft?
Sami
--
Sami Vaarala (sami.vaarala@netseal.com)
NetSeal Technologies
http://www.netseal.com/
Follow-Ups:
References: