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

response to Last Call on: IP Authentication using Keyed MD5



The document: draft-ietf-ipsec-ah-md5-03.txt
presents what is supposed to become the "must to implement" message
authentication function for IPSP and IPv6. The authors of that document
have ignored past recommendations I made to this group regarding
the choice of this function. This included recommendations worked out
together with my colleagues Mihir Bellare and Ran Canetti in IBM Research,
and Burt Kaliski and Matt Robshaw from RSA Labs.

Out of these recommendations, all based on the idea of keying the
(otherwise keyless) MD5 function, I chose one that seems the most acceptable
to the WG (based on feedback from people to the list and personal
discussions with some of its members).
This particular function is presented in an Internet draft that was just
posted:  draft-krawczyk-keyed-md5-00.txt

This draft limits itself to the description of the function in a way
which is protocol independent, and can be referenced by
other documents specifying its particular use for a given protocol, e.g.,
the Authentication Header of IPSP and IPv6. (This approach is similar to the
way RFC-1321 is referenced for MD5). In particular, the draft does not
explain the rationale for this particular transform. Information on that
is provided in the articles referenced in the draft. Some of this rationale
was also several times sketched in my notes to the IPSEC WG list.

The particular choice presented in this new draft
is intended to keep the following properties:

* no change to the MD5 code required
* no degradation of MD5 speed
* simple key requirements

Departing from these conditions, other constructions with better analytical
properties can be suggested . For example, keying the MD5 function via its
initial registers as proposed in references  BCK  and  PV  of the draft
(this requires less assumptions on the compression function of MD5
at the cost of a minimal change in MD5 code).

However, the proposed scheme does not suffer of any practical weakness
known today. On the other hand, if the above properties are to be relaxed
then other designs which may prove more robust to future attacks are
possible.

A separate note by Paul Van OOrschot to these lists proposes going in this
direction. I support his position if the above conditions (no modification
of MD5, speed, etc) are relaxed. Otherwise, I propose the adoption of
keyed-MD5 as described in the above draft (draft-krawczyk-keyed-md5-00.txt).

Hugo (Krawczyk)


Follow-Ups: