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

Re: draft-ietf-ipsec-esp-des-md5-00.txt

> Security Working Group                                         J. Hughes
> Request for Comments: DRAFT                        Network Systems Corp.
>                                                            February 1996
> 
> 
>      Combined DES-CBC, MD5 and Replay Prevention Security Transform

So let me first thank you for spending your time to draft a transform
which includes confidentiality & integrity & replay protection in ESP!

Unfortunately, your current text has some serious flaws (though I think
they can be fixed within your basic framework).  I'll explain.


First, you use unkeyed MD5 for integrity protection.  This is altogether
insufficient (even though the MD5 digest is encrypted).  I've included an
attack at the bottom of this email if you want more details.

You need to use *keyed* MD5 for integrity; use one of the MD5 MACs that
is detailed in the AH ipsec RFCs.  (HMAC looks ideal.)

The MD5 MAC should cover everything in the ESP header and afterwards that
it can; in particular, it should protect the SPI and the IV (which you
don't have it doing currently).

You might consider placing the MD5 MAC output at the beginning of the
encrypted data, rather than the end: that way it will have an additional
IV-like randomizing influence.


Second, the replay protection mechanism you describe is insufficient:
it requires a counter to be increasing.  Since IP datagrams frequently
arrive out-of-order, you'll be dropping an awful lot of packets.  Instead,
the receiver needs some sort of window for sequence numbers.  (Steve Kent
suggested a simple scheme along these lines.)

I do like the idea of the 32 bit session specific nonce in the replay
protection field.  Good!

You should mention that there will be significant difficulties in getting
replay protection to work well in the case of multiple senders per SPI.
(One hack which might work if there are just a few senders is to give
each sender a different 32 bit session specific nonce.)  I don't know of
any good way to handle many-sender replay protection; leave that issue
for the future, I suppose.


Third, now there will be key scheduling issues.  Since the MD5 MAC will
be keyed, we will need two keys.  DON'T use the same key for both MD5 and
DES; this is a horrible idea.  (I'll elaborate on why if you like.)  The
MD5 & DES keys should be chosen independently.

Since security associations typically only allow one transform key to be
associated with them (in the implementations I've seen), you'll need a way
to specify the MD5 & DES keys from the transform key.

One simple solution is to have a 56+128 = 184 bit transform key: use the
first 56 bits of the transform key as the DES key, and the last 128 bits as
the MD5 key.  You'll have to be very careful to warn people to make sure
those bits are independent, though-- this solution might be tempting fate
a bit.

A more sophisticated & safer solution is to have a 128 bit transform key,
and then specify a simple key schedule to generate the DES & MD5 keys, e.g.
	MD5-key = MD5("md5mac" || transform-key)
	DES-key = MD5("descbc" || transform-key).

You should probably include a little note to implementors who are tempted
to make an export-weakened version of this transform, as well: though that
should be highly discouraged, such implementors should take care to only
reveal bits of the DES-key in the Espionage Enabling Field, and MUST NOT
reveal bits of the transform-key or the MD5-key.


I've been thinking about these issues a lot; in fact, I think I wrote
some text for a possible transform along these lines a while ago...it might
still be floating around somewhere.  But don't get the wrong idea: I'm not
criticizing your draft because of some "not invented here" syndrome-- I
just happened to have thought a lot about this stuff already, and would
like to help get it right.

Thanks for taking the time to work on this transform!  I hope this note
will help you improve its security.



P.S.  Here's an example of an attack on unkeyed MD5, as used for integrity
protection.  I think there's more discussion of these topics in Tsudik's
paper on hash-based MACs (which is even available on the web somewhere!).

If I want to get you to sign a message M, then I calculate
	X = M || md5(M) || M'
for any M', get you to sign X, and receive
	DES-CBC(X || md5(X))
	= DES-CBC(M || md5(M) || M' || md5(X)).
Now remember that I can trim from the end of DES-CBC to short messages;
so trim off the encrypted M' & md5(X) blocks, to get
	DES-CBC(M || md5(M))
which is a forged signed & encrypted version of M.

There are probably sharper attacks; but this should be enough to convince
you that an unkeyed function is unsuitable for use as a MAC.
References: