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/rfc2451.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 doc/rfc/rfc2451.txt (limited to 'doc/rfc/rfc2451.txt') diff --git a/doc/rfc/rfc2451.txt b/doc/rfc/rfc2451.txt new file mode 100644 index 0000000..7d1b0ed --- /dev/null +++ b/doc/rfc/rfc2451.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group R. Pereira +Request for Comments: 2451 TimeStep Corporation +Category: Standards Track R. Adams + Cisco Systems Inc. + November 1998 + + + The ESP CBC-Mode Cipher Algorithms + +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. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +Abstract + + This document describes how to use CBC-mode cipher algorithms with + the IPSec ESP (Encapsulating Security Payload) Protocol. It not only + clearly states how to use certain cipher algorithms, but also how to + use all CBC-mode cipher algorithms. + +Table of Contents + + 1. Introduction...................................................2 + 1.1 Specification of Requirements...............................2 + 1.2 Intellectual Property Rights Statement......................2 + 2. Cipher Algorithms..............................................2 + 2.1 Mode........................................................3 + 2.2 Key Size....................................................3 + 2.3 Weak Keys...................................................4 + 2.4 Block Size and Padding......................................5 + 2.5 Rounds......................................................6 + 2.6 Backgrounds.................................................6 + 2.7 Performance.................................................8 + 3. ESP Payload....................................................8 + 3.1 ESP Environmental Considerations............................9 + 3.2 Keying Material.............................................9 + 4. Security Considerations........................................9 + 5. References....................................................10 + 6. Acknowledgments...............................................11 + 7. Editors' Addresses............................................12 + + + +Pereira & Adams Standards Track [Page 1] + +RFC 2451 ESP CBC-Mode Cipher Algorithms November 1998 + + + 8. Full Copyright Statement......................................14 + +1. Introduction + + The Encapsulating Security Payload (ESP) [Kent98] provides + confidentiality for IP datagrams by encrypting the payload data to be + protected. This specification describes the ESP use of CBC-mode + cipher algorithms. + + While this document does not describe the use of the default cipher + algorithm DES, the reader should be familiar with that document. + [Madson98] + + It is assumed that the reader is familiar with the terms and concepts + described in the "Security Architecture for the Internet Protocol" + [Atkinson95], "IP Security Document Roadmap" [Thayer97], and "IP + Encapsulating Security Payload (ESP)" [Kent98] documents. + + Furthermore, this document is a companion to [Kent98] and MUST be + read in its context. + +1.1 Specification of Requirements + + The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", + and "MAY" that appear in this document are to be interpreted as + described in [Bradner97]. + +1.2 Intellectual Property Rights Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementers or users of this specification can + be obtained from the IETF Secretariat. + +2. Cipher Algorithms + + All symmetric block cipher algorithms share common characteristics + and variables. These include mode, key size, weak keys, block size, + and rounds. All of which will be explained below. + + + +Pereira & Adams Standards Track [Page 2] + +RFC 2451 ESP CBC-Mode Cipher Algorithms November 1998 + + + While this document illustrates certain cipher algorithms such as + Blowfish [Schneier93], CAST-128 [Adams97], 3DES, IDEA [Lai] [MOV], + and RC5 [Baldwin96], any other block cipher algorithm may be used + with ESP if all of the variables described within this document are + clearly defined. + +2.1 Mode + + All symmetric block cipher algorithms described or insinuated within + this document use Cipher Block Chaining (CBC) mode. This mode + requires an Initialization Vector (IV) that is the same size as the + block size. Use of a randomly generated IV prevents generation of + identical ciphertext from packets which have identical data that + spans the first block of the cipher algorithm's blocksize. + + The IV is XOR'd with the first plaintext block, before it is + encrypted. Then for successive blocks, the previous ciphertext block + is XOR'd with the current plaintext, before it is encrypted. + + More information on CBC mode can be obtained in [Schneier95]. + +2.2 Key Size + + Some cipher algorithms allow for variable sized keys, while others + only allow a specific key size. The length of the key correlates + with the strength of that algorithm, thus larger keys are always + harder to break than shorter ones. + + This document stipulates that all key sizes MUST be a multiple of 8 + bits. + + This document does specify the default key size for each cipher + algorithm. This size was chosen by consulting experts on the + algorithm and by balancing strength of the algorithm with + performance. + + + + + + + + + + + + + + + + +Pereira & Adams Standards Track [Page 3] + +RFC 2451 ESP CBC-Mode Cipher Algorithms November 1998 + + + +==============+==================+=================+==========+ + | Algorithm | Key Sizes (bits) | Popular Sizes | Default | + +==============+==================+=================+==========+ + | CAST-128 [1] | 40 to 128 | 40, 64, 80, 128 | 128 | + +--------------+------------------+-----------------+----------+ + | RC5 | 40 to 2040 | 40, 128, 160 | 128 | + +--------------+------------------+-----------------+----------+ + | IDEA | 128 | 128 | 128 | + +--------------+------------------+-----------------+----------+ + | Blowfish | 40 to 448 | 128 | 128 | + +--------------+------------------+-----------------+----------+ + | 3DES [2] | 192 | 192 | 192 | + +--------------+------------------+-----------------+----------+ + + Notes: + + [1] With CAST-128, keys less than 128 bits MUST be padded with zeros + in the rightmost, or least significant, positions out to 128 bits + since the CAST-128 key schedule assumes an input key of 128 bits. + Thus if you had a key with a size of 80 bits '3B5D831CFE', it would + be padded to produce a key with a size of 128 bits + '3B5D831CFE000000'. + + [2] The first 3DES key is taken from the first 64 bits, the second + from the next 64 bits, and the third from the last 64 bits. + Implementations MUST take into consideration the parity bits when + initially accepting a new set of keys. Each of the three keys is + really 56 bits in length with the extra 8 bits used for parity. + + The reader should note that the minimum key size for all of the above + cipher algorithms is 40 bits, and that the authors strongly advise + that implementations do NOT use key sizes smaller than 40 bits. + +2.3 Weak Keys + + Weak key checks SHOULD be performed. If such a key is found, the key + SHOULD be rejected and a new SA requested. Some cipher algorithms + have weak keys or keys that MUST not be used due to their weak + nature. + + New weak keys might be discovered, so this document does not in any + way contain all possible weak keys for these ciphers. Please check + with other sources of cryptography such as [MOV] and [Schneier] for + further weak keys. + + CAST-128: + + No known weak keys. + + + +Pereira & Adams Standards Track [Page 4] + +RFC 2451 ESP CBC-Mode Cipher Algorithms November 1998 + + + RC5: + + No known weak keys when used with 16 rounds. + + + IDEA: + + IDEA has been found to have weak keys. Please check with [MOV] and + [Schneier] for more information. + + + Blowfish: + + Weak keys for Blowfish have been discovered. Weak keys are keys that + produce the identical entries in a given S-box. Unfortunately, there + is no way to test for weak keys before the S- box values are + generated. However, the chances of randomly generating such a key + are small. + + + 3DES: + + DES has 64 known weak keys, including so-called semi-weak keys and + possibly-weak keys [Schneier95, pp 280-282]. The likelihood of + picking one at random is negligible. + + For DES-EDE3, there is no known need to reject weak or + complementation keys. Any weakness is obviated by the use of + multiple keys. + + However, if the first two or last two independent 64-bit keys are + equal (k1 == k2 or k2 == k3), then the 3DES operation is simply the + same as DES. Implementers MUST reject keys that exhibit this + property. + +2.4 Block Size and Padding + + All of the algorithms described in this document use a block size of + eight octets (64 bits). + + Padding is used to align the payload type and pad length octets as + specified in [Kent98]. Padding must be sufficient to align the data + to be encrypted to an eight octet (64 bit) boundary. + + + + + + + + +Pereira & Adams Standards Track [Page 5] + +RFC 2451 ESP CBC-Mode Cipher Algorithms November 1998 + + +2.5 Rounds + + This variable determines how many times a block is encrypted. While + this variable MAY be negotiated, a default value MUST always exist + when it is not negotiated. + + +====================+============+======================+ + | Algorithm | Negotiable | Default Rounds | + +====================+============+======================+ + | CAST-128 | No | key<=80 bits, 12 | + | | | key>80 bits, 16 | + +--------------------+------------+----------------------+ + | RC5 | No | 16 | + +--------------------+------------+----------------------+ + | IDEA | No | 8 | + +--------------------+------------+----------------------+ + | Blowfish | No | 16 | + +--------------------+------------+----------------------+ + | 3DES | No | 48 (16x3) | + +--------------------+------------+----------------------+ + +2.6 Backgrounds + + CAST-128: + + The CAST design procedure was originally developed by Carlisle Adams + and Stafford Tavares at Queen's University, Kingston, Ontario, + Canada. Subsequent enhancements have been made over the years by + Carlisle Adams and Michael Wiener of Entrust Technologies. CAST-128 + is the result of applying the CAST Design Procedure as outlined in + [Adams97]. + + + RC5: + + The RC5 encryption algorithm was developed by Ron Rivest for RSA Data + Security Inc. in order to address the need for a high- performance + software and hardware ciphering alternative to DES. It is patented + (pat.no. 5,724,428). A description of RC5 may be found in [MOV] and + [Schneier]. + + + IDEA: + + Xuejia Lai and James Massey developed the IDEA (International Data + Encryption Algorithm) algorithm. The algorithm is described in + detail in [Lai], [Schneier] and [MOV]. + + + + +Pereira & Adams Standards Track [Page 6] + +RFC 2451 ESP CBC-Mode Cipher Algorithms November 1998 + + + The IDEA algorithm is patented in Europe and in the United States + with patent application pending in Japan. Licenses are required for + commercial uses of IDEA. + + For patent and licensing information, contact: + + Ascom Systec AG, Dept. CMVV + Gewerbepark, CH-5506 + Magenwil, Switzerland + Phone: +41 64 56 59 83 + Fax: +41 64 56 59 90 + idea@ascom.ch + http://www.ascom.ch/Web/systec/policy/normal/exhibit1.html + + Blowfish: + + Bruce Schneier of Counterpane Systems developed the Blowfish block + cipher algorithm. The algorithm is described in detail in + [Schneier93], [Schneier95] and [Schneier]. + + 3DES: + + This DES variant, colloquially known as "Triple DES" or as DES-EDE3, + processes each block three times, each time with a different key. + This technique of using more than one DES operation was proposed in + [Tuchman79]. + + P1 P2 Pi + | | | + IV->->(X) +>->->->(X) +>->->->(X) + v ^ v ^ v + +-----+ ^ +-----+ ^ +-----+ + k1->| E | ^ k1->| E | ^ k1->| E | + +-----+ ^ +-----+ ^ +-----+ + | ^ | ^ | + v ^ v ^ v + +-----+ ^ +-----+ ^ +-----+ + k2->| D | ^ k2->| D | ^ k2->| D | + +-----+ ^ +-----+ ^ +-----+ + | ^ | ^ | + v ^ v ^ v + +-----+ ^ +-----+ ^ +-----+ + k3->| E | ^ k3->| E | ^ k3->| E | + +-----+ ^ +-----+ ^ +-----+ + | ^ | ^ | + +>->->+ +>->->+ +>->-> + | | | + C1 C2 Ci + + + +Pereira & Adams Standards Track [Page 7] + +RFC 2451 ESP CBC-Mode Cipher Algorithms November 1998 + + + The DES-EDE3-CBC algorithm is a simple variant of the DES-CBC + algorithm [FIPS-46]. The "outer" chaining technique is used. + + In DES-EDE3-CBC, an Initialization Vector (IV) is XOR'd with the + first 64-bit (8 byte) plaintext block (P1). The keyed DES function + is iterated three times, an encryption (Ek1) followed by a decryption + (Dk2) followed by an encryption (Ek3), and generates the ciphertext + (C1) for the block. Each iteration uses an independent key: k1, k2 + and k3. + + For successive blocks, the previous ciphertext block is XOR'd with + the current plaintext (Pi). The keyed DES-EDE3 encryption function + generates the ciphertext (Ci) for that block. + + To decrypt, the order of the functions is reversed: decrypt with k3, + encrypt with k2, decrypt with k1, and XOR the previous ciphertext + block. + + Note that when all three keys (k1, k2 and k3) are the same, DES- + EDE3-CBC is equivalent to DES-CBC. This property allows the DES-EDE3 + hardware implementations to operate in DES mode without modification. + + For more explanation and implementation information for Triple DES, + see [Schneier95]. + +2.7 Performance + + For a comparison table of the estimated speed of any of these and + other cipher algorithms, please see [Schneier97] or for an up-to-date + performance comparison, please see [Bosseleaers]. + +3. ESP Payload + + The ESP payload is made up of the IV followed by raw cipher-text. + Thus the payload field, as defined in [Kent98], is broken down + according to the following diagram: + + +---------------+---------------+---------------+---------------+ + | | + + Initialization Vector (8 octets) + + | | + +---------------+---------------+---------------+---------------+ + | | + ~ Encrypted Payload (variable length) ~ + | | + +---------------------------------------------------------------+ + 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 + + + + +Pereira & Adams Standards Track [Page 8] + +RFC 2451 ESP CBC-Mode Cipher Algorithms November 1998 + + + The IV field MUST be same size as the block size of the cipher + algorithm being used. The IV MUST be chosen at random. Common + practice is to use random data for the first IV and the last block of + encrypted data from an encryption process as the IV for the next + encryption process. + + Including the IV in each datagram ensures that decryption of each + received datagram can be performed, even when some datagrams are + dropped, or datagrams are re-ordered in transit. + + To avoid ECB encryption of very similar plaintext blocks in different + packets, implementations MUST NOT use a counter or other low-Hamming + distance source for IVs. + +3.1 ESP Environmental Considerations + + Currently, there are no known issues regarding interactions between + these algorithms and other aspects of ESP, such as use of certain + authentication schemes. + +3.2 Keying Material + + The minimum number of bits sent from the key exchange protocol to + this ESP algorithm must be greater or equal to the key size. + + The cipher's encryption and decryption key is taken from the first + bits of the keying material, where represents the required + key size. + +4. Security Considerations + + Implementations are encouraged to use the largest key sizes they can + when taking into account performance considerations for their + particular hardware and software configuration. Note that encryption + necessarily impacts both sides of a secure channel, so such + consideration must take into account not only the client side, but + the server as well. + + For information on the case for using random values please see + [Bell97]. + + For further security considerations, the reader is encouraged to read + the documents that describe the actual cipher algorithms. + + + + + + + + +Pereira & Adams Standards Track [Page 9] + +RFC 2451 ESP CBC-Mode Cipher Algorithms November 1998 + + +5. References + + [Adams97] Adams, C, "The CAST-128 Encryption Algorithm", + RFC2144, 1997. + + [Atkinson98]Kent, S. and R. Atkinson, "Security Architecture for the + Internet Protocol", RFC 2401, November 1998. + + [Baldwin96] Baldwin, R. and R. Rivest, "The RC5, RC5-CBC, RC5-CBC- + Pad, and RC5-CTS Algorithms", RFC 2040, October 1996. + + [Bell97] S. Bellovin, "Probable Plaintext Cryptanalysis of the IP + Security Protocols", Proceedings of the Symposium on + Network and Distributed System Security, San Diego, CA, + pp. 155-160, February 1997 (also + http://www.research.att.com/~smb/probtxt.{ps, pdf}). + + [Bosselaers]A. Bosselaers, "Performance of Pentium implementations", + http://www.esat.kuleuven.ac.be/~bosselae/ + + [Bradner97] Bradner, S., "Key words for use in RFCs to indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [Crypto93] J. Daemen, R. Govaerts, J. Vandewalle, "Weak Keys for + IDEA", Advances in Cryptology, CRYPTO 93 Proceedings, + Springer-Verlag, pp. 224-230. + + [FIPS-46] US National Bureau of Standards, "Data Encryption + Standard", Federal Information Processing Standard (FIPS) + Publication 46, January 1977. + + [Kent98] Kent, S. and R. Atkinson, "IP Encapsulating Security + Payload (ESP)", RFC 2406, November 1998. + + [Lai] X. Lai, "On the Design and Security of Block Ciphers", + ETH Series in Information Processing, v. 1, Konstanz: + Hartung-Gorre Verlag, 1992. + + [Madson98] Madson, C. and N. Dorswamy, "The ESP DES-CBC Cipher + Algorithm With Explicit IV", RFC 2405, November 1998. + + [MOV] A. Menezes, P. Van Oorschot, S. Vanstone, "Handbook of + Applied Cryptography", CRC Press, 1997. ISBN 0-8493- + 8523-7 + + [Schneier] B. Schneier, "Applied Cryptography Second Edition", John + Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7 + + + + +Pereira & Adams Standards Track [Page 10] + +RFC 2451 ESP CBC-Mode Cipher Algorithms November 1998 + + + [Schneier93]B. Schneier, "Description of a New Variable-Length Key, + 64-Bit Block Cipher", from "Fast Software Encryption, + Cambridge Security Workshop Proceedings", Springer- + Verlag, 1994, pp. 191-204. + http://www.counterpane.com/bfsverlag.html + + [Schneier95]B. Schneier, "The Blowfish Encryption Algorithm - One + Year Later", Dr. Dobb's Journal, September 1995, + http://www.counterpane.com/bfdobsoyl.html + + [Schneier97]B. Scheier, "Speed Comparisons of Block Ciphers on a + Pentium." February 1997, + http://www.counterpane.com/speed.html + + [Thayer97] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security + Document Roadmap", RFC 2411, November 1998. + + [Tuchman79] Tuchman, W, "Hellman Presents No Shortcut Solutions to + DES", IEEE Spectrum, v. 16 n. 7, July 1979, pp. 40-41. + +6. Acknowledgments + + This document is a merger of most of the ESP cipher algorithm + documents. This merger was done to facilitate greater understanding + of the commonality of all of the ESP algorithms and to further the + development of these algorithm within ESP. + + The content of this document is based on suggestions originally from + Stephen Kent and subsequent discussions from the IPSec mailing list + as well as other IPSec documents. + + Special thanks to Carlisle Adams and Paul Van Oorschot both of + Entrust Technologies who provided input and review of CAST. + + Thanks to all of the editors of the previous ESP 3DES documents; W. + Simpson, N. Doraswamy, P. Metzger, and P. Karn. + + Thanks to Brett Howard from TimeStep for his original work of ESP- + RC5. + + Thanks to Markku-Juhani Saarinen, Helger Lipmaa and Bart Preneel for + their input on IDEA and other ciphers. + + + + + + + + + +Pereira & Adams Standards Track [Page 11] + +RFC 2451 ESP CBC-Mode Cipher Algorithms November 1998 + + +7. Editors' Addresses + + Roy Pereira + TimeStep Corporation + + Phone: +1 (613) 599-3610 x 4808 + EMail: rpereira@timestep.com + + + Rob Adams + Cisco Systems Inc. + + Phone: +1 (408) 457-5397 + EMail: adams@cisco.com + + + Contributors: + + Robert W. Baldwin + RSA Data Security, Inc. + + Phone: +1 (415) 595-8782 + EMail: baldwin@rsa.com or baldwin@lcs.mit.edu + + + Greg Carter + Entrust Technologies + + Phone: +1 (613) 763-1358 + EMail: carterg@entrust.com + + + Rodney Thayer + Sable Technology Corporation + + Phone: +1 (617) 332-7292 + EMail: rodney@sabletech.com + + + + + + + + + + + + + + +Pereira & Adams Standards Track [Page 12] + +RFC 2451 ESP CBC-Mode Cipher Algorithms November 1998 + + + The IPSec working group can be contacted via the IPSec working + group's mailing list (ipsec@tis.com) or through its chairs: + + Robert Moskowitz + International Computer Security Association + + EMail: rgm@icsa.net + + + Theodore Y. Ts'o + Massachusetts Institute of Technology + + EMail: tytso@MIT.EDU + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Pereira & Adams Standards Track [Page 13] + +RFC 2451 ESP CBC-Mode Cipher Algorithms November 1998 + + +8. Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Pereira & Adams Standards Track [Page 14] + -- cgit v1.2.3