[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