From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1829.txt | 608 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 608 insertions(+) create mode 100644 doc/rfc/rfc1829.txt (limited to 'doc/rfc/rfc1829.txt') diff --git a/doc/rfc/rfc1829.txt b/doc/rfc/rfc1829.txt new file mode 100644 index 0000000..dd039c2 --- /dev/null +++ b/doc/rfc/rfc1829.txt @@ -0,0 +1,608 @@ + + + + + + +Network Working Group P. Karn +Request for Comments: 1829 Qualcomm +Category: Standards Track P. Metzger + Piermont + W. Simpson + Daydreamer + August 1995 + + + The ESP DES-CBC Transform + + + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + + +Abstract + + This document describes the DES-CBC security transform for the IP + Encapsulating Security Payload (ESP). + + +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 ........................................ 3 + + 3. Algorithm ............................................. 5 + 3.1 Encryption ...................................... 5 + 3.2 Decryption ...................................... 5 + + SECURITY CONSIDERATIONS ...................................... 6 + ACKNOWLEDGEMENTS ............................................. 7 + REFERENCES ................................................... 8 + AUTHOR'S ADDRESS ............................................. 10 + + + + + +Karn, Metzger & Simpson Standards Track [Page i] + +RFC 1829 ESP DES-CBC August 1995 + + +1. Introduction + + The Encapsulating Security Payload (ESP) [RFC-1827] provides + confidentiality for IP datagrams by encrypting the payload 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]. + + All implementations that claim conformance or compliance with the + Encapsulating Security Payload specification MUST implement this + DES-CBC transform. + + This document assumes that the reader is familiar with the related + document "Security Architecture for the Internet Protocol" + [RFC-1825], which defines the overall security plan for IP, and + provides important background for this specification. + + + +1.1. Keys + + The secret DES key shared between the communicating parties is eight + octets in length. This key consists of a 56-bit quantity used by the + DES algorithm. The 56-bit key is stored as a 64-bit (eight octet) + quantity, with the least significant bit of each octet used as a + parity bit. + + + +1.2. Initialization Vector + + This mode of DES requires an Initialization Vector (IV) that is eight + octets in length. + + Each datagram contains its own 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 IV values is implementation dependent. + + Notes: + A common acceptable technique is simply a counter, beginning with + a randomly chosen value. While this provides an easy method for + preventing repetition, and is sufficiently robust for practical + use, cryptanalysis may use the rare serendipitous occurrence when + a corresponding bit position in the first DES block increments in + exactly the same fashion. + + +Karn, Metzger & Simpson Standards Track [Page 1] + +RFC 1829 ESP DES-CBC August 1995 + + + Other implementations 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. + + + +1.3. Data Size + + The DES algorithm operates on blocks of eight 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 eight octets, then an error is indicated, as + described in [RFC-1825]. + + + +1.4. Performance + + At the time of writing, at least one hardware implementation can + encrypt or decrypt at about 1 Gbps [Schneier94, p. 231]. + + + + + + + + + + + + + + + + + + + + + + + + + +Karn, Metzger & Simpson Standards Track [Page 2] + +RFC 1829 ESP DES-CBC August 1995 + + +2. Payload Format + + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Security Parameters Index (SPI) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Initialization Vector (IV) ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ Payload Data ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ... Padding | Pad Length | Payload Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Security Parameters Index (SPI) + + A 32-bit value identifying the Security Parameters for this + datagram. The value MUST NOT be zero. + + Initialization Vector (IV) + + The size of this field is variable, although it is constant for + all DES-CBC datagrams of the same SPI and IP Destination. Octets + are sent in network order (most significant octet first) + [RFC-1700]. + + The size MUST be a multiple of 32-bits. Sizes of 32 and 64 bits + are required to be supported. The use of other sizes is beyond + the scope of this specification. The size is expected to be + indicated by the key management mechanism. + + When the size is 32-bits, a 64-bit IV is formed from the 32-bit + value followed by (concatenated with) the bit-wise complement of + the 32-bit value. This field size is most common, as it aligns + the Payload Data for both 32-bit and 64-bit processing. + + All conformant implementations MUST also correctly process a + 64-bit field size. This provides strict compatibility with + existing hardware implementations. + + It is the intent that the value not repeat during the lifetime + of the encryption session key. Even when a full 64-bit IV is + used, the session key SHOULD be changed at least as frequently + as 2**32 datagrams. + + +Karn, Metzger & Simpson Standards Track [Page 3] + +RFC 1829 ESP DES-CBC August 1995 + + + Payload Data + + The size of this field is variable. + + Prior to encryption and after decryption, this field begins with + the IP Protocol/Payload header specified in the Payload Type + field. Note that in the case of IP-in-IP encapsulation (Payload + Type 4), this will be another IP header. + + Padding + + The size of this field is variable. + + Prior to encryption, it is filled with unspecified implementation + dependent (preferably random) values, to align the Pad Length and + Payload Type fields at an eight octet boundary. + + After decryption, it MUST be ignored. + + Pad Length + + This field indicates the size of the Padding field. It does not + include the Pad Length and Payload 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. + + Payload 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 (Tunnel- + Mode), this field will contain the value 4, which indicates + IP-in-IP encapsulation. + + + + + + + + +Karn, Metzger & Simpson Standards Track [Page 4] + +RFC 1829 ESP DES-CBC August 1995 + + +3. Algorithm + + In DES-CBC, the base DES encryption function is applied to the XOR of + each plaintext block with the previous ciphertext block to yield the + ciphertext for the current block. This provides for + re-synchronization when datagrams are lost. + + For more explanation and implementation information for DES, see + [Schneier94]. + + + +3.1. Encryption + + Append zero or more octets of (preferably random) padding to the + plaintext, to make its modulo 8 length equal to 6. For example, if + the plaintext length is 41, 5 octets of padding are added. + + Append a Pad Length octet containing the number of padding octets + just added. + + Append a Payload Type octet containing the IP Protocol/Payload value + which identifies the protocol header that begins the payload. + + Provide an Initialization Vector (IV) of the size indicated by the + SPI. + + Encrypt the payload with DES in CBC mode, producing a ciphertext of + the same length. + + Octets are mapped to DES blocks in network order (most significant + octet first) [RFC-1700]. 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. + + Construct an appropriate IP datagram for the target Destination, with + the indicated SPI, IV, and payload. + + The Total/Payload Length in the encapsulating IP Header reflects the + length of the encrypted data, plus the SPI, IV, padding, Pad Length, + and Payload Type octets. + + + +3.2. Decryption + + First, the SPI field is removed and examined. This is used as an + index into the local Security Parameter table to find the negotiated + + +Karn, Metzger & Simpson Standards Track [Page 5] + +RFC 1829 ESP DES-CBC August 1995 + + + parameters 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 Payload 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/Payload 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 Payload + 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 nodes. + + Among other considerations, applications may wish to take care not to + select weak keys, although the odds of picking one at random are low + [Schneier94, p 233]. + + The cut and paste attack described by [Bell95] exploits the nature of + all Cipher Block Chaining algorithms. When a block is damaged in + transmission, on decryption both it and the following block will be + garbled by the decryption process, but all subsequent blocks will be + decrypted correctly. If an attacker has legitimate access to the + same key, this feature can be used to insert or replay previously + encrypted data of other users of the same engine, revealing the + plaintext. The usual (ICMP, TCP, UDP) transport checksum can detect + this attack, but on its own is not considered cryptographically + strong. In this situation, user or connection oriented integrity + checking is needed [RFC-1826]. + + At the time of writing of this document, [BS93] demonstrated a + + +Karn, Metzger & Simpson Standards Track [Page 6] + +RFC 1829 ESP DES-CBC August 1995 + + + differential cryptanalysis based chosen-plaintext attack requiring + 2^47 plaintext-ciphertext pairs, and [Matsui94] demonstrated a linear + cryptanalysis based known-plaintext attack 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. + + One or two blocks of known plaintext suffice to recover a DES key. + Because IP datagrams typically begin with a block of known and/or + guessable header text, frequent key changes will not protect against + this attack. + + It is suggested that DES is not a good encryption algorithm for the + protection of even moderate value information in the face of such + equipment. Triple DES is probably a better choice for such purposes. + + However, despite these potential risks, the level of privacy provided + by use of ESP DES-CBC in the Internet environment is far greater than + sending the datagram as cleartext. + + + +Acknowledgements + + This document was reviewed by the IP Security Working Group of the + Internet Engineering Task Force (IETF). Comments should be submitted + to the ipsec@ans.net mailing list. + + Some of the text of this specification was derived from work by + Randall Atkinson for the SIP, SIPP, and IPv6 Working Groups. + + The use of DES for confidentiality is closely modeled on the work + done for SNMPv2 [RFC-1446]. + + Steve Bellovin, Steve Deering, Karl Fox, Charles Lynn, Craig Metz, + Dave Mihelcic and Jeffrey Schiller provided useful critiques of + earlier versions of this draft. + + + + + + + + + + +Karn, Metzger & Simpson Standards Track [Page 7] + +RFC 1829 ESP DES-CBC August 1995 + + +References + + [Bell95] Bellovin, S., "An Issue With DES-CBC When Used Without + Strong Integrity", Proceedings of the 32nd IETF, Danvers, + MA, April 1995. + + [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. + + [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 + 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. + + [Matsui94] + Matsui, M., "Linear Cryptanalysis method dor DES Cipher," + Advances in Cryptology -- Eurocrypt '93 Proceedings, Berlin: + Springer-Verlag, 1994. + + [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-1700] + Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, + +Karn, Metzger & Simpson Standards Track [Page 8] + +RFC 1829 ESP DES-CBC August 1995 + + + RFC-1700, USC/Information Sciences Institute, October 1994. + + [RFC-1800] + Postel, J., "Internet Official Protocol Standards", STD 1, + RFC-1800, USC/Information Sciences Institute, July 1995. + + [RFC-1825] + Atkinson, R., "Security Architecture for the Internet + Protocol", RFC-1825, Naval Research Laboratory, July 1995. + + [RFC-1826] + Atkinson, R., "IP Authentication Header", RFC-1826, Naval + Research Laboratory, July 1995. + + [RFC-1827] + Atkinson, R., "IP Encapsulating Security Protocol (ESP)", + RFC-1827, Naval Research Laboratory, July 1995. + + [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. + + + + + + + + + + + + + + + + + + + + + + + + +Karn, Metzger & Simpson Standards Track [Page 9] + +RFC 1829 ESP DES-CBC August 1995 + + +Author's Address + + Questions about this memo can also be directed to: + + Phil Karn + Qualcomm, Inc. + 6455 Lusk Blvd. + San Diego, California 92121-2779 + + karn@unix.ka9q.ampr.org + + + 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 + + + + + + + + + + + + + + + + + + + + + + +Karn, Metzger & Simpson Standards Track [Page 10] + \ No newline at end of file -- cgit v1.2.3