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

No Subject



 > Subject: Re: draft-ietf-ipsec-ah-md5-00.txt
 >
 > > Ron Rivest has stated that a shared secret at the front of a message is not
 > > sufficient for authentication.  I thought that I remembered this being
 > > discussed ath the San Jose IETF.  Further, I thought that we agreed that we
 > > would solve this weakness by puting the shared secret before and after the
 > > data payload.
 > >
 > The appending attack is solved by including the IP Total Length field
 > in the calculation.  Ran explained this.
 >

Just including the length as an authenticated field is NOT enough.
To defeat the trivial appending attack on key-prepended MD5 one
needs to specify that the length value appears in a FIXED OFFSET
from the begining of the information being authenticated (e.g.,
it is the first value in that information, or appears starting in
byte 8, etc.). Otherwise, the attack is still feasible (e.g., if I put the
length at the end of the information I can add whatever I want to the
authenticated information and at the end I append the *new* length).
BTW, MD5 itself, by definition, adds the message length to the end of the
authenticated information but as said this doesn't help here.

Although prepending keys may have a slight advantage for computation (first
block can be pre-processed), I recommend we use appended (or even better,
prepended and appended keys). Let's not forget that MD5 was NOT designed
as a key-ed authentication function, thus some extra care is advisable.



 >
 > > Does anyone else remember this?  I seem to remember the discussion causing
 > > a tanget about "prepend" not being a word.
 > >
 > That was me.  I remember.  The WG minutes do not suggest a decision was
 > made.  I have email from the Area Director recommending we only use
 > the front, as that is compatible with what other WGs are doing.

I recommend other groups change what they are doing if it is not secure
enough.

Hugo