To: ipsec@ans.net Cc: Michael.Roe@cl.cam.ac.uk Subject: Comments on the IPSEC documents Date: Fri, 30 Jun 1995 11:48:37 +0100 From: Mike Roe 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.