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

Re: suggestion for JFK


In message <20011211224904.B94E354C48@tailor.sailpix.com>, dharkins@tibernian.c
om writes:
>address.
>
>  The responder should rate limit these messages, of course, and could
>scan an input queue for the bad token to eliminate these bogus packets
>before any serious work is done on them but there is no way to locate the
>offender.
>
>  If the IP address of the initiator that sent message 1 was included
>in the token calculation-- i.e. HMAC{Hkr}(Ni, Nr, g^i, g^r, addr)-- it
>would force such an attacker to reveal his IP address. I think this would
>be a good thing.

Except that:
a) this would break in the presence of things like NAT boxes
b) it's architecturally "unclean" (there's no other place in the protocol
   where addresses are used)

Now, there are 3 cases with lots-and-lots of message 3's:
a) The HMAC is not valid --- in which case, they'll be dropped immediately
   upon computing the HMAC.

b) They are all valid (both the HMAC and the contents); in that case, the
   Responder will do the work for the first one (after all, it's a valid
   message), and return that for the rest of them.
   Further rate-limiting may be added at your pleasure.

c) If the HMAC is valid, but the rest of the message is not (e.g., the certs
   don't verify, or the encryption is garbage, etc.), then the responder
   "blacklists" the HMAC value (not the IP address); on receiving a new
   message 3, the HMAC is looked-up; if it matches, the message is dropped.
   If it passes the lookup (i.e., it's not found in the black list), the HMAC
   is verified; if it passes *that*, you go on processing the message.

   One can use a Patricia Trie do do this, which has a cost of O(w) --- where
   w is the length of the key in bits (in the case of HMAC, 96) --- regardless
   of the number of entries. Of course, the more entries in the blacklist, the
   more memory expended. However, the blacklist can be wiped out when HKr is
   changed (which the Responder can do whenever he chooses).

One cannot blacklist IP addresses in the same manner, because that will allow
an attacker to deny JFK service to any IP address of his or her choosing (get a
valid HMAC, then send a spoofed packet from victim-IP and voila -- victim-IP is
blacklisted at the Responder).
-Angelos
Follow-Ups: References: