[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing
A quite similar idea was proposed in
K. Matsuura and H. Imai. ``Protection of Authenticated Key-Agreement Protocol
against a Denial-of-Service Attack''. Proceedings of 1998
International Symposium on Information Theory and Its Applications
(ISITA'98), pp. 466-470, Oct. 1998.
and
K. Matsuura and H. Imai. ``Protection of Authenticated Key-Agreement Protocol
against a Denial-of-Service Attack''. Cientifica, Vol.2,
No.11, pp.15-19, 1999.
as ``falling-together strategy.''
This is used in
http://www.ietf.org/internet-drafts/draft-matsuura-sign-mode-01.txt
and
discourages DoS attackers from exhausting CPU resource of the target;
CPU-exhaustion DoS attack imposes expensive computation
on the attackers themselves.
The main differences between your proposal and mine are:
(1) Yours can control the cost on the attacker while mine cannot.
(2) Mine does not require any additional "quiz" but makes use of
a random material which appears in signature-verification procedure
(which is anyway required if authenticated by signature).
Related articles can be obtained at
http://imailab-www.iis.u-tokyo.ac.jp/Members/kanta-bib-e.html
Regards,
Tamir Zegman <zegman@checkpoint.com> wrote:
>>While Main Mode and Base Mode provide some protection against DoS attacks
>>through the cookies mechanism, no protection is provided whenever the
attacker
>>is on the path between the responder and the spoofed initiator.
>>In such a case the responder is still susceptible to cookie crumb attacks or
to
>>modular exponentiations attacks.
>>
>>Let me propose a method to ward off modular exponentiations attacks.
>>The method is as follows:
>>If a responder detects that it being attacked (let say by the fact that it
has
>>more than X simultaneous Phase 1 negotiations, where X is configurable) it
will
>>do the following:
>>1. Generate a 128 bit random number A.
>>2. Compute MD5(A).
>>3. Send a special ISAKMP payload to the initiator that contains -
>> I. MD5(A).
>> II. The first B bits of A, where B is configurable.
>>
>>Upon receipt of this payload, the initiator will be asked to compute A
(using
>>brute force methods) and send it back to the responder.
>>This computation is possible with the aid of the first B bits of A.
>>The responder will then proceed to do the modular exponentiations
computations
>>only if it got A from the initiator.
>>
>>Using these methods (and assuming that there is no efficient method to
invert
>>the MD5 function given MD5(A) and the first B bits of A) DoS attacks become
very
>>difficult.
>>
>>Notes:
>>1. Any other cryptographic hash function can be used.
>>2. If B is too small the initiator can refuse to carry out the exchange (so
as
>>not to spend to much resources).
>>3. This theoretically opens up another attack in which the attacker attacks
the
>>initiator (and not the responder) by sending him this payload. This in my
mind
>>is not such a serious problem, since in scenarios that allow this kind of
>>attack, the DoS attacker instead of mounting this attack can simply pretend
to
>>be the responder making the initiator to do the modular exponentiations.
>>
>>Regards,
>>Tamir.
>>
>>
--^^--
Kanta
Follow-Ups:
References: