draft-ietf-ipsec-ciph-des-expiv-01.txt   rfc2405.txt 
Network Working Group IPsec Working Group Network Working Group C. Madson
INTERNET DRAFT C. Madson Request for Comments: 2405 Cisco Systems, Inc.
Expires in Six Months Cisco Systems, Inc. Category: Standards Track N. Doraswamy
N. Doraswamy
Bay Networks, Inc. Bay Networks, Inc.
November 1997 November 1998
The ESP DES-CBC Cipher Algorithm The ESP DES-CBC Cipher Algorithm
With Explicit IV With Explicit IV
<draft-ietf-ipsec-ciph-des-expiv-01.txt>
Status of this Memo Status of this Memo
This document is a submission to the IETF Internet Protocol Security This document specifies an Internet standards track protocol for the
(IPSEC) Working Group. Comments are solicited and should be addressed Internet community, and requests discussion and suggestions for
to the working group mailing list (ipsec@tis.com) or to the authors. improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
This document is an Internet-Draft. Internet Drafts are working and status of this protocol. Distribution of this memo is unlimited.
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 draft documents are valid for a maximum of six months
and may be updated, replaced, or obsolete by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the Copyright Notice
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited. Copyright (C) The Internet Society (1998). All Rights Reserved.
Abstract Abstract
This document describes the use of the DES Cipher algorithm in Cipher This document describes the use of the DES Cipher algorithm in Cipher
Block Chaining Mode, with an explicit IV, as a confidentiality Block Chaining Mode, with an explicit IV, as a confidentiality
mechanism within the context of the IPSec Encapsulating Security mechanism within the context of the IPSec Encapsulating Security
Payload (ESP). Payload (ESP).
INTERNET DRAFT November 1997 Expires in Six Months
1. Introduction 1. Introduction
This document describes the use of the DES Cipher algorithm in Cipher This document describes the use of the DES Cipher algorithm in Cipher
Block Chaining Mode as a confidentiality mechanism within the context Block Chaining Mode as a confidentiality mechanism within the context
of the Encapsulating Security Payload. of the Encapsulating Security Payload.
DES is a symmetric block cipher algorithm. The algorithm is described DES is a symmetric block cipher algorithm. The algorithm is described
in [FIPS-46][FIPS-46-1][FIPS-74][FIPS-81]. [Schneier96] provides a in [FIPS-46-2][FIPS-74][FIPS-81]. [Schneier96] provides a general
general description of Cipher Block Chaining Mode, a mode which is description of Cipher Block Chaining Mode, a mode which is applicable
applicable to several encryption algorithms. to several encryption algorithms.
As specified in this draft, DES-CBC is not an authentication As specified in this memo, DES-CBC is not an authentication
mechanism. [Although DES-MAC, described in [Schneier96] amongst other mechanism. [Although DES-MAC, described in [Schneier96] amongst other
places, does provide authentication, DES-MAC is not discussed here.] places, does provide authentication, DES-MAC is not discussed here.]
For further information on how the various pieces of ESP fit together For further information on how the various pieces of ESP fit together
to provide security services, refer to [ESP] and [Thayer97]. to provide security services, refer to [ESP] and [road].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-2119]. document are to be interpreted as described in [RFC-2119].
2. Algorithm and Mode 2. Algorithm and Mode
DES-CBC is a symmetric secret-key block algorithm. It has a block DES-CBC is a symmetric secret-key block algorithm. It has a block
size of 64 bits. size of 64 bits.
[FIPS-46][FIPS-46-1][FIPS-74] and [FIPS-81] describe the DES [FIPS-46-2][FIPS-74] and [FIPS-81] describe the DES algorithm, while
algorithm, while [Schneier96] provides a good description of CBC [Schneier96] provides a good description of CBC mode.
mode.
2.1 Performance 2.1 Performance
Phil Karn has tuned DES-CBC software to achieve 10.45 Mbps with a 90 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 MHz Pentium, scaling to 15.9 Mbps with a 133 MHz Pentium. Other DES
speed estimates may be found in [Schneier96]. speed estimates may be found in [Schneier96].
3. ESP Payload 3. ESP Payload
DES-CBC requires an explicit Initialization Vector (IV) of 8 octets DES-CBC requires an explicit Initialization Vector (IV) of 8 octets
(64 bits). This IV immediately precedes the protected (encrypted) (64 bits). This IV immediately precedes the protected (encrypted)
payload. The IV SHOULD be chosen at random. payload. The IV MUST be a random value.
Including the IV in each datagram ensures that decryption of each Including the IV in each datagram ensures that decryption of each
received datagram can be performed, even when some datagrams are received datagram can be performed, even when some datagrams are
dropped, or datagrams are re-ordered in transit. dropped, or datagrams are re-ordered in transit.
Implementation note: Implementation note:
Common practice is to use random data for the first IV and the 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 last 8 octets of encrypted data from an encryption process as the
IV for the next encryption process; this logically extends the CBC IV for the next encryption process; this logically extends the CBC
across the packets. It also has the advantage of limiting the across the packets. It also has the advantage of limiting the
INTERNET DRAFT November 1997 Expires in Six Months
leakage of information from the random number genrator. No matter leakage of information from the random number genrator. No matter
which mechnism is used, the receiver MUST NOT assume any meaning which mechnism is used, the receiver MUST NOT assume any meaning
for this value, other than that it is an IV. 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 payload field, as defined in [ESP], is broken down according to
the following diagram: the following diagram:
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
+ Initialization Vector (IV) + + Initialization Vector (IV) +
| | | |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| | | |
~ Encrypted Payload (variable length) ~ ~ Encrypted Payload (variable length) ~
skipping to change at page 3, line 37 skipping to change at page 3, line 28
The DES-CBC algorithm described in this document MUST use a block The DES-CBC algorithm described in this document MUST use a block
size of 8 octets (64 bits). size of 8 octets (64 bits).
When padding is required, it MUST be done according to the When padding is required, it MUST be done according to the
conventions specified in [ESP]. conventions specified in [ESP].
4. Key Material 4. Key Material
DES-CBC is a symmetric secret key algorithm. The key size is 64-bits. 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 [It is commonly known as a 56-bit key as the key has 56 significant
bits; these 56 bits are stored in an 8-byte (64- bit) value, where bits; the least significant bit in every byte is the parity bit.]
each byte has seven significant bits from the 56-bit value and the
least significant bit is used as a parity bit.]
[ESP] describes the general mechanism to derive keying material for [arch] describes the general mechanism to derive keying material for
the ESP transform. The derivation of the key from some amount of the ESP transform. The derivation of the key from some amount of
keying material does not differ between the manually- and keying material does not differ between the manually- and
automatically-keyed security associations. automatically-keyed security associations.
The mechanism MUST derive a 64-bit key value for use by this cipher. This mechanism MUST derive a 64-bit key value for use by this cipher.
This derived value MUST be adjusted for parity as necessary. Weak key The mechanism will derive raw key values, the derivation process
checks will be performed; if a weak key is dicovered, the key will be itself is not responsible for handling parity or weak key checks.
rejected and IPSEC will request a new SA.
4.1 Weak Keys Weak key checks SHOULD be performed. If such a key is found, the key
SHOULD be rejected and a new SA requested.
DES has 64 known weak keys, including so-called semi-weak keys and Implementation note:
possibly-weak keys (from [Schneier96] -- corrected version provided
by William Allan Simpson -- shown here in hex with parity bits):
0101 0101 0101 0101 If an implementation chooses to do weak key checking, it should
1f1f 1f1f 0e0e 0e0e recognize that the known weak keys [FIPS74] have been adjusted for
e0e0 e0e0 f1f1 f1f1 parity. Otherwise the handling of parity is a local issue.
fefe fefe fefe fefe
INTERNET DRAFT November 1997 Expires in Six Months A strong pseudo-random function MUST be used to generate the required
key. For a discussion on this topic, reference [RFC1750].
semi-weak key pairs: 4.1 Weak Keys
01fe 01fe 01fe 01fe fe01 fe01 fe01 fe01 DES has 16 known weak keys, including so-called semi-weak keys. The
1fe0 1fe0 0ef1 0ef1 e0f1 e0f1 f10e f10e list of weak keys can be found in [FIPS74].
01e0 01e0 01f1 01f1 e001 e001 f101 f101
1ffe 1ffe 0efe 0efe fe1f fe1f fe0e fe0e
011f 011f 010e 010e 1f01 1f01 0e01 0e01
e0fe e0fe f1fe f1fe fee0 fee0 fef1 fef1
possibly-weak keys: 4.2 Key Lifetime
1f1f 0101 0e0e 0101 e001 01e0 f101 01f1 [Blaze96] discusses the costs and key recovery time for brute force
011f 1f01 010e 0e01 fe1f 01e0 fe0e 01f1 attacks. It presents various combinations of total cost/time to
1f01 011f 0e01 010e fe01 1fe0 fe01 0ef1 recover a key/cost per key recovered for 40-bit and 56-bit DES keys,
0101 1f1f 0101 0e0e e01f 1fe0 f10e 0ef1 based on late 1995 estimates.
--------------------
e0e0 0101 f1f1 0101 fe01 01fe fe01 01fe
fefe 0101 fefe 0101 e01f 01fe f10e 01fe
fee0 1f01 fef1 0e01 e001 1ffe f101 0efe
e0fe 1f01 f1fe 0e01 fe1f 1ffe fe0e 0efe
--------------------
fee0 011f fef1 010e 1ffe 01e0 0efe 01f1
e0fe 011f f1fe 010e 01fe 1fe0 01fe 0ef1
e0e0 1f1f f1f1 0e0e 1fe0 01fe 0ef1 01fe
fefe 1f1f fefe 0e0e 01e0 1ffe 01f1 0efe
fe1f e001 fe0e f101 0101 e0e0 0101 f1f1 While a brute force search of a 56-bit DES keyspace can be considered
e01f fe01 f10e fe01 1f1f e0e0 0e0e f1f1 infeasable for the so-called casual hacker, who is simply using spare
fe01 e01f fe01 f1e0 1f01 fee0 0e01 fef1 CPU cycles or other low-cost resources, it is within reach of someone
e001 fe1f f101 fe0e 011f fee0 010e fef1 willing to spend a bit more money.
--------------------
01e0 e001 01f1 f101 1f01 e0fe 0e01 f1fe
1ffe e001 0efe f101 011f e0fe 010e f1fe
1fe0 fe01 0ef1 fe01 0101 fefe 0101 fefe
01fe fe01 01fe fe01 1f1f fefe 0e0e fefe
--------------------
1fe0 e01f 0ef1 f10e fefe e0e0 fefe f1f1
01fe e01f 01fe f10e e0fe fee0 f1fe fef1
01e0 fe1f 01f1 fe0e fee0 e0fe fef1 f1fe
1ffe fe1f 0efe fe0e e0e0 fefe f1f1 fefe
Implementations SHOULD take care not to select weak keys [CN94], For example, for a cost of $300,000, a 56-bit DES key can be
although the likelihood of picking one at random is negligible. recovered in an average of 19 days using off-the-shelf technology and
in only 3 hours using a custom developed chip.
4.2 Key Lifetime 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.
There are no current recommendations for key lifetime. [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 5. Interaction with Authentication Algorithms
As of this writing, there are no known issues which preclude the use As of this writing, there are no known issues which preclude the use
of the DES-CBC algorithm with any specific authentication algorithm. of the DES-CBC algorithm with any specific authentication algorithm.
INTERNET DRAFT November 1997 Expires in Six Months
6. Security Considerations 6. Security Considerations
[Much of this section was originally written by William Allen Simpson [Much of this section was originally written by William Allen Simpson
and Perry Metzger.] and Perry Metzger.]
Users need to understand that the quality of the security provided by Users need to understand that the quality of the security provided by
this specification depends completely on the strength of the DES this specification depends completely on the strength of the DES
algorithm, the correctness of that algorithm's implementation, the algorithm, the correctness of that algorithm's implementation, the
security of the Security Association management mechanism and its security of the Security Association management mechanism and its
implementation, the strength of the key [CN94], and upon the correct- implementation, the strength of the key [CN94], and upon the
ness of the implementations in all of the participating nodes. correctness of the implementations in all of the participating nodes.
[Bell95] and [Bell96] describe a cut and paste splicing attack which [Bell95] and [Bell96] describe a cut and paste splicing attack which
applies to all Cipher Block Chaining algorithms. This attack can be applies to all Cipher Block Chaining algorithms. This attack can be
addressed with the use of an authentication mechanism. addressed with the use of an authentication mechanism.
The use of the cipher mechanism without any corresponding The use of the cipher mechanism without any corresponding
authentication mechanism is strongly discouraged. This cipher can be authentication mechanism is strongly discouraged. This cipher can be
used in an ESP transform that also includes authentication; it can used in an ESP transform that also includes authentication; it can
also be used in an ESP transform that doesn't include authentication also be used in an ESP transform that doesn't include authentication
provided there is an companion AH header. Refer to [ESP], [AH], provided there is an companion AH header. Refer to [ESP], [AH],
[arch], and [Thayer97] for more details. [arch], and [road] for more details.
When the default ESP padding is used, the padding bytes have a When the default ESP padding is used, the padding bytes have a
predictable value. They provide a small measure of tamper detection predictable value. They provide a small measure of tamper detection
on their own block and the previous block in CBC mode. This makes it on their own block and the previous block in CBC mode. This makes it
somewhat harder to perform splicing attacks, and avoids a possible somewhat harder to perform splicing attacks, and avoids a possible
covert channel. This small amount of known plaintext does not create covert channel. This small amount of known plaintext does not create
any problems for modern ciphers. any problems for modern ciphers.
At the time of writing of this document, [BS93] demonstrated a dif- At the time of writing of this document, [BS93] demonstrated a
ferential cryptanalysis based chosen-plaintext attack requiring 2^47 differential cryptanalysis based chosen-plaintext attack requiring
plaintext-ciphertext pairs, where the size of a pair is the size of a 2^47 plaintext-ciphertext pairs, where the size of a pair is the size
DES block (64 bits). [Matsui94] demonstrated a linear cryptanalysis of a DES block (64 bits). [Matsui94] demonstrated a linear
based known-plaintext attack requiring only 2^43 plain- text- cryptanalysis based known-plaintext attack requiring only 2^43
ciphertext pairs. Although these attacks are not considered plaintext-ciphertext pairs. Although these attacks are not
practical, they must be taken into account. considered practical, they must be taken into account.
More disturbingly, [Weiner94] has shown the design of a DES cracking More disturbingly, [Wiener94] has shown the design of a DES cracking
machine costing $1 Million that can crack one key every 3.5 hours. machine costing $1 Million that can crack one key every 3.5 hours.
This is an extremely practical attack. This is an extremely practical attack.
One or two blocks of known plaintext suffice to recover a DES key. 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 Because IP datagrams typically begin with a block of known and/or
guessable header text, frequent key changes will not protect against guessable header text, frequent key changes will not protect against
this attack. this attack.
It is suggested that DES is not a good encryption algorithm for the It is suggested that DES is not a good encryption algorithm for the
protection of even moderate value information in the face of such protection of even moderate value information in the face of such
equipment. Triple DES is probably a better choice for such purposes. equipment. Triple DES is probably a better choice for such purposes.
However, despite these potential risks, the level of privacy provided However, despite these potential risks, the level of privacy provided
by use of ESP DES-CBC in the Internet environment is far greater than by use of ESP DES-CBC in the Internet environment is far greater than
sending the datagram as cleartext. sending the datagram as cleartext.
INTERNET DRAFT November 1997 Expires in Six Months 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 7. References
[Bell95] Bellovin, S., "An Issue With DES-CBC When Used Without [Bell95] Bellovin, S., "An Issue With DES-CBC When Used Without
Strong Integrity", Presentation at the 32nd Internet Engineering Strong Integrity", Presentation at the 32nd Internet
Task Force, Danvers Massachusetts, April 1995. Engineering Task Force, Danvers Massachusetts, April
1995.
[Bell96] Bellovin, S., "Problem Areas for the IP Security Protocols", [Bell96] Bellovin, S., "Problem Areas for the IP Security
Proceedings of the Sixth Usenix Security Symposium, July 1996. Protocols", Proceedings of the Sixth Usenix Security
Symposium, July 1996.
[BS93] Biham, E., and Shamir, A., "Differential Cryptanalysis of [Bell97] Bellovin, S., "Probable Plaintext Cryptanalysis of the
the Data Encryption Standard", Berlin: Springer-Verlag, 1993. 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}).
[CN94] Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak Data: [BS93] Biham, E., and A. Shamir, "Differential Cryptanalysis of
Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp. the Data Encryption Standard", Berlin: Springer-Verlag,
253-280, July 1994. 1993.
[FIPS-46] US National Bureau of Standards, "Data Encryption Standard", [Blaze96] Blaze, M., Diffie, W., Rivest, R., Schneier, B.,
Federal Information Processing Standard (FIPS) Publication 46, Shimomura, T., Thompson, E., and M. Wiener, "Minimal Key
January 1977. Lengths for Symmetric Ciphers to Provide Adequate
Commercial Security", currently available at
http://www.bsa.org/policy/encryption/cryptographers.html.
[FIPS-46-1] US National Bureau of Standards, "Data Encryption Standard", [CN94] Carroll, J.M., and S. Nudiati, "On Weak Keys and Weak
Federal Information Processing Standard (FIPS) Publication 46-1, Data: Foiling the Two Nemeses", Cryptologia, Vol. 18
January 1988. No. 23 pp. 253-280, July 1994.
[FIPS-74] US National Bureau of Standards, "Guidelines for [FIPS-46-2] US National Bureau of Standards, "Data Encryption
Implementing and Using the Data Encryption Standard", Federal Standard", Federal Information Processing Standard
Information Processing Standard (FIPS) Publication 74, April 1981. (FIPS) Publication 46-2, December 1993,
http://www.itl.nist.gov/div897/pubs/fip46-2.htm
(supercedes FIPS-46-1).
[FIPS-81] US National Bureau of Standards, "DES Modes of Operation" [FIPS-74] US National Bureau of Standards, "Guidelines for
Federal Information Processing Standard (FIPS) Publication 81, Implementing and Using the Data Encryption Standard",
December 1980. Federal Information Processing Standard (FIPS)
Publication 74, April 1981,
http://www.itl.nist.gov/div897/pubs/fip74.htm.
[Matsui94] Matsui, M., "Linear Cryptanalysis method for DES Cipher," [FIPS-81] US National Bureau of Standards, "DES Modes of
Advances in Cryptology -- Eurocrypt '93 Proceedings, Berlin: Operation", Federal Information Processing Standard
Springer-Verlag, 1994. (FIPS) Publication 81, December 1980,
http://www.itl.nist.gov/div897/pubs/fip81.htm.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [Matsui94] Matsui, M., "Linear Cryptanalysis method for DES
Requirement Levels", RFC-2119/BCP 14, March, 1997. Cipher", Advances in Cryptology -- Eurocrypt '93
Proceedings, Berlin: Springer-Verlag, 1994.
[Schneier96] Schneier, B., "Applied Cryptography Second Edition", [RFC-1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
John Wiley & Sons, New York, NY, 1996. ISBN 0-471-12845-7. Recommendations for Security", RFC 1750, December 1994.
[Weiner94] Wiener, M.J., "Efficient DES Key Search", School of [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Computer Science, Carleton University, Ottawa, Canada, TR-244, May Requirement Levels", BCP 14, RFC 2119, March 1997.
1994. Presented at the Rump Session of Crypto '93.
[ESP] Kent, S., Atkinson, R., "IP Encapsulating Security Payload [Schneier96] Schneier, B., "Applied Cryptography Second Edition",
(ESP)", draft-ietf-ipsec-esp-v2-02.txt, work in progress, November John Wiley & Sons, New York, NY, 1996. ISBN 0-471-
1997. 12845-7.
[AH] Kent, S., Atkinson, R., "IP Authentication Header (AH)", [Wiener94] Wiener, M.J., "Efficient DES Key Search", School of
draft-ietf-ipsec-auth-header-03.txt, work in progress, November Computer Science, Carleton University, Ottawa, Canada,
1997. 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.]
INTERNET DRAFT November 1997 Expires in Six Months [ESP] Kent, S., and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[arch] Kent, S., Atkinson, R., "Security Architecture for the [AH] Kent, S., and R. Atkinson, "IP Authentication Header
Internet Protocol", draft-ietf-ipsec-arch-sec-02.txt, work in (AH)", RFC 2402, November 1998.
progress, November 1997.
[Thayer97] Thayer, R., Doraswamy, N., Glenn, R., "IP Security [arch] Kent, S., and R. Atkinson, "Security Architecture for
Document Roadmap", draft-ietf-ipsec-doc-roadmap-02.txt, work in the Internet Protocol", RFC 2401, November 1998.
progress, November, 1997.
[road] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998.
8. Acknowledgments 8. Acknowledgments
Much of the information provided here originated with various ESP-DES Much of the information provided here originated with various ESP-DES
documents authored by Perry Metzger and William Allen Simpson, documents authored by Perry Metzger and William Allen Simpson,
including the data entry of the known weak key values, and especially especially the Security Considerations section.
the Security Considerations section.
This document is also derived in part from previous works by Jim This document is also derived in part from previous works by Jim
Hughes, those people that worked with Jim on the combined DES- Hughes, those people that worked with Jim on the combined DES-
CBC+HMAC-MD5 ESP transforms, the ANX bakeoff participants, and the CBC+HMAC-MD5 ESP transforms, the ANX bakeoff participants, and the
members of the IPsec working group. members of the IPsec working group.
Thanks also to Rob Glenn for assisting with the nroff formatting. Thanks to Rob Glenn for assisting with the nroff formatting.
The IPSec working group can be contacted via the IPSec working The IPSec working group can be contacted via the IPSec working
group's mailing list (ipsec@tis.com) or through its chairs: group's mailing list (ipsec@tis.com) or through its chairs:
Robert Moskowitz Robert Moskowitz
<rgm@chrysler.com> International Computer Security Association
Chrysler Corporation
Theodore Y. Ts'o EMail: rgm@icsa.net
<tytso@MIT.EDU>
Massachusetts Institute of Technology Theodore Y. Ts'o
Massachusetts Institute of Technology
EMail: tytso@MIT.EDU
9. Editors' Addresses 9. Editors' Addresses
Cheryl Madson Cheryl Madson
<cmadson@cisco.com> Cisco Systems, Inc.
Cisco Systems, Inc.
Naganand Doraswamy EMail: cmadson@cisco.com
<naganand@baynetworks.com>
Bay Networks, Inc. Naganand Doraswamy
Bay Networks, Inc.
EMail: naganand@baynetworks.com
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.
 End of changes. 58 change blocks. 
167 lines changed or deleted 182 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/