response to Last Call on: IP Authentication using Keyed MD5
hugo@watson.ibm.com Tue, 27 June 1995 01:29 UTC
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16894; 26 Jun 95 21:29 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16890; 26 Jun 95 21:29 EDT
Received: from interlock.ans.net by CNRI.Reston.VA.US id aa20928; 26 Jun 95 21:29 EDT
Received: by interlock.ans.net id AA40361 (InterLock SMTP Gateway 3.0 for ipsec-out@ans.net); Mon, 26 Jun 1995 21:21:31 -0400
Message-Id: <199506270121.AA40361@interlock.ans.net>
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Mon, 26 Jun 1995 21:21:31 -0400
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Mon, 26 Jun 1995 21:21:31 -0400
Date: Mon, 26 Jun 1995 20:22:51 -0400
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: hugo@watson.ibm.com
To: ietf@CNRI.Reston.VA.US
Cc: ipsec@ans.net, iesg@CNRI.Reston.VA.US, PAULV@bnr.ca
Subject: 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)
- Re: response to Last Call on: IP Authentication u… Perry E. Metzger
- response to Last Call on: IP Authentication using… paul (p.c.) van oorschot
- response to Last Call on: IP Authentication using… hugo
- Re: response to Last Call on: IP Authentication u… Robert Elz
- Re: response to Last Call on: IP Authentication u… Perry E. Metzger
- Re: response to Last Call on: IP Authentication u… Debra Arneson
- response to Last Call on: IP Authentication using… paul (p.c.) van oorschot
- response to Last Call on: IP Authentication using… hugo
- response to Last Call on: IP Authentication using… hugo
- Re: response to Last Call on: IP Authentication u… Perry E. Metzger
- Re: response to Last Call on: IP Authentication u… Craig Partridge