idnits 2.17.1 draft-ietf-ipsec-ciph-aes-cbc-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 2) being 61 lines 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 copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 interaction with some aspect of the cipher's definition. If weak keys are discovered for any of the AES ciphers, then weak keys SHOULD be checked for and discarded when using manual key man-agement. When using dynamic key management, such as [IKE], weak key checks SHOULD NOT be performed as they are seen as an unnecessary added code complexity that could weaken the intended security [EVALU-ATION]. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'EVALU-ATION' is mentioned on line 223, but not defined == Missing Reference: 'SER-PENT-2' is mentioned on line 312, but not defined == Missing Reference: 'TM' is mentioned on line 612, but not defined == Unused Reference: 'CRYPTO-M' is defined on line 539, but no explicit reference was found in the text == Unused Reference: 'EVALUATION' is defined on line 553, but no explicit reference was found in the text == Unused Reference: 'IKE-ECC' is defined on line 561, but no explicit reference was found in the text == Unused Reference: 'ISAKMP' is defined on line 565, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (ref. 'ARCH') (Obsoleted by RFC 4301) -- Possible downref: Non-RFC (?) normative reference: ref. 'CRYPTO-B' -- Possible downref: Non-RFC (?) normative reference: ref. 'CRYPTO-M' -- Possible downref: Non-RFC (?) normative reference: ref. 'CRYPTO-S' ** Obsolete normative reference: RFC 2407 (ref. 'DOI') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) -- Possible downref: Non-RFC (?) normative reference: ref. 'EVALUATION' -- Possible downref: Normative reference to a draft: ref. 'IKE' == Outdated reference: A later version (-10) exists of draft-ietf-ipsec-ike-ecc-groups-01 ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-ike-ecc-groups (ref. 'IKE-ECC') -- Possible downref: Non-RFC (?) normative reference: ref. 'ISAKMP' == Outdated reference: A later version (-08) exists of draft-orman-public-key-lengths-00 -- Possible downref: Non-RFC (?) normative reference: ref. 'KEYLEN-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'MARS-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'MARS-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'MARS-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'PERF-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'PERF-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'PERF-3' -- Possible downref: Non-RFC (?) normative reference: ref. 'PERF-4' -- Possible downref: Non-RFC (?) normative reference: ref. 'RC6' -- Possible downref: Non-RFC (?) normative reference: ref. 'RIJNDAEL' ** Obsolete normative reference: RFC 2411 (ref. 'ROAD') (Obsoleted by RFC 6071) -- Possible downref: Non-RFC (?) normative reference: ref. 'SERPENT-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SERPENT-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'TWOFISH-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'TWOFISH-2' Summary: 10 errors (**), 0 flaws (~~), 14 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group IPsec Working Group 2 INTERNET DRAFT S. Frankel, NIST 3 March 2000 R. Glenn, NIST 4 Expiration Date: September 2000 S. Kelly, RedCreek 6 The Candidate AES Cipher Algorithms and Their Use With IPsec 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Drafts Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 This document is a submission to the IETF Internet Protocol Security 29 (IPSEC) Working Group. Comments are solicited and should be addressed 30 to the working group mailing list (ipsec@tis.com) or to the editors. 32 Distribution of this memo is unlimited. 34 Abstract 36 This document describes the use of the AES Cipher Algorithms in Ci- 37 pher Block Chaining Mode, with an explicit IV, as a confidentiality 38 mechanism within the context of the IPsec Encapsulating Security Pay- 39 load (ESP). 41 This Internet Draft specifies the use of each of the 5 AES finalist 42 candidates in the ESP Header. Once the AES cipher is chosen, this 43 document will be changed to reflect that choice. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1 Specification of Requirements . . . . . . . . . . . . . . . . . 4 49 2. The Candidate AES Cipher Algorithms . . . . . . . . . . . . . . 4 50 2.1 Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2.2 Key Size . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 2.3 Weak Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 2.4 Block Size and Padding . . . . . . . . . . . . . . . . . . . . 6 54 2.5 Rounds . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 2.6 Cipher-specific Information . . . . . . . . . . . . . . . . . . 6 56 2.7 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 3. ESP Payload . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 3.1 ESP Algorithmic Interactions . . . . . . . . . . . . . . . . . 8 59 3.2 Keying Material . . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.3 IKE Interactions . . . . . . . . . . . . . . . . . . . . . . . 8 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 10 62 5. Intellectual Property Rights Statement . . . . . . . . . . . . 11 63 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 11 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 66 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14 67 1. Introduction 69 Recognizing that the venerable DES cipher was reaching the end of its 70 useful life, in January 1997 NIST (the National Institute of Stan- 71 dards and Technology) announced a plan to select its successor, the 72 AES (Advanced Encryption Standard). The AES will be the government's 73 designated encryption cipher, and will be definitively described in a 74 FIPS (Federal Information Processing Standard). The expectation is 75 that the AES will suffice to protect sensitive government information 76 at least until the next century. It is also expected to be widely 77 adopted by businesses and financial institutions. 79 The initial call for AES candidates specified the following require- 80 ments: 82 + unclassified 84 + publicly disclosed 86 + available royalty-free worldwide 88 + capable of handling a block size of at least 128 bits 90 + at a minimum, capable of handling key sizes of 128, 192, and 91 256 bits 93 The distinguishing characteristics on which the final AES cipher will 94 be selected are: 96 + security 98 + computational efficiency and memory requirements on a variety 99 of software and hardware, including smart cards 101 + flexibility and simplicity 103 Of the 15 ciphers that were submitted as AES candidates in August 104 1998, 5 were designated as finalists. Analysis and discussion of the 105 candidates continues. Either 1 or 2 of the finalists will be 106 selected as the AES cipher; the AES FIPS is expected to be completed 107 by summer 2001. 109 It is the intention of the IETF IPsec Working Group that AES will 110 eventually be adopted as the default IPsec ESP cipher and will obtain 111 the status of MUST be included in compliant IPsec implementations. 112 However, until 1 or 2 of the finalists are selected and until there 113 is more experience with regard to the cryptographic strengths and 114 weaknesses of the algorithms, this document should be used to experi- 115 ment with the AES candidates and determine how they can best be used 116 in IPsec implementations. This document should be considered experi- 117 mental. 119 The remainder of this document specifies the use of the five finalist 120 AES candidate ciphers within the context of IPsec ESP. For further 121 information on how the various pieces of ESP fit together to provide 122 security services, refer to [ARCH], [ESP], and [ROAD]. 124 1.1 Specification of Requirements 126 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" that 128 appear in this document are to be interpreted as described in 129 [RFC-2119]. 131 2. The Candidate AES Cipher Algorithms 133 All symmetric block cipher algorithms share common characteristics 134 and variables, including mode, key size, weak keys, block size, and 135 rounds. The following sections contain descriptions of the relevant 136 characteristics of the candidate AES ciphers. 138 Some of the candidate AES ciphers are covered by copyrights, patents 139 or patent applications. Each submitter has sworn that, if selected 140 as the AES cipher algorithm, the algorithm will be made available 141 world-wide on a royalty-free basis. 143 The AES homepage, http://www.nist.gov/aes, contains a wealth of in- 144 formation about the 5 finalists, including definitive descriptions of 145 each algorithm, comparative analyses, performance statistics, test 146 vectors and intellectual property information. This site also con- 147 tains information on how to obtain reference implementations from 148 NIST for each of the candidate algorithms. 150 2.1 Mode 152 No operational modes are currently defined for the AES ciphers. How- 153 ever, the Cipher Block Chaining (CBC) mode is well-defined and well- 154 understood for symmetric ciphers, and is currently required for all 155 other ESP ciphers. This document specifies the use of the AES ci- 156 phers in CBC mode within ESP. This mode requires an Initialization 157 Vector (IV) that is the same size as the block size. Use of a ran- 158 domly generated IV prevents generation of identical ciphertext from 159 packets which have identical data that spans the first block of the 160 cipher algorithm's block size. 162 The IV is XOR'd with the first plaintext block before it is encrypt- 163 ed. Then for successive blocks, the previous ciphertext block is 164 XOR'd with the current plaintext, before it is encrypted. 166 More information on CBC mode can be obtained in [CRYPTO-S]. For the 167 use of CBC mode in ESP with 64-bit ciphers, see [CBC]. 169 [AUTHORS' NOTE: Should we require CBC mode using the ciphertext from 170 the previously generated block? On the AES discussion list, it has 171 been suggested that a Counter Feedback Mode be defined, which allows 172 parallel encryption of blocks. Should we stick with CBC, use some 173 variant of a Counter Feedback Mode, or wait for the AES FIPS to de- 174 cide?] 176 2.2 Key Size 178 Some cipher algorithms allow for variable sized keys, while others 179 only allow specific, pre-defined key sizes. The length of the key 180 typically correlates with the strength of the algorithm; thus larger 181 keys are usually harder to break than shorter ones. 183 This document stipulates that all key sizes MUST be a multiple of 8 184 bits. 186 This document specifies the default (i.e. MUST be supported) key size 187 for all of the AES cipher algorithms. All of the candidate ciphers 188 were required to accept key sizes of 128, 192 and 256 bits. The de- 189 fault key size that implementations MUST support for IPsec is 128 190 bits. 192 +============+=========================+===========+ 193 | Algorithm | Key Sizes (bits) | Default | 194 +============+=========================+===========+ 195 | MARS | 128 - 448* | 128 | 196 +------------+-------------------------+-----------+ 197 | RC6 | variable up to 2040 | 128 | 198 +------------+-------------------------+-----------+ 199 | Rijndael | 128, 192, 256 | 128 | 200 +------------+-------------------------+-----------+ 201 | Serpent | variable up to 256** | 128 | 202 +------------+-------------------------+-----------+ 203 | Twofish | variable up to 256*** | 128 | 204 +------------+-------------------------+-----------+ 206 *NOTE1: MARS key lengths must be multiples of 32 bits. 207 **NOTE2: Serpent keys are always padded to 256 bits. The padding con- 208 sists of a "1" bit followed by "0" bits. 209 ***NOTE3: Twofish keys, other than the default sizes, are always 210 padded with "0" bits up to the next default size. 212 2.3 Weak Keys 214 At the time of writing this document there are no known weak keys for 215 any of the AES ciphers. 217 Some cipher algorithms have weak keys or keys that MUST not be used 218 due to their interaction with some aspect of the cipher's definition. 219 If weak keys are discovered for any of the AES ciphers, then weak 220 keys SHOULD be checked for and discarded when using manual key man- 221 agement. When using dynamic key management, such as [IKE], weak key 222 checks SHOULD NOT be performed as they are seen as an unnecessary 223 added code complexity that could weaken the intended security [EVALU- 224 ATION]. 226 2.4 Block Size and Padding 228 All of the algorithms described in this document use a block size of 229 sixteen octets (128 bits), as required in the AES specifications. 230 Some of the algorithms can handle larger block sizes as well. 232 Padding is required by the candidate AES algorithms to maintain a 233 16-octet (128-bit) blocksize. Padding MUST be added, as specified in 234 [ESP], such that the data to be encrypted (which includes the ESP Pad 235 Length and Next Header fields) has a length that is a multiple of 16 236 octets. 238 Because of the algorithm specific padding requirement, no additional 239 padding is required to ensure that the ciphertext terminates on a 240 4-octet boundary (i.e. maintaining a 16-octet blocksize guarantees 241 that the ESP Pad Length and Next Header fields will be right aligned 242 within a 4-octet word). Additional padding may be included, as 243 specifed in [ESP], as long as the 16-octet blocksize is maintained. 245 2.5 Rounds 247 This variable determines how many times a block is encrypted. While 248 this variable MAY be negotiated, a default value MUST always exist 249 when it is not negotiated. 251 +============+===============+=======================+ 252 | Algorithm | Negotiable? | Default # of Rounds | 253 +============+===============+=======================+ 254 | MARS | Yes | 32 | 255 +------------+---------------+-----------------------+ 256 | RC6 | Yes | 20 | 257 +------------+---------------+-----------------------+ 258 | Rijndael | Yes | 10, 12, 14* | 259 +------------+---------------+-----------------------+ 260 | Serpent | Yes | 32 | 261 +------------+---------------+-----------------------+ 262 | Twofish | Yes | 16 | 263 +------------+---------------+-----------------------+ 265 *NOTE1: Rijndael's Default # of Rounds is dependent on key size. De- 266 fault # of Rounds = keylen/32 + 6. 268 2.6 Cipher-specific Information 270 MARS: 272 MARS is IBM's submission to the AES competition. The inventors, who 273 are from the US and Switzerland, are: Carolynn Burwick, Don Copper- 274 smith, Edward D'Avignon, Rosario Gennaro, Shai Halevi, Charanjit Jut- 275 la, Sstephen Matyas Jr., Luke O'Connor, Mohammad Peyravian, David 276 Safford, and Nevenko Zunic, A patent application, IBM application 277 CR99802, is pending. However, the MARS homepage contains the follow- 278 ing statement: "MARS is now available world-wide under a royalty-free 279 license from Tivoli." MARS is defined in [MARS-1] and [MARS-2]. A 280 change to the key generation technique is described in [MARS-3]. The 281 MARS homepage is: http://www.research.ibm.com/security/mars.html. 283 RC6: 285 RC6 was invented by Ronald Rivest of MIT, and by Matthew Robshaw, Ray 286 Sidney, and Yiqun Lisa Yin, all from RSA Laboratories. The name RC6 287 is protected by a copyright. The algorithm is covered by USA patent 288 number 5,724,428 (granted March 3, 1998); two other US patents are 289 pending: application serial numbers 08/854,210 (filed April 21, 1997) 290 and 09/094,649 (filed June 15, 1998). The RC6 family of algorithms is 291 defined in [RC6]. The RC6 homepage is: 292 http://www.rsasecurity.com/rsalabs/aes/. 294 Rijndael: 296 Rijndael was invented by Joan Daemen from Banksys/PWI and Vincent Ri- 297 jmen from ESAT-COSIC, both in Belgium. It is not covered by any 298 patents, and the Rijndael homepage contains the following statement: 299 "Rijndael is available for free. You can use it for whatever purposes 300 you want, irrespective of whether it is accepted as AES or not." Ri- 301 jndael's description can be found in [RIJNDAEL]. The Rijndael home- 302 page is: http://www.esat.kuleuven.ac.be/~rijmen/rijndael/. 304 Serpent: 306 Serpent was invented by Ross Anderson of Cambridge University, Eli 307 Biham of the Technion, Israel and Lars Knudsen of the University of 308 Bergen, Norway. Two UK patent applications are pending: 9722789.7 309 (filed October 29, 1997) and 9722798.9 (filed October 30, 1997). 310 However, the Serpent homepage contains the following statement: "Ser- 311 pent is now completely in the public domain, and we impose no re- 312 strictions on its use." Serpent is defined in [SERPENT-1] and [SER- 313 PENT-2]. The Serpent homepage is: 314 http://www.cl.cam.ac.uk/~rja14/serpent.html. 316 Twofish: 318 Twofish was invented by Bruce Schneier, John Kelsey, Chris Hall and 319 Niels Ferguson, all from Counterpane Systems, Doug Whiting of Hi/fn, 320 and David Wagner from the University of California Berkeley. It is 321 not covered by any patents, and the Twofish homepage contains the 322 following statement: "Twofish is unpatented, and the source code is 323 uncopyrighted and license-free; it is free for all uses." Twofish is 324 defined in [TWOFISH-1] and [TWOFISH-2]. The Twofish homepage is: 325 http://www.counterpane.com/twofish.html. 327 2.7 Performance 329 For a comparison table of the estimated speeds of these and other ci- 330 pher algorithms, please see [PERF-1], [PERF-2], [PERF-3], or 331 [PERF-4]. The AES homepage, http://www.nist.gov/aes, has pointers to 332 other analyses. The individual cypher documents, [MARS-1], [MARS-2], 333 [RC6], [RIJNDAEL], [SERPENT-1], [SERPENT-2], [TWOFISH-1] and 334 [TWOFISH-2] also contain performance statistics. 336 3. ESP Payload 338 The ESP payload is made up of the IV followed by raw cipher-text. 339 Thus the payload field, as defined in [ESP], is broken down according 340 to the following diagram: 342 +---------------+---------------+---------------+---------------+ 343 | | 344 + Initialization Vector (16 octets) + 345 | | 346 +---------------+---------------+---------------+---------------+ 347 | | 348 ~ Encrypted Payload (variable length, a multiple of 16 octets) ~ 349 | | 350 +---------------------------------------------------------------+ 352 The IV field MUST be the same size as the block size of the cipher 353 algorithm being used. The IV MUST be chosen at random. Common prac- 354 tice is to use random data for the first IV and the last block of en- 355 crypted data from an encryption process as the IV for the next en- 356 cryption process. 358 Including the IV in each datagram ensures that decryption of each re- 359 ceived datagram can be performed, even when some datagrams are 360 dropped, or datagrams are re-ordered in transit. 362 To avoid ECB encryption of very similar plaintext blocks in different 363 packets, implementations MUST NOT use a counter or other low-Hamming 364 distance source for IVs. 366 3.1 ESP Algorithmic Interactions 368 Currently, there are no known issues regarding interactions between 369 these algorithms and other aspects of ESP, such as use of certain au- 370 thentication schemes. 372 3.2 Keying Material 374 The minimum number of bits sent from the key exchange protocol to the 375 ESP algorithm must be greater than or equal to the key size. 377 The cipher's encryption and decryption key is taken from the first 378 bits of the keying material, where represents the required 379 key size. 381 3.3 IKE Interactions 383 To facilitate the experimental use of the AES candidate ciphers, it 384 would be useful to temporarily define standard IPsec ESP Transform 385 Identifiers for each of the AES algorithms. [DOI] reserves the val- 386 ues 249-255 for "private use amongst cooperating systems." The fol- 387 lowing IPsec ESP Transform Identifiers are suggested for IKE interop- 388 erability using the AES candidate ciphers: 390 +===================+=========+ 391 | Transform ID | Value | 392 +===================+=========+ 393 | ESP_AES_MARS | 249 | 394 +-------------------+---------+ 395 | ESP_AES_RC6 | 250 | 396 +-------------------+---------+ 397 | ESP_AES_RIJNDAEL | 251 | 398 +-------------------+---------+ 399 | ESP_AES_SERPENT | 252 | 400 +-------------------+---------+ 401 | ESP_AES_TWOFISH | 253 | 402 +-------------------+---------+ 404 Since the AES candidate ciphers allow variable key lengths, the Key 405 Length attribute MUST be specified in a Phase 2 exchange [DOI]. The 406 Key Length attribute MAY be specified in a Phase 1 exchange [IKE]; if 407 it is not specified, the default key length is 128 bits. 409 If IKE is used to negotiate keys for the AES candidate ciphers, the 410 recommended characteristics of the groups governing the Diffie-Hell- 411 man exchange are as follows: 413 +===========+=================+================+===============+ 414 | Key Size | Exponent Size | Modulus Size | Group Type | 415 +===========+=================+================+===============+ 416 | 128 | 256 | 3240 | MODP | 417 +-----------+-----------------+----------------+---------------+ 418 | 192 | 384 | 7945 | MODP | 419 +-----------+-----------------+----------------+---------------+ 420 | 256 | 512 | 15430 | MODP | 421 +-----------+-----------------+----------------+---------------+ 422 | 128 | 248 | 248 | EC2N | 423 +-----------+-----------------+----------------+---------------+ 424 | 192 | 376 | 376 | EC2N | 425 +-----------+-----------------+----------------+---------------+ 426 | 256 | 504 | 504 | EC2N | 427 +-----------+-----------------+----------------+---------------+ 429 NOTE: This table is based on Section 4.5 in [KEYLEN-1] and on email 430 communications with Hilarie Orman [KEYLEN-2]. 432 Additional information about the relationship between the group gov- 433 erning a Diffie-Hellman exchange and the symmetric keys derived from 434 the exchange can be found in [KEYLEN-1]. 436 For symmetric key lengths that exceed the output of the hash used to 437 generate the key, the Diffie-Hellman shared secret MUST be hashed 438 twice, and the resulting values combined to form the keying material 439 [KEYLEN-2], as follows: 441 P1 = Hash(0|shared_secret) 442 P2 = Hash(1|shared_secret) 444 keying_material = (P1 << shift_bits XOR P2) 446 The first hash output, P1, is shifted left a variable number of bits, 447 depending upon the hash and the key length, prior to XOR'ing it with 448 the second hash output, P2. 450 +===========+=========+============+===================+ 451 | Key Size | Hash | Dual DH? | # of Shift Bits | 452 +===========+=========+============+===================+ 453 | 128 | MD5 | N | - | 454 +-----------+---------+------------+-------------------+ 455 | 128 | SHA-1 | N | - | 456 +-----------+---------+------------+-------------------+ 457 | 192 | MD5 | Y | 64 | 458 +-----------+---------+------------+-------------------+ 459 | 192 | SHA-1 | Y | 32 | 460 +-----------+---------+------------+-------------------+ 461 | 256 | MD5 | Y | 128 | 462 +-----------+---------+------------+-------------------+ 463 | 256 | SHA-1 | Y | 96 | 464 +-----------+---------+------------+-------------------+ 466 If additional keying material is required for an authentication key, 467 IKE's iterative key-boosting algorithm MUST be used [IKE, Section 468 6.2]. 470 4. Security Considerations 472 Implementations are encouraged to use the largest key sizes they can 473 when taking into account performance considerations for their partic- 474 ular hardware and software configuration. Note that encryption nec- 475 essarily impacts both sides of a secure channel, so such considera- 476 tion must take into account not only the client side, but the server 477 as well. 479 Because these candidate AES algorithms are relatively new and have 480 only undergone limited cryptographic analysis, their use in IPsec im- 481 plementations should be considered experimental. Once NIST has pub- 482 lished the AES FIPS, and at the recommendation of cryptographic ex- 483 perts, AES should become a default and mandatory-to-implement cipher 484 algorithm for IPsec. 486 For more information regarding the necessary use of random IV values, 487 see [CRYPTO-B]. 489 For further security considerations, the reader is encouraged to read 490 the documents that describe the actual cipher algorithms. 492 5. Intellectual Property Rights Statement 494 Pursuant to the provisions of [RFC-2026], the authors represent that 495 they have disclosed the existence of any proprietary or intellectual 496 property rights in the contribution that are reasonably and personal- 497 ly known to the authors. The authors do not represent that they per- 498 sonally know of all potentially pertinent proprietary and intellectu- 499 al property rights owned or claimed by the organizations they repre- 500 sent or third parties. 502 The IETF takes no position regarding the validity or scope of any in- 503 tellectual property or other rights that might be claimed to pertain 504 to the implementation or use of the technology described in this doc- 505 ument or the extent to which any license under such rights might or 506 might not be available; neither does it represent that it has made 507 any effort to identify any such rights. Information on the IETF's 508 procedures with respect to rights in standards-track and standards- 509 related documentation can be found in BCP-11. Copies of claims of 510 rights made available for publication and any assurances of licenses 511 to be made available, or the result of an attempt made to obtain a 512 general license or permission for the use of such proprietary rights 513 by implementers or users of this specification can be obtained from 514 the IETF Secretariat. 516 6. Acknowledgments 518 Portions of this text, as well as its general structure, were un- 519 abashedly lifted from [CBC]. 521 The authors want to thank Hilarie Orman for providing expert advice 522 (and a sanity check) on key sizes, requirements for Diffie-Hellman 523 groups, and IKE interactions. 525 7. References 527 [ARCH] Kent, S. and R. Atkinson, "Security Architecture for 528 the Internet Protocol", RFC 2401, November 1998. 530 [CBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 531 Algorithms," RFC 2451, November 1998. 533 [CRYPTO-B] Bellovin, S., "Probable Plaintext Cryptanalysis of the 534 IP Security Protocols", Proceedings of the Symposium on 535 Network and Distributed System Security, San Diego, CA, 536 pp. 155-160, February 1997. 537 http://www.research.att.com/~smb/probtxt.{ps, pdf}). 539 [CRYPTO-M] A. Menezes, P. Van Oorschot, S. Vanstone, "Handbook of 540 Applied Cryptography", CRC Press, 1997, ISBN 541 0-8493-8523-7. 543 [CRYPTO-S] B. Schneier, "Applied Cryptography Second Edition", 544 John Wiley & Sons, New York, NY, 1995, ISBN 545 0-471-12845-7. 547 [DOI] Piper, D., "The Internet IP Security Domain of 548 Interpretation for ISAKMP," RFC 2407, November 1998. 550 [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security 551 Payload (ESP)", RFC 2406, November 1998. 553 [EVALUATION] 554 Ferguson, N. and B. Schneier, "A Cryptographic 555 Evaluation of IPsec," Counterpane Internet Security, 556 Inc., January 2000. 558 [IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange 559 (IKE)", draft-ietf-ipsec-ike-01.txt, May 1999. 561 [IKE-ECC] Panjwani, P. and Y. Poeluev, "Additional ECC Groups For 562 IKE," draft-ietf-ipsec-ike-ecc-groups-01.txt, 563 Septermber 1999. 565 [ISAKMP] Maughan, D., M. Schertler, M. Schneider, and J. Turner, 566 "The Internet Security Association and Key Management 567 Protocol (ISAKMP)," 569 [KEYLEN-1] Orman, H. and P. Hoffman, "Determining Strengths For 570 Public Keys Used For Exchanging Symmetric Keys," draft- 571 orman-public-key-lengths-00.txt, February 2000. 573 [KEYLEN-2] Orman, H., email communications, February 2000. 575 [MARS-1] Burwick, C., D. Coppersmith, E. D'Avignon, R. Gennaro, 576 S. Halevi, C. Jutla, S. Matyas Jr., L. O'Connor, M. 577 Peyravian, D. Safford, and N. Zunic, "MARS - a 578 candidate cipher for AES," NIST AES Proposal, Jun 1998. 579 http://csrc.nist.gov/encryption/aes/round2/AESAlgs/MARS/mars.pdf 580 http://www.research.ibm.com/security/mars.html 582 [MARS-2] Burwick, C., D. Coppersmith, E. D'Avignon, R. Gennaro, 583 S. Halevi, C. Jutla, S. Matyas Jr., L. O'Connor, M. 584 Peyravian, D. Safford, and N. Zunic, "The MARS 585 Encryption Algorithm," NIST AES Proposal, Jun 1998. 586 http://csrc.nist.gov/encryption/aes/round2/AESAlgs/MARS/mars-int.pdf 588 [MARS-3] Zunic, N., "Suggested 'tweaks' for the MARS cipher," 589 NIST AES Proposal, May 1999. 590 http://csrc.nist.gov/encryption/aes/round2/AESAlgs/MARS/mars-twk.txt 592 [PERF-1] Bassham, L. III, "Efficiency Testing of ANSI C 593 Implementations of Round1 Candidate Algorithms for the 594 Advanced Encryption Standard". 595 http://csrc.nist.gov/encryption/aes/round1/r1-ansic.pdf 597 [PERF-2] Lipmaa, Helger, "Efficiency Testing Table." 598 http://home.cyber.ee/helger/aes 600 [PERF-3] Nechvetal, J., E. Barker, D. Dodson, M. Dworkin, J. 601 Foti and E. Roback, "Status Report on the First Round 602 of the Development of the Advanced Encryption 603 Standard". 604 http://csrc.nist.gov/encryption/aes/round1/r1report.pdf 606 [PERF-4] Schneier, B., J. Kelsey, D. Whiting, D. Wagner, C. 607 Hall, and N. Ferguson, "Performance Comparison of the 608 AES Submissions." 609 http://www.counterpane.com/AES-performance.html 611 [RC6] Rivest, R., M. Robshaw, R. Sidney, and Y. Yin, "The 612 RC6[TM] Block Cipher," NIST AES Proposal, Jun 1998. 613 http://csrc.nist.gov/encryption/aes/round2/AESAlgs/RC6/cipher.pdf 615 [RFC-2026] Bradner, S., "The Internet Standards Process -- 616 Revision 3", RFC2026, October 1996. 618 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 619 Requirement Levels", RFC-2119, March 1997. 621 [RIJNDAEL] Daemen, J. and V. Rijman, "AES Proposal: Rijndael," 622 NIST AES Proposal, Jun 1998. 623 http://csrc.nist.gov/encryption/aes/round2/AESAlgs/Rijndael/Rijndael.pdf 625 [ROAD] Thayer, R., N. Doraswamy and R. Glenn, "IP Security 626 Document Roadmap", RFC 2411, November 1998. 628 [SERPENT-1] Anderson, R., E. Biham, and L. Knudsen, "Serpent: A 629 Proposal for the Advanced Encryption Standard," NIST 630 AES Proposal, Jun 1998. 631 http://csrc.nist.gov/encryption/aes/round2/AESAlgs/Serpent/Serpent.pdf 633 [SERPENT-2] Biham, E., R. Anderson, L. Knudsen, "Serpent: A New 634 Block Cipher Proposal," Fast Software Encryption - 635 FSE98, Springer LNCS, vol. 1372, pp. 222-238. 637 [TWOFISH-1] Schneier, B., J. Kelsey, D. Whiting, D. Wagner, C. 638 Hall, and N. Ferguson, "Twofish: A 128-Bit Block 639 Cipher," NIST AES Proposal, Jun 1998. 640 http://csrc.nist.gov/encryption/aes/round2/AESAlgs/Twofish/Twofish.pdf 642 [TWOFISH-2] Schneier, B., J. Kelsey, D. Whiting, D. Wagner, C. 643 Hall, and N. Ferguson, "The Twofish Encryption 644 Algorithm: A 128-Bit Block Cipher," John Wiley & Sons, 645 1999. 646 http://www.counterpane.com/ipsec.html 648 8. Authors' Addresses 650 Sheila Frankel 651 NIST 652 820 West Diamond Ave. 653 Room 680 654 Gaithersburg, MD 20899 655 Phone: +1 (301) 975-3297 656 Email: sheila.frankel@nist.gov 658 Rob Glenn 659 NIST 660 820 West Diamond Ave. 661 Room 455 662 Gaithersburg, MD 20899 663 Phone: +1 (301) 975-3667 664 Email: rob.glenn@nist.gov 666 Scott Kelly 667 RedCreek Communications 668 3900 Newpark Mall Road 669 Newark, CA 94560 670 Phone: +1 (510) 745-3969 671 Email: skelly@redcreek.com 673 The IPsec working group can be contacted through the chair: 675 Ted T'so 676 Massachusetts Institute of Technology 677 e-mail: tytso@mit.edu 679 9. Full Copyright Statement 681 Copyright (C) The Internet Society (1998). All Rights Reserved. 683 This document and translations of it may be copied and furnished to 684 others, and derivative works that comment on or otherwise explain it 685 or assist in its implementation may be prepared, copied, published 686 and distributed, in whole or in part, without restriction of any 687 kind, provided that the above copyright notice and this paragraph are 688 included on all such copies and derivative works. However, this doc- 689 ument itself may not be modified in any way, such as by removing the 690 copyright notice or references to the Internet Society or other In- 691 ternet organizations, except as needed for the purpose of developing 692 Internet standards in which case the procedures for copyrights de- 693 fined in the Internet Standards process must be followed, or as re- 694 quired to translate it into languages other than English. 696 The limited permissions granted above are perpetual and will not be 697 revoked by the Internet Society or its successors or assigns. 699 This document and the information contained herein is provided on an 700 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 701 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 702 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HERE- 703 IN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 704 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.