[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing



Kanta Matsuura wrote:

> A quite similar idea was proposed in
>

Yes I agree.
I must say that your draft made me think of the problem and possible solutions to
it.
My proposal has some advantages at least from an engineering point of view:
1. It adds only 2 payloads.
2. It is orthogonal to the authentication method you choose to employ and the key
derivation mechanism.
3. It's simpler.
4. As you already mentioned - one can control the amount of computations performed
by the initiator.

Regards,
Tamir.

> 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

--
=========================================================================
This message may contain confidential and/or proprietary information, and is
intended only for the person / entity to whom it was originally addressed.
The content of this message may contain private views and opinions which do
not constitute a formal disclosure or commitment unless specifically stated.
References: