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

Re: suggestion for JFK

  NAT wouldn't break because the IP address included in the calculation
would be that of the NAT box the initiator is behind. 

  Your case (c) was what I was suggesting-- if decryption fails then do
not process anymore packets with that token. I'm not saying that a
well-written JFK implementation would crash or peg a CPU or whatever,
just that in the event of an attack it would be a benefit to know where
that attack is coming from. True, this would be architecturally impure,
but I'd swap cleanliness for some added information to send to syslog
in the event of an attack.

  Dan.

On Tue, 11 Dec 2001 18:46:04 EST you wrote
> 
> 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) --- regardles
>s
>    of the number of entries. Of course, the more entries in the blacklist, th
>e
>    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: