idnits 2.17.1 draft-ietf-ipsec-ciph-aes-cbc-04.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 16 longer pages, the longest (page 1) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 29 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 12 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. 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 the AES, then weak keys SHOULD be checked for and discarded when using manual key management. When using dynamic key management, such as [IKE], weak key checks SHOULD NOT be performed as they are seen as an unnecessary added code com-plexity that could weaken the intended security [EVALUATION]. -- 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' ** 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-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' == Outdated reference: A later version (-04) exists of draft-ietf-ipsec-ike-modp-groups-00 ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) == Outdated reference: A later version (-10) exists of draft-ietf-ipsec-ike-ecc-groups-02 ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-ike-ecc-groups (ref. 'IKE-ECC') == Outdated reference: A later version (-08) exists of draft-orman-public-key-lengths-01 -- Possible downref: Non-RFC (?) normative reference: ref. 'MODES' -- 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' ** Obsolete normative reference: RFC 2411 (ref. 'ROAD') (Obsoleted by RFC 6071) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA2-1' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA2-2' Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft IPsec Working Group 3 June 2002 S. Frankel, NIST 4 Expiration Date: December 2002 S. Kelly, Black Storm Networks 5 R. Glenn, NIST 7 The AES Cipher Algorithm and Its Use With IPsec 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working Groups. Note that other groups may also distribute 16 working documents as Internet Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Drafts Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This document is a submission to the IETF Internet Protocol Security 30 (IPsec) Working Group. Comments are solicited and should be addressed 31 to the working group mailing list (ipsec@lists.tislabs.com) or to the 32 editors. 34 Distribution of this memo is unlimited. 36 Abstract 38 This document describes the use of the AES Cipher Algorithm in Cipher 39 Block Chaining Mode, with an explicit IV, as a confidentiality mecha- 40 nism within the context of the IPsec Encapsulating Security Payload 41 (ESP). 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 1.1 Specification of Requirements . . . . . . . . . . . . . . . 3 47 2. The AES Cipher Algorithm . . . . . . . . . . . . . . . . . . . . 4 48 2.1 Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 2.2 Key Size . . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 2.3 Weak Keys . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2.4 Block Size and Padding . . . . . . . . . . . . . . . . . . . 5 52 2.5 Rounds . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 2.6 Additional Information . . . . . . . . . . . . . . . . . . . 5 54 2.7 Performance . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3. ESP Payload . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.1 ESP Algorithmic Interactions . . . . . . . . . . . . . . . . 6 57 3.2 Keying Material . . . . . . . . . . . . . . . . . . . . . . 6 58 4. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5. IKE Interactions . . . . . . . . . . . . . . . . . . . . . . . . 10 60 5.1 Phase 1 Identifier . . . . . . . . . . . . . . . . . . . . . 10 61 5.2 Phase 2 Identifier . . . . . . . . . . . . . . . . . . . . . 10 62 5.3 Key Length Attribute . . . . . . . . . . . . . . . . . . . . 10 63 5.4 Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . . 10 64 5.4.1 Relative Strength . . . . . . . . . . . . . . . . . . 11 65 5.5 Hash Algorithm Considerations . . . . . . . . . . . . . . . 12 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 12 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 12 68 8. Intellectual Property Rights Statement . . . . . . . . . . . . . 12 69 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 13 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 72 12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 16 73 1. Introduction 75 As the culmination of a four-year competitive process, NIST (the Na- 76 tional Institute of Standards and Technology) has selected the AES 77 (Advanced Encryption Standard), the successor to the venerable DES. 78 The competition was an open one, with public participation and com- 79 ment solicited at each step of the process. The AES [AES], formerly 80 known as Rijndael, was chosen from a field of five finalists. 82 The AES selection was made on the basis of several characteristics: 84 + security 86 + unclassified 88 + publicly disclosed 90 + available royalty-free worldwide 92 + capable of handling a block size of at least 128 bits 94 + at a minimum, capable of handling key sizes of 128, 192, and 95 256 bits 97 + computational efficiency and memory requirements on a variety 98 of software and hardware, including smart cards 100 + flexibility, simplicity and ease of implementation 102 The AES will be the government's designated encryption cipher. The 103 expectation is that the AES will suffice to protect sensitive 104 (unclassified) government information at least until the next cen- 105 tury. It is also expected to be widely adopted by businesses and 106 financial institutions. 108 It is the intention of the IETF IPsec Working Group that AES will 109 eventually be adopted as the default IPsec ESP cipher and will obtain 110 the status of MUST be included in compliant IPsec implementations. 112 The remainder of this document specifies the use of the AES within 113 the context of IPsec ESP. For further information on how the various 114 pieces of ESP fit together to provide security services, refer to 115 [ARCH], [ESP], and [ROAD]. 117 1.1 Specification of Requirements 119 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" that 121 appear in this document are to be interpreted as described in 122 [RFC-2119]. 124 2. The AES Cipher Algorithm 126 All symmetric block cipher algorithms share common characteristics 127 and variables, including mode, key size, weak keys, block size, and 128 rounds. The following sections contain descriptions of the relevant 129 characteristics of the AES cipher. 131 2.1 Mode 133 NIST has defined 5 modes of operation for AES and other FIPS-approved 134 ciphers [MODES]: CBC (Cipher Block Chaining), ECB (Electronic Code- 135 Book), CFB (Cipher FeedBack), OFB (Output FeedBack) and CTR 136 (Counter). The CBC mode is well-defined and well-understood for sym- 137 metric ciphers, and is currently required for all other ESP ciphers. 139 This document specifies the use of the AES cipher in CBC mode within 140 ESP. This mode requires an Initialization Vector (IV) that is the 141 same size as the block size. Use of a randomly generated IV prevents 142 generation of identical ciphertext from packets which have identical 143 data that spans the first block of the cipher algorithm's block size. 145 The IV is XOR'd with the first plaintext block before it is 146 encrypted. Then for successive blocks, the previous ciphertext block 147 is XOR'd with the current plaintext, before it is encrypted. 149 More information on CBC mode can be obtained in [MODES, CRYPTO-S]. 150 For the use of CBC mode in ESP with 64-bit ciphers, see [CBC]. 152 2.2 Key Size 154 Some cipher algorithms allow for variable sized keys, while others 155 only allow specific, pre-defined key sizes. The length of the key 156 typically correlates with the strength of the algorithm; thus larger 157 keys are usually harder to break than shorter ones. 159 This document specifies the default (i.e. MUST be supported) key size 160 for the AES cipher algorithm. The default key size that implementa- 161 tions MUST support for IPsec is 128 bits. In addition, implementa- 162 tions MAY support key sizes of 192 and 256 bits. 164 2.3 Weak Keys 166 At the time of writing this document there are no known weak keys for 167 the AES. 169 Some cipher algorithms have weak keys or keys that MUST not be used 170 due to their interaction with some aspect of the cipher's definition. 171 If weak keys are discovered for the AES, then weak keys SHOULD be 172 checked for and discarded when using manual key management. When 173 using dynamic key management, such as [IKE], weak key checks SHOULD 174 NOT be performed as they are seen as an unnecessary added code com- 175 plexity that could weaken the intended security [EVALUATION]. 177 2.4 Block Size and Padding 179 The AES uses a block size of sixteen octets (128 bits). 181 Padding is required by the AES to maintain a 16-octet (128-bit) 182 blocksize. Padding MUST be added, as specified in [ESP], such that 183 the data to be encrypted (which includes the ESP Pad Length and Next 184 Header fields) has a length that is a multiple of 16 octets. 186 Because of the algorithm specific padding requirement, no additional 187 padding is required to ensure that the ciphertext terminates on a 188 4-octet boundary (i.e. maintaining a 16-octet blocksize guarantees 189 that the ESP Pad Length and Next Header fields will be right aligned 190 within a 4-octet word). Additional padding MAY be included, as 191 specifed in [ESP], as long as the 16-octet blocksize is maintained. 193 2.5 Rounds 195 This variable determines how many times a block is encrypted. While 196 this variable MAY be negotiated, a default value MUST always exist 197 when it is not negotiated. Within IPsec, the AES MUST support 10 198 rounds, corresponding to the mandatory 128-bit keysize. 200 The AES's default number of rounds is 12 for a 192-bit keysize and 14 201 for a 256-bit keysize. 203 2.6 Additional Information 205 AES was invented by Joan Daemen from Banksys/PWI and Vincent Rijmen 206 from ESAT-COSIC, both in Belgium, and is available world-wide on a 207 royalty-free basis. It is not covered by any patents, and the Rijn- 208 dael homepage contains the following statement: "Rijndael is avail- 209 able for free. You can use it for whatever purposes you want, irre- 210 spective of whether it is accepted as AES or not." AES's description 211 can be found in [AES]. The Rijndael homepage is: 212 http://www.esat.kuleuven.ac.be/~rijmen/rijndael/. 214 The AES homepage, http://www.nist.gov/aes, contains a wealth of in- 215 formation about the AES, including a definitive description of the 216 AES algorithm, performance statistics, test vectors and intellectual 217 property information. This site also contains information on how to 218 obtain an AES reference implementation from NIST. 220 2.7 Performance 222 For a comparison table of the estimated speeds of AES and other ci- 223 pher algorithms, please see [PERF-1], [PERF-2], [PERF-3], or 224 [PERF-4]. The AES homepage has pointers to other analyses. 226 3. ESP Payload 228 The ESP payload is made up of the IV followed by raw cipher-text. 229 Thus the payload field, as defined in [ESP], is broken down according 230 to the following diagram: 232 +---------------+---------------+---------------+---------------+ 233 | | 234 + Initialization Vector (16 octets) + 235 | | 236 +---------------+---------------+---------------+---------------+ 237 | | 238 ~ Encrypted Payload (variable length, a multiple of 16 octets) ~ 239 | | 240 +---------------------------------------------------------------+ 242 The IV field MUST be the same size as the block size of the cipher 243 algorithm being used. The IV MUST be chosen at random, and MUST be 244 unpredictable. 246 Including the IV in each datagram ensures that decryption of each re- 247 ceived datagram can be performed, even when some datagrams are 248 dropped, or datagrams are re-ordered in transit. 250 To avoid CBC encryption of very similar plaintext blocks in different 251 packets, implementations MUST NOT use a counter or other low-Hamming 252 distance source for IVs. 254 3.1 ESP Algorithmic Interactions 256 Currently, there are no known issues regarding interactions between 257 the AES and other aspects of ESP, such as use of certain authentica- 258 tion schemes. 260 3.2 Keying Material 262 The minimum number of bits sent from the key exchange protocol to the 263 ESP algorithm must be greater than or equal to the key size. 265 The cipher's encryption and decryption key is taken from the first 266 bits of the keying material, where represents the required 267 key size. 269 4. Test Vectors 271 The first 4 test cases test AES-CBC encryption. Each test case in- 272 cludes the key, the plaintext, and the resulting ciphertext. The 273 values of keys and data are either hexadecimal numbers (prefixed by 274 "0x") or ASCII character strings (surrounded by double quotes). If a 275 value is an ASCII character string, then the AES-CBC computation for 276 the corresponding test case DOES NOT include the trailing null char- 277 acter ('\0') of the string. The computed cyphertext values are all 278 hexadecimal numbers. 280 The last 4 test cases illustrate sample ESP packets using AES-CBC for 281 encryption. All data are hexadecimal numbers (not prefixed by "0x"). 283 These test cases were verified using 2 independent implementations: 284 the NIST AES-CBC reference implementation and an implementation pro- 285 vided by the authors of the Rijndael algorithm 286 (http://csrc.nist.gov/encryption/aes/rijndael/ 287 rijndael-unix-refc.tar). 289 Case #1: Encrypting 16 bytes (1 blocks) using AES-CBC with 128-bit key 290 Key : 0x06a9214036b8a15b512e03d534120006 291 IV : 0x3dafba429d9eb430b422da802c9fac41 292 Plaintext : "Single block msg" 293 Ciphertext: 0xe353779c1079aeb82708942dbe77181a 295 Case #2: Encrypting 32 bytes (2 blocks) using AES-CBC with 128-bit key 296 Key : 0xc286696d887c9aa0611bbb3e2025a45a 297 IV : 0x562e17996d093d28ddb3ba695a2e6f58 298 Plaintext : 0x000102030405060708090a0b0c0d0e0f 299 101112131415161718191a1b1c1d1e1f 300 Ciphertext: 0xd296cd94c2cccf8a3a863028b5e1dc0a 301 7586602d253cfff91b8266bea6d61ab1 303 Case #3: Encrypting 48 bytes (3 blocks) using AES-CBC with 128-bit key 304 Key : 0x6c3ea0477630ce21a2ce334aa746c2cd 305 IV : 0xc782dc4c098c66cbd9cd27d825682c81 306 Plaintext : "This is a 48-byte message (exactly 3 AES blocks)" 307 Ciphertext: 0xd0a02b3836451753d493665d33f0e886 308 2dea54cdb293abc7506939276772f8d5 309 021c19216bad525c8579695d83ba2684 311 Case #4: Encrypting 64 bytes (4 blocks) using AES-CBC with 128-bit key 312 Key : 0x56e47a38c5598974bc46903dba290349 313 IV : 0x8ce82eefbea0da3c44699ed7db51b7d9 314 Plaintext : 0xa0a1a2a3a4a5a6a7a8a9aaabacadaeaf 315 b0b1b2b3b4b5b6b7b8b9babbbcbdbebf 316 c0c1c2c3c4c5c6c7c8c9cacbcccdcecf 317 d0d1d2d3d4d5d6d7d8d9dadbdcdddedf 318 Ciphertext: 0xc30e32ffedc0774e6aff6af0869f71aa 319 0f3af07a9a31a9c684db207eb0ef8e4e 320 35907aa632c3ffdf868bb7b29d3d46ad 321 83ce9f9a102ee99d49a53e87f4c3da55 323 Case #5: Sample transport-mode ESP packet (ping 192.168.123.100) 324 Key: 90d382b4 10eeba7a d938c46c ec1a82bf 325 SPI: 4321 326 Source address: 192.168.123.3 327 Destination address: 192.168.123.100 328 Sequence number: 1 329 IV: e96e8c08 ab465763 fd098d45 dd3ff893 331 Original packet: 332 IP header (20 bytes): 45000054 08f20000 4001f9fe c0a87b03 c0a87b64 333 Data (64 bytes): 334 08000ebd a70a0000 8e9c083d b95b0700 08090a0b 0c0d0e0f 10111213 14151617 335 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637 337 Augment data with: 338 Padding: 01020304 05060708 090a0b0c 0d0e 339 Pad length: 0e 340 Next header: 01 (ICMP) 342 Pre-encryption Data with padding, pad length and next header (80 bytes): 343 08000ebd a70a0000 8e9c083d b95b0700 08090a0b 0c0d0e0f 10111213 14151617 344 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637 345 01020304 05060708 090a0b0c 0d0e0e01 347 Post-encryption packet with SPI, Sequence number, IV: 348 IP header: 4500007c 08f20000 4032f9a5 c0a87b03 c0a87b64 349 SPI/Seq #: 00004321 00000001 350 IV: e96e8c08 ab465763 fd098d45 dd3ff893 351 Encrypted Data (80 bytes): 352 f663c25d 325c18c6 a9453e19 4e120849 a4870b66 cc6b9965 330013b4 898dc856 353 a4699e52 3a55db08 0b59ec3a 8e4b7e52 775b07d1 db34ed9c 538ab50c 551b874a 354 a269add0 47ad2d59 13ac19b7 cfbad4a6 356 Case #6: Sample transport-mode ESP packet (ping -p 77 -s 20 192.168.123.100) 357 Key: 90d382b4 10eeba7a d938c46c ec1a82bf 358 SPI: 4321 359 Source address: 192.168.123.3 360 Destination address: 192.168.123.100 361 Sequence number: 8 362 IV: 69d08df7 d203329d b093fc49 24e5bd80 364 Original packet: 365 IP header (20 bytes): 45000030 08fe0000 4001fa16 c0a87b03 c0a87b64 366 Data (28 bytes): 367 0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777 369 Augment data with: 370 Padding: 0102 371 Pad length: 02 372 Next header: 01 (ICMP) 374 Pre-encryption Data with padding, pad length and next header (32 bytes): 375 0800b5e8 a80a0500 a69c083d 0b660e00 77777777 77777777 77777777 01020201 377 Post-encryption packet with SPI, Sequence number, IV: 378 IP header: 4500004c 08fe0000 4032f9c9 c0a87b03 c0a87b64 379 SPI/Seq #: 00004321 00000008 380 IV: 69d08df7 d203329d b093fc49 24e5bd80 381 Encrypted Data (32 bytes): 382 f5199588 1ec4e0c4 488987ce 742e8109 689bb379 d2d750c0 d915dca3 46a89f75 384 Case #7: Sample tunnel-mode ESP packet (ping 192.168.123.200) 385 Key: 01234567 89abcdef 01234567 89abcdef 386 SPI: 8765 387 Source address: 192.168.123.3 388 Destination address: 192.168.123.200 389 Sequence number: 2 390 IV: f4e76524 4f6407ad f13dc138 0f673f37 392 Original packet: 393 IP header (20 bytes): 45000054 09040000 4001f988 c0a87b03 c0a87bc8 394 Data (64 bytes): 395 08009f76 a90a0100 b49c083d 02a20400 08090a0b 0c0d0e0f 10111213 14151617 396 18191a1b 1c1d1e1f 20212223 24252627 28292a2b 2c2d2e2f 30313233 34353637 398 Augment data with: 399 Padding: 01020304 05060708 090a 400 Pad length: 0a 401 Next header: 04 (IP-in-IP) 403 Pre-encryption Data with original IP header, padding, pad length and 404 next header (96 bytes): 405 45000054 09040000 4001f988 c0a87b03 c0a87bc8 08009f76 a90a0100 b49c083d 406 02a20400 08090a0b 0c0d0e0f 10111213 14151617 18191a1b 1c1d1e1f 20212223 407 24252627 28292a2b 2c2d2e2f 30313233 34353637 01020304 05060708 090a0a04 409 Post-encryption packet with SPI, Sequence number, IV: 410 IP header: 4500008c 09050000 4032f91e c0a87b03 c0a87bc8 411 SPI/Seq #: 00008765 00000002 412 IV: f4e76524 4f6407ad f13dc138 0f673f37 413 Encrypted Data (96 bytes): 414 773b5241 a4c44922 5e4f3ce5 ed611b0c 237ca96c f74a9301 3c1b0ea1 a0cf70f8 415 e4ecaec7 8ac53aad 7a0f022b 859243c6 47752e94 a859352b 8a4d4d2d ecd136e5 416 c177f132 ad3fbfb2 201ac990 4c74ee0a 109e0ca1 e4dfe9d5 a100b842 f1c22f0d 418 Case #8: Sample tunnel-mode ESP packet (ping -p ff -s 40 192.168.123.200) 419 Key: 01234567 89abcdef 01234567 89abcdef 420 SPI: 8765 421 Source address: 192.168.123.3 422 Destination address: 192.168.123.200 423 Sequence number: 5 424 IV: 85d47224 b5f3dd5d 2101d4ea 8dffab22 426 Original packet: 427 IP header (20 bytes): 45000044 090c0000 4001f990 c0a87b03 c0a87bc8 428 Data (48 bytes): 429 0800d63c aa0a0200 c69c083d a3de0300 ffffffff ffffffff ffffffff ffffffff 430 ffffffff ffffffff ffffffff ffffffff 432 Augment data with: 433 Padding: 01020304 05060708 090a 434 Pad length: 0a 435 Next header: 04 (IP-in-IP) 437 Pre-encryption Data with original IP header, padding, pad length and 438 next header (80 bytes): 439 45000044 090c0000 4001f990 c0a87b03 c0a87bc8 0800d63c aa0a0200 c69c083d 440 a3de0300 ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff 441 ffffffff 01020304 05060708 090a0a04 443 Post-encryption packet with SPI, Sequence number, IV: 444 IP header: 4500007c 090d0000 4032f926 c0a87b03 c0a87bc8 445 SPI/Seq #: 00008765 00000005 446 IV: 85d47224 b5f3dd5d 2101d4ea 8dffab22 447 Encrypted Data (80 bytes): 449 15b92683 819596a8 047232cc 00f7048f e45318e1 1f8a0f62 ede3c3fc 61203bb5 450 0f980a08 c9843fd3 a1b06d5c 07ff9639 b7eb7dfb 3512e5de 435e7207 ed971ef3 451 d2726d9b 5ef6affc 6d17a0de cbb13892 453 5. IKE Interactions 455 5.1 Phase 1 Identifier 457 For Phase 1 negotiations, IANA has assigned an Encryption Algorithm 458 ID of 7 for AES-CBC. 460 5.2 Phase 2 Identifier 462 For Phase 2 negotiations, IANA has assigned an ESP Transform Identi- 463 fier of 12 for ESP_AES. 465 5.3 Key Length Attribute 467 Since the AES allows variable key lengths, the Key Length attribute 468 MUST be specified in both a Phase 1 exchange [IKE] and a Phase 2 ex- 469 change [DOI]. 471 5.4 Diffie-Hellman Groups 473 The Diffie-Hellman algorithm is the basis of cryptographic key ex- 474 change within IPsec. The algorithm may be implemented using either 475 "MODP" (modulus-exponent) groups or "EC" (elliptic curve) groups. The 476 general procedure is as follows: the initiator chooses a random expo- 477 nent x with K bits of entropy that is 2K bits in length (the K bits 478 may be hashed to produce 2K bits), and then computes g^x using the 479 group operation: 481 X = g^x 483 For MODP the group operation is modular multiplication, while for EC 484 the operation is point addition on the curve. The notation "g^x" 485 means "iterate the group operation x times". X is then sent to the 486 responder. The responder chooses a secret number y, and similarly 487 computes 489 Y = g^y 491 which is in turn sent to the initiator. At this point, both the ini- 492 tiator and responder may compute a shared secret value by combining 493 their own secret value with the exponential and applying the group 494 operation: 496 Z = g^(xy) = Y^x = X^y 498 From Z, both derive identical cryptographic keys. 500 This description is simplified in the interest of brevity, and an in- 501 depth description of this mechanism is beyond the scope of this memo. 502 For further details, refer to the wealth of published literature on 503 this topic. 505 5.4.1 Relative Strength 507 The relative strength of the encryption keys derived via the Diffie- 508 Hellman exchange may be characterized in terms the randomness of the 509 participant's exponents and the strength of the Diffie-Hellman group; 510 if an exponent has at least 128 completely random bits, it is said 511 to have 128-bits of "entropy". If the Diffie-Hellman group cannot be 512 broken in less time than searching a 128-bit key space, then the de- 513 rived 128-bit key is said to have 128 bits of "strength". For an in- 514 depth discussion regarding relative strength of values derived from 515 DH exchanges, see [KEYLEN]. 517 In some cases, one may choose to settle for an amount of entropy 518 which is less than that of a completely random key of the given size. 519 There are numerous reasons for making such a choice, among which 520 might include a concern for the computational effort required to com- 521 plete the key exchange. For example, the following table lists recom- 522 mended modulus and exponent sizes for various key lengths using ei- 523 ther MODP or EC groups. 525 +===========+=================+================+===============+ 526 | Key Size | Exponent Size | Modulus Size | Group Type | 527 +===========+=================+================+===============+ 528 | 128 | 256 | 3240 | MODP | 529 +-----------+-----------------+----------------+---------------+ 530 | 192 | 384 | 7945 | MODP | 531 +-----------+-----------------+----------------+---------------+ 532 | 256 | 512 | 15430 | MODP | 533 +-----------+-----------------+----------------+---------------+ 534 | 128 | 248 | 248 | EC2N | 535 +-----------+-----------------+----------------+---------------+ 536 | 192 | 376 | 376 | EC2N | 537 +-----------+-----------------+----------------+---------------+ 538 | 256 | 504 | 504 | EC2N | 539 +-----------+-----------------+----------------+---------------+ 541 NOTE: This table is based on Section 4.5 in [KEYLEN] 543 Note that the sizes of the moduli and exponents for the MODP groups 544 in the table above are very large, and the computational effort re- 545 quired to complete the exponentiation and modulo operations with such 546 large values is quite significant using hardware commonly available 547 in the year 2002. If such considerations are deemed important, then 548 keys larger than 128 bits SHOULD NOT be used. Further, if it is de- 549 termined that less than 128 bits of strength will suffice for the se- 550 curity requirements of the given application, then smaller exponents 551 and moduli may be used. 553 [GROUPS] defines four additional Diffie-Hellman MODP groups for IKE. 554 Two of these groups, a 3072-bit MODP group and a 4096-bit MODP group, 555 could be used to establish 128-bit AES keys. [IKE-ECC] defines four 556 additional Diffie-Hellman ECC groups for IKE. Two of these groups, 557 Group 8 and 9, both of which are 283-bit ECC groups, could be used to 558 establish 128-bit AES keys. Additional information about the rela- 559 tionship between the group governing a Diffie-Hellman exchange and 560 the symmetric keys derived from the exchange can be found in 561 [KEYLEN]. 563 5.5 Hash Algorithm Considerations 565 A companion competition, to select the successor to SHA-1, the wide- 566 ly-used hash algorithm, recently concluded. The resulting hashes, 567 called SHA-256, SHA-384 and SHA-512 [SHA2-1, SHA2-2] are capable of 568 producing output of three different lengths (256, 384 and 512 bits), 569 sufficient for the generation (within IKE) and authentication (within 570 ESP) of the three AES key sizes (128, 192 and 256 bits). IANA has 571 already assigned Phase 1 Hash Algorithm values of 4, 5 and 6 to 572 SHA2-256, SHA2-384, and SHA2-512. IANA has also assigned AH Trans- 573 form Identifiers of 5, 6 and 7 to AH_SHA2-256, AH_SHA2-384, and 574 AH_SHA2-512.) 576 However, HMAC-SHA-1 [HMAC-SHA] and HMAC-MD5 [HMAC-MD5] are currently 577 considered of sufficient strength to serve both as IKE generators of 578 128-bit AES keys and as ESP authenticators for AES encryption using 579 128-bit keys. 581 6. Security Considerations 583 Implementations are encouraged to use the largest key sizes they can 584 when taking into account performance considerations for their partic- 585 ular hardware and software configuration. Note that encryption nec- 586 essarily impacts both sides of a secure channel, so such considera- 587 tion must take into account not only the client side, but the server 588 as well. However, a key size of 128 bits is considered secure for the 589 foreseeable future. 591 For more information regarding the necessary use of random IV values, 592 see [CRYPTO-B]. 594 For further security considerations, the reader is encouraged to read 595 [AES]. 597 7. IANA Considerations 599 IANA has assigned Encryption Algorithm ID 7 to AES-CBC. 600 IANA has assigned ESP Transform Identifier 12 to ESP_AES. 602 8. Intellectual Property Rights Statement 604 Pursuant to the provisions of [RFC-2026], the authors represent that 605 they have disclosed the existence of any proprietary or intellectual 606 property rights in the contribution that are reasonably and personal- 607 ly known to the authors. The authors do not represent that they per- 608 sonally know of all potentially pertinent proprietary and intellectu- 609 al property rights owned or claimed by the organizations they repre- 610 sent or third parties. 612 The IETF takes no position regarding the validity or scope of any in- 613 tellectual property or other rights that might be claimed to pertain 614 to the implementation or use of the technology described in this doc- 615 ument or the extent to which any license under such rights might or 616 might not be available; neither does it represent that it has made 617 any effort to identify any such rights. Information on the IETF's 618 procedures with respect to rights in standards-track and standards- 619 related documentation can be found in BCP-11. Copies of claims of 620 rights made available for publication and any assurances of licenses 621 to be made available, or the result of an attempt made to obtain a 622 general license or permission for the use of such proprietary rights 623 by implementers or users of this specification can be obtained from 624 the IETF Secretariat. 626 9. Acknowledgments 628 Portions of this text, as well as its general structure, were un- 629 abashedly lifted from [CBC]. 631 The authors want to thank Hilarie Orman for providing expert advice 632 (and a sanity check) on key sizes, requirements for Diffie-Hellman 633 groups, and IKE interactions. We also thank Scott Fluhrer for his 634 helpful comments and recommendations. 636 10. References 638 [AES] NIST, FIPS PUB 197, "Advanced Encryption Standard 639 (AES)," November 2001. 640 http://csrc.nist.gov/publications/fips/fips197/fips-197.{ps,pdf} 642 [ARCH] Kent, S. and R. Atkinson, "Security Architecture for 643 the Internet Protocol", RFC 2401, November 1998. 645 [CBC] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher 646 Algorithms," RFC 2451, November 1998. 648 [CRYPTO-B] Bellovin, S., "Probable Plaintext Cryptanalysis of the 649 IP Security Protocols", Proceedings of the Symposium on 650 Network and Distributed System Security, San Diego, CA, 651 pp. 155-160, February 1997. 652 http://www.research.att.com/~smb/papers/probtxt.{ps, pdf} 654 [CRYPTO-S] B. Schneier, "Applied Cryptography Second Edition", 655 John Wiley & Sons, New York, NY, 1995, ISBN 656 0-471-12845-7. 658 [DOI] Piper, D., "The Internet IP Security Domain of 659 Interpretation for ISAKMP," RFC 2407, November 1998. 661 [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security 662 Payload (ESP)", RFC 2406, November 1998. 664 [EVALUATION] 665 Ferguson, N. and B. Schneier, "A Cryptographic 666 Evaluation of IPsec," Counterpane Internet Security, 667 Inc., January 2000. 668 http://www.counterpane.com/ipsec.{pdf,ps.zip} 670 [GROUPS] Kivinen, T. and M. Kojo, "More MODP Diffie-Hellman 671 groups for IKE," draft-ietf-ipsec-ike-modp- 672 groups-00.txt, October 2000. 674 [HMAC-MD5] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within 675 ESP and AH," RFC 2403, November 1998. 677 [HMAC-SHA] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 678 within ESP and AH," RFC 2404, November 1998. 680 [IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange 681 (IKE)", RFC 2409, November 1998. 683 [IKE-ECC] Panjwani, P. and Y. Poeluev, "Additional ECC Groups For 684 IKE," draft-ietf-ipsec-ike-ecc-groups-02.txt, May 2000. 686 [KEYLEN] Orman, H. and P. Hoffman, "Determining Strengths For 687 Public Keys Used For Exchanging Symmetric Keys," draft- 688 orman-public-key-lengths-01.txt, August 2000. 690 [MODES] Dworkin, M., "Recommendation for Block Cipher Modes of 691 Operation: Methods and Techniques," NIST Special 692 Publication 800-38A, December 2001. 693 http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf 695 [PERF-1] Bassham, L. III, "Efficiency Testing of ANSI C 696 Implementations of Round1 Candidate Algorithms for the 697 Advanced Encryption Standard." 698 http://csrc.nist.gov/encryption/aes/round1/r1-ansic.pdf 700 [PERF-2] Lipmaa, Helger, "AES/Rijndael: speed." 701 http://www.tcs.hut.fi/~helger/aes/rijndael.html 703 [PERF-3] Nechvetal, J., E. Barker, D. Dodson, M. Dworkin, J. 704 Foti and E. Roback, "Status Report on the First Round 705 of the Development of the Advanced Encryption 706 Standard." 707 http://csrc.nist.gov/encryption/aes/round1/r1report.pdf 709 [PERF-4] Schneier, B., J. Kelsey, D. Whiting, D. Wagner, C. 710 Hall, and N. Ferguson, "Performance Comparison of the 711 AES Submissions." 712 http://www.counterpane.com/aes-performance.{pdf,ps.zip} 714 [RFC-2026] Bradner, S., "The Internet Standards Process -- 715 Revision 3", RFC2026, October 1996. 717 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 718 Requirement Levels", RFC 2119, March 1997. 720 [ROAD] Thayer, R., N. Doraswamy and R. Glenn, "IP Security 721 Document Roadmap", RFC 2411, November 1998. 723 [SHA2-1] NIST, Draft FIPS PUB 180-2 "Specifications for the 724 Secure Hash Standard," May 2001. 725 http://csrc.nist.gov/encryption/shs/dfips-180-2.pdf 727 [SHA2-2] "Descriptions of SHA-256, SHA-384, and SHA-512." 728 http://csrc.nist.gov/cryptval/shs/sha256-384-512.pdf 730 11. Authors' Addresses 732 Sheila Frankel 733 NIST 734 820 West Diamond Ave. 735 Room 680 736 Gaithersburg, MD 20899 737 Phone: +1 (301) 975-3297 738 Email: sheila.frankel@nist.gov 740 Scott Kelly 741 Black Storm Networks 742 250 Cambridge Ave 743 Palo Alto CA 94304 744 Phone: +1 (650) 617-2934 745 Email: scott@bstormnetworks.com 747 Rob Glenn 748 NIST 749 820 West Diamond Ave. 750 Room 605 751 Gaithersburg, MD 20899 752 Phone: +1 (301) 975-3667 753 Email: rob.glenn@nist.gov 755 The IPsec working group can be contacted through the chairs: 757 Barbara Fraser 758 Cisco Systems Inc. 759 Email: byfraser@cisco.com 761 Theodore Ts'o 762 Massachusetts Institute of Technology 763 Email: tytso@mit.edu 765 12. Full Copyright Statement 767 Copyright (C) The Internet Society (1998). All Rights Reserved. 769 This document and translations of it may be copied and furnished to 770 others, and derivative works that comment on or otherwise explain it 771 or assist in its implementation may be prepared, copied, published 772 and distributed, in whole or in part, without restriction of any 773 kind, provided that the above copyright notice and this paragraph are 774 included on all such copies and derivative works. However, this doc- 775 ument itself may not be modified in any way, such as by removing the 776 copyright notice or references to the Internet Society or other In- 777 ternet organizations, except as needed for the purpose of developing 778 Internet standards in which case the procedures for copyrights de- 779 fined in the Internet Standards process must be followed, or as re- 780 quired to translate it into languages other than English. 782 The limited permissions granted above are perpetual and will not be 783 revoked by the Internet Society or its successors or assigns. 785 This document and the information contained herein is provided on an 786 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 787 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 788 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HERE- 789 IN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 790 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.