[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Tunnnel protocol - answers and clarifications
Tunnel Protocol Revisited - Response to Ken Hardwick's comments
---------------------------------------------------------------
Ken,
Thanks much for your comments on our tunnel proposal. They help us
clarifying some important points. Here's our response
to your suggestions/questions:
>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.
The principle here is the fact that the more you use a key the more
it is exposed (e.g., using key with weak encryption). This
motivates the derivation of a different key for each session.
> 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.
The basic comment here is that there is a significant cost associated
with master key exchange (regardless of the procedure: manual, public-key,
key dist. center,etc.). Many users will prefer to maintain shared
master keys for relatively long periods of time and use newly derived
session keys for data encryption/authentication.
Life-time of keys will need to be negotiated between the parties as
well as the particular cryptographic algorithms for use.
> 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?
No, having derived SK doesn't allow the eavesdropper to derive future SK's
(and, in particular, not K itself). This is a property of pseudorandom
functions.
>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.
We don't understand your emphasis on human intervention here, but let's first
make some general comments about the use of time as a measure against replay:
a. We are, in principle, against, as we believe consistent timestamps are
hard to maintain, especially in adversarial scenarios, and therefore
untrustable.
b. Our nonce mechanism avoids the use of time, but assumes a nonce is shared
between S & R;
c. (Already clarified in the original note) In cases the nonce is not
shared (or is lost), there exist 2 options: extra flow, or use of
timestamp. We would prefer the extra flow option, but believe many
people in Internet will not. (We would like to know the group's opinion
on the issue.)
d. One can let S send the time only (if it does not have or did not keep
N_R) in which case it will be R's decision (policy) whether it accepts or
not the TIME value for a valid authentication. One reason we
included in our (schematic) flow from S to R both TIME and N_R
is to cover the case in which S has kept the N_R value but R did not.
As before, R may decide whether TIME only is sufficient or not.
e. If time is chosen to be used by some users, it may make sense only in
the S to R flow (R will always have N_S for the response). An adversary
that takes advantage of this weak freshness mechanism and manages
to re-send an old S-R flow that R accepts as fresh, will succeed in
clogging R but not in finding the new (master or session) key. Notice
that in the case of a master key exchange, R chooses a fresh K_R
which the adversary (not knowing S's private key) cannot find. In the
case of a session key exchange, the incorporation of N_R' which is chosen
by R into the MAC expression guarantees the freshness of the key. The
adversary, not knowing K, cannot find it. We stress that this function
of N_R' is necessary even if one decides that S does not keep N_R'
for future use.
IMPORTANT: The flows of our protocol may be used for the parties' mutual
authentication regardless of a key exchange. In that case, the
freshness of the time/nonce IS essential.
> 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.
There is no need for secrecy or integrity protection of the nonce on its
way between S and R, so in a way the extra flow does the 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.
>
We feel that the proposed solution deals well with the clogging problem. It
helps alleviating the problem without adding unnecessary complexity
to the normal use of the protocol.
>
>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.
We agree, but feel that Internet is heterogeneous enough that many people
may not need it and refuse to pay that price. If there is enough interest,
D-H could be incorporated to the protocol as an option/extension.
>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.
We agree. Our solutions are designed to support multiple tunnels between
a pair of nodes. Again, it would be nice to hear from the group before
we go on.
>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?
As explained above, time is required only in the case that a nonce is not
shared. About knowing the time, this is not required since the time
is also transmitted outside the MAC expression (please refer to the
packet figures in our proposal).
>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?
Getting back in sync is done exactly as in the case where a nonce is
not shared (i.e., use time or exchange new nonce with extra flow).
>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?
K_R *is* sent (encrypted) in E_2. Further, note that we are indeed using this
option (See COMBINED PROTOCOL in our proposal).
>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?
Verification *is* cheaper than encryption. For example, assuming
512 bits, if the public exponent is 3, verification is 256 times
faster; if the p.e. is 2^16 + 1, then verification is 512/17
(~ 30) times faster.
BTW, these exponentiations (the "long" ones) are the ones we count
in our proposal.
GHK