idnits 2.17.1 draft-ietf-ipsec-ciph-aes-ctr-05.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 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 (July 2003) is 7590 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 173 -- Looks like a reference, but probably isn't: '2' on line 173 -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' ** 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. 'MODES' -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. 'ARCH') (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2411 (ref. 'ROADMAP') (Obsoleted by RFC 6071) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPsec Working Group R. Housley 3 Internet Draft Vigil Security 4 expires in six months July 2003 6 Using AES Counter Mode With IPsec ESP 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute 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-Draft 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. Please send comments on this document to the 31 working group mailing list (ipsec@lists.tislabs.com). 33 Distribution of this memo is unlimited. 35 Abstract 37 This document describes the use of AES Counter Mode, with an explicit 38 initialization vector, as an IPsec Encapsulating Security Payload 39 confidentiality mechanism. 41 Table of Contents 43 1 Introduction .............................................. 3 44 1.1 Conventions Used In This Document ......................... 3 45 2 AES Block Cipher .......................................... 3 46 2.1 Counter Mode .............................................. 3 47 2.2 Key Size and Rounds ....................................... 5 48 2.3 Block Size ................................................ 6 49 3 ESP Payload ............................................... 6 50 3.1 Initialization Vector ..................................... 6 51 3.2 Encrypted Payload ......................................... 7 52 3.3 Authentication Data ....................................... 7 53 4 Counter Block Format ...................................... 7 54 5 IKE Conventions ........................................... 8 55 5.1 Keying Material and Nonces ................................ 8 56 5.2 Phase 1 Identifier ........................................ 9 57 5.3 Phase 2 Identifier ........................................ 9 58 5.4 Key Length Attribute ...................................... 9 59 6 Test Vectors .............................................. 9 60 7 Security Considerations ................................... 13 61 8 Design Rationale .......................................... 15 62 9 IANA Considerations ....................................... 16 63 10 Acknowledgments ........................................... 17 64 11 References ................................................ 17 65 11.1 Normative References ...................................... 17 66 11.2 Informative References .................................... 17 67 12 Author's Address .......................................... 18 68 13 Full Copyright Statement .................................. 19 70 1. Introduction 72 The National Institute of Standards and Technology (NIST) recently 73 selected the Advanced Encryption Standard (AES) [AES], also known as 74 Rijndael. The AES is a block cipher, and it can be used in many 75 different modes. This document describes the use of AES Counter Mode 76 (AES-CTR), with an explicit initialization vector (IV), as an IPsec 77 Encapsulating Security Payload (ESP) [ESP] confidentiality mechanism. 79 This document does not provide an overview of IPsec. However, 80 information about how the various components of IPsec and the way in 81 which they collectively provide security services is available in 82 [ARCH] and [ROADMAP]. 84 1.1. Conventions Used In This Document 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [STDWORDS]. 90 2. AES Block Cipher 92 This section contains a brief description of the relevant 93 characteristics of the AES block cipher. Implementation requirements 94 are also discussed. 96 2.1. Counter Mode 98 NIST has defined five modes of operation for AES and other FIPS- 99 approved block ciphers [MODES]. Each of these modes has different 100 characteristics. The five modes are: ECB (Electronic Code Book), CBC 101 (Cipher Block Chaining), CFB (Cipher FeedBack), OFB (Output 102 FeedBack), and CTR (Counter). 104 Only AES Counter mode (AES-CTR) is discussed in this specification. 105 AES-CTR requires the encryptor to generate a unique per-packet value, 106 and communicate this value to the decryptor. This specification 107 calls this per-packet value an initialization vector (IV). The same 108 IV and key combination MUST NOT be used more than once. The 109 encryptor can generate the IV in any manner that ensures uniqueness. 110 Common approaches to IV generation include incrementing a counter for 111 each packet and linear feedback shift registers (LFSRs). 113 This specification calls for the use of a nonce for additional 114 protection against precomputation attacks. The nonce value need not 115 be secret. However, the nonce MUST be unpredictable prior to the 116 establishment of the IPsec security association that is making use of 117 AES-CTR. 119 AES-CTR has many properties that make it an attractive encryption 120 algorithm for in high-speed networking. AES-CTR uses the AES block 121 cipher to create a stream cipher. Data is encrypted and decrypted by 122 XORing with the key stream produced by AES encrypting sequential 123 counter block values. AES-CTR is easy to implement, and AES-CTR can 124 be pipelined and parallelized. AES-CTR also supports key stream 125 precomputation. 127 Pipelining is possible because AES has multiple rounds (see section 128 2.2). A hardware implementation (and some software implementations) 129 can create a pipeline by unwinding the loop implied by this round 130 structure. For example, after a 16-octet block has been input, one 131 round later another 16-octet block can be input, and so on. In AES- 132 CTR, these inputs are the sequential counter block values used to 133 generate the key stream. 135 Multiple independent AES encrypt implementations can also be used to 136 improve performance. For example, one could use two AES encrypt 137 implementations in parallel, to process a sequence of counter block 138 values, doubling the effective throughput. 140 The sender can precompute the key stream. Since the key stream does 141 not depend on any data in the packet, the key stream can be 142 precomputed once the nonce and IV are assigned. This precomputation 143 can reduce packet latency. The receiver cannot perform similar 144 precomputation because the IV will not be known before the packet 145 arrives. 147 AES-CTR uses the only AES encrypt operation (for both encryption and 148 decryption), making AES-CTR implementations smaller than 149 implementations of many other AES modes. 151 When used correctly, AES-CTR provides a high level of 152 confidentiality. Unfortunately, AES-CTR is easy to use incorrectly. 153 Being a stream cipher, any reuse of the per-packet value, called the 154 IV, with the same nonce and key is catastrophic. An IV collision 155 immediately leaks information about the plaintext in both packets. 156 For this reason, it is inappropriate to use this mode of operation 157 with static keys. Extraordinary measures would be needed to prevent 158 reuse of an IV value with the static key across power cycles. To be 159 safe, implementations MUST use fresh keys with AES-CTR. The Internet 160 Key Exchange (IKE) [IKE] protocol can be used to establish fresh 161 keys. IKE can also provide the nonce value. 163 With AES-CTR, it is trivial to use a valid ciphertext to forge other 164 (valid to the decryptor) ciphertexts. Thus, it is equally 165 catastrophic to use AES-CTR without a companion authentication 166 function. Implementations MUST use AES-CTR in conjunction with an 167 authentication function, such as HMAC-SHA-1-96 [HMAC-SHA]. 169 To encrypt a payload with AES-CTR, the encryptor partitions the 170 plaintext, PT, into 128-bit blocks. The final block need not be 128 171 bits; it can be less. 173 PT = PT[1] PT[2] ... PT[n] 175 Each PT block is XORed with a block of the key stream to generate the 176 ciphertext, CT. The AES encryption of each counter block results in 177 128 bits of key stream. The most significant 96 bits of the counter 178 block are set to the nonce value, which is 32 bits, followed by the 179 per-packet IV value, which is 64 bits. The least significant 32 bits 180 of the counter block are initially set to one. This counter value is 181 incremented by one to generate subsequent counter blocks, each 182 resulting in another 128 bits of key stream. The encryption of n 183 plaintext blocks can be summarized as: 185 CTRBLK := NONCE || IV || ONE 186 FOR i := 1 to n-1 DO 187 CT[i] := PT[i] XOR AES(CTRBLK) 188 CTRBLK := CTRBLK + 1 189 END 190 CT[n] := PT[n] XOR TRUNC(AES(CTRBLK)) 192 The AES() function performs AES encryption with the fresh key. 194 The TRUNC() function truncates the output of the AES encrypt 195 operation to the same length as the final plaintext block, returning 196 the most significant bits. 198 Decryption is similar. The decryption of n ciphertext blocks can be 199 summarized as: 201 CTRBLK := NONCE || IV || ONE 202 FOR i := 1 to n-1 DO 203 PT[i] := CT[i] XOR AES(CTRBLK) 204 CTRBLK := CTRBLK + 1 205 END 206 PT[n] := CT[n] XOR TRUNC(AES(CTRBLK)) 208 2.2. Key Size and Rounds 210 AES supports three key sizes: 128 bits, 192 bits, and 256 bits. The 211 default key size is 128 bits, and all implementations MUST support 212 this key size. Implementations MAY also support key sizes of 192 213 bits and 256 bits. 215 AES uses a different number of rounds for each of the defined key 216 sizes. When a 128-bit key is used, implementations MUST use 10 217 rounds. When a 192-bit key is used, implementations MUST use 12 218 rounds. When a 256-bit key is used, implementations MUST use 14 219 rounds. 221 2.3. Block Size 223 The AES has a block size of 128 bits (16 octets). As such, when 224 using AES-CTR, each AES encrypt operation generates 128 bits of key 225 stream. AES-CTR encryption is the XOR of the key stream with the 226 plaintext. AES-CTR decryption is the XOR of the key stream with the 227 ciphertext. If the generated key stream is longer than the plaintext 228 or ciphertext, the extra key stream bits are simply discarded. For 229 this reason, AES-CTR does not require the plaintext to be padded to a 230 multiple of the block size. However, to provide limited traffic flow 231 confidentiality, padding MAY be included, as specified in [ESP]. 233 3. ESP Payload 235 The ESP payload is comprised of the IV followed by the ciphertext. 236 The payload field, as defined in [ESP], is structured as shown in 237 Figure 1. 239 0 1 2 3 240 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Initialization Vector | 243 | (8 octets) | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | | 246 ~ Encrypted Payload (variable) ~ 247 | | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | | 250 ~ Authentication Data (variable) ~ 251 | | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Figure 1. ESP Payload Encrypted with AES-CTR 256 3.1. Initialization Vector 258 The AES-CTR IV field MUST be eight octets. The IV MUST be chosen by 259 the encryptor in a manner that ensures that the same IV value is used 260 only once for a given key. The encryptor can generate the IV in any 261 manner that ensures uniqueness. Common approaches to IV generation 262 include incrementing a counter for each packet and linear feedback 263 shift registers (LFSRs). 265 Including the IV in each packet ensures that the decryptor can 266 generate the key stream needed for decryption, even when some packets 267 are lost or reordered. 269 3.2. Encrypted Payload 271 The encrypted payload contains the ciphertext. 273 AES-CTR mode does not require plaintext padding. However, ESP does 274 require padding to 32-bit word-align the authentication data. The 275 padding, Pad Length, and the Next Header MUST be concatenated with 276 the plaintext before performing encryption, as described in [ESP]. 278 3.3. Authentication Data 280 Since it is trivial to construct a forgery AES-CTR ciphertext from a 281 valid AES-CTR ciphertext, AES-CTR implementations MUST employ a non- 282 NULL ESP authentication method. HMAC-SHA-1-96 [HMAC-SHA] is a likely 283 choice. 285 4. Counter Block Format 287 Each packet conveys the IV that is necessary to construct the 288 sequence of counter blocks used to generate the key stream necessary 289 to decrypt the payload. The AES counter block cipher block is 128 290 bits. Figure 2 shows the format of the counter block. 292 0 1 2 3 293 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Nonce | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Initialization Vector (IV) | 298 | | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Block Counter | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Figure 2. Counter Block Format 305 The components of the counter block are as follows: 307 Nonce 308 The Nonce field is 32 bits. As the name implies, the nonce is 309 a single use value. That is, a fresh nonce value MUST be 310 assigned for each security association. It MUST be assigned at 311 the beginning of the security association. The nonce value 312 need not be secret, but it MUST be unpredictable prior to the 313 beginning of the security association. 315 Initialization Vector 316 The IV field is 64 bits. As described in section 3.1, the IV 317 MUST be chosen by the encryptor in a manner that ensures that 318 the same IV value is used only once for a given key. 320 Block Counter 321 The block counter field is the least significant 32 bits of the 322 counter block. The block counter begins with the value of one, 323 and it is incremented to generate subsequent portions of the 324 key stream. The block counter is a 32-bit big-endian integer 325 value. 327 Using the encryption process described in section 2.1, this 328 construction permits each packet to consist of up to: 330 (2^32)-1 blocks = 4,294,967,295 blocks 331 = 68,719,476,720 octets 333 This construction can produce enough key stream for each packet 334 sufficient to handle any IPv6 jumbogram [JUMBO]. 336 5. IKE Conventions 338 This section describes the conventions used to generate keying 339 material and nonces for use with AES-CTR using the Internet Key 340 Exchange (IKE) [IKE] protocol. The identifiers and attributes needed 341 to negotiate a security association which uses AES-CTR are also 342 defined. 344 5.1. Keying Material and Nonces 346 As described in section 2.1, implementations MUST use fresh keys with 347 AES-CTR. IKE can be used to establish fresh keys. This section 348 describes the conventions for obtaining the unpredictable nonce value 349 from IKE. Note that this convention provides a nonce value that is 350 secret as well as unpredictable. 352 IKE makes use of a pseudo-random function (PRF) to derive keying 353 material. The PRF is used iteratively to derive keying material of 354 arbitrary size, called KEYMAT. Keying material is extracted from the 355 output string without regard to boundaries. 357 The size of the requested KEYMAT MUST be four octets longer than is 358 needed for the associated AES key. The keying material is used as 359 follows: 361 AES-CTR with a 128 bit key 362 The KEYMAT requested for each AES-CTR key is 20 octets. The 363 first 16 octets are the 128-bit AES key, and the remaining four 364 octets are used as the nonce value in the counter block. 366 AES-CTR with a 192 bit key 367 The KEYMAT requested for each AES-CTR key is 28 octets. The 368 first 24 octets are the 192-bit AES key, and the remaining four 369 octets are used as the nonce value in the counter block. 371 AES-CTR with a 256 bit key 372 The KEYMAT requested for each AES-CTR key is 36 octets. The 373 first 32 octets are the 256-bit AES key, and the remaining four 374 octets are used as the nonce value in the counter block. 376 5.2. Phase 1 Identifier 378 This document does not specify the conventions for using AES-CTR for 379 IKE Phase 1 negotiations. For AES-CTR to be used in this manner, a 380 separate specification is needed, and an Encryption Algorithm 381 Identifier needs to be assigned. 383 5.3. Phase 2 Identifier 385 For IKE Phase 2 negotiations, IANA has assigned an ESP Transform 386 Identifier of for AES-CTR with an explicit IV. 388 5.4. Key Length Attribute 390 Since the AES supports three key lengths, the Key Length attribute 391 MUST be specified in the IKE Phase 2 exchange [DOI]. The Key Length 392 attribute MUST have a value of 128, 192, or 256. 394 6. Test Vectors 396 This section contains nine test vectors, which can be used to confirm 397 that an implementation has correctly implemented AES-CTR. The first 398 three test vectors use AES with a 128 bit key; the next three test 399 vectors use AES with a 192 bit key; and the last three test vectors 400 use AES with a 256 bit key. 402 Test Vector #1: Encrypting 16 octets using AES-CTR with 128-bit key 403 AES Key : AE 68 52 F8 12 10 67 CC 4B F7 A5 76 55 77 F3 9E 404 AES-CTR IV : 00 00 00 00 00 00 00 00 405 Nonce : 00 00 00 30 406 Plaintext String : 'Single block msg' 407 Plaintext : 53 69 6E 67 6C 65 20 62 6C 6F 63 6B 20 6D 73 67 408 Counter Block (1): 00 00 00 30 00 00 00 00 00 00 00 00 00 00 00 01 409 Key Stream (1): B7 60 33 28 DB C2 93 1B 41 0E 16 C8 06 7E 62 DF 410 Ciphertext : E4 09 5D 4F B7 A7 B3 79 2D 61 75 A3 26 13 11 B8 412 Test Vector #2: Encrypting 32 octets using AES-CTR with 128-bit key 413 AES Key : 7E 24 06 78 17 FA E0 D7 43 D6 CE 1F 32 53 91 63 414 AES-CTR IV : C0 54 3B 59 DA 48 D9 0B 415 Nonce : 00 6C B6 DB 416 Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 417 : 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 418 Counter Block (1): 00 6C B6 DB C0 54 3B 59 DA 48 D9 0B 00 00 00 01 419 Key Stream (1): 51 05 A3 05 12 8F 74 DE 71 04 4B E5 82 D7 DD 87 420 Counter Block (2): 00 6C B6 DB C0 54 3B 59 DA 48 D9 0B 00 00 00 02 421 Key Stream (2): FB 3F 0C EF 52 CF 41 DF E4 FF 2A C4 8D 5C A0 37 422 Ciphertext : 51 04 A1 06 16 8A 72 D9 79 0D 41 EE 8E DA D3 88 423 : EB 2E 1E FC 46 DA 57 C8 FC E6 30 DF 91 41 BE 28 425 Test Vector #3: Encrypting 36 octets using AES-CTR with 128-bit key 426 AES Key : 76 91 BE 03 5E 50 20 A8 AC 6E 61 85 29 F9 A0 DC 427 AES-CTR IV : 27 77 7F 3F 4A 17 86 F0 428 Nonce : 00 E0 01 7B 429 Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 430 : 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 431 : 20 21 22 23 432 Counter Block (1): 00 E0 01 7B 27 77 7F 3F 4A 17 86 F0 00 00 00 01 433 Key Stream (1): C1 CE 4A AB 9B 2A FB DE C7 4F 58 E2 E3 D6 7C D8 434 Counter Block (2): 00 E0 01 7B 27 77 7F 3F 4A 17 86 F0 00 00 00 02 435 Key Stream (2): 55 51 B6 38 CA 78 6E 21 CD 83 46 F1 B2 EE 0E 4C 436 Counter Block (3): 00 E0 01 7B 27 77 7F 3F 4A 17 86 F0 00 00 00 03 437 Key Stream (3): 05 93 25 0C 17 55 36 00 A6 3D FE CF 56 23 87 E9 438 Ciphertext : C1 CF 48 A8 9F 2F FD D9 CF 46 52 E9 EF DB 72 D7 439 : 45 40 A4 2B DE 6D 78 36 D5 9A 5C EA AE F3 10 53 440 : 25 B2 07 2F 442 Test Vector #4: Encrypting 16 octets using AES-CTR with 192-bit key 443 AES Key : 16 AF 5B 14 5F C9 F5 79 C1 75 F9 3E 3B FB 0E ED 444 : 86 3D 06 CC FD B7 85 15 445 AES-CTR IV : 36 73 3C 14 7D 6D 93 CB 446 Nonce : 00 00 00 48 447 Plaintext String : 'Single block msg' 448 Plaintext : 53 69 6E 67 6C 65 20 62 6C 6F 63 6B 20 6D 73 67 449 Counter Block (1): 00 00 00 48 36 73 3C 14 7D 6D 93 CB 00 00 00 01 450 Key Stream (1): 18 3C 56 28 8E 3C E9 AA 22 16 56 CB 23 A6 9A 4F 451 Ciphertext : 4B 55 38 4F E2 59 C9 C8 4E 79 35 A0 03 CB E9 28 453 Test Vector #5: Encrypting 32 octets using AES-CTR with 192-bit key 454 AES Key : 7C 5C B2 40 1B 3D C3 3C 19 E7 34 08 19 E0 F6 9C 455 : 67 8C 3D B8 E6 F6 A9 1A 456 AES-CTR IV : 02 0C 6E AD C2 CB 50 0D 457 Nonce : 00 96 B0 3B 458 Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 459 : 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 460 Counter Block (1): 00 96 B0 3B 02 0C 6E AD C2 CB 50 0D 00 00 00 01 461 Key Stream (1): 45 33 41 FF 64 9E 25 35 76 D6 A0 F1 7D 3C C3 90 462 Counter Block (2): 00 96 B0 3B 02 0C 6E AD C2 CB 50 0D 00 00 00 02 463 Key Stream (2): 94 81 62 0F 4E C1 B1 8B E4 06 FA E4 5E E9 E5 1F 464 Ciphertext : 45 32 43 FC 60 9B 23 32 7E DF AA FA 71 31 CD 9F 465 : 84 90 70 1C 5A D4 A7 9C FC 1F E0 FF 42 F4 FB 00 467 Test Vector #6: Encrypting 36 octets using AES-CTR with 192-bit key 468 AES Key : 02 BF 39 1E E8 EC B1 59 B9 59 61 7B 09 65 27 9B 469 : F5 9B 60 A7 86 D3 E0 FE 470 AES-CTR IV : 5C BD 60 27 8D CC 09 12 471 Nonce : 00 07 BD FD 472 Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 473 : 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 474 : 20 21 22 23 475 Counter Block (1): 00 07 BD FD 5C BD 60 27 8D CC 09 12 00 00 00 01 476 Key Stream (1): 96 88 3D C6 5A 59 74 28 5C 02 77 DA D1 FA E9 57 477 Counter Block (2): 00 07 BD FD 5C BD 60 27 8D CC 09 12 00 00 00 02 478 Key Stream (2): C2 99 AE 86 D2 84 73 9F 5D 2F D2 0A 7A 32 3F 97 479 Counter Block (3): 00 07 BD FD 5C BD 60 27 8D CC 09 12 00 00 00 03 480 Key Stream (3): 8B CF 2B 16 39 99 B2 26 15 B4 9C D4 FE 57 39 98 481 Ciphertext : 96 89 3F C5 5E 5C 72 2F 54 0B 7D D1 DD F7 E7 58 482 : D2 88 BC 95 C6 91 65 88 45 36 C8 11 66 2F 21 88 483 : AB EE 09 35 485 Test Vector #7: Encrypting 16 octets using AES-CTR with 256-bit key 486 AES Key : 77 6B EF F2 85 1D B0 6F 4C 8A 05 42 C8 69 6F 6C 487 : 6A 81 AF 1E EC 96 B4 D3 7F C1 D6 89 E6 C1 C1 04 488 AES-CTR IV : DB 56 72 C9 7A A8 F0 B2 489 Nonce : 00 00 00 60 490 Plaintext String : 'Single block msg' 491 Plaintext : 53 69 6E 67 6C 65 20 62 6C 6F 63 6B 20 6D 73 67 492 Counter Block (1): 00 00 00 60 DB 56 72 C9 7A A8 F0 B2 00 00 00 01 493 Key Stream (1): 47 33 BE 7A D3 E7 6E A5 3A 67 00 B7 51 8E 93 A7 494 Ciphertext : 14 5A D0 1D BF 82 4E C7 56 08 63 DC 71 E3 E0 C0 496 Test Vector #8: Encrypting 32 octets using AES-CTR with 256-bit key 497 AES Key : F6 D6 6D 6B D5 2D 59 BB 07 96 36 58 79 EF F8 86 498 : C6 6D D5 1A 5B 6A 99 74 4B 50 59 0C 87 A2 38 84 499 AES-CTR IV : C1 58 5E F1 5A 43 D8 75 500 Nonce : 00 FA AC 24 501 Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 502 : 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 503 Counter block (1): 00 FA AC 24 C1 58 5E F1 5A 43 D8 75 00 00 00 01 504 Key stream (1): F0 5F 21 18 3C 91 67 2B 41 E7 0A 00 8C 43 BC A6 505 Counter block (2): 00 FA AC 24 C1 58 5E F1 5A 43 D8 75 00 00 00 02 506 Key stream (2): A8 21 79 43 9B 96 8B 7D 4D 29 99 06 8F 59 B1 03 507 Ciphertext : F0 5E 23 1B 38 94 61 2C 49 EE 00 0B 80 4E B2 A9 508 : B8 30 6B 50 8F 83 9D 6A 55 30 83 1D 93 44 AF 1C 510 Test Vector #9: Encrypting 36 octets using AES-CTR with 256-bit key 511 AES Key : FF 7A 61 7C E6 91 48 E4 F1 72 6E 2F 43 58 1D E2 512 : AA 62 D9 F8 05 53 2E DF F1 EE D6 87 FB 54 15 3D 513 AES-CTR IV : 51 A5 1D 70 A1 C1 11 48 514 Nonce : 00 1C C5 B7 515 Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 516 : 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 517 : 20 21 22 23 518 Counter block (1): 00 1C C5 B7 51 A5 1D 70 A1 C1 11 48 00 00 00 01 519 Key stream (1): EB 6D 50 81 19 0E BD F0 C6 7C 9E 4D 26 C7 41 A5 520 Counter block (2): 00 1C C5 B7 51 A5 1D 70 A1 C1 11 48 00 00 00 02 521 Key stream (2): A4 16 CD 95 71 7C EB 10 EC 95 DA AE 9F CB 19 00 522 Counter block (3): 00 1C C5 B7 51 A5 1D 70 A1 C1 11 48 00 00 00 03 523 Key stream (3): 3E E1 C4 9B C6 B9 CA 21 3F 6E E2 71 D0 A9 33 39 524 Ciphertext : EB 6C 52 82 1D 0B BB F7 CE 75 94 46 2A CA 4F AA 525 : B4 07 DF 86 65 69 FD 07 F4 8C C0 B5 83 D6 07 1F 526 : 1E C0 E6 B8 528 7. Security Considerations 530 When used properly, AES-CTR mode provides strong confidentiality. 531 Bellare, Desai, Jokipii, Rogaway show in [BDJR] that the privacy 532 guarantees provided by counter mode are at least as strong as those 533 for CBC mode when using the same block cipher. 535 Unfortunately, it is very easy to misuse this counter mode. If 536 counter block values are ever used for more that one packet with the 537 same key, then the same key stream will be used to encrypt both 538 packets, and the confidentiality guarantees are voided. 540 What happens if the encryptor XORs the same key stream with two 541 different plaintexts? Suppose two plaintext byte sequences P1, P2, 542 P3 and Q1, Q2, Q3 are both encrypted with key stream K1, K2, K3. The 543 two corresponding ciphertexts are: 545 (P1 XOR K1), (P2 XOR K2), (P3 XOR K3) 547 (Q1 XOR K1), (Q2 XOR K2), (Q3 XOR K3) 549 If both of these two ciphertext streams are exposed to an attacker, 550 then a catastrophic failure of confidentiality results, since: 552 (P1 XOR K1) XOR (Q1 XOR K1) = P1 XOR Q1 553 (P2 XOR K2) XOR (Q2 XOR K2) = P2 XOR Q2 554 (P3 XOR K3) XOR (Q3 XOR K3) = P3 XOR Q3 556 Once the attacker obtains the two plaintexts XORed together, it is 557 relatively straightforward to separate them. Thus, using any stream 558 cipher, including AES-CTR, to encrypt two plaintexts under the same 559 key stream leaks the plaintext. 561 Therefore, stream ciphers, including AES-CTR, should not be used with 562 static keys. It is inappropriate to use AES-CTR with static keys. 563 Extraordinary measures would be needed to prevent reuse of a counter 564 block value with the static key across power cycles. To be safe, ESP 565 implementations MUST use fresh keys with AES-CTR. The Internet Key 566 Exchange (IKE) protocol [IKE] can be used to establish fresh keys. 567 IKE can also be used to establish the nonce at the beginning of the 568 security association. 570 When IKE is used to establish fresh keys between two peer entities, 571 separate keys are established for the two traffic flows. When a 572 mechanism other than IKE is used to establish fresh keys, and that 573 mechanism establishes only a single key to encrypt packets, then 574 there is a high probability that the peers will select the same IV 575 values for some packets. Thus, to avoid counter block collisions, 576 ESP implementations that permit use of the same key for encrypting 577 outbound traffic and decrypting incoming traffic with the same peer 578 MUST ensure that the two peers assign different Nonce values to the 579 security association. 581 Data forgery is trivial with CTR mode. The demonstration of this 582 attack is similar to the key stream reuse discussion above. If a 583 known plaintext byte sequence P1, P2, P3 is encrypted with key stream 584 K1, K2, K3, then the attacker can replace the plaintext with one of 585 his own choosing. The ciphertext is: 587 (P1 XOR K1), (P2 XOR K2), (P3 XOR K3) 589 The attacker simply XORs a selected sequence Q1, Q2, Q3 with the 590 ciphertext to obtain: 592 (Q1 XOR (P1 XOR K1)), (Q2 XOR (P2 XOR K2)), (Q3 XOR (P3 XOR K3)) 594 Which is the same as: 596 ((Q1 XOR P1) XOR K1), ((Q2 XOR P2) XOR K2), ((Q3 XOR P3) XOR K3) 598 Decryption of the attacker-generated ciphertext will yield exactly 599 what the attacker intended: 601 (Q1 XOR P1), (Q2 XOR P2), (Q3 XOR P3) 603 Accordingly, ESP implementations MUST use of AES-CTR in conjunction 604 with ESP authentication. 606 Additionally, since AES has a 128-bit block size, regardless of the 607 mode employed, the ciphertext generated by AES encryption becomes 608 distinguishable from random values after 2^64 blocks are encrypted 609 with a single key. Since ESP with Enhanced Sequence Numbers allows 610 for up to 2^64 packets in a single security association, there is 611 real potential for more than 2^64 blocks to be encrypted with one 612 key. Therefore, implementations SHOULD generate a fresh key before 613 2^64 blocks are encrypted with the same key. Note that ESP with 614 32-bit Sequence Numbers will not exceed 2^64 blocks even if all of 615 the packets are maximum-length IPv6 jumbograms [JUMBO]. 617 There are fairly generic precomputation attacks against all block 618 cipher modes that allow a meet-in-the-middle attack against the key. 619 These attacks require the creation and searching of huge tables of 620 ciphertext associated with known plaintext and known keys. Assuming 621 that the memory and processor resources are available for a 622 precomputation attack, then the theoretical strength of AES-CTR (and 623 any other block cipher mode) is limited to 2^(n/2) bits, where n is 624 the number of bits in the key. The use of long keys is the best 625 countermeasure to precomputation attacks. Therefore, implementations 626 that employ 128-bit AES keys should take precautions to make the 627 precomputation attacks more difficult. The unpredictable nonce value 628 in the counter block significantly increases the size of the table 629 that the attacker must compute to mount a successful attack. 631 8. Design Rationale 633 In the development of this specification, the use of the ESP sequence 634 number field instead of an explicit IV field was considered. This 635 selection is not a cryptographic security issue, as either approach 636 will prevent counter block collisions. 638 In a very conservative model of encryption security, at most 2^64 639 blocks ought to be encrypted with AES-CTR under a single key. Under 640 this constraint, no more than 64 bits are needed to identify each 641 packet within a security association. Since the ESP extended 642 sequence number is 64 bits, it is an obvious candidate for use as an 643 implicit IV. This would dictate a single method for the assignment 644 of per-packet value in the counter block. The use of an explicit IV 645 does not dictate such a method, which is desirable for several 646 reasons. 648 1. Only the encryptor can ensure that the value is not used for 649 more than one packet, so there is no advantage to selecting a 650 mechanism that allows the decryptor to determine whether counter 651 block values collide. Damage from the collision is done, whether 652 the decryptor detects it or not. 654 2. Allows adders, LFSRs, and any other technique that meets the 655 time budget of the encryptor, so long as the technique results in 656 a unique value for each packet. Adders are simple and 657 straightforward to implement, but due to carries, they do not 658 execute in constant time. LFSRs offer an alternative that 659 executes in constant time. 661 3. Complexity is in control of the implementer. Further, the 662 decision made by the implementer of the encryptor does not make 663 the decryptor more (or less) complex. 665 4. When the encryptor has more than one cryptographic hardware 666 device, an IV prefix can be assigned to each device, ensuring that 667 collisions will not occur. Yet, since the decryptor does not need 668 to examine IV structure, the decryptor is unaffected by the IV 669 structure selected by the encryptor. One cannot make use of the 670 same technique with the ESP sequence numbers, because the 671 semantics for them require sequential value generation. 673 5. Assurance boundaries are very important to implementations 674 that will be evaluated against the FIPS Pub 140-1 or FIPS Pub 675 140-2 [SECRQMTS]. The assignment of the per-packet counter block 676 value needs to be inside the assurance boundary. Some 677 implementations assign the sequence number inside the assurance 678 boundary, but others do not. A sequence number collision does not 679 have the dire consequences, but, as described in section 6, a 680 collision in counter block values has disastrous consequences. 682 6. Coupling with the sequence number is possible in those 683 architectures where the sequence number assignment is performed 684 within the assurance boundary. In this situation, the sequence 685 number and the IV field will contain the same value. 687 7. Decoupling from the sequence number is possible in those 688 architectures where the sequence number assignment is performed 689 outside the assurance boundary. 691 The use of an explicit IV field directly follows from the decoupling 692 of the sequence number and the per-packet counter block value. The 693 overhead associated with 64 bits for the IV field is acceptable. 694 This overhead is significantly less than the overhead associated with 695 Cipher Block Chaining (CBC) mode. As normally employed, CBC requires 696 a full block for the IV and, on average, half of a block for padding. 697 AES-CTR with an explicit IV has about one-third of the overhead as 698 AES-CBC, and the overhead is constant for each packet. 700 The inclusion of the nonce provides a weak countermeasure against 701 precomputation attacks. For this countermeasure to be effective, the 702 attacker must not be able to predict the value of the nonce well in 703 advance of security association establishment. The use of long keys 704 provides a strong countermeasure to precomputation attacks, and AES 705 offers key sizes that thwart these attacks for many decades to come. 707 A 28-bit block counter value is sufficient for the generation of a 708 key stream to encrypt the largest possible IPv6 jumbogram [JUMBO]; 709 however, a 32-bit field is used. This size is convenient for both 710 hardware and software implementations. 712 9. IANA Considerations 714 IANA has assigned as the ESP transform number for AES-CTR with 715 an explicit IV. 717 10. Acknowledgements 719 This document is the result of extensive discussions and compromises. 720 While not all of the participants are completely satisfied with the 721 outcome, the document is better for their contributions. 723 The author thanks the members of the IPsec working group for their 724 contributions to the design, with special mention of the efforts of 725 (in alphabetical order) Steve Bellovin, David Black, Niels Ferguson, 726 Charlie Kaufman, Steve Kent, Tero Kivinen, Paul Koning, David McGrew, 727 Robert Moskowitz, Jesse Walker, and Doug Whiting. 729 The author thanks and Alireza Hodjat, John Viega, and Doug Whiting 730 for assistance with the test vectors. 732 11. References 734 This section provides normative and informative references. 736 11.1. Normative References 738 [AES] NIST, FIPS PUB 197, "Advanced Encryption Standard 739 (AES)," November 2001. 741 [DOI] Piper, D., "The Internet IP Security Domain of 742 Interpretation for ISAKMP," RFC 2407, November 1998. 744 [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security 745 Payload (ESP)," RFC 2406, November 1998. 747 [MODES] Dworkin, M., "Recommendation for Block Cipher Modes 748 of Operation: Methods and Techniques," NIST Special 750 Publication 800-38A, December 2001. 752 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 753 Requirement Levels," RFC 2119, March 1997. 755 11.2. Informative References 757 [ARCH] Kent, S. and R. Atkinson, "Security Architecture for 758 the Internet Protocol," RFC 2401, November 1998. 760 [BDJR] Bellare, M, Desai, A., Jokipii, E., and P. Rogaway, 761 "A Concrete Security Treatment of Symmetric Encryption: 762 Analysis of the DES Modes of Operation", Proceedings 763 38th Annual Symposium on Foundations of Computer 764 Science, 1997. 766 [HMAC-SHA] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 767 within ESP and AH," RFC 2404, November 1998. 769 [IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange 770 (IKE)," RFC 2409, November 1998. 772 [JUMBO] Borman, D., Deering, S., and R. Hinden, "IPv6 773 Jumbograms," RFC 2675, August 1999. 775 [ROADMAP] Thayer, R., N. Doraswamy and R. Glenn, "IP Security 776 Document Roadmap," RFC 2411, November 1998. 778 [SECRQMTS] National Institute of Standards and Technology. 779 FIPS Pub 140-1: Security Requirements for Cryptographic 780 Modules. 11 January 1994. 782 National Institute of Standards and Technology. 783 FIPS Pub 140-2: Security Requirements for Cryptographic 784 Modules. 25 May 2001. [Supercedes FIPS Pub 140-1] 786 12. Author's Address 788 Russell Housley 789 Vigil Security, LLC 790 918 Spring Knoll Drive 791 Herndon, VA 20170 792 USA 793 housley@vigilsec.com 795 13. Full Copyright Statement 797 Copyright (C) The Internet Society 2003. All Rights Reserved. 799 This document and translations of it may be copied and furnished to 800 others, and derivative works that comment on or otherwise explain it 801 or assist in its implementation may be prepared, copied, published 802 and distributed, in whole or in part, without restriction of any 803 kind, provided that the above copyright notice and this paragraph are 804 included on all such copies and derivative works. However, this 805 document itself may not be modified in any way, such as by removing 806 the copyright notice or references to the Internet Society or other 807 Internet organizations, except as needed for the purpose of 808 developing Internet standards in which case the procedures for 809 copyrights defined in the Internet Standards process must be 810 followed, or as required to translate it into languages other than 811 English. 813 The limited permissions granted above are perpetual and will not be 814 revoked by the Internet Society or its successors or assigns. 816 This document and the information contained herein is provided on an 817 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 818 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 819 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 820 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 821 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.