[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: