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

draft-ietf-ipsec-ah-md5-00.txt

Ref:  Your note of Tue, 17 Jan 1995 11:06:00 -0500 (attached)

To your question below: I do not know of any attack in prepended MD5
if you fix the position of the length parameter (relative to the begining
of the information). However, I want to prevent what Ted Ts'o pointed to
very clearly:

   I'm not a cryptographyer, so I don't know if there are any inherent
   advantages to putting the key at both the beginning and the end, as
   opposed to just simply putting length near the beginning --- however,
   one good thing about doing it "right" is that if someone ever lifts this
   code, or the assumptions change (I don't know enough about IPv6 to know
   whether or not this is likely), we won't need to rely on someone
   remember that we made this assumption, and that we now need to do
   something different now that this assumption is gone.

THat is, the security being given by the length is somewhat fragile
in the sense that the position of the length parameter is indpendent of the
security function (it was chosen by IP not by IPSEC).
This will let people forget/overlook its security role, and this invites
troubles.  The key appended to the end provides an explicit security mechanism.

Beyond this let me stress that I do not know of any serious cryptanalysis
work against MD5 as keyed authentication function.
MD5 was created with a very different goal, namely, being a collision free
(or one-way) hash function. The serious cryptanalysis efforts I am aware of
were directed to find collisions. But that property says nothing about
its quality as authentication function.
Therefore, as I said in my original note: some extra care is advisable.


 > From: "Perry E. Metzger" <perry@imsi.com>
 >
 >
 > hugo@watson.ibm.com says:
 > >  > It does. See rfc791 on IP. Total length always occupies the third and
 > >  > fourth octet of the IP header.
 > >
 > > The minimal thing is to explicitely write in the draft that one is relying
 > > on the fixed offset for security;
 >
 > I have no objections to adding such a comment into our draft.
 >
 > > a better thing is not to rely on that and append the key.
 >
 > Do you think this would really provide a benefit given the specialized
 > nature of the thing we are authenticating (that is, IP packets with
 > explicit lengths)? If this is really a consideration for legitimate
 > cryptographic reasons, I believe the IPv6 working group should also be
 > convinced to alter their spec as they would be vulnerable for
 > precisely the same reasons. What kind of attack do you think could be
 > mounted on the scheme, given the existance of an explicit length?
 >
 > Perry