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

Re: suggestion for JFK




In message <20011212164027.0558C54C42@tailor.sailpix.com>, Dan Harkins writes:
>
>the token. Only if the two match do you try to decrypt the following
>encrypted data. This check has to be done regardless, right?

Correct.

>If the addresss is included and token is corrrect but the encrypted data
>is garbage you will know who sent you the garbage. If you don't include
>the IP address all you know is you got garbage.

For clarification:

The attack scenario you described in the first email was that a valid
HMAC would be used from a large number of other IP addresses; if the
IP address is included in the HMAC cookie, and since the address does
not appear inside the protocol explicitly (as the nonces and
exponentials do), the Responder would only be able to tell that the
HMAC was not given to that IP address. You still don't know who you
gave it to originally (unless state is kept). Logging the false IP is
not very useful, especially if you're under a DDoS (you then introduce
another DDoS, on your logging facility).

If you include the IP address as a protocol payload, then you can tell
who you gave the cookie to (you could encode the address as part of
the cookie, to avoid extra payloads).

Otherwise, hashing the IP address along with the rest only helps you
to detect entities that use their own IP address to send you malformed
message 3's (with valid HMACs).

In any case, I think we're beating a dead horse here.

>> As for the NAT case, s/NAT/mobility or SCTP or multi-homed hosts or...
>
>JFK will be creating an outbound IPsec SA to that IP address anyway.
>Why does binding that IP address to the exchange that created the key
>break things?

This is equivalent to some implementations' fallacious source-IP
address checking for incoming ESP packets -- it unnecessarily binds
the SA (in this case, the exchange) to one particular IP address which
breaks mobility (and perhaps other things too). All you really care
about is whether the peer knows the shared key (in JFK, all you really
care about is whether they know the cookie).

As for the IPsec SAs, they may well be bound to different/more IP
addresses (again, think SCTP).
-Angelos


References: