summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2405.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2405.txt')
-rw-r--r--doc/rfc/rfc2405.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc2405.txt b/doc/rfc/rfc2405.txt
new file mode 100644
index 0000000..d9109ab
--- /dev/null
+++ b/doc/rfc/rfc2405.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group C. Madson
+Request for Comments: 2405 Cisco Systems, Inc.
+Category: Standards Track N. Doraswamy
+ Bay Networks, Inc.
+ November 1998
+
+
+ The ESP DES-CBC Cipher Algorithm
+ With Explicit IV
+
+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 the use of the DES Cipher algorithm in Cipher
+ Block Chaining Mode, with an explicit IV, as a confidentiality
+ mechanism within the context of the IPSec Encapsulating Security
+ Payload (ESP).
+
+1. Introduction
+
+ This document describes the use of the DES Cipher algorithm in Cipher
+ Block Chaining Mode as a confidentiality mechanism within the context
+ of the Encapsulating Security Payload.
+
+ DES is a symmetric block cipher algorithm. The algorithm is described
+ in [FIPS-46-2][FIPS-74][FIPS-81]. [Schneier96] provides a general
+ description of Cipher Block Chaining Mode, a mode which is applicable
+ to several encryption algorithms.
+
+ As specified in this memo, DES-CBC is not an authentication
+ mechanism. [Although DES-MAC, described in [Schneier96] amongst other
+ places, does provide authentication, DES-MAC is not discussed here.]
+
+ For further information on how the various pieces of ESP fit together
+ to provide security services, refer to [ESP] and [road].
+
+
+
+
+
+Madson & Doraswamy Standards Track [Page 1]
+
+RFC 2405 The ESP DES-CBC Cipher Algorithm November 1998
+
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC-2119].
+
+2. Algorithm and Mode
+
+ DES-CBC is a symmetric secret-key block algorithm. It has a block
+ size of 64 bits.
+
+ [FIPS-46-2][FIPS-74] and [FIPS-81] describe the DES algorithm, while
+ [Schneier96] provides a good description of CBC mode.
+
+2.1 Performance
+
+ Phil Karn has tuned DES-CBC software to achieve 10.45 Mbps with a 90
+ MHz Pentium, scaling to 15.9 Mbps with a 133 MHz Pentium. Other DES
+ speed estimates may be found in [Schneier96].
+
+3. ESP Payload
+
+ DES-CBC requires an explicit Initialization Vector (IV) of 8 octets
+ (64 bits). This IV immediately precedes the protected (encrypted)
+ payload. The IV MUST be a random value.
+
+ 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.
+
+ Implementation note:
+
+ Common practice is to use random data for the first IV and the
+ last 8 octets of encrypted data from an encryption process as the
+ IV for the next encryption process; this logically extends the CBC
+ across the packets. It also has the advantage of limiting the
+ leakage of information from the random number genrator. No matter
+ which mechnism is used, the receiver MUST NOT assume any meaning
+ for this value, other than that it is an IV.
+
+ 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.
+
+ The payload field, as defined in [ESP], is broken down according to
+ the following diagram:
+
+
+
+
+
+
+
+Madson & Doraswamy Standards Track [Page 2]
+
+RFC 2405 The ESP DES-CBC Cipher Algorithm November 1998
+
+
+ +---------------+---------------+---------------+---------------+
+ | |
+ + Initialization Vector (IV) +
+ | |
+ +---------------+---------------+---------------+---------------+
+ | |
+ ~ 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
+
+3.1 Block Size and Padding
+
+ The DES-CBC algorithm described in this document MUST use a block
+ size of 8 octets (64 bits).
+
+ When padding is required, it MUST be done according to the
+ conventions specified in [ESP].
+
+4. Key Material
+
+ DES-CBC is a symmetric secret key algorithm. The key size is 64-bits.
+ [It is commonly known as a 56-bit key as the key has 56 significant
+ bits; the least significant bit in every byte is the parity bit.]
+
+ [arch] describes the general mechanism to derive keying material for
+ the ESP transform. The derivation of the key from some amount of
+ keying material does not differ between the manually- and
+ automatically-keyed security associations.
+
+ This mechanism MUST derive a 64-bit key value for use by this cipher.
+ The mechanism will derive raw key values, the derivation process
+ itself is not responsible for handling parity or weak key checks.
+
+ Weak key checks SHOULD be performed. If such a key is found, the key
+ SHOULD be rejected and a new SA requested.
+
+ Implementation note:
+
+ If an implementation chooses to do weak key checking, it should
+ recognize that the known weak keys [FIPS74] have been adjusted for
+ parity. Otherwise the handling of parity is a local issue.
+
+ A strong pseudo-random function MUST be used to generate the required
+ key. For a discussion on this topic, reference [RFC1750].
+
+
+
+
+
+
+Madson & Doraswamy Standards Track [Page 3]
+
+RFC 2405 The ESP DES-CBC Cipher Algorithm November 1998
+
+
+4.1 Weak Keys
+
+ DES has 16 known weak keys, including so-called semi-weak keys. The
+ list of weak keys can be found in [FIPS74].
+
+4.2 Key Lifetime
+
+ [Blaze96] discusses the costs and key recovery time for brute force
+ attacks. It presents various combinations of total cost/time to
+ recover a key/cost per key recovered for 40-bit and 56-bit DES keys,
+ based on late 1995 estimates.
+
+ While a brute force search of a 56-bit DES keyspace can be considered
+ infeasable for the so-called casual hacker, who is simply using spare
+ CPU cycles or other low-cost resources, it is within reach of someone
+ willing to spend a bit more money.
+
+ For example, for a cost of $300,000, a 56-bit DES key can be
+ recovered in an average of 19 days using off-the-shelf technology and
+ in only 3 hours using a custom developed chip.
+
+ It should be noted that there are other attacks which can recover the
+ key faster, that brute force attacks are considered the "worst case",
+ although the easiest to implement.
+
+ [Wiener94] also discusses a $1M machine which can break a DES key in
+ 3.5 hours (1993 estimates), using a known-plaintext attack. As
+ discussed in the Security Considerations section, a known plaintext
+ attack is reasonably likely.
+
+ It should also be noted that over time, the total and average search
+ costs as well as the average key recovery time will continue to drop.
+
+ While the above does not provide specific recommendations for key
+ lifetime, it does reinforce the point that for a given application
+ the desired key lifetime is dependent upon the perceived threat (an
+ educated guess as to the amount of resources available to the
+ attacker) relative to the worth of the data to be protected.
+
+ While there are no recommendations for volume-based lifetimes made
+ here, it shoud be noted that given sufficient volume there is an
+ increased probabilty that known plaintext can be accumulated.
+
+5. Interaction with Authentication Algorithms
+
+ As of this writing, there are no known issues which preclude the use
+ of the DES-CBC algorithm with any specific authentication algorithm.
+
+
+
+
+Madson & Doraswamy Standards Track [Page 4]
+
+RFC 2405 The ESP DES-CBC Cipher Algorithm November 1998
+
+
+6. Security Considerations
+
+ [Much of this section was originally written by William Allen Simpson
+ and Perry Metzger.]
+
+ 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 Security Association management mechanism and its
+ implementation, the strength of the key [CN94], and upon the
+ correctness of the implementations in all of the participating nodes.
+
+ [Bell95] and [Bell96] describe a cut and paste splicing attack which
+ applies to all Cipher Block Chaining algorithms. This attack can be
+ addressed with the use of an authentication mechanism.
+
+ The use of the cipher mechanism without any corresponding
+ authentication mechanism is strongly discouraged. This cipher can be
+ used in an ESP transform that also includes authentication; it can
+ also be used in an ESP transform that doesn't include authentication
+ provided there is an companion AH header. Refer to [ESP], [AH],
+ [arch], and [road] for more details.
+
+ When the default ESP padding is used, the padding bytes have a
+ predictable value. They provide a small measure of tamper detection
+ on their own block and the previous block in CBC mode. This makes it
+ somewhat harder to perform splicing attacks, and avoids a possible
+ covert channel. This small amount of known plaintext does not create
+ any problems for modern ciphers.
+
+ At the time of writing of this document, [BS93] demonstrated a
+ differential cryptanalysis based chosen-plaintext attack requiring
+ 2^47 plaintext-ciphertext pairs, where the size of a pair is the size
+ of a DES block (64 bits). [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, [Wiener94] 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.
+
+
+
+
+
+Madson & Doraswamy Standards Track [Page 5]
+
+RFC 2405 The ESP DES-CBC Cipher Algorithm November 1998
+
+
+ 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.
+
+ The case for using random values for IVs has been refined with the
+ following summary provided by Steve Bellovin. Refer to [Bell97] for
+ further information.
+
+ "The problem arises if you use a counter as an IV, or some other
+ source with a low Hamming distance between successive IVs, for
+ encryption in CBC mode. In CBC mode, the "effective plaintext"
+ for an encryption is the XOR of the actual plaintext and the
+ ciphertext of the preceeding block. Normally, that's a random
+ value, which means that the effective plaintext is quite random.
+ That's good, because many blocks of actual plaintext don't change
+ very much from packet to packet, either.
+
+ For the first block of plaintext, though, the IV takes the place
+ of the previous block of ciphertext. If the IV doesn't differ
+ much from the previous IV, and the actual plaintext block doesn't
+ differ much from the previous packet's, then the effective
+ plaintext won't differ much, either. This means that you have
+ pairs of ciphertext blocks combined with plaintext blocks that
+ differ in just a few bit positions. This can be a wedge for
+ assorted cryptanalytic attacks."
+
+ The discussion on IVs has been updated to require that an
+ implementation not use a low-Hamming distance source for IVs.
+
+7. References
+
+ [Bell95] Bellovin, S., "An Issue With DES-CBC When Used Without
+ Strong Integrity", Presentation at the 32nd Internet
+ Engineering Task Force, Danvers Massachusetts, April
+ 1995.
+
+ [Bell96] Bellovin, S., "Problem Areas for the IP Security
+ Protocols", Proceedings of the Sixth Usenix Security
+ Symposium, July 1996.
+
+
+
+
+
+
+
+
+Madson & Doraswamy Standards Track [Page 6]
+
+RFC 2405 The ESP DES-CBC Cipher Algorithm November 1998
+
+
+ [Bell97] Bellovin, S., "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/papers/probtxt.{ps,
+ pdf}).
+
+ [BS93] Biham, E., and A. Shamir, "Differential Cryptanalysis of
+ the Data Encryption Standard", Berlin: Springer-Verlag,
+ 1993.
+
+ [Blaze96] Blaze, M., Diffie, W., Rivest, R., Schneier, B.,
+ Shimomura, T., Thompson, E., and M. Wiener, "Minimal Key
+ Lengths for Symmetric Ciphers to Provide Adequate
+ Commercial Security", currently available at
+ http://www.bsa.org/policy/encryption/cryptographers.html.
+
+ [CN94] Carroll, J.M., and S. Nudiati, "On Weak Keys and Weak
+ Data: Foiling the Two Nemeses", Cryptologia, Vol. 18
+ No. 23 pp. 253-280, July 1994.
+
+ [FIPS-46-2] US National Bureau of Standards, "Data Encryption
+ Standard", Federal Information Processing Standard
+ (FIPS) Publication 46-2, December 1993,
+ http://www.itl.nist.gov/div897/pubs/fip46-2.htm
+ (supercedes FIPS-46-1).
+
+ [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,
+ http://www.itl.nist.gov/div897/pubs/fip74.htm.
+
+ [FIPS-81] US National Bureau of Standards, "DES Modes of
+ Operation", Federal Information Processing Standard
+ (FIPS) Publication 81, December 1980,
+ http://www.itl.nist.gov/div897/pubs/fip81.htm.
+
+ [Matsui94] Matsui, M., "Linear Cryptanalysis method for DES
+ Cipher", Advances in Cryptology -- Eurocrypt '93
+ Proceedings, Berlin: Springer-Verlag, 1994.
+
+ [RFC-1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
+ Recommendations for Security", RFC 1750, December 1994.
+
+ [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+Madson & Doraswamy Standards Track [Page 7]
+
+RFC 2405 The ESP DES-CBC Cipher Algorithm November 1998
+
+
+ [Schneier96] Schneier, B., "Applied Cryptography Second Edition",
+ John Wiley & Sons, New York, NY, 1996. ISBN 0-471-
+ 12845-7.
+
+ [Wiener94] 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. [Reprinted in "Practical Cryptography for
+ Data Internetworks", W.Stallings, editor, IEEE Computer
+ Society Press, pp.31-79 (1996). Currently available at
+ ftp://ripem.msu.edu/pub/crypt/docs/des-key-search.ps.]
+
+ [ESP] Kent, S., and R. Atkinson, "IP Encapsulating Security
+ Payload (ESP)", RFC 2406, November 1998.
+
+ [AH] Kent, S., and R. Atkinson, "IP Authentication Header
+ (AH)", RFC 2402, November 1998.
+
+ [arch] Kent, S., and R. Atkinson, "Security Architecture for
+ the Internet Protocol", RFC 2401, November 1998.
+
+ [road] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
+ Document Roadmap", RFC 2411, November 1998.
+
+8. Acknowledgments
+
+ Much of the information provided here originated with various ESP-DES
+ documents authored by Perry Metzger and William Allen Simpson,
+ especially the Security Considerations section.
+
+ This document is also derived in part from previous works by Jim
+ Hughes, those people that worked with Jim on the combined DES-
+ CBC+HMAC-MD5 ESP transforms, the ANX bakeoff participants, and the
+ members of the IPsec working group.
+
+ Thanks to Rob Glenn for assisting with the nroff formatting.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Madson & Doraswamy Standards Track [Page 8]
+
+RFC 2405 The ESP DES-CBC Cipher Algorithm 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
+
+
+9. Editors' Addresses
+
+ Cheryl Madson
+ Cisco Systems, Inc.
+
+ EMail: cmadson@cisco.com
+
+
+ Naganand Doraswamy
+ Bay Networks, Inc.
+
+ EMail: naganand@baynetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Madson & Doraswamy Standards Track [Page 9]
+
+RFC 2405 The ESP DES-CBC Cipher Algorithm November 1998
+
+
+10. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Madson & Doraswamy Standards Track [Page 10]
+