To: IPSEC Community, IESG (iesg@cnri.reston.va.us, ietf@cnri.reston.va.us) From: Ronald L. Rivest Date: June 30, 1995 Re: Comments on IPSEC Internet Drafts This is response to the call for comments on the following documents, which are proposed for consideration as Proposed Standards: [SA] Security Architecture for the Internet Protocol [AH] IP Authentication Header [AHMD] IP Authentication using Keyed MD5 [ESP] IP Encapsulating Security Payload (ESP) [ESPDES] The ESP DES-CBC Transform 0. EXECUTIVE SUMMARY I believe these documents are in need of significant further work before they are ready for adoption as proposed standards. 1. INTRODUCTION These documents propose techniques for securing network communications at the IP layer. The first gives a general overview of the proposed security architecture. The next two discuss the use of authentication headers to authenticate IP packets. The last two discuss methods for achieving confidentiality (and authentication) of IP packets. This note will critique these documents collectively, emphasizing the areas where I believe further work is needed, rather than discussing areas that are already well done. Since I have not actively followed the dialogue leading up to these proposals, and am not an expert at IP/Internet protocols, some of my concerns may reflect my own ignorance of the context or intent of these proposals. If so, this may be an indication of where these documents should be improved, without necessarily changing the proposals themselves. I was stimulated in part to provide these comments by Phil Rogaway's note: [ROG] Problems with Proposed IP Cryptography Some of my comments will be based on Phil Rogaway's excellent critique. I have also found the following excellent document very relevant and interesting: [PO] MDx-MAC and Building Fast MACs from Hash Functions by Bart Preeneel and Paul C. van Oorschot available by ftp from K.U.Leuven: ftp server: ftp.esat.kuleuven.ac.be directory: pub/COSIC/preneel file: mdxmac_crypto95.ps 2. DISCUSSION OF PHIL ROGAWAY'S COMMENTS I begin by reviewing Phil Rogaway's comments. 2.1 "AUTHENTICITY = INTEGRITY" [cf ROG 1.] I agree entirely with Phil here; the distinction between message authenticity and message integrity is vacuous here, and the proposed documents should be rewritten to use just a single term (message authenticity) for this notion. (I support Phil's recommendation 1.) 2.2 "ENCRYPTION DOES NOT GUARANTEE INTEGRITY" [cf ROG 2.] Again, Phil is on target here. The proposed documents have a confused and ambiguous discussion as to how authenticity is to be achieved. The confidentiality and authenticity techniques should be cleanly separated orthogonal mechanisms. (I strongly support Phil's recommendation 2.) 2.3. "IT IS WORTHLESS TO ENCRYPT KNOWN HEADERS" [cf ROG 3.] Here Phil recommends (his recommendation 3) that the encryption of known headers should be forbidden, on the grounds that AH, and not ESP, should be used for authenticity. I agree. (I support Phil's recommendation 3.) 2.4 "DON'T ENCRYPT MESSAGE AUTHENTICATION CODES" [cf ROG 4.] Although it is not uncommon to encrypt MACs, Phil is exhibiting excellent taste by suggesting that the scope of the authentication header should include the encrypted packet, rather than vice versa. While I don't know of any security weaknesses from the proposed organization, Phil's suggestion is cleaner and preferable. (I support Phil's recommendation 4.) 2.5 "DEFINE TRANSFORMS GENERICALLY" [cf ROG 5.] This recommendation is just common sense in support of better modularity in the description of what is being proposed. (I support Phil's recommendation 5.) 2.6 "MANDATE HARDWARE-EFFICIENT *AND* SOFTWARE-EFFICIENT TRANSFORMS"[cf ROG 6.] Efficiency is clearly an important issue when we are talking about operations that affect potentially every packet on the Internet. I think that the main point here is that there should be considerable freedom to choose alternative encryption techniques. (I have no problem with Phil's recommendation 6.) 2.7 "USE 128-BIT KEYS" [cf ROG 7] The key sizes should either be totally arbitrary (perhaps up to some generous limit, such as 4096 bits), at the user's discretion, or else be fixed at 128 bits as Phil proposes. I prefer the former approach, as it provides flexibility that may be necessary to accomodate different algorithms or other considerations (such as export control). (I think that the key sizes should be at the user's discretion.) 2.8 "THE MAC MECHANISM" [cf ROG 8] I begin by noting that Burt Kaliski and Matt Robshaw have written an excellent article that is relevant: "Message Authentication with MD5" by Burt Kaliski and Matt Robshaw CRYPTOBYTES, vol 1, number 1 (spring 1995), pages 5--8. (available from the authors at burt@rsa.com or matt@rsa.com) Phil criticizes the proposed use of MD5 as a MAC mechanism for: (1) being too slow, (2) having no theoretical foundations for the proposed mode of use of MD5. (3) having no manifest parallelism in the design of MD5. Unfortunately, at this point in time we faced with choosing from what is available. Phil proposes an excellent direction in his recommendation 8, but this is still research, not something that is ready for standardization. Phil says he is working on something, and this may turn out to be a better proposal than the current MD5 proposal. I have also been thinking about new hash function designs that might provide superior performance. However, at this point in time there are no concrete alternatives on the table. Keyed-MD5 may be a plausible choice at the current instant, but we should be prepared for the fact that in the very near future we may see significantly better alternatives proposed and sufficiently evaluated to be considered as replacements. (Also, the use of hash functions with more than 128 bits of output may become routine good practice.) There may be some confusion as to whether the current proposal is (1) MAC_a(x) = MD5(MD5(x).a) or (2) MAC_a(x) = MD5(a.x.a) Phil seems to say that the current proposal is (1), whereas [AH] says that it is (2); I believe Phil's comment here is based on an earlier proposal. The general question of how to best design a (keyed-)MAC from a one-way hash function is still quite open, and under vigorous research. The paper [PO] provides some excellent discussion and analysis of the proposed methods (1) and (2), among others. I think that our understanding of this area is likely to improve significantly in the very near term. The best solution in the end is likely to be an approach one that is designed to be a keyed-MAC from the start. We are still at the early stages of understanding how to do this, but I think that efficient and workable proposals may arise very quickly from the crypto community, now that attention has been drawn to this issue. (I think Phil's recommendation 8 is an excellent goal; but it doesn't answer the question as to what one should do something immediately, or if one should do something immediately.) The best approach may be not to commit to a keyed-MAC function at this time, but rather to explicitly nominate a "straw-man" proposal that is obviously weak and which MUST clearly be replaced at a later date (but soon!) when we know a little more. The straw-man algorithm could be used in trial implementations for testing purposes, but would provide no real authentication. For example, choosing as a straw-man algorithm MD5 with NO key input would be such a straw-man algorithm. This can be used as a place-holder until there is a better consensus in the cryptographic community as to how to proceed with a (keyed-)MAC. I believe that such an approach is better than nominating one of the current proposals (e.g. (2) above) as a "straw-man", since there might then be too much pressure to leave it in place, even if it turned out to have significant deficiencies under further analysis (such as is begun with [PO].) Having an explicitly weak "straw-man standard" in place as an acknowledgement that we are not really sure yet of what we are doing will put intense pressure on the crypto community to get its act together on this matter quickly, and I would hope that within six to eighteen months a consensus will evolve (so this issue could be resolved during '96 at the latest). The current workings of the ipsec community have generally been outside the purview of much of the crypto community, although a few cryptographers have paid attention to ipsec issues and have contributed generously of their time. The straw-man proposal would provide a very high-profile challenge that there is a still a felt need for efficient, secure, keyed-MACs for standardization purposes. 2.9 "THE ENCRYPTION MECHANISM" [cf ROG 9] Phil suggests that "at this point, it may be irresponsible for any NEW proposal to specify DES in a mode of operation which is susceptible to 2**56 complexity key-exhaustion." I agree. The proposal to use triple-DES in a mode that is potentially compatible with single-DES (due originally, I believe, to Walt Tuchman), can satisfy those users who want the efficiency (and security) of single-DES. (I agree with Phil's recommendation number 9.) Phil also criticizes the proposal for lack of specificity in describing how the DES-CBC is to be performed. I think that his comments here are well-motivated. (I agree with Phil's recommendation number 10, although I think that this is a minor point.) 3. ADDITONAL COMMENTS AND DISCUSSION I give here some additional comments, in no particular order. Some of these may reflect real concern about the security or feasibility of the proposed schemes, whereas others may merely reflect my misunderstanding of the proposal. Some of these comments may repeat themes already addressed above. 3.1 KEY DISTRIBUTION / KEY AGREEMENT These proposals are incomplete and essentially unusable without at least one specific proposal for non-manual key distribution or key agreement. While individual parties can clearly set up ad-hoc mechanism for key distribution or key agreement, the proposals studied here are not going to have any widespread deployment or utility until some standards for key distribution or key agreement are also available. While there is some discussion of this issue in [SA], there is nothing yet usable provided in terms of a proposal for a standard. I think that the current proposals should be held in abeyance (and worked on) until a complete package including key distribution and/or key agreement is also ready for consideration; I see little harm, and much potential good, in doing so. 3.2 LACK OF SPECIFICITY OR CLARITY There are many places where the proposals are insufficiently clear about what is intended, so much so that an implementor can not proceed. Here is a small list of items I noticed. (This is not intended to be comprehensive.) [SA] p 6: "SHOULD let that SPI become stale..." (when is an SPI stale?) [AH] (page 6) It is recommended here and in other places [e.g. AHMD p. 1] to use "pseudo-random" values (here for the SPI, in AHMD for the authentication key). How is a user to pick a "pseudo-random" value? Are counters suitable for the SPI? Is a linear-congruential generator suitable? (page 7-8) "This requirement is placed in order to allow for future IP optional headers which the receiver might not know about but the sender necessarily knows about if it is including such options in the packet." (I have no idea what this means.) [AHMD] [ESP] (page 6) "If strict red/black separation is being enforced..." (This term needs a reference or a definition.) (page 7) "If no key exists for this session or the attempt to decrypt fails," It is not clear what it means for the decryption to fail. The authors seem to imply that the it means that the next layer of protocol has a problem with the decrypted text, which is, in my opinion, a poor choice. I think that the only reason decryption should "fail" is that decryption is impossible (e.g. the ciphertext is not a multiple of the cipher block size). Authentication failure should be used to detect all other problems. (page 8) If user-oriented keying is not in use..." This paragraph makes no sense to me. It should be elaborated. What is the attack that is being prevented here? [ESPDES] (page 3) "The session key SHOULD be changed at least as frequently as every 2**32 datagrams." What is the justification for this condition? What attack is being prevented here? (page 3) "This field is considered to be transparent, though most users will not be able to make sense of its contents." This sentence pretends to be transparent, but this reader could not make sense of its contents. 3.3 HOST-ORIENTED vs USER-ORIENTED KEYING In [SA, section 4.4] it is stated that "support for user-oriented keying SHOULD be present in all IP implementations". Since "users" as such are not named principals at the IP protocol level, we are getting into strange territory here. It is not clear what "support for user-oriented keying" means. Does this merely mean that each user can be associated with a separate SPI, or does it mean that the host system must support secure multi-user processing somehow (e.g., so one user can not read another user's key by probing memory addresses assigned to the other user)? If I send encrypted traffice to an SPI that is associated with a particular user, what am I guaranteed about the security of that traffic from other users on the same host as the receiver? If nothing is guaranteed, why have this feature? The entire discussion on user-oriented keying seems confused (or at least confusing). This capability ought to be more carefully described, or dropped. I'm tempted to recommend just dropping it. More broadly, these documents need to have a clearer philosophical position as to what their goals are. In particular, these documents should make it clear how what they are doing differs from security protocols that work at higher layers of the protocol stack. It would seem sensible to think that a protocol at this IP layer should ONLY worry about security between hosts, and let protocols at higher layers take care of security between end-users or their applications. Bringing in users and userids to this protocol risks great confusion and muddled systems. 3.4 USE OF MD5 The language in [AH, section 4] says "If a block-oriented authentication algorithm (e.g. MD5 or MD4) is in use and the IP packet is not an integral number of blocks, the authentication data calculation is performed using zero bytes at the end to pad the length out to an integral number of blocks [Riv92]." This is VERY confused, since MD5 (and MD4) are byte-oriented algorithms that are specified to normally take variable-length byte-strings as input. It is not necessary (and may even be dangerous) for the user to supply his own padding! 3.5 AUDIT LOGS In [AH, page 9] and other places, it is stated that the system "MUST record the authentication failure in the system log or audit log." Given the rate at which bad packets can be delivered to a system by a malicious adversary, it may not be too hard for the adversary to fill up the disk of a complying implementation with the audit log. I think the "MUST" should be downgraded to "SHOULD". 4. CONCLUSIONS I feel that the proposed protocols are not sufficiently worked out to allow proceedings with them as a proposed standard. Ronald L. Rivest Room 324 545 Technology Square Cambridge, MA 02139 617-646-0504 http://theory.lcs.mit.edu/~rivest rivest@theory.lcs.mit.edu