idnits 2.17.1 draft-ietf-ipsec-ciph-cbc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Some cipher algorithms have weak keys or keys that MUST not be used due to their weak nature. [Kent97] describes what to do when such a key is generated. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 20, 1997) is 9654 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 255 -- Looks like a reference, but probably isn't: '2' on line 162 ** Downref: Normative reference to an Informational RFC: RFC 2144 (ref. 'Adams97') == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-arch-sec-01 ** Downref: Normative reference to an Informational RFC: RFC 2040 (ref. 'Baldwin96') -- Possible downref: Non-RFC (?) normative reference: ref. 'Crypto93' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-46' == Outdated reference: A later version (-05) exists of draft-ietf-ipsec-esp-v2-00 -- Possible downref: Non-RFC (?) normative reference: ref. 'Lai' == Outdated reference: A later version (-01) exists of draft-ietf-ipsec-ciph-des-expiv-00 -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier93' -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier97' == Outdated reference: A later version (-01) exists of draft-ietf-ipsec-doc-roadmap-00 ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-doc-roadmap (ref. 'Thayer97') -- Possible downref: Non-RFC (?) normative reference: ref. 'Tuchman79' Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Pereira 3 IP Security Working Group TimeStep Corporation 4 Internet Draft R. Adams 5 Expires in six months cisco Systems Inc. 6 November 20, 1997 8 The ESP CBC-Mode Cipher Algorithms 9 11 Status of this Memo 13 This document is a submission to the IETF Internet Protocol 14 Security (IPSEC) Working Group. Comments are solicited and should 15 be addressed to the working group mailing list (ipsec@tis.com) or 16 to the editor. 18 This document is an Internet-Draft. Internet Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working Groups. Note that other groups may also distribute 21 working documents as Internet Drafts. 23 Internet-Drafts draft documents are valid for a maximum of six 24 months and may be updated, replaced, or obsolete by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in 27 progress." 29 To learn the current status of any Internet-Draft, please check the 30 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 31 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 32 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 33 ftp.isi.edu (US West Coast). 35 Distribution of this memo is unlimited. 37 Abstract 39 This document describes how to use CBC-mode cipher algorithms with 40 the IPSec ESP (Encapsulating Security Payload) Protocol. It not 41 only clearly states how to use certain cipher algorithms, but also 42 how to use all CBC-mode cipher algorithms. 44 Internet Draft The ESP CBC-Mode Cipher Algorithms Nov-97 46 Table of Contents 48 1. Introduction...................................................2 49 1.1 Specification of Requirements...............................2 50 2. Cipher Algorithms..............................................3 51 2.1 Mode........................................................3 52 2.2 Key Size....................................................3 53 2.3 Weak Keys...................................................4 54 2.4 Block Size and Padding......................................5 55 2.5 Rounds......................................................6 56 2.6 Backgrounds.................................................6 57 2.7 Performance.................................................9 58 3. ESP Payload...................................................10 59 3.1 ESP Environmental Considerations...........................10 60 3.2 Keying Material............................................10 61 4. Security Considerations.......................................10 62 5. References....................................................11 63 6. Acknowledgments...............................................12 64 7. Editors' Addresses............................................12 65 8. Internet Draft Notes..........................................13 67 1. Introduction 69 The Encapsulating Security Payload (ESP) [Kent97] provides 70 confidentiality for IP datagrams by encrypting the payload data to 71 be protected. This specification describes the ESP use of CBC-mode 72 cipher algorithms. 74 While this document does not describe the use of the default cipher 75 algorithm DES, the reader should be familiar with that document. 76 [Madson97] 78 It is assumed that the reader is familiar with the terms and 79 concepts described in the "Security Architecture for the Internet 80 Protocol" [Atkinson95], "IP Security Document Roadmap" [Thayer97], 81 and "IP Encapsulating Security Payload (ESP)" [Kent97] documents. 83 Furthermore, this document is a companion to [Kent97] and MUST be 84 read in its context. 86 1.1 Specification of Requirements 88 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 89 NOT", and "MAY" that appear in this document are to be interpreted 90 as described in [Bradner97]. 92 Internet Draft The ESP CBC-Mode Cipher Algorithms Nov-97 94 2. Cipher Algorithms 96 All symmetric block cipher algorithms share common characteristics 97 and variables. These include mode, key size, weak keys, block 98 size, and rounds. All of which will be explained below. 100 While this document illustrates certain cipher algorithms such as 101 Blowfish [Schneier93], CAST-128 [Adams97], 3DES, IDEA [Lai], and 102 RC5 [Baldwin96], any other block cipher algorithm may be used with 103 ESP if all of the variables described within this document are 104 clearly defined. 106 2.1 Mode 108 All symmetric block cipher algorithms described or insinuated 109 within this document use Cipher Block Chaining (CBC) mode. This 110 mode requires an Initialization Vector (IV) that is the same size 111 as the block size. Use of a randomly generated IV prevents 112 generation of identical ciphertext from packets which have 113 identical data that spans the first block of the cipher algorithm's 114 blocksize. 116 The IV is XOR'd with the first plaintext block, before it is 117 encrypted. Then for successive blocks, the previous ciphertext 118 block is XOR'd with the current plaintext, before it is encrypted. 120 More information on CBC mode can be obtained in [Schneier95]. 122 2.2 Key Size 124 Some cipher algorithms allow for variable sized keys, while others 125 only allow a specific key size. The length of the key correlates 126 with the strength of that algorithm, thus larger keys are always 127 harder to break than shorter ones. 129 This document stipulates that all key sizes MUST be a multiple of 8 130 bits. 132 This document does specify the default key size for each cipher 133 algorithm. This size was chosen by consulting experts on the 134 algorithm and by balancing strength of the algorithm with 135 performance. 137 Internet Draft The ESP CBC-Mode Cipher Algorithms Nov-97 139 +==============+==================+=================+==========+ 140 | Algorithm | Key Sizes (bits) | Popular Sizes | Default | 141 +==============+==================+=================+==========+ 142 | CAST-128 [1] | 40 to 128 | 40, 64, 80, 128 | 128 | 143 +--------------+------------------+-----------------+----------+ 144 | RC5 | 40 to 2040 | 40, 128, 160 | 128 | 145 +--------------+------------------+-----------------+----------+ 146 | IDEA | 128 | 128 | 128 | 147 +--------------+------------------+-----------------+----------+ 148 | Blowfish | 40 to 448 | 128 | 128 | 149 +--------------+------------------+-----------------+----------+ 150 | 3DES [2] | 192 | 192 | 192 | 151 +--------------+------------------+-----------------+----------+ 153 Notes: 155 [1] With CAST-128, keys less than 128 bits MUST be padded with 156 zeros in the rightmost, or least significant, positions out to 128 157 bits since the CAST-128 key schedule assumes an input key of 128 158 bits. Thus if you had a key with a size of 80 bits '3B5D831CFE', 159 it would be padded to produce a key with a size of 128 bits 160 '3B5D831CFE000000'. 162 [2] The first 3DES key is taken from the first 64 bits, the second 163 from the next 64 bits, and the third from the last 64 bits. 164 Implementations MUST take into consideration the parity bits when 165 initially accepting a new set of keys. 167 The reader should note that the minimum key size for all of the 168 above cipher algorithms is 40 bits, and that the authors strongly 169 advise that implementations do NOT use key sizes smaller than 40 170 bits. 172 2.3 Weak Keys 174 Some cipher algorithms have weak keys or keys that MUST not be used 175 due to their weak nature. [Kent97] describes what to do when such 176 a key is generated. 178 CAST-128: 180 No known weak keys. 182 RC5: 184 No known weak keys when used with 16 rounds. 186 Internet Draft The ESP CBC-Mode Cipher Algorithms Nov-97 188 IDEA: 190 IDEA has weak keys of the following form [Crypto93]: 192 0000,0000,0x00,0000,0000,000x,xxxx,x000 194 where "x" can be any hexadecimal number. 196 Keys of this form guarantee the value of bit-wise XOR of resultant 197 ciphertext pairs from the bit-wise XOR of certain plaintext pairs. 199 Blowfish: 201 Weak keys for Blowfish have been discovered. Weak keys are keys 202 that produce the identical entries in a given S-box. 203 Unfortunately, there is no way to test for weak keys before the S- 204 box values are generated. However, the chances of randomly 205 generating such a key are small. 207 3DES: 209 DES has 64 known weak keys, including so-called semi-weak keys and 210 possibly-weak keys [Schneier95, pp 280-282]. The likelihood of 211 picking one at random is negligible. 213 For DES-EDE3, there is no known need to reject weak or 214 complementation keys. Any weakness is obviated by the use of 215 multiple keys. 217 However, if the first two or last two independent 64-bit keys are 218 equal (k1 == k2 or k2 == k3), then the 3DES operation is simply the 219 same as DES. Implementers MUST reject keys that exhibit this 220 property. 222 2.4 Block Size and Padding 224 All of the algorithms described in this document use a block size 225 of eight octets (64 bits). 227 Padding is used to align the payload type and pad length octets as 228 specified in [Kent97]. Padding must be sufficient to align the 229 data to be encrypted to an eight octet (64 bit) boundary. 231 Internet Draft The ESP CBC-Mode Cipher Algorithms Nov-97 233 2.5 Rounds 235 This variable determines how many times a block is encrypted. 236 While this variable MAY be negotiated, a default value MUST always 237 exist when it is not negotiated. 239 +====================+============+======================+ 240 | Algorithm | Negotiable | Default Rounds | 241 +====================+============+======================+ 242 | CAST-128 | No | key<=80 bits, 12 | 243 | | | key>80 bits, 16 | 244 +--------------------+------------+----------------------+ 245 | RC5 | No | 16 | 246 +--------------------+------------+----------------------+ 247 | IDEA [1] | 4, 8 | 8 | 248 +--------------------+------------+----------------------+ 249 | Blowfish | No | 16 | 250 +--------------------+------------+----------------------+ 251 | 3DES | No | 48 (16x3) | 252 +--------------------+------------+----------------------+ 254 Notes: 255 [1] Although there are no known attacks against four round IDEA, 256 those choosing to use four round IDEA for performance reasons may 257 wish to use a shorter key lifetime (presumably via site specific 258 policy). 260 2.6 Backgrounds 262 CAST-128: 264 The CAST design procedure was originally developed by Carlisle 265 Adams and Stafford Travares at Queen's University, Kingston, 266 Ontario, Canada. Subsequent enhancements have been made over the 267 years by Carlisle Adams and Michael Wiener of Entrust Technologies. 268 CAST-128 is the result of applying the CAST Design Procedure as 269 outlined in [Adams97]. 271 RC5: 273 The RC5 encryption algorithm was developed by Ron Rivest for RSA 274 Data Security Inc. in order to address the need for a high- 275 performance software and hardware ciphering alternative to DES. 277 Internet Draft The ESP CBC-Mode Cipher Algorithms Nov-97 279 IDEA: 281 Xuejia Lai and James Massey developed the IDEA (International Data 282 Encryption Algorithm) algorithm. The algorithm is described in 283 detail in [Lai] and [Schneier]. 285 The IDEA algorithm is patented in Europe and in the United States 286 with patent application pending in Japan. Licenses are required 287 for commercial uses of IDEA. 289 For patent and licensing information, contact: 291 Ascom Systec AG, Dept. CMVV 292 Gewerbepark, CH-5506 293 Magenwil, Switzerland 294 Phone: +41 64 56 59 83 295 Fax: +41 64 56 59 90 296 idea@ascom.ch 297 http://www.ascom.ch/Web/systec/policy/normal/exhibit1.html 299 Blowfish: 301 Bruce Schneier of Counterpane Systems developed the Blowfish block 302 cipher algorithm. The algorithm is described in detail in 303 [Schneier93], [Schneier95] and [Schneier]. 305 3DES: 307 This DES variant, colloquially known as "Triple DES" or as DES- 308 EDE3, processes each block three times, each time with a different 309 key. This technique of using more than one DES operation was 310 proposed in [Tuchman79]. 312 Internet Draft The ESP CBC-Mode Cipher Algorithms Nov-97 314 P1 P2 Pi 315 | | | 316 IV->->(X) +>->->->(X) +>->->->(X) 317 v ^ v ^ v 318 +-----+ ^ +-----+ ^ +-----+ 319 k1->| E | ^ k1->| E | ^ k1->| E | 320 +-----+ ^ +-----+ ^ +-----+ 321 | ^ | ^ | 322 v ^ v ^ v 323 +-----+ ^ +-----+ ^ +-----+ 324 k2->| D | ^ k2->| D | ^ k2->| D | 325 +-----+ ^ +-----+ ^ +-----+ 326 | ^ | ^ | 327 v ^ v ^ v 328 +-----+ ^ +-----+ ^ +-----+ 329 k3->| E | ^ k3->| E | ^ k3->| E | 330 +-----+ ^ +-----+ ^ +-----+ 331 | ^ | ^ | 332 +>->->+ +>->->+ +>->-> 333 | | | 334 C1 C2 Ci 336 The DES-EDE3-CBC algorithm is a simple variant of the DES-CBC 337 algorithm [FIPS-46]. The "outer" chaining technique is used. 339 In DES-EDE3-CBC, an Initialization Vector (IV) is XOR'd with the 340 first 64-bit (8 byte) plaintext block (P1). The keyed DES function 341 is iterated three times, an encryption (Ek1) followed by a 342 decryption (Dk2) followed by an encryption (Ek3), and generates the 343 ciphertext (C1) for the block. Each iteration uses an independent 344 key: k1, k2 and k3. 346 For successive blocks, the previous ciphertext block is XOR'd with 347 the current plaintext (Pi). The keyed DES-EDE3 encryption function 348 generates the ciphertext (Ci) for that block. 350 To decrypt, the order of the functions is reversed: decrypt with 351 k3, encrypt with k2, decrypt with k1, and XOR the previous 352 ciphertext block. 354 Note that when all three keys (k1, k2 and k3) are the same, DES- 355 EDE3-CBC is equivalent to DES-CBC. This property allows the DES- 356 EDE3 hardware implementations to operate in DES mode without 357 modification. 359 For more explanation and implementation information for Triple DES, 360 see [Schneier95]. 362 Internet Draft The ESP CBC-Mode Cipher Algorithms Nov-97 364 2.7 Performance 366 For a comparison table of the speed of any of these and other 367 cipher algorithms, please see [Schneier97]. 369 CAST-128: 371 CAST runs approximately 3 times faster than a highly optimized DES 372 implementation and runs 5-6 times faster than the DES 373 implementations found in typical applications. This is based on a 374 non-optimized C++ implementation of CAST-128. It can therefore be 375 tuned to give even higher performance, if this is required. 377 RC5: 379 Benchmark numbers from RSA Data Security suggest that RC5-CBC runs 380 about twice as fast as Eric Young's DES-CBC implementation from 381 SSLeay on the popular 32-bit CPUs. 383 IDEA: 385 Normal eight round IDEA is approximately twice as fast as DES on 386 386 and 486 processors. However on a Pentium, both eight round 387 IDEA and 56 bit key, 16 round DES require about the same number of 388 clock cycles per byte encrypted. Four round IDEA is twice as fast 389 as eight round IDEA. 391 Blowfish: 393 Blowfish is designed to encrypt data very efficiently on 32 bit 394 processors. Although setting up the keys for Blowfish is complex 395 and time consuming, actual encryption is efficient. Sixteen round 396 Blowfish uses only 18 clock cycles per byte encrypted on a Pentium 397 versus 45 clock cycles for 16 round DES with a 56 bit key, and 108 398 for 48 round Triple-DES. 400 3DES: 402 Triple DES is approximately 2.5 times slower than "single" DES 403 (rather than 3 times), because inner permutations may be removed. 404 Phil Karn has tuned DES-EDE3-CBC software to achieve very fast 405 performance. Other DES speed estimates may be found at [Schneier, 406 page 279]. 408 Internet Draft The ESP CBC-Mode Cipher Algorithms Nov-97 410 3. ESP Payload 412 The ESP payload is made up of the IV followed by raw cipher-text. 413 Thus the payload field, as defined in [Kent97], is broken down 414 according to the following diagram: 416 +---------------+---------------+---------------+---------------+ 417 | | 418 + Initialization Vector (8 octets) + 419 | | 420 +---------------+---------------+---------------+---------------+ 421 | | 422 ~ Encrypted Payload (variable length) ~ 423 | | 424 +---------------------------------------------------------------+ 425 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 427 The IV field MUST be same size as the block size of the cipher 428 algorithm being used. The IV SHOULD be chosen at random. Common 429 practice is to use random data for the first IV and the last block 430 of encrypted data from an encryption process as the IV for the next 431 encryption process. 433 3.1 ESP Environmental Considerations 435 Currently, there are no known issues regarding interactions between 436 these algorithms and other aspects of ESP, such as use of certain 437 authentication schemes. 439 3.2 Keying Material 441 The minimum number of bits sent from the key exchange protocol to 442 this ESP algorithm must be greater or equal to the key size. 444 The cipher's encryption and decryption key is taken from the first 445 bits of the keying material, where represents the required 446 key size. 448 4. Security Considerations 450 Implementations are encouraged to use the largest key sizes they 451 can when taking into account performance considerations for their 452 particular hardware and software configuration. Note that 453 encryption necessarily impacts both sides of a secure channel, so 454 such consideration must take into account not only the client side, 455 but the server as well. 457 Internet Draft The ESP CBC-Mode Cipher Algorithms Nov-97 459 For further security considerations, the reader is encouraged to 460 read the documents that describe the actual cipher algorithms. 462 5. References 464 [Adams97] Adams, C., "The CAST-128 Encryption Algorithm", RFC2144, 465 1997. 467 [Atkinson95] Atkinson, R., "Security Architecture for the Internet 468 Protocol", draft-ietf-ipsec-arch-sec-01 470 [Baldwin96] Baldwin, R.W., Rivest, R., "The RC5, RC5-CBC, RC5-CBC- 471 Pad, and RC5-CTS Algorithms", RFC2040, October 1996 473 [Bradner97] Bradner, S., "Key words for use in RFCs to indicate 474 Requirement Levels", RFC2119, March 1997 476 [Crypto93] Daeman, J., Govaerts, R., Vandewalle, J., "Weak Keys for 477 IDEA", Advances in Cryptology, CRYPTO 93 Proceedings, Springer- 478 Verlag, pp. 224-230. 480 [FIPS-46] US National Bureau of Standards, "Data Encryption 481 Standard", Federal Information Processing Standard (FIPS) 482 Publication 46, January 1977. 484 [Kent97] Kent, S., Atkinson, R., "IP Encapsulating Security Payload 485 (ESP)", draft-ietf-ipsec-esp-v2-00 487 [Lai] Lai, X. "On the Design and Security of Block Ciphers", ETH 488 Series in Information Processing, v. 1, Konstanz: Hartung-Gorre 489 Verlag, 1992. 491 [Madson97] Madson, C., Dorswamy, N., "The ESP DES-CBC Cipher 492 Algorithm With Explicit IV", draft-ietf-ipsec-ciph-des-expiv-00 494 [Schneier] Schneier, B., "Applied Cryptography Second Edition", 495 John Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7 497 [Schneier93] Schneier, B., "Description of a New Variable-Length 498 Key, 64-Bit Block Cipher", from "Fast Software Encryption, 499 Cambridge Security Workshop Proceedings", Springer-Verlag, 1994, 500 pp. 191-204. http://www.counterpane.com/bfsverlag.html 502 [Schneier95] Schneier, B., "The Blowfish Encryption Algorithm - One 503 Year Later", Dr. Dobb's Journal, September 1995, 504 http://www.counterpane.com/bfdobsoyl.html 506 Internet Draft The ESP CBC-Mode Cipher Algorithms Nov-97 508 [Schneier97] Scheier, B. "Speed Comparisons of Block Ciphers on a 509 Pentium." February 1997, http://www.counterpane.com/speed.html 511 [Thayer97] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document 512 Roadmap", draft-ietf-ipsec-doc-roadmap-00 514 [Tuchman79] Tuchman, W, "Hellman Presents No Shortcut Solutions to 515 DES", IEEE Spectrum, v. 16 n. 7, July 1979, pp. 40-41. 517 6. Acknowledgments 519 This document is a merger of most of the ESP cipher algorithm 520 documents. This merger was done to facilitate greater 521 understanding of the commonality of all of the ESP algorithms and 522 to further the development of these algorithm within ESP. 524 The content of this document is based on suggestions originally 525 from Stephen Kent and subsequent discussions from the IPSec mailing 526 list as well as other IPSec drafts. 528 For CAST, special thanks to Carlisle Adams and Paul Van Oorschot 529 both of Entrust Technologies who provided input and review. 531 For 3DES, thanks to all of the editors of the previous ESP 3DES 532 documents; W. Simpson, N. Doraswamy, P. Metzger, and P. Karn. 534 For RC5, thanks to Brett Howard from TimeStep for his original 535 work. 537 7. Editors' Addresses 539 Roy Pereira 540 541 TimeStep Corporation 542 +1 (613) 599-3610 x 4808 544 Rob Adams 545 546 cisco Systems Inc. 547 +1 (408) 457 5397 549 Contributors: 551 Robert W. Baldwin 552 or 553 RSA Data Security, Inc. 554 +1 (415) 595-8782 556 Internet Draft The ESP CBC-Mode Cipher Algorithms Nov-97 558 Greg Carter 559 560 Entrust Technologies 561 +1 (613) 763-1358 563 Rodney Thayer 564 rodney@sabletech.com 565 Sable Technology Corporation 566 +1 (617) 332-7292 568 The IPSec working group can be contacted via the IPSec working 569 group's mailing list (ipsec@tis.com) or through its chairs: 571 Robert Moskowitz 572 rgm@chrysler.com 573 Chrysler Corporation 575 Theodore Y. Ts�o 576 tytso@MIT.EDU 577 Massachusetts Institute of Technology 579 8. Internet Draft Notes 581 This document obsoletes the following documents: 582 draft-ietf-ipsec-ciph-cast-128cbc-00.txt, R. Pereira, G. Carter 583 draft-ietf-ipsec-ciph-rc5-cbc-00.txt, R. Pereira, R. Baldwin 584 draft-ietf-ipsec-ciph-3des-expiv-00.txt, R. Pereira, R. Thayer 585 draft-ietf-ipsec-ciph-idea-cbc-00.txt, R. Adams 586 draft-ietf-ipsec-ciph-blowfish-cbc-00.txt, R. Adams 588 The key size for IDEA was restricted for "ease of use" purposes. 589 Furthermore, the use of setting the sub-keys directly was removed, 590 again for ease of use. 592 IDEA�s weak key derivation was removed as it is the responsibility 593 of the ESP document to describe actions when there is a weak key. 595 DES-CBC could be part of this document with very little effort. 596 Should it be?