[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tunnel Protocol Revisited
Hello all,
I haven't been to an IPSEC meeting yet (hope to make Toronto). However,
I'm working at Network Systems with Jim Hughes and we are jointly working
on ways to incorporate data privacy to our products.
Here are my reactions to the Garay/Herzberg/Krawcyzk (GHK) proposal
for tunnel establishment. With several worthy contributions now hopefully
tunnel establishment issues will pick up from their formally glacial pace.
1. One of the ideas is to improve performance by using a master key
to derive session keys over the course of several sessions. I am
having trouble seeing how this is any more secure than just using
the same master key for several sessions and eventually going through
a full negotiation for a new one.
First, it implies that there will be many "sessions" during a reasonable
master key lifetime. I'm not sure why this should be so. Sessions
should indeed time out due to inactivity, etc. but the overhead of
maintaining dozens/hundreds of tunnels is limited. I suppose it
might apply in a host where there is a distinct event when
sessions (binds) have initiated and terminated.
Second, if my eavesdropper has recorded my encrypted conversations and,
with extreme effort, eventually decrypts some part of the message
stream, will not the rest of the traffic encrypted with a descendant
of the same master key be open? This is certainly true if our eavesdropper
computes the master key K, as the next key computation SK=F_K(T)
is all based on known data. If the eavesdropper has cracked one
SK, can K or the next SK be derived from that?
2. I have a problem with both the Hughes and GHK techniques to prevent
replay prevention of sleeve establishment. My concern centers around
what I personally call "administrative robustness" -- the neophyte
sysadmin setting up a tunnel needs to be able to do so with a minimum
of coordination with the other end (another person who may be a
[also marginally qualified] total stranger); further the tunnel must
not be fragile to adminstrative screwups (like planned or unplanned
time of day/ daylight savings/ timezone equipment move) that
fundamentally don't affect the security of the system.
Replay prevention using time requires that all entities have and maintain
a reasonably correct notion of absolute GMT. For a naive user's PC or
a small site feeder router, that's asking a lot.
The nonce approach of GHK looks a bit nicer. I assume that if time
is used that the *initial* nonce must be distributed by means sufficently
secure to ignore the replay prevention threat -- that sending "here's my
initial nonce" in the clear before beginning an initial session is
open to man-in-the-middle attacks. Am I right? If otherwise the nonce
can be sent over an unsecured medium then this system will do the entire
job.
My personal preference is to have a three way handshake before data is
sent. Each side gets to have a random string of its own returned back
to it, ensuring that none of the messages are old ones. No knowledge
of the other party than their public key is required or assumed.
Yes, it takes more elapsed time, but it's far more idiotproof.
A second possibility (although it mixes tunnel establishment and
traffic protocols) is to return the responding party's random string
with the initial traffic message which has presumably caused the
originator to establish the tunnel in the first place.
This does not deal with the "clogging" concern first voiced by Jim.
In fact a replay attack will force a responder to receive two
messages and perform one decrypt in order to recognize a replay attack.
However, there is nothing subtle about a *detected* replay attack,
and I personally don't have a problem with denial of service through
message storms so long as the cause is detected and reported. There
are *so many* ways to take out an IP node with saturation transmissions
if that's what you want to do.
3. Jim Hughes and I both feel that Diffie-Hellman needs to be *available*
as part of tunnel negotiation. GHK laid the issue out nicely: without
D-H, a good technique requires that an intruder coerce or steal *both*
private keys of the entities of each end of a tunnel in order to
derive the traffic key of old sessions. This will be sufficient for many
people who feel that *their* router or host won't be stolen, just the
other guy's.
Many of our customers are governmental and commercial professional
paranoids who attach high value to the privacy of *ancient* (years
old) information that may have been recorded enroute. The fact that
such information is laid open if attackers got hold of several old
private keys through theft, administrative error or "social engineering"
is not acceptable.
The down side of this is that D-H is *very* expensive in CPU time.
Playing with the RSAREF code showed me that one side of a 1024 bit
D-H key negotiation took 4.5 sec on a 16MHz Sparc, contrasted with
1.0 sec for a 1024 bit RSA encrypt plus decrypt.
Yes, it's a case of creeping features but I'd like to see how we can
make traffic keys cryptographically unknowable after the fact.
4. A point I have raised with Jim before is that there must be a clear
mechanism to establish *several* tunnels between a pair of IP nodes.
Each tunnel may have different crypto, compression, etc. options, and
each may have a different forwarding policy when their traffic messages
are decrypted. None of the proposals so far prohibit this in their
formative stages, but this objective needs some airing before
a standard emerges.
The following comments are at a lower level of detail:
5. The session re-establishment protocol where the MAC_K() quantities
are exchanged depends on both parties being able to build the
payload that was MAC_K() hashed and compare the result. However the
receiver must know the *exact* time sent by the sender in order to
compute MAC_K(TIME, N_S, N_R), or cast about through trial and
error for times that are very close. If the nonces are refreshed
in every negotiation is the time needed?
6. If session establishment response is lost, the sender holds N_R while
the receiver is working with N'_R. How do they get back in sync?
7. In note 2 of the master key exchange protocol the return flow
can be replaced with MAC_K(E_2, N_S, N'_R). This confuses me.
How can the sender compute K if K_R is not sent? How will it
know N'_R for the next session exchange?
8. In note 3 of the master key exchange protocol it's stated that
signature verification is much cheaper than decryption. Huh?
Step 1 in verifying the signature is to *do* an RSA decrypt.
Am I missing something?
- Ken