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

Re: Draft Charter IPSEC WG



Steve,

The key management protocol I envision for network-layer security
would be interactive, something along the following lines:

1. The systems do a Diffie-Hellman key exchange and immediately begin
using the resulting key for IP packet encryption (using symmetric
cryptography) and/or authentication (using a keyed hash function).

2. The two systems immediately compute and transmit RSA signatures on
the DH exchanges, also exchanging RSA public key certificates if
necessary. If the signatures fail, or if they are not received after
some timeout, the protocol resets to the unkeyed state and starts
again.

Once the signatures have been verified, other upper layer protocols
and applications can be notified that secure communications are now
available between that host pair.

3. Either host can reinitiate the keying process with a peer host at
any time by destroying its current key for that host pair and returning
to step 1.

This protocol has some very nice properties for interactive
communications, such as the fact that the host-pair "session" key is
unrecoverable once it is destroyed, even if the entire exchange has
been recorded and one or both hosts' private RSA keys are later
compromised. And rekeying pairs of hosts on a regular basis (say,
every 10 minutes) would limit the amount of data that could be
compromised by compromising an active session key.

The best an active eavesdropper could do is to trick the parties into
revealing their public key certificates (by doing the
middle-against-the-ends attack against the Diffie-Hellman step).
However, the hosts would detect this as soon as they exchange RSA
signatures and not use the key to authenticate or encrypt any user
traffic.

Unlike many application layer security protocols, this protocol
assumes bidirectional communication. I don't know what you're planning
for an application layer key exchange protocol, but it's possible that
we may still several different protocols if yours must assume
unidirectionality.

Phil



Follow-Ups: