[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Some comments on JFK
(1) In message 1 the initiator sends g^i. This is replayed in message
3. I see why the initiator needs to tell the responder the group he
wants to use but why does it need to communicate g^i? If you simply
want the initiator to commit to g^i, why not use a hash? This would
save some bandwidth, which is always nice :)
(2) The discussion of message 2 says:
The authenticator key is changed at least
as often as g^r, thus preventing replays of stale data.
But the discussion of message 3 says:
The Responder's exponential (g^r) is re-sent by the Initiator because
the Responder may be generating a new g^r for every new JFK
protocol run
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?
I agree that HKr must be changed to prevent replays but I don't see
why it needs to be changed as often as g^r. Have I missed something?
There appear to be some similar inconsistencies in the discussion of
message 3 caching where it says:
This cache of messages can be reset as soon as g^r or HKr are
changed.
Incidentally, it would save some bandwidth if the client echoed
a hash of g^r (or a key id provided in message 2) in message 3.
Again, this would save some bandwidth.
(3) The discussion of message 3 says:
The Responder keeps a copy of recently-received Message (3)'s, and
their corresponding Message (4). Receiving a duplicate (or
replayed) Message (3) causes the Responder to simply retransmit the
corresponding Message (4), without creating new state or invoking IPsec.
This suggests that the cache lookup is performed on the entire message 3.
E.g.
if(msg4=table_lookup(message3,message3_len)){
retransmit(msg4);
}
else ...
However, this may open the responder to a DoS attack whereby the
attacker replays copies of message 3 with different encrypted blocks
(i.e. garbage). The attacker can thereby force a cache miss and force
the responder to repeatedly compute g^ir while attempting to process
these messages. This entails no particular computational burden on
the attacker.
The easiest fix for this is for the responder to use only the
authenticated data (Ni,Nr,g^i,g^r) or simply HKr as the cache key.
(3) Section 2.3 says:
The Initiator bears the initial computational burden
and must establish round-trip communication with the Responder
before the latter is required to perform expensive operations.
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.
The Responder may compute a new exponential g^r for each
interaction. This is an expensive option, however, and at times of
high load (or attack) it would be inadvisable.
Technically speaking, it's not the generation of g^r that is
expensive. If you're using g=2 this is can be made pretty fast.
It's SIG{r}(g^r) that's expensive, especially if you're using
RSA. This is just a nit of course.
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 :) Additionally, it seems
like bad practice to use the same key for messages (3) and (4). I'd
much rather see different keys.
Also, I don't see where you're getting the 3DES initialization vector
from, though I assume you use CBC. Is it generated from g^ir? Random
and included in the message?
(4) Section 2.5 contains a minor glitch:
implicit in $\mbox{ID}_I$ and $\mbox{ID}_R$) should be accomplished
(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.
(6) Performance issues:
The standard JFK exchange requires at least the following
public-key operations on each side:
1 DH key agreement
1 signature generation
1 signature verification + 1 verification for each peer certificate
If you want true PFS the situation is worse since you must
also do an extra g^X mod p and signature generation (to sign g^r,
whereas if you reuse g^r you can amortize this signature over multiple
interactions). This may not sound like a lot but remember that people
avoid SSL for performance reasons even though it's substantially cheaper
than JFK. I'd certainly expect people to reuse keys rather than
use PFS in order to improve performance. This isn't that desirable.
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.
[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.]
Anyway, for this to work the server needs to recognize that it's
in PFS mode and do a MAC in message 4 and the client needs to
know what to expect when it reads message 4.
Let me know if any of this isn't clear or if I've misunderstood
something.
-Ekr
--
[Eric Rescorla ekr@rtfm.com]
Author of "SSL and TLS: Designing and Building Secure Systems"
http://www.rtfm.com/
Follow-Ups: