[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cookie verification
Sami, Thank you for the reply.
"Sami Vaarala" <sami.vaarala@netseal.com> wrote:
>>> 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?
I'm not quite sure what do you mean by "standard transform".
>>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?)
Of course, in terms of connection timeout, there exists a trade-off between
performance (for an innocent entity who couldn't make a quick response
due to some unfortunate conditions) and DoS-resistance.
If we use the signature mode in my draft,
the amount of attacker's work includes heavy signature verification.
This makes the trade-off better.
>>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.
This could be useful for making a specific evaluation
by using performance specification of the currently-available
implementation of public-key primitives;
we could find an appropriate period for timeout.
>>If you'd be interested I could document the cookie generation
>>method we're using -- perhaps this would be useful for your
>>draft?
Yes, I'm interested in it.
Please go ahead!
--^^--
Kanta
References: