[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
deriving keying material from the shared secret
The particular secrecy and authentication transforms we are considering
need varying amounts of keying material. For example, the current ESP
draft (draft-ietf-ipsec-esp-des-md5-02.txt) uses two 56-bit DES keys
(though it extracts 64-bit chunks), a single 64-bit IV (why one instead
of two?), and a 128-bit HMAC key. A mechanism for deriving these keys
from the shared secret is given in the text; it involves a 512-bit
pad field whose contents varies, and MD5.
By contrast, the current MD5-HMAC draft (draft-ietf-ipsec-ah-hmac-md5-00.txt)
uses a variable-length key apparently taken directly from the shared
secret, crunching it through MD5 if needed to reduce it to 64 bytes if
needed.
I suggest that we have one standard method of extracting keys from
the shared secret, probably spelled out in a separate RFC. It is
important, in my opinion, to make it extremely difficult to derive
one key given one of the others derived from the same shared secret.
For example, suppose one can determine the IV used for the ESP
transform as defined; we don't want to make it easy to determine
the session keys from the IV.
The derivation mechanism used in the ESP draft is probably wrong, since
it uses MD5 run on the concatenation of a constant string (which differs
for each key) and the shared secret. Since the constant string is
64 bytes long, the natural input block length of MD5, when the secret
is crunched in it is equivalent to running MD5' on just the secret,
where MD5 differs from MD5 only in the starting values of the state
registers A, B, C, D. If the shared secret is, say, 155 bits (and I
think that that will be common, if elliptic curves are used and if I'm
reading the Oakley spec correctly), then the attacker need only go after
one of the simpler cases for attacking MD5. (A forthcoming draft paper
will show why it may be relatively easier to get the key for one direction
than for the other. And given the key, the IV is trivial to recover.)
Possibly, we should run HMAC on the padding string, using the shared
secret as the key. At the least, I suggest that MD5(key,constantstring)
would be more secure.
Comments?