[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
fast re-keying
Phil,
This is a response to an "old" note of you on fast re-keying
(2 weeks and 300 messages old ;-), which I believe is an important
issue.
I am glad that we agree on the necessity of a fast re-keying
mechanism based on MD5 or alike functions in addition to the basic
(and significantly more expensive) key exchanges based on
public key and/or Diffie-Hellman.
Now it just remains to agree on the details.
Following are my comments to your proposal
(indented text is from your note).
> I propose that the session key be derived from the following:
>
> MD5 { local cookie, remote cookie, shared DH secret, SAID }
>
> Use as many bits as you need from the front of the hash result. E.g.,
> for single-key DES, take the first 64 bits and overwrite every 8th bit
> to have the proper parity. For IDEA, just use the entire MD5 result
> as-is.
The use of MD5 for deriving the keys is fine with me (as usual this should
be replaceable by any other "pseudorandom" function, e.g. DES-MAC-CBC).
>
> The cookies are included mainly so that different keys are generated
> for each direction of transmission. They're handy enough.
>
> Including the SAID in the hash is how I generate distinct keys for
> each new SAID between a given host pair without requiring a new DH
> exchange each time. This does imply a new SAID everytime you rekey,
> which I consider reasonable given the size of the field. It also keeps
> the protocol simple.
Since you are going through an interactive process to refresh the key (as
you explain below) then there is no reason to impose this special role to
the SAID (aka SPI these days). We better have no assumption on the SAID
(not even that it does not repeat through the life of a DH key; this should be
completely free for the implementation to decide).
The right way that I see to implement the fast re-key is to exchange
nonces between the parties and use them as arguments to MD5 for the derivation
of the keys. These nonces ensure the freshness and authenticity of the
exchanged key. The protocol remains simple and very cheap (as explained below).
You can say: where do I put these nonces in the protocol?
Very simple, put them instead of the DH parts g^x, g^y.
Not only it gives the freshness referred to above, it also saves a lot of
bandwidth. Just sending the g^x,g^y as dummy values as you suggest seems
to me unjustfiably wasteful (1000bits each and if you're sending also
g and p it will come to 3000 bits that are essentially unused).
Since in any case the field for g^x is variable-length (it depends on the
size of the modulus) one can specify that a length of less than, say, 128
bits, means that the field carries a nonce.
The later is just to demonstrate that you do not have to create new message
types in order to support fast re-keying (although I personally prefer to
have these messages independent from the basic key exchange, i.e. from the
details of the PK/DH based protocol. In any case, this is a separate issue
for discussion).
>
> Creating a new SAID without a new DH computation doesn't necessarily
> require adding new message types, although it could be done that way.
> It could simply follow the same Photuris exchange, possibly with a new
> set of cookies if they are time-varying. In the DH step, though, the
> previous public values would be exchanged. The DH module in the
> implementation could compare the new values to the ones previously
> received. If they're the same, and if we haven't generated a new
> public value on our end, we'd simply bypass the DH exponentiation
> and keep the old shared secret.
The need for cookies here is not clear to me. In particular, fast re-key
does not need to require cookies since only fast to compute and verify
functions are used. But again, I see this as a secondary detail.
Now, if you want to see a particular implementation of the ideas sketched
above you can check our MKMP draft (draft-cheng-modular-ikmp-00.txt or .ps).
It contains a fast re-key protocol that exactly fits the above description;
we call this, I guess, the short-lived key protocol.
In that specific protocol, we assume shared nonces but that's just for
efficiency and not essential; if you prefer, you can exchange nonces
during the protocol itself. In that case, it fits exactly the message
structure of Photuris or my variant.
There are important additional issues that you did not cover in your
description, e.g., how do you derive long or multiple keys, the advantage
of refreshing the "master" key with each fast re-key, reducing
plaintext/ciphertext information, etc. These are left for future messages.
Hugo