Re: Suggested modification to AES privacy draft

[daw@mozart.cs.berkeley.edu (David Wagner)]

>The meta-point here is that if Eve can send packets through the SA,
>there's a good chance that she can also read packets coming through
>the SA via tools like "tcpdump" ...

This is not my understanding.  My understanding is that, in some
scenarios, Eve can eavesdrop on encrypted packets and send traffic
over a SA, but not eavesdrop directly on unencrypted packets.  A simple
example of this is host-keying on a multi-user machine where Eve has an
unprivileged account.  See Bellovin's paper introducing cut-and-paste
attacks.

Moreover, it looks to me like this weakness *might* be exploitable even
on single-user machines where Eve doesn't have an account.  Consider:
Many user-level applications act as a server that will relay data sent
by the client to a third host.

A good example is sendmail.  If the victim machine is running a sendmail
daemon that acts as an open relay, Eve can connect to port 25 and specify
an email with a To: address referring to some third host; the sendmail
daemon will then re-transmit this email message to the third host, and
if the victim is set up to use an IPSec SA for communications with the
third host, this email message will be sent over the SA.  Notice that
Eve can choose the content of the email message in any way she likes;
if she's especially clever, she may even be able to send packets of the
form needed for Fluhrer's attack.

The point is that here sendmail allows chosen-plaintext attacks, and
Fluhrer's attack shows that IPSec does not seem to be secure against
chosen-plaintext attacks unless IV's are unpredictable.

Of course, sendmail is hardly the only example of an application that
will relay messages in a way that might allow chosen-plaintext attacks,
so I think it would be prudent to assume that adversaries will have the
capability to mount chosen-plaintext attacks on IPSec.

Given this, I think we need to fix IPSec and plug the hole.