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/rfc1851.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc1851.txt (limited to 'doc/rfc/rfc1851.txt') diff --git a/doc/rfc/rfc1851.txt b/doc/rfc/rfc1851.txt new file mode 100644 index 0000000..65981e6 --- /dev/null +++ b/doc/rfc/rfc1851.txt @@ -0,0 +1,619 @@ + + + + + + +Network Working Group P. Karn +Request for Comments: 1851 Qualcomm +Category: Experimental P. Metzger + Piermont + W. Simpson + Daydreamer + September 1995 + + + The ESP Triple DES Transform + + +Status of this Memo + + This document defines an Experimental Protocol for the Internet + community. This does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + + +Abstract + + This document describes the Triple DES-CBC security transform for the + IP Encapsulating Security Payload (ESP). + + +Table of Contents + + 1. Introduction .......................................... 2 + 1.1 Keys ............................................ 2 + 1.2 Initialization Vector ........................... 2 + 1.3 Data Size ....................................... 3 + 1.4 Performance ..................................... 3 + + 2. Payload Format ........................................ 4 + + 3. Algorithm ............................................. 6 + 3.1 Encryption ...................................... 6 + 3.2 Decryption ...................................... 7 + + SECURITY CONSIDERATIONS ...................................... 7 + ACKNOWLEDGEMENTS ............................................. 8 + REFERENCES ................................................... 9 + AUTHOR'S ADDRESS ............................................. 11 + + + + + + + +Karn, et al Experimental [Page 1] + +RFC 1851 ESP 3DES September 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 a variant of + of the Cipher Block Chaining (CBC) mode of the US Data Encryption + Standard (DES) algorithm [FIPS-46, FIPS-46-1, FIPS-74, FIPS-81]. + This variant, known as Triple DES (3DES), processes each block of the + plaintext three times, each time with a different key [Tuchman79]. + + 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 3DES key shared between the communicating parties is + effectively 168-bits long. This key consists of three independent + 56-bit quantities used by the DES algorithm. Each of the three 56- + bit subkeys 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 3DES 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, et al Experimental [Page 2] + +RFC 1851 ESP 3DES September 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 3DES 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 + + Three DES-CBC implementations may be pipelined in series to provide + parallel computation. At the time of writing, at least one hardware + implementation can encrypt or decrypt at about 1 Gbps [Schneier94, p. + 231]. + + + + + + + + + + + + + + + + + + + + + + + + +Karn, et al Experimental [Page 3] + +RFC 1851 ESP 3DES September 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 3DES 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, et al Experimental [Page 4] + +RFC 1851 ESP 3DES September 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, et al Experimental [Page 5] + +RFC 1851 ESP 3DES September 1995 + + +3. Algorithm + + The 3DES algorithm is a simple variant on the DES-CBC algorithm. The + DES function is replaced by three rounds of that function, an + encryption followed by a decryption followed by an encryption, each + with independant keys, k1, k2 and k3. + + Note that when all three keys (k1, k2 and k3) are the same, 3DES is + equivalent to DES-CBC. This property allows the 3DES hardware + implementations to operate in DES mode without modification. + + For more explanation and implementation information for Triple 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 Triple DES (EDE 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. + + + + + + +Karn, et al Experimental [Page 6] + +RFC 1851 ESP 3DES September 1995 + + +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 + 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 Triple DES (DED + 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 Triple + 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 for any of the three DES rounds, although the odds + of picking one at random are low [Schneier94, p. 233]. + + It was originally thought that DES might be a group, but it has been + demonstrated that it is not [CW92]. Since DES is not a group, + composition of multiple rounds of DES is not equivalent to simply + using DES with a different key. + + Triple DES with independent keys is not, as naively might be + expected, as difficult to break by brute force as a cryptosystem with + three times the keylength. A space/time tradeoff has been shown + which can brute-force break triple block encryptions in the time + + + +Karn, et al Experimental [Page 7] + +RFC 1851 ESP 3DES September 1995 + + + naively expected for double encryption [MH81]. + + However, 2DES can be broken with a meet-in-the-middle attack, without + significantly more complexity than breaking DES requires [ibid], so + 3DES with independant keys is actually needed to provide this level + of security. An attack on 3DES using two independent keys that is + somewhat (sixteen times) faster than any known for independent keys + has been shown [OW91]. + + 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]. + + Although it is widely believed that 3DES is substantially stronger + than DES, as it is less amenable to brute force attack, it should be + noted that real cryptanalysis of 3DES might not use brute force + methods at all. Instead, it might be performed using variants on + differential [BS93] or linear [Matsui94] cryptanalysis. It should + also be noted that no encryption algorithm is permanently safe from + brute force attack, because of the increasing speed of modern + computers. + + As with all cryptosystems, those responsible for applications with + substantial risk when security is breeched should pay close attention + to developments in cryptography, and especially cryptanalysis, and + switch to other transforms should 3DES prove weak. + + + +Acknowledgements + + Some of the text of this specification was derived from work by + Randall Atkinson for the SIP, SIPP, and IPv6 Working Groups. + + Comments should be submitted to the ipsec@ans.net mailing list. + + + + + + + + +Karn, et al Experimental [Page 8] + +RFC 1851 ESP 3DES September 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. + + [CW92] Campbell, K.W., and Wiener, M.J., "Proof that DES Is Not a + Group", Advances in Cryptology -- Crypto '92 Proceedings, + Berlin: Springer-Verlag, 1993, pp 518-526. + + [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. + + [MH81] Merle, R.C., and Hellman, M., "On the Security of Multiple + Encryption", Communications of the ACM, v. 24 n. 7, 1981, + pp. 465-467. + + + + +Karn, et al Experimental [Page 9] + +RFC 1851 ESP 3DES September 1995 + + + [OW91] van Oorschot, P.C., and Weiner, M.J. "A Known-Plaintext + Attack on Two-Key Triple Encryption", Advances in Cryptology + -- Eurocrypt '90 Proceedings, Berlin: Springer-Verlag, 1991, + pp. 318-325. + + [RFC-1800] + Postel, J., "Internet Official Protocol Standards", STD 1, + RFC 1800, USC/Information Sciences Institute, July 1995. + + [RFC-1700] + Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC + 1700, USC/Information Sciences Institute, October 1994. + + [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 + + [Tuchman79] + Tuchman, W, "Hellman Presents No Shortcut Solutions to DES", + IEEE Spectrum, v. 16 n. 7, July 1979, pp. 40-41. + + + + + + + + + + + + + + + + + + + +Karn, et al Experimental [Page 10] + +RFC 1851 ESP 3DES September 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, et al Experimental [Page 11] + -- cgit v1.2.3