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

draft-ietf-ipsec-icmp-fail-01.txt



draft-ietf-ipsec-icmp-fail-01.txt creates a small security hole.

In particular, it defines a ICMP 'decryption failed' message, which leaks a
little information about an encrypted datagram.

Let me use the standard DES-CBC transform as an example: the last encrypted
block contains padding, padding-length, and payload-type.  The padding-length
may be as large as 255 to hide the length of the plaintext payload.  I claim
this length can be recovered by taking advantage of the ICMP failure messages.

Here's the attack.  Take a long DES-CBC-ESP encrypted IP datagram, for which
you want to know the true length of the payload.  Delete all the ciphertext
blocks except the last N blocks (and set the IV to be the N+1 to last
ciphertext block), send the resulting datagram, and check whether you get a
ICMP 'decryption failed' error.  If the padding-length byte was greater than
8N-2, you will receive a 'decryption failed' error (because presumably the
receiver will send a 'decryption failed' ICMP error when the decrypted
padding-length value is greater than the length of the encrypted payload).
If the padding-length is at most 8N-2, the decryption will succeed (although
some nonsense bits will be sent up to the transport protocol's port-- no harm
done).  A binary search over N will quickly find the datagram's secret length
(plus or minus 8 bytes or so).

So this cut-and-paste replay attack on DES-CBC, and its interaction with the
ICMP failure draft, opens a minor security weakness: an active attacker can
recover the length of the plaintext payload without too much effort.  (What
other scarier, subtler interactions are out there?  Eek.)

A fix?  One fix is to never use DES-CBC without authentication, I suppose.