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

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

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: