[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft-ietf-ipsec-<many>-00.txt
Ref: Your note of Tue, 17 Jan 1995 10:06:39 -0500 (attached)
>
> Colin Plumb says:
> > Thus, I can make a large number of undetected changes (defined as XORs)
> > to the first 8 bytes of a message. If I know what they are to start
> > with, I can possibly change them to desired values.
> >
> > Is this a problem?
>
> Yup, it is. The working group pretty much felt comfortable with MD5,
> and I feel a whole lot better with MD5 myself.
>
The paper "Message Authentication", by Jueneman, Matyas and Meyer,
IEEE Comm. Magazine, Vol 23, No.9, 9/85, pp. 29-40 contains more examples of
this type of attacks. In different variations (and different levels of
relevance), these attacks apply to *all* methods of authentication that are
based on computing a checksum using a *known* function (e.g., the CRC
with known polynomial or MD5 without keys), appending that checksum
to the transmitted information and finally encrypting everything together
under a CBC mode. (See page 36 of the paper, column 2; these known
checksum functions are referred to in the paper as "MDC".)
Many of these attacks require chosen plaintext and other things to make the
life of the adversary easier. However, as the paper states, a good
authentication function shouldn't be suceptible to theses attacks.
Even if in all specific scenarios we can think of today these attacks seem
unrealistic, Murphy will create those scenarios tomorow (or yesterday).
A simple example of an attack (not from the paper) is as follows.
(I use CRC, but as said any un-keyed function will do).
Let's say that A posts a file in some server that is to be retrieved
by other people. When B asks for the file the servers authenticates it
and sends to B.
Now A (here for Adversary) is interested that when C asks for the file
she gets only a prefix of it, say first 100 bytes. For that, before posting
the file, A computes the value of the CRC on the first 100 bytes and adds
this value to the file following these 100 bytes.
After that A concatenates the rest of the file, and posts it to the server.
Clearly, when the file is transmitted to C (encrypted under the key between
C and the server which A does not know), A can intercept it, and relay to C
only the 104 bytes prefix which is legally authenticated!
Is this a problem??? Not necessarily. Who will want to do that?
What about length parameters appended to the authentication?
What about the meaning of the CRC in the middle of the file for
somebody that get it all?
A lot of valid questions; however, a good authentication function shouldn't
allow for such weaknesses.
As usual, we are in a business of trade-offs and we may decide that this is
good enough for IPSEC, but we still have to be aware of the limitations of
these techniques. And make notes of it in the proposals/drafts.
Hugo
PS: Perry, when you say MD5 you mean key-ed MD5 or regular MD5.