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

DoS attack on JFK



  The new JFK draft claims that resistance to CPU exhaustion attacks
against the responder is a design goal. It also refers to Photuris
and its use of cookies to thwart this sort of attack and further 
mentions that "[a]lthough the concept of the cookie was adopted by IKE,
its use in that protocol did not follow the guidelines established by
Photuris and left it open to DoS attacks." While JFK has not adopted
the use of cookies it uses an "authenticator" blob for the same function.
Unfortunately it also has not followed the guidlines established by
Photuris and it is also open to DoS attack.

  The first basic requirement for cookies that Photuris laid down was:

  "1. The cookie MUST depend on the specific parties.  This prevents an
      attacker from obtaining a cookie using a real IP address and UDP
      port, and then using it to swamp the victim with requests from
      randomly chosen IP addresses or ports."

In JFK the authenticator does not include anything specific to the
initiator that would prevent using valid authenticator blobs to swamp
a victim with requests from random IP addresses.

  The attack is a varient on Simpson's "cookie jar attack":

1. An attacker sends N different message ones to a target. Each of
these contains different Ni and g^i values, but the attacker need not
use any energy generating these different values, they can all just be
garbage. 

2. He will get N different message twos back. Each one will contain an
authenticator blob, HMAC{HKr}(Ni, Nr, g^i, g^r), specific to a message
he sent (the messages are correlated by comparing the Ni values).

Provided that g^r on the Nth message two is the same as the g^r on the
first message two the attacker knows that all the authenticator blobs are
all signed by the current HKr. If the first and last g^r differ then the
attacker starts the attack over.

3. Once he has N message twos he constructs N message threes with the
nonces and exponentials tied to the correct authenticator blob with more
garbage in the place of the encrypted identity, sa, and signature. These
are all sent from randomly chosen IP addresses. The responder is forced
to exponentiate to generate Ke to decrypt the garbage.

  My repeatedly sending "Ni, g^i" to the target and noting when g^r changes
an attacker can get a pretty good idea on when to begin the attack and how
high to set N for maximum effect. 

  To limit the amount of resources necessary to launch this attack the
attacker could use a "stateless" form of attack where it maintains a bunch
of garbage bits whose length makes them look like a valid g^i value and
when it generates a garbage Ni it replaces the last len(Ni) bits of the g^i
with Ni. When it sends the message one containing "Ni, g^i" it can promptly
forget Ni and g^i since Ni will be returned by the target in message two.
Upon receipt of message two the attacker can reconstruct the g^i used with
the particular Ni returned by the target to make message three.

  If the authenticator blob included something specific to the initiator,
like his IP address, it would prevent this attack. Either the bogus message
threes would be thrown away prior to exponentiation because the authenticator
check failed (IP address was wrong) or if the attacker chose to send all the
bogus message threes from the same IP address (to cause the authenticator
check to be successful) the responder could make note of an unsuccessful
decryption from a particular IP address and refuse any more messages from
it for a period of time. At most it would be one pointless exponentiation
and decryption.

  I suggest that the the authenticator be changed to:

	HMAC{HKr}(IPi, Ni, Nr, g^i, g^r)

where IPi is the source IP address of the received message one.

  Dan.