[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Comments on the IPSEC documents
Comments on the IP Security Internet Drafts
Michael Roe
Roger Needham
Mark Lomas
Ross Anderson
Ian Jackson
Cambridge University Computer Laboratory
Executive Summary
=================
This document identifies some fairly serious problems with the
cryptographic protocols which have been proposed for IP-level
security.
Accordingly, we believe that these draft protocols should not be
adopted as Internet Proposed Standards without undergoing further revision.
References
===========
``Security Architecture for the Internet Protocol''
draft-ietf-ipsec-arch-02.txt 8 May 1995
``Encapsulating Security Payload''
draft-ietf-ipsec-esp-01.txt 23 April 1995
``The ESP DES-CBC Transform''
draft-ietf-ipsec-esp-des-cbc-04.txt April 1995
``IP Authentication using Keyed MD5''
draft-ietf-ipsec-ah-md5-03.txt
``Keyed-MD5 for Message Authentication''
draft-krawczyk-keyed-md5-00.txt
1. DES-CBC doesn't provide integrity
====================================
In the architecture, clause 1.3, 5th para, the current text says:
``The IP Encapsulating Security Payload (ESP) is designed to provide
integrity, authentication, and confidentiality to IP datagrams.''
Clause 4.3 of the ESP document says that ESP doesn't always provide
integrity.
In ESP DES-CBC, clause 1, the current text says:
``The Encapsulating Security Payload (ES) [A-ESP] provides confidentiality
and integrity by encrypting the data to be protected.
This specification describes the ESP use of the Cipher Block Chaining
(CBC) mode of the US Data Encryption Standard (DES) algorithm
(FIPS-46, FIPS-46-1, FIPS-74, FIPS-81).''
In ESP DES-CBC, ``Security Considerations'' clause, the current text says:
``... on its own is not considered cryptographically strong. In this
situation, user or connection oriented integrity checking is needed [A-AH].''
The CBC mode of DES does not provide integrity; it only provides
confidentiality. This in itself is not a problem, as CBC mode is quite
suitable in situations where only confidentiality is needed.
However, it does cause a major problem for this series of related
documents. The architecture document assumes that the Encapsulating Security
Payload provides integrity as well as confidentiality. The ESP document
then admits that ESP, when used with some cryptographic transformations,
doesn't provide integrity. Finally, the DES-CBC document defines the
cryptographic transformation that is to be used, and it doesn't provide
integrity.
In the two steps from the architecture, to the ESP, to the cryptographic
transformation, things have gone badly wrong. The position has changed
by degrees from integrity being provided, to being optionally provided,
to not being provided.
To make matters worse, the DES-CBC document implies (but doesn't say outright)
that DES-CBC provides integrity.
This isn't true.
For example:
(a) The attacker can remove an integral number of 8-octet blocks from
the beginning of the ciphertext without being detected.
(b) The attacker can remove an integral number of 8-octet blocks from
the end of the ciphertext without being detected.
(c) The attacker can splice together messages (When the spliced
message is deciphered, the block at which the splice occurred may
look unusual. The attacker may well be able to get away with this)
It could be argued that DES-CBC does provide integrity, it just does it
poorly. In the same spirit, one can argue that a Caesar cipher or ROT-13
provides confidentiality, but does it poorly. No-one is seriously proposing
that a Caesar cipher should be the standard confidentiality transformation
for Internet use. Similarly, DES-CBC shouldn't be the standard integrity
transformation; integrity-wise, it's just too easy to break.
Suggested Improvements:
This could potentially be fixed in two possible ways:
(a) By replacing the DES-CBC transformation currently used by ESP with a
different transformation that does provide integrity.
We recommend this alternative.
(b) By deciding that ESP sometimes provides confidentiality only, and
changing the documents to reflect this:
i) The DES-CBC document would have to admit that DES-CBC doesn't
provide integrity
ii) The architecture document would have to admit that ESP doesn't
always provide integrity, and that if you need integrity and
confidentiality you may need BOTH an ESP header AND an Authentication
header on each datagram.
The ESP document explains that two headers may be needed (in
clause 4.3). The architecture document doesn't mention this.
This is a very important feature of the architecture. If you're
intended to use two headers, the architecture document should say
so. Conversely, if you're not supposed to use two headers, then the
ESP document shouldn't advise you to do so.
2. ``Keyed MD5'' may not be as secure as MD5
============================================
The MD5 algorithm is designed as a collision-free hash function. That is,
it is designed so that it is hard to find x and y such that MD5(x) = MD5(y),
and x<>y.
The ``keyed MD5'' method of authentication that is proposed in the
``keyed MD5'' document assumes that MD5 has a completely different property.
Specifically, it assumes that MD5(k,m,k) for message m and secret key k is
good as a message authentication code.
MD5 wasn't designed to have this property. Furthermore, it is quite possible
that MD5 will turn out not to have this property. It is quite possible that
``keyed MD5'' turns out to be very easy to break, while MD5 (used as a
collision-free hash function) remains very strong.
For example, suppose there is a statistical correlation between the input
bits and the output bits of MD5. An attacker might be able to use this
correlation to determine k, the session key. Once the attacker knows the
session key, you're lost. Note that this doesn't help the attack break
MD5 used as a collision-free hash function. It's purely an attack on
MD5 used as a MAC.
The assumption that MD5 is good as a MAC occurs elsewhere in these
documents:
IP Authentication Header, clause 4, para 1:
``Only algorithms believed to be cryptographically strong one-way functions
should be used with the IP authentication header.''
Being a good one-way function has nothing to do with being a good MAC.
This clause prevents the Authentication Header being used with some
perfectly acceptable cryptographic algorithms, because although they're
good MACs (which is what is needed) they're not good one-way functions.
Conversely, this clause encourages implementors to use unsuitable algorithms:
there are good one-way functions which are extremely poor as MACs.
IP Authentication Header, clause 4, para 3 says:
``If a block-oriented authentication algorithm (e.g. MD5, MD4) ...''
This is another example of the same error.
Suggested improvement
=====================
Delete ``one-way functions'' from IP-AH, clause 4, para 1, last sentence
(shown above).
Use ``DES MAC'' as an example of a data origin authentication algorithm,
not MD5 and MD4 (in IP-AH, clause 4, para 2)
More significantly, there should be a new document which describes the
use of the Authentication Header with a DES MAC. This algorithm could
be used by people who fear that keyed-MD5 is weak. DES MAC needn't be
made MANDATORY for all implementations. Indeed, export laws and other
regulations will probably prevent some vendors supporting DES MAC.
However, it should be specified so that people who want it can use it.
3. Separation of DES-CBC from other protocol layers
This issue isn't to do with *security*, but has rather to do with
the best way of organising the specification into separate documents.
As currently written, the DES MAC document describes the cryptographic
transformation in way that is dependent on other parts of the protocol
(the SPI, and the payload type).
It is quite likely that some other Internet protocol will be developed
that needs a DES MAC. It would be nice to have a document that just
describes DES MAC, and nothing else, that could be cited by other protocols
that need a DES MAC.
As things stand, the description of the DES MAC is badly entangled with
details of how ESP works. If another Internet protocol needs a DES MAC,
an entirely new RFC will have to be written (which will be almost exactly
like the ESP DES-MAC document, but with the ESP specific bits removed).
Suggested change:
Separate the description of DES CBC from the rest of the protocol.
in particular, take the SPI out of the DES CBC document (there is
no real reason why it should be in there).
It would make it easier to separate the description of DES MAC from
ESP if the payload type field came *before* the padding, rather than after.
That way, the DES MAC document could just describe how to pad and encipher
a block of data. The ESP document would explain what was in the enciphered
block of data (including the payload type).
4. Use of a counter as an IV
The DES CBC document suggests using a counter as an IV. This may be vulnerable
with some higher layer protocols.
If two ciphertexts are the same, an attacker can infer that the plaintext are
the same.
One of the purposes of the IV is to prevent an attacker doing this. The IV is
always different, ensuring that if the same plaintext is sent twice, the
ciphertexts will be different.
Unfortunately, this can go wrong if changes in the IV are statistically
correlated with changes in the plaintext.
Suppose that both the IV and the first block of plaintext are counters
(e.g. the plaintext is a transport layer sequence number, or something
like that). The first block of ciphertext will be DES(IV xor P1)
= DES(counter1 XOR counter2) = DES(0) = constant. That is, the effect of the
IV has been cancelled out. The same plaintext for the rest of the message
will result in the same ciphertext for the rest of the message, leaking
valuable information to an attacker.
The above example is an extreme case. In less extreme cases, what happens
is that collisions just become more likely, rather than happening every
time. For example, half the time only the bottom bit of a counter changes.
If the first block of plaintext also has the property that sometime only
the bottom bit changes, then the two may cancel each other out quite often.