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

Re: IKE-SIGMA: draft-krawczyk-ipsec-ike-sigma-00.txt

Dear Brian,

Thanks for the comments.

First of all keep in mind that the cookies technique just covers
a type of easy-to-mount DoS attack, but certainly not all possibilities.
This is why it is SO IMPORTANT to use an adaptive method.
You do not want to almost duplicate ALL traffic produced by the protocol
(i.e from 3 messages to 5) at ALL times, just to provide a defense in 
relatively few cases against this limited type of DoS attack.

As for your specific issues:

I may be missing something but regarding the first point you make,
the draft is clear about the fact that no protection is provided
or intended in the case that the attacker can intercept both 
messages 1 and 2. Certainly, this is not prevented even if you 
include SA and KE under the RC calculation.

As for the second point: I did consider adding SA, KE for situations like
this, however I rejected the idea. In the case that RC is computed
with SHA-1 or MD5 adding these values would TRIPLE the time to compute
RC (with a 1024-bit prime). If you use a 128-bit block cipher for the 
computation (say AES) then adding these fields 10-PLICATE the cost 
of generation and verification!  This certainly is NOT worth the 
little defense that this whole thing achieves. 
After all if the attacker can intercept messages 1 and 2, and be so fast in 
sending message 3 with the (forged) initiator's IP address then the same
attacker can produce the whole attack by sending message 1 with I's address. 
The dammage caused to I by the attack you describe is not so bad and not in
any case not what we are trying to solve. RC is a defense for R not for I.

If I misunderstood your suggestion, please explain again.
This part of my SIGMA draft describing RC is certainly a "detail" of my 
whole proposal and can be changed if improvements are found. 
(Actually, I'd like to hear of possible improvements since I also describe
this RC mechanism in the context of the PIC protocol of IPSRA
draft-ietf-ipsra-pic-04.txt, which may soon become a standard track RFC.)

Thanks,

Hugo


On Wed, 21 Nov 2001, Brian Hunter wrote:

> I am only commenting on the content of the proposal and not on whether
> or not this proposal should be accepted into the WG.  I am not sure if
> these comments should be left until after the draft is accepted or not.
> 
> After reading the draft, I would like to propose a modification to the
> suggested scheme for creating RCs in 2.3.  It is noted that this is not
> a mandatory scheme since RCs are only used by the responder, but by
> suggesting it in the draft, it is likely that it will be used by at
> least some implementations.
> 
> The purpose of the RC is to prevent DoS and is only used when the
> Responder believes it is under attack.  The fourth note in section 2.3
> states that the RC also protects against attackers who intercept the
> second message of the exchange.
> -Note 4
>   "The inclusion of Ni under the computation of RC achieves, at 
>   no extra cost, a strengthening of the DoS protection mechanism 
>   provided by RC: an attacker that intercepts the second message 
>   from R to I (which includes the RC cookie and the Initiator's
>   IP address), but did not generate or intercept the first message 
>   from I to R, cannot use the intercepted cookie RC for sending a 
>   seemingly-valid message 3 since this attacker lacks the unique 
>   value Ni that needs to be included in this third message."
> 
> However, this provides no protection against an attacker who can listen
> to messages 1 and 2 of the exchange and then send a seemingly-valid
> message 3.  The sixth note tries to prevent a replay-attack but I
> believe the use of this window and tracking mechanism opens up a new
> potential DoS attack.
> -Note 6
>   "The parameter T included in the cookie computation is intended to 
>   prevent the attacker from replaying old values of message 3.
>   However, for the period of time that a certain value of T is 
>   acceptable at R an attacker could replay the message 3 with this
>   value of T. The simplest solution to this is to implement T as a 
>   counter and keep track of the values in the current window that 
>   have been already received. In this way, no replay at all is 
>   possible."
> 
> Now if the attacker can read message 2 (and message 1) and send a
> seemingly-valid message 3 before the Initiator can, he has denied the
> Initiator from using this negotiation since the Responder will silently
> reject all further message 3s.  The problem lies in the fact that the
> attacker is capable of changing the proposed SA and KE in the third
> message without the Responder being able to tell the difference.  Thus,
> the Responder believes message 3 is from the Initiator and will send
> message 4 to the Initiator but the SA and KE may not be acceptable to
> the Initiator and it must re-start the whole negotiation.
> 
> Thus, if an attacker can make a Responder believe it is under attack and
> starts to use RCs, then the attacker can actually cause DoS because of
> the RCs and extra messages.
> 
> This can be avoided by adding SA and KE (and OIDii if present) from
> message 1 to the hashed values to obtain v.  Thus v would now look like
> this:
>   v = prf(K, T | IPi | Ni | SA | KE [| OIDii])
> 
> Now when the Responder verifies v sent back from the Initiator in
> message 3, it can verify that SA and KE in message 3 are the same as
> those in message 1.  In this manner, a quicker attacker can only insert
> a valid message 3, which would actually decrease the round trip time and
> speed up the negotiation.
> 
> Note that this modification does not increase the size of v since it can
> still be truncated as per the fifth note in 2.3.  Nor does it create any
> state on the Responder.
> 
> The drawback to this method is that depending on the length of SA and
> KE, an extra hash round(s) may be required to perform the prf.
> 
> Is this a viable solution to this attack?
> 
> Brian
>
Follow-Ups: References: