Network Working Group P Metzger Internet Draft W A Simpson expires in six months January 1995 The ESP DES-CBC Transform draft-metzger-esp-des-cbc-01.txt | Status of this Memo This document is a submission to the IP Security Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ipsec@ans.net mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on: ftp.is.co.za (Africa) | nic.nordu.net (Europe) ds.internic.net (US East Coast) | ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Abstract This document describes the DES-CBC security transform for the Encapsulating Security Payload (ESP). Troublemakers expires in six months [Page 1] DRAFT ESP DES-CBC January 1995 1. Introduction The Encapsulating Security Payload (ESP) [RAesp] 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]. A recent book also provides | information on DES [Schneier94]. All implementations that claim conformance or compliance with the | Encapsulating Security Payload specification MUST implement this | DES-CBC transform. Implementors should consult the most recent version of the IAB | Standards [RFC-1610] for further guidance on the status of this | document. 1.1. Keys The secret DES key shared between the communicating parties is 64 bits long. This key consists of a 56-bit quantity used by the DES algorithm, and 8 parity bits arranged such that one parity bit is the least significant bit of each octet. 1.2. Initialization Vector This mode of DES requires an Initialization Vector (IV) that is 8 octets in length. Each datagram contains its own DES IV. Including the IV in each datagram ensures that decryption of each received datagram can be performed, even when other datagrams are dropped, or datagrams are re-ordered in transit. The method for selection of the IV values is implementation dependent. Note: A common technique is simply a counter, beginning with a randomly chosen value. Other implementations also exhibit unpredictability, usually through a pseudo-random number generator. Care should be taken that the periodicity of the number generator is long enough to prevent repetition during the lifetime of the session key. Troublemakers expires in six months [Page 1] DRAFT ESP DES-CBC January 1995 1.3. Data Size The DES algorithm operates on blocks of 8 octets. This often requires padding after the end of the unencrypted payload data. Both input and output result in the same number of octets, which facilitates in-place encryption and decryption. On receipt, if the length of the data to be decrypted is not an integral multiple of 8 octets, then an error is indicated. The datagram is discarded, and an appropriate ICMP message is returned. The failure SHOULD be recorded in the system or audit log, including the cleartext values for the SAID, date/time, Source, Destination, and other identifying information. 1.4. Performance | At least one hardware implementation of DES-CBC can encrypt or | decrypt at about 1 Gbps [Schneier94, p. 231]. | 2. Payload Format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Association Identifier (SAID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Initialization Vector (IV) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Payload Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Padding | Pad Length | Data Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security Association Identifier (SAID) A 32-bit value identifying the Security Association for this datagram. If no Security Association has been established, the value of this field is zero. Troublemakers expires in six months [Page 2] DRAFT ESP DES-CBC January 1995 Initialization Vector The size of this field is variable, though for any given Security Association it has a particular known size. Its position and size is constant for all DES-CBC datagrams of the same SAID and IP Destination. This field is considered to be transparent, though most users will not be able to make sense of its contents. The field may be longer or shorter than the 64-bits used by DES, in multiples of 32-bits. This allows alignment of the Encrypted Data for in-place decryption. All conformant implementations MUST correctly process a 64-bit field size. When the size is negotiated to 0-bits, the IP fragment | Identification field is left justified within the 64-bit value. | The remaining bits of the IV are zeroed. If this option is used, | all such IP datagrams MUST carry non-zero Identification fields. | When the size is negotiated to 32-bits, the inverse of the 32-bits is appended to form a 64-bit value. When the size is negotiated to 96-bits or greater, the alignment of the 64-bit value within this field is negotiated by an | additional parameter. Unused octets are filled with unspecified | implementation dependent values, which are ignored on reciept. Payload Data The size of this field is variable. This field is opaque. Prior to encryption and after decryption, the contents of this field begins with an entire IP datagram (IP-Mode), or an IP Payload header (Transport-Mode). Padding The size of this field is variable. This field is opaque. Prior to encryption, it is filled with unspecified implementation dependent values. After decryption, it MUST be ignored. Troublemakers expires in six months [Page 3] DRAFT ESP DES-CBC January 1995 Pad Length This field indicates the size of the Padding field. It does not include the Pad Length and Data Type fields. The value typically ranges from 0 to 7, but may be up to 255 to permit hiding of the | actual data length. This field is opaque. That is, the value is set prior to encryption, and is examined only after decryption. Data Type This field indicates the contents of the Payload Data field, using the IP Protocol/Payload value. Up-to-date values of the IP Protocol/Payload are specified in the most recent "Assigned | Numbers" [RFC-1700]. This field is opaque. That is, the value is set prior to encryption, and is examined only after decryption. For example, when encrypting an entire IP datagram (IP-Mode), this field will contain the value 4, which indicates IP-in-IP encapsulation. 3. Calculation | 3.1. Encryption | Append zero or more octets of padding to the plain text, to make | its length in octets modulo 8 equal to 6. | Append a Pad Length octet containing the number of padding octets | just added. | Append a Data Type octet containing the IP Protocol/Payload value | which identifies the protocol header that begins the payload. | Encrypt the payload with DES in CBC mode, producing a cipher text of | the same length. | Octets are mapped to DES blocks according to a "big-endian" | convention; octet 0 (modulo 8) of the payload corresponds to bits 1-8 | of the 64-bit DES input block, while octet 7 (modulo 8) corresponds | to bits 57-64 of the DES input block. | Contruct a new IP datagram for that Destination, with the indicated | Troublemakers expires in six months [Page 4] DRAFT ESP DES-CBC January 1995 SAID, IV, and payload. | The Total Length in the IP Header reflects the length of the | encrypted data, plus the SAID, IV, padding, pad length, and data type | octets. | 3.2. Decryption | First, the SAID field is examined. This is used as an index into the | local Security Association table to find the encryption algorithm | identifier and decryption key. | The negotiated form of the IV determines the size of the IV field. | These octets are removed, and an appropriate 64-bit IV value is | constructed. | The encrypted part of the payload is decrypted using DES in the CBC | mode. | The Data Type is removed and examined. If it is unrecognized, the | payload is discarded with an appropriate ICMP message. | The Pad Length is removed and examined. The specified number of pad | octets are removed from the end of the decrypted payload, and the IP | Total Length is adjusted accordingly. | The IP Header(s) and the remaining portion of the decrypted payload | are passed to the protocol receive routine specified by the Data Type | field. | Security Considerations | Users need to understand that the quality of the security provided by | this specification depends completely on the strength of the DES | algorithm, the correctness of that algorithm's implementation, the security of the key management mechanism and its implementation, the | strength of the key [CN94], and upon the correctness of the | implementations in all of the participating systems. It is known that DES is an algorithm approaching the end of its useful lifetime. At the time of writing of this document, [BS93] | demonstrated a differential cryptanalysis based chosen-plaintext attack requiring 2^47 plaintext-ciphertext pairs, and [Matsui94] | demonstrated a linear cryptanalysis based known-plaintext attack Troublemakers expires in six months [Page 5] DRAFT ESP DES-CBC January 1995 requiring only 2^43 plaintext-ciphertext pairs. Although these attacks are not considered practical, they must be taken into account. More disturbingly, [Weiner94] has shown the design of a DES cracking | machine costing $1 Million that can crack one key every 3.5 hours. This is an extremely practical attack, and it is suggested that DES is not a good encryption algorithm for the protection of even moderate value in the face of such equipment. Triple DES is probably a better choice for such purposes. Acknowledgements The original text of this specification was derived from work by Ran Atkinson for the SIP, SIPP, and IPv6 Working Groups. The text on implementation practice was contributed by Phil Karn. | The use of DES for confidentiality is closely modeled on the work | done for SNMPv2 [RFC-1446]. References [BS93] Biham, E., and Shamir, A., "Differential Cryptanalysis of | the Data Encryption Standard", Berlin: Springer-Verlag, | 1993. | [CN94] Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak Data: | Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp. | 253-280, July 1994. | [Matsui94] | Matsui, M., "Linear Cryptanalysis method dor DES Cipher," | Advances in cryptology -- Eurocrypt '93 Proceedings, Berlin: | Springer-Verlag, 1994. | [FIPS-46] | US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46, January 1977. | [FIPS-46-1] | US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication Troublemakers expires in six months [Page 6] DRAFT ESP DES-CBC January 1995 46-1, January 1988. | [FIPS-74] | US National Bureau of Standards, "Guidelines for * Implementing and Using the Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 74, April 1981. | [FIPS-81] | US National Bureau of Standards, "DES Modes of Operation" | Federal Information Processing Standard (FIPS) Publication | 81, December 1980. | [RAesp] Randall Atkinson, Perry Metzger, William Simpson, | "Encapsulating Security Protocol (ESP)", work in progress. | [RFC-1446] | Galvin, J., and McCloghrie, K., "Security Protocols for | Version 2 of the Simple Network Management Protocol | (SNMPv2)", RFC-1446, DDN Network Information Center, April | 1993. | [RFC-1610] | Postel, J., "Internet Official Protocol Standards", STD 1, | RFC 1610, USC/Information Sciences Institute, July 1994. | [RFC-1700] | Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC | 1700, USC/Information Sciences Institute, October 1994. | [Schneier94] | Schneier, B., "Applied Cryptography", John Wiley & Sons, New York, NY, 1994. ISBN 0-471-59756-2 | [Weiner94] | Wiener, M.J., "Efficient DES Key Search", School of Computer Science, Carleton University, Ottawa, Canada, TR-244, May 1994. Presented at the Rump Session of Crypto '93. * Author's Address Questions about this memo can also be directed to: Randall Atkinson Information Technology Division Naval Research Laboratory Troublemakers expires in six months [Page 7] DRAFT ESP DES-CBC January 1995 Washington, DC 20375-5320 USA Telephone: (DSN) 354-8590 Fax: (DSN) 354-7942 Perry Metzger Piermont Information Systems Inc. 160 Cabrini Blvd., Suite #2 New York, NY 10033 perry@piermont.com William Allen Simpson Daydreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com Troublemakers expires in six months [Page 8] DRAFT ESP DES-CBC January 1995 Table of Contents 1. Introduction .......................................... 1 1.1 Keys ............................................ 1 1.2 Initialization Vector ........................... 1 1.3 Data Size ....................................... 2 1.4 Performance .....................................2 2. Payload Format ........................................ 2 3. Calculation ...........................................4 | 3.1 Encryption ......................................4 3.2 Decryption ......................................5 SECURITY CONSIDERATIONS ......................................5 ACKNOWLEDGEMENTS ............................................. 6 REFERENCES ................................................... 6 AUTHOR'S ADDRESS ............................................. 7