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

Re: Some comments on JFK

"Angelos D. Keromytis" <angelos@cs.columbia.edu> writes:
> In message <200112022238.fB2Mcp505964@romeo.rtfm.com>, Eric Rescorla writes:
> >This seems problematic. Verification of message 3 uses HKr so if you
> >have multiple message 2s outstanding each with different g^rs (and
> >hence different HKrs according to the first quote) then you must
> >maintain a table of old HKrs, one per message.  Is this really your
> >intention?
> 
> If you have different g^r's, you need to keep the corresponding r's anyway, so
> you can keep HKr as well. If you're re-using the same (r, g^r) pair, you only
> need to keep those around (and only one HKr).
Right, but what's the virtue of changing HKr so frequently? 

> >Note that the initiator does not have to perform expensive computations
> >in order to force the responder to perform expensive computations.
> >It's trivial to generate a plausible-appearing g^i without doing
> >any actual modular exponentiation. This forces the responder to
> >compute g^ir. The initiator does of course have to prove that he
> >can perform a round-trip.
> 
> Right, but valid initiators do have to spend cycles before the responder
> does.
Yes, but purpose of forcing the initiator to spend cycles before the
responder is for DoS prevention, not rate throttling of legitimate
initiators, no?

> >    The key used to protect
> >    Messages (3) and (4), Ke, is computed as HMAC{g^ir}{Ni, Nr, 1}. The
> >    session key used by IPsec (or any other application), Kir, is
> >    HMAC{g^ir}(Ni, Nr, 0).
> >
> >This isn't guaranteed to create a long enough key. In particular, you
> >don't say whether you're using 2 or 3 key 3DES but if you're using 3
> >key then you're already short at least 8 bits :)
> 
> Good point -- the reason for selecting this scheme is that it was shown to be
> secure (ask Omer Reingold for more details -- co-author of the draft). 
I understand that Uri has a provably secure PRF scheme that will
generate an essentially unlimited amount of keying material from
your shared key: draft-blumenthal-keygen-02.txt. This would eem
to be a superior choice.
      
> >Additionally, it seems
> >like bad practice to use the same key for messages (3) and (4). I'd
> >much rather see different keys.
> 
> Actually, there is no security problem by reusing the same key in the
> two messages (the encryption is used only for privacy purposes -- the
> security of the exchange is based on the signatures).
This makes some unstated assumptions about the encryption algorithm.
For instance, using RC4 or DES-ECB could lead to revelation
of plaintext. A design that used separate keys would not have this
problem. If you're going to have substitutable algorithms it's
better to design for the worst case.

> CBC seems the most likely candidate, although we wouldn't want to preclude
> some of the newer modes of operation. If there is an IV, it is random and
> included in the message.
Ok. This will obviously need to be specified.

> >(5) The wire format is, uh... unusual. Is there some reason
> >     you've chosen not to go with some fixed packet format specified
> >     either by byte-diagrams or some description language. This is
> >     not going to be the easiest message format to write a codec
> >     for.
> 
> I thought it was one of the simplest formats imaginable...
Simple, but annoying.

> >     It's possible to optimize away the extra signature by adding a little
> >     complexity to the protocol. If we change g^r with every interaction
> >     we can dispense with the final signature in message 4, provided that
> >     message 2 contains a signature over Ni and Nr as well as g^r.
> 
> Always changing g^r requires state to be kept for each Message 1 received,
> thereby re-introducing the problem with IKE. That would be a clear violation
> of our design goals.
I don't think what I wrote here was clear. I'm suggesting that the responder
operate in two modes:

(1) Ordinary PFS mode where a new g^r is created for each interaction
and state is created after msg 1. 
(2) "Safe" mode (presumably where the responder believes itself to be
under attack) and g^r is reused.

This is already possible with JFK but at a performance cost--PFS mode
is faster than safe mode. The modifications to the protocol that I
suggested make PFS mode as fast as safe mode.

> >     [Actually, it's arguable that we could dispense with the signature 
> >     in message 4 entirely and replace it with a MAC but that would
> >     allow an attacker who compromised a single g^r to impersonate the
> >     server indefinitely. You could imagine some sort of hack where 
> >     the signature was over g^r and a timestamp but this seems pretty
> >     scary.]           
> 
> To impersonate the server indefinitely, the attacker also has to have the
> server's RSA key (and if he does, there's no protocol to protect you against
> that :-)
I was talking about a situation in which you replaced the signature in
message 4 with a MAC. In that case, an attacker who recovers any r,g^r
pair can pose as the server since he can capture a g^r signature off the
wire.

-Ekr

-- 
[Eric Rescorla                                   ekr@rtfm.com]
                http://www.rtfm.com/
References: