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

Re: Future ISAKMP Denial of Service Vulnerablity Needs Addressing

Tamir Zegman 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.

Well, maybe I'm missing something here, but I don't get the point.

You're assuming an active attacker on the path between the initiator and the
responder.
You propose to generate a random number, sending its MD5 and first bits to the
initiator.
The initiator then must use brute force to get back the initial number.

Here are my reamarks :
1. If the initiator can brute-force to get back the number, so does the attacker.
The latter can then still force the responder to do the modular exponentiation --at
additionnal cost but it depends on the number of bits received, to see wich one is
more costly isn't easy.

2. Someone spoofing on the path still can intercept the packet and block the
transmissions. (this is still DoS in my point of view.) He can also transmit the
packet to the real initiator, waiting for his response, avoiding himself to get
into heavy computational task. Still he can re-initiate a spofing negotiation with
the responder.

3. It puts a computational overhead on both the initiator and responder. Both of
them still has to maintain the cookies states. How should we handle that ?

4. What security offers the addition of the MD5 calculation, since anyone still has
to brute-force to  guess the number ? Your construct tacitly assumes that there is
less computational overhead to brute-force the number than to do the modular
exponentiation. Do you have an idea on the size required to get that  property on
MD5 ? What happens if there exist a collision ?

5. IMHO this doesn't prevent the attack by someone on the path between both
entities as you assume.


Again, I admit I may be wrong, but I don't get the added value of your construct in
terms of security.
Best regards.

Alain Jourez
References: