idnits 2.17.1 draft-ietf-ipsec-ciph-aes-ctr-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: ---------------------------------------------------------------------------- == 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 (May 2003) is 7652 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 May 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 followed by the per-packet IV value, 179 and the least significant 32 bits of the counter block are initially 180 set to one. This counter value is incremented by one to generate 181 subsequent counter blocks, each resulting in another 128 bits of key 182 stream. The encryption of n plaintext blocks can be summarized as: 184 CTRBLK := NONCE || IV || ONE 185 FOR i := 1 to n-1 DO 186 CT[i] := PT[i] XOR AES(CTRBLK) 187 CTRBLK := CTRBLK + 1 188 END 189 CT[n] := PT[n] XOR TRUNC(AES(CTRBLK)) 191 The AES() function performs AES encryption with the fresh key. 193 The TRUNC() function truncates the output of the AES encrypt 194 operation to the same length as the final plaintext block, returning 195 the most significant bits. 197 Decryption is similar. The decryption of n ciphertext blocks can be 198 summarized as: 200 CTRBLK := NONCE || IV || ONE 201 FOR i := 1 to n-1 DO 202 PT[i] := CT[i] XOR AES(CTRBLK) 203 CTRBLK := CTRBLK + 1 204 END 205 PT[n] := CT[n] XOR TRUNC(AES(CTRBLK)) 207 2.2. Key Size and Rounds 209 AES supports three key sizes: 128 bits, 192 bits, and 256 bits. The 210 default key size is 128 bits, and all implementations MUST support 211 this key size. Implementations MAY also support key sizes of 192 212 bits and 256 bits. 214 AES uses a different number of rounds for each of the defined key 215 sizes. When a 128-bit key is used, implementations MUST use 10 216 rounds. When a 192-bit key is used, implementations MUST use 12 217 rounds. When a 256-bit key is used, implementations MUST use 14 218 rounds. 220 2.3. Block Size 222 The AES has a block size of 128 bits (16 octets). As such, when 223 using AES-CTR, each AES encrypt operation generates 128 bits of key 224 stream. AES-CTR encryption is the XOR of the key stream with the 225 plaintext. AES-CTR decryption is the XOR of the key stream with the 226 ciphertext. If the generated key stream is longer than the plaintext 227 or ciphertext, the extra key stream bits are simply discarded. For 228 this reason, AES-CTR does not require the plaintext to be padded to a 229 multiple of the block size. However, to provide limited traffic flow 230 confidentiality, padding MAY be included, as specified in [ESP]. 232 3. ESP Payload 234 The ESP payload is comprised of the IV followed by the ciphertext. 235 The payload field, as defined in [ESP], is structured as shown in 236 Figure 1. 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Initialization Vector | 242 | (8 octets) | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | | 245 ~ Encrypted Payload (variable) ~ 246 | | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | | 249 ~ Authentication Data (variable) ~ 250 | | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 Figure 1. ESP Payload Encrypted with AES-CTR 255 3.1. Initialization Vector 257 The AES-CTR IV field MUST be eight octets. The IV MUST be chosen by 258 the encryptor in a manner that ensures that the same IV value is used 259 only once for a given key. The encryptor can generate the IV in any 260 manner that ensures uniqueness. Common approaches to IV generation 261 include incrementing a counter for each packet and linear feedback 262 shift registers (LFSRs). 264 Including the IV in each packet ensures that the decryptor can 265 generate the key stream needed for decryption, even when some packets 266 are lost or reordered. 268 3.2. Encrypted Payload 270 The encrypted payload contains the ciphertext. 272 AES-CTR mode does not require plaintext padding. However, ESP does 273 require padding to 32-bit word-align the authentication data. The 274 padding, Pad Length, and the Next Header MUST be concatenated with 275 the plaintext before performing encryption, as described in [ESP]. 277 3.3. Authentication Data 279 Since it is trivial to construct a forgery AES-CTR ciphertext from a 280 valid AES-CTR ciphertext, AES-CTR implementations MUST employ a non- 281 NULL ESP authentication method. HMAC-SHA-1-96 [HMAC-SHA] is a likely 282 choice. 284 4. Counter Block Format 286 Each packet conveys the IV that is necessary to construct the 287 sequence of counter blocks used to generate the key stream necessary 288 to decrypt the payload. The AES counter block cipher block is 128 289 bits. Figure 2 shows the format of the counter block. 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Nonce | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Initialization Vector (IV) | 297 | | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Block Counter | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 Figure 2. Counter Block Format 304 The components of the counter block are as follows: 306 Nonce 307 The Nonce field is 32 bits. As the name implies, the nonce is 308 a single use value. It MUST be assigned at the beginning of 309 the security association. The nonce value need not be secret, 310 but it MUST be unpredictable prior to the beginning of the 311 security association. 313 Initialization Vector 314 The IV field is 64 bits. As described in section 3.1, the IV 315 MUST be chosen by the encryptor in a manner that ensures that 316 the same IV value is used only once for a given key. 318 Block Counter 319 The block counter field is the least significant 32 bits of the 320 counter block. The block counter begins with the value of one, 321 and it is incremented to generate subsequent portions of the 322 key stream. The block counter is a 32-bit big-endian integer 323 value. 325 Using the encryption process described in section 2.1, this 326 construction permits each packet to consist of up to: 328 (2^32)-1 blocks = 4,294,967,295 blocks 329 = 68,719,476,720 octets 331 This construction can produce enough key stream for each packet 332 sufficient to handle any IPv6 jumbogram [JUMBO]. 334 5. IKE Conventions 336 This section describes the conventions used to generate keying 337 material and nonces for use with AES-CTR using the Internet Key 338 Exchange (IKE) [IKE] protocol. The identifiers and attributes needed 339 to negotiate a security association which uses AES-CTR are also 340 defined. 342 5.1. Keying Material and Nonces 344 As described in section 2.1, implementations MUST use fresh keys with 345 AES-CTR. IKE can be used to establish fresh keys. This section 346 describes the conventions for obtaining the unpredictable nonce value 347 from IKE. Note that this convention provides a nonce value that is 348 secret as well as unpredictable. 350 IKE makes use of a pseudo-random function (PRF) to derive keying 351 material. The PRF is used iteratively to derive keying material of 352 arbitrary size. Keying material is extracted from the output string 353 without regard to boundaries. 355 IKE uses the PRF to generate an output stream that parsed into five 356 keys: SK_d, SK_ai, SK_ar, SK_ei, and SK_er. SK_d is used to derive 357 new keys for the child security associations. SK_ai and SK_ar are 358 the authentication keys for the initiator and the responder, 359 respectively. SK_ei and SK_er are the encryption keys for the 360 initiator and the responder, respectively. 362 SK_ai and SK_ei are used to protect traffic from the initiator to the 363 responder. SK_ar and SK_er are used to protect traffic from the 364 responder to the initiator. 366 The size of SK_ei and SK_er are each four octets longer than is 367 needed by the associated AES key. The keying material is used as 368 follows: 370 AES-CTR with a 128 bit key 371 SK_ei and SK_er are each 20 octets. The first 16 octets are 372 the 128-bit AES key, and the remaining four octets are used as 373 the nonce value in the counter block. 375 AES-CTR with a 192 bit key 376 SK_ei and SK_er are each 28 octets. The first 24 octets are 377 the 192-bit AES key, and the remaining four octets are used as 378 the nonce value in the counter block. 380 AES-CTR with a 256 bit key 381 SK_ei and SK_er are each 36 octets. The first 32 octets are 382 the 256-bit AES key, and the remaining four octets are used as 383 the nonce value in the counter block. 385 5.2. Phase 1 Identifier 387 This document does not specify the conventions for using AES-CTR for 388 IKE Phase 1 negotiations. For AES-CTR to be used in this manner, a 389 separate specification is needed, and an Encryption Algorithm 390 Identifier needs to be assigned. 392 5.3. Phase 2 Identifier 394 For IKE Phase 2 negotiations, IANA has assigned an ESP Transform 395 Identifier of for AES-CTR with an explicit IV. 397 5.4. Key Length Attribute 399 Since the AES supports three key lengths, the Key Length attribute 400 MUST be specified in the IKE Phase 2 exchange [DOI]. The Key Length 401 attribute MUST have a value of 128, 192, or 256. 403 6. Test Vectors 405 This section contains nine test vectors, which can be used to confirm 406 that an implementation has correctly implemented AES-CTR. The first 407 three test vectors use AES with a 128 bit key; the next three test 408 vectors use AES with a 192 bit key; and the last three test vectors 409 use AES with a 256 bit key. 411 Test Vector #1: Encrypting 16 octets using AES-CTR with 128-bit key 412 AES Key : AE 68 52 F8 12 10 67 CC 4B F7 A5 76 55 77 F3 9E 413 AES-CTR IV : 00 00 00 00 00 00 00 00 414 Nonce : 00 00 00 30 415 Plaintext String : 'Single block msg' 416 Plaintext : 53 69 6E 67 6C 65 20 62 6C 6F 63 6B 20 6D 73 67 417 Counter Block (1): 00 00 00 30 00 00 00 00 00 00 00 00 00 00 00 01 418 Key Stream (1): B7 60 33 28 DB C2 93 1B 41 0E 16 C8 06 7E 62 DF 419 Ciphertext : E4 09 5D 4F B7 A7 B3 79 2D 61 75 A3 26 13 11 B8 421 Test Vector #2: Encrypting 32 octets using AES-CTR with 128-bit key 422 AES Key : 7E 24 06 78 17 FA E0 D7 43 D6 CE 1F 32 53 91 63 423 AES-CTR IV : C0 54 3B 59 DA 48 D9 0B 424 Nonce : 00 6C B6 DB 425 Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 426 : 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 427 Counter Block (1): 00 6C B6 DB C0 54 3B 59 DA 48 D9 0B 00 00 00 01 428 Key Stream (1): 51 05 A3 05 12 8F 74 DE 71 04 4B E5 82 D7 DD 87 429 Counter Block (2): 00 6C B6 DB C0 54 3B 59 DA 48 D9 0B 00 00 00 02 430 Key Stream (2): FB 3F 0C EF 52 CF 41 DF E4 FF 2A C4 8D 5C A0 37 431 Ciphertext : 51 04 A1 06 16 8A 72 D9 79 0D 41 EE 8E DA D3 88 432 : EB 2E 1E FC 46 DA 57 C8 FC E6 30 DF 91 41 BE 28 434 Test Vector #3: Encrypting 36 octets using AES-CTR with 128-bit key 435 AES Key : 76 91 BE 03 5E 50 20 A8 AC 6E 61 85 29 F9 A0 DC 436 AES-CTR IV : 27 77 7F 3F 4A 17 86 F0 437 Nonce : 00 E0 01 7B 438 Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 439 : 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 440 : 20 21 22 23 441 Counter Block (1): 00 E0 01 7B 27 77 7F 3F 4A 17 86 F0 00 00 00 01 442 Key Stream (1): C1 CE 4A AB 9B 2A FB DE C7 4F 58 E2 E3 D6 7C D8 443 Counter Block (2): 00 E0 01 7B 27 77 7F 3F 4A 17 86 F0 00 00 00 02 444 Key Stream (2): 55 51 B6 38 CA 78 6E 21 CD 83 46 F1 B2 EE 0E 4C 445 Counter Block (3): 00 E0 01 7B 27 77 7F 3F 4A 17 86 F0 00 00 00 03 446 Key Stream (3): 05 93 25 0C 17 55 36 00 A6 3D FE CF 56 23 87 E9 447 Ciphertext : C1 CF 48 A8 9F 2F FD D9 CF 46 52 E9 EF DB 72 D7 448 : 45 40 A4 2B DE 6D 78 36 D5 9A 5C EA AE F3 10 53 449 : 25 B2 07 2F 451 Test Vector #4: Encrypting 16 octets using AES-CTR with 192-bit key 452 AES Key : 16 AF 5B 14 5F C9 F5 79 C1 75 F9 3E 3B FB 0E ED 453 : 86 3D 06 CC FD B7 85 15 454 AES-CTR IV : 36 73 3C 14 7D 6D 93 CB 455 Nonce : 00 00 00 48 456 Plaintext String : 'Single block msg' 457 Plaintext : 53 69 6E 67 6C 65 20 62 6C 6F 63 6B 20 6D 73 67 458 Counter Block (1): 00 00 00 48 36 73 3C 14 7D 6D 93 CB 00 00 00 01 459 Key Stream (1): 18 3C 56 28 8E 3C E9 AA 22 16 56 CB 23 A6 9A 4F 460 Ciphertext : 4B 55 38 4F E2 59 C9 C8 4E 79 35 A0 03 CB E9 28 462 Test Vector #5: Encrypting 32 octets using AES-CTR with 192-bit key 463 AES Key : 7C 5C B2 40 1B 3D C3 3C 19 E7 34 08 19 E0 F6 9C 464 : 67 8C 3D B8 E6 F6 A9 1A 465 AES-CTR IV : 02 0C 6E AD C2 CB 50 0D 466 Nonce : 00 96 B0 3B 467 Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 468 : 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 469 Counter Block (1): 00 96 B0 3B 02 0C 6E AD C2 CB 50 0D 00 00 00 01 470 Key Stream (1): 45 33 41 FF 64 9E 25 35 76 D6 A0 F1 7D 3C C3 90 471 Counter Block (2): 00 96 B0 3B 02 0C 6E AD C2 CB 50 0D 00 00 00 02 472 Key Stream (2): 94 81 62 0F 4E C1 B1 8B E4 06 FA E4 5E E9 E5 1F 473 Ciphertext : 45 32 43 FC 60 9B 23 32 7E DF AA FA 71 31 CD 9F 474 : 84 90 70 1C 5A D4 A7 9C FC 1F E0 FF 42 F4 FB 00 476 Test Vector #6: Encrypting 36 octets using AES-CTR with 192-bit key 477 AES Key : 02 BF 39 1E E8 EC B1 59 B9 59 61 7B 09 65 27 9B 478 : F5 9B 60 A7 86 D3 E0 FE 479 AES-CTR IV : 5C BD 60 27 8D CC 09 12 480 Nonce : 00 07 BD FD 481 Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 482 : 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 483 : 20 21 22 23 484 Counter Block (1): 00 07 BD FD 5C BD 60 27 8D CC 09 12 00 00 00 01 485 Key Stream (1): 96 88 3D C6 5A 59 74 28 5C 02 77 DA D1 FA E9 57 486 Counter Block (2): 00 07 BD FD 5C BD 60 27 8D CC 09 12 00 00 00 02 487 Key Stream (2): C2 99 AE 86 D2 84 73 9F 5D 2F D2 0A 7A 32 3F 97 488 Counter Block (3): 00 07 BD FD 5C BD 60 27 8D CC 09 12 00 00 00 03 489 Key Stream (3): 8B CF 2B 16 39 99 B2 26 15 B4 9C D4 FE 57 39 98 490 Ciphertext : 96 89 3F C5 5E 5C 72 2F 54 0B 7D D1 DD F7 E7 58 491 : D2 88 BC 95 C6 91 65 88 45 36 C8 11 66 2F 21 88 492 : AB EE 09 35 494 Test Vector #7: Encrypting 16 octets using AES-CTR with 256-bit key 495 AES Key : 77 6B EF F2 85 1D B0 6F 4C 8A 05 42 C8 69 6F 6C 496 : 6A 81 AF 1E EC 96 B4 D3 7F C1 D6 89 E6 C1 C1 04 497 AES-CTR IV : DB 56 72 C9 7A A8 F0 B2 498 Nonce : 00 00 00 60 499 Plaintext String : 'Single block msg' 500 Plaintext : 53 69 6E 67 6C 65 20 62 6C 6F 63 6B 20 6D 73 67 501 Counter Block (1): 00 00 00 60 DB 56 72 C9 7A A8 F0 B2 00 00 00 01 502 Key Stream (1): 47 33 BE 7A D3 E7 6E A5 3A 67 00 B7 51 8E 93 A7 503 Ciphertext : 14 5A D0 1D BF 82 4E C7 56 08 63 DC 71 E3 E0 C0 505 Test Vector #8: Encrypting 32 octets using AES-CTR with 256-bit key 506 AES Key : F6 D6 6D 6B D5 2D 59 BB 07 96 36 58 79 EF F8 86 507 : C6 6D D5 1A 5B 6A 99 74 4B 50 59 0C 87 A2 38 84 508 AES-CTR IV : C1 58 5E F1 5A 43 D8 75 509 Nonce : 00 FA AC 24 510 Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 511 : 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 512 Counter block (1): 00 FA AC 24 C1 58 5E F1 5A 43 D8 75 00 00 00 01 513 Key stream (1): F0 5F 21 18 3C 91 67 2B 41 E7 0A 00 8C 43 BC A6 514 Counter block (2): 00 FA AC 24 C1 58 5E F1 5A 43 D8 75 00 00 00 02 515 Key stream (2): A8 21 79 43 9B 96 8B 7D 4D 29 99 06 8F 59 B1 03 516 Ciphertext : F0 5E 23 1B 38 94 61 2C 49 EE 00 0B 80 4E B2 A9 517 : B8 30 6B 50 8F 83 9D 6A 55 30 83 1D 93 44 AF 1C 519 Test Vector #9: Encrypting 36 octets using AES-CTR with 256-bit key 520 AES Key : FF 7A 61 7C E6 91 48 E4 F1 72 6E 2F 43 58 1D E2 521 : AA 62 D9 F8 05 53 2E DF F1 EE D6 87 FB 54 15 3D 522 AES-CTR IV : 51 A5 1D 70 A1 C1 11 48 523 Nonce : 00 1C C5 B7 524 Plaintext : 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 525 : 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 526 : 20 21 22 23 527 Counter block (1): 00 1C C5 B7 51 A5 1D 70 A1 C1 11 48 00 00 00 01 528 Key stream (1): EB 6D 50 81 19 0E BD F0 C6 7C 9E 4D 26 C7 41 A5 529 Counter block (2): 00 1C C5 B7 51 A5 1D 70 A1 C1 11 48 00 00 00 02 530 Key stream (2): A4 16 CD 95 71 7C EB 10 EC 95 DA AE 9F CB 19 00 531 Counter block (3): 00 1C C5 B7 51 A5 1D 70 A1 C1 11 48 00 00 00 03 532 Key stream (3): 3E E1 C4 9B C6 B9 CA 21 3F 6E E2 71 D0 A9 33 39 533 Ciphertext : EB 6C 52 82 1D 0B BB F7 CE 75 94 46 2A CA 4F AA 534 : B4 07 DF 86 65 69 FD 07 F4 8C C0 B5 83 D6 07 1F 535 : 1E C0 E6 B8 537 7. Security Considerations 539 When used properly, AES-CTR mode provides strong confidentiality. 540 Bellare, Desai, Jokipii, Rogaway show in [BDJR] that the privacy 541 guarantees provided by counter mode are at least as strong as those 542 for CBC mode when using the same block cipher. 544 Unfortunately, it is very easy to misuse this counter mode. If 545 counter block values are ever used for more that one packet with the 546 same key, then the same key stream will be used to encrypt both 547 packets, and the confidentiality guarantees are voided. 549 What happens if the encryptor XORs the same key stream with two 550 different plaintexts? Suppose two plaintext byte sequences P1, P2, 551 P3 and Q1, Q2, Q3 are both encrypted with key stream K1, K2, K3. The 552 two corresponding ciphertexts are: 554 (P1 XOR K1), (P2 XOR K2), (P3 XOR K3) 556 (Q1 XOR K1), (Q2 XOR K2), (Q3 XOR K3) 558 If both of these two ciphertext streams are exposed to an attacker, 559 then a catastrophic failure of confidentiality results, since: 561 (P1 XOR K1) XOR (Q1 XOR K1) = P1 XOR Q1 562 (P2 XOR K2) XOR (Q2 XOR K2) = P2 XOR Q2 563 (P3 XOR K3) XOR (Q3 XOR K3) = P3 XOR Q3 565 Once the attacker obtains the two plaintexts XORed together, it is 566 relatively straightforward to separate them. Thus, using any stream 567 cipher, including AES-CTR, to encrypt two plaintexts under the same 568 key stream leaks the plaintext. 570 Therefore, stream ciphers, including AES-CTR, should not be used with 571 static keys. It is inappropriate to use AES-CTR with static keys. 572 Extraordinary measures would be needed to prevent reuse of a counter 573 block value with the static key across power cycles. To be safe, ESP 574 implementations MUST use fresh keys with AES-CTR. The Internet Key 575 Exchange (IKE) protocol [IKE] can be used to establish fresh keys. 576 IKE can also be used to establish the nonce at the beginning of the 577 security association. 579 When IKE is used to establish fresh keys between two peer entities, 580 separate keys are established for the two traffic flows. When a 581 mechanism other than IKE is used to establish fresh keys, and that 582 mechanism establishes only a single key to encrypt packets, then 583 there is a high probability that the peers will select the same IV 584 values for some packets. Thus, to avoid counter block collisions, 585 ESP implementations that permit use of the same key for encrypting 586 outbound traffic and decrypting incoming traffic with the same peer 587 MUST ensure that the two peers assign different Nonce values to the 588 security association. 590 Data forgery is trivial with CTR mode. The demonstration of this 591 attack is similar to the key stream reuse discussion above. If a 592 known plaintext byte sequence P1, P2, P3 is encrypted with key stream 593 K1, K2, K3, then the attacker can replace the plaintext with one of 594 his own choosing. The ciphertext is: 596 (P1 XOR K1), (P2 XOR K2), (P3 XOR K3) 598 The attacker simply XORs a selected sequence Q1, Q2, Q3 with the 599 ciphertext to obtain: 601 (Q1 XOR (P1 XOR K1)), (Q2 XOR (P2 XOR K2)), (Q3 XOR (P3 XOR K3)) 603 Which is the same as: 605 ((Q1 XOR P1) XOR K1), ((Q2 XOR P2) XOR K2), ((Q3 XOR P3) XOR K3) 607 Decryption of the attacker-generated ciphertext will yield exactly 608 what the attacker intended: 610 (Q1 XOR P1), (Q2 XOR P2), (Q3 XOR P3) 612 Accordingly, ESP implementations MUST use of AES-CTR in conjunction 613 with ESP authentication. 615 Additionally, since AES has a 128-bit block size, regardless of the 616 mode employed, the ciphertext generated by AES encryption becomes 617 distinguishable from random values after 2^64 blocks are encrypted 618 with a single key. Since ESP with Enhanced Sequence Numbers allows 619 for up to 2^64 packets in a single security association, there is 620 real potential for more than 2^64 blocks to be encrypted with one 621 key. Therefore, implementations SHOULD generate a fresh key before 622 2^64 blocks are encrypted with the same key. Note that ESP with 623 32-bit Sequence Numbers will not exceed 2^64 blocks even if all of 624 the packets are maximum-length IPv6 jumbograms [JUMBO]. 626 There are fairly generic precomputation attacks against all block 627 cipher modes that allow a meet-in-the-middle attack against the key. 628 These attacks require the creation and searching of huge tables of 629 ciphertext associated with known plaintext and known keys. Assuming 630 that the memory and processor resources are available for a 631 precomputation attack, then the theoretical strength of AES-CTR (and 632 any other block cipher mode) is limited to 2^(n/2) bits, where n is 633 the number of bits in the key. The use of long keys is the best 634 countermeasure to precomputation attacks. Therefore, implementations 635 that employ 128-bit AES keys should take precautions to make the 636 precomputation attacks more difficult. The unpredictable nonce value 637 in the counter block significantly increases the size of the table 638 that the attacker must compute to mount a successful attack. 640 8. Design Rationale 642 In the development of this specification, the use of the ESP sequence 643 number field instead of an explicit IV field was considered. This 644 selection is not a cryptographic security issue, as either approach 645 will prevent counter block collisions. 647 In a very conservative model of encryption security, at most 2^64 648 blocks ought to be encrypted with AES-CTR under a single key. Under 649 this constraint, no more than 64 bits are needed to identify each 650 packet within a security association. Since the ESP extended 651 sequence number is 64 bits, it is an obvious candidate for use as an 652 implicit IV. This would dictate a single method for the assignment 653 of per-packet value in the counter block. The use of an explicit IV 654 does not dictate such a method, which is desirable for several 655 reasons. 657 1. Only the encryptor can ensure that the value is not used for 658 more than one packet, so there is no advantage to selecting a 659 mechanism that allows the decryptor to determine whether counter 660 block values collide. Damage from the collision is done, whether 661 the decryptor detects it or not. 663 2. Allows adders, LFSRs, and any other technique that meets the 664 time budget of the encryptor, so long as the technique results in 665 a unique value for each packet. Adders are simple and 666 straightforward to implement, but due to carries, they do not 667 execute in constant time. LSFRs offer an alternative that 668 executes in constant time. 670 3. Complexity is in control of the implementer. Further, the 671 decision made by the implementer of the encryptor does not make 672 the decryptor more (or less) complex. 674 4. When the encryptor has more than one cryptographic hardware 675 device, an IV prefix can be assigned to each device, ensuring that 676 collisions will not occur. Yet, since the decryptor does not need 677 to examine IV structure, the decryptor is unaffected by the IV 678 structure selected by the encryptor. One cannot make use of the 679 same technique with the ESP sequence numbers, because the 680 semantics for them require sequential value generation. 682 5. Assurance boundaries are very important to implementations 683 that will be evaluated against the FIPS Pub 140-1 or FIPS Pub 684 140-2 [SECRQMTS]. The assignment of the per-packet counter block 685 value needs to be inside the assurance boundary. Some 686 implementations assign the sequence number inside the assurance 687 boundary, but others do not. A sequence number collision does not 688 have the dire consequences, but, as described in section 6, a 689 collision in counter block values has disastrous consequences. 691 6. Coupling with the sequence number is possible in those 692 architectures where the sequence number assignment is performed 693 within the assurance boundary. In this situation, the sequence 694 number and the IV field will contain the same value. 696 7. Decoupling from the sequence number is possible in those 697 architectures where the sequence number assignment is performed 698 outside the assurance boundary. 700 The use of an explicit IV field directly follows from the decoupling 701 of the sequence number and the per-packet counter block value. The 702 overhead associated with 64 bits for the IV field is acceptable. 703 This overhead is significantly less than the overhead associated with 704 Cipher Block Chaining (CBC) mode. As normally employed, CBC requires 705 a full block for the IV and, on average, half of a block for padding. 706 AES-CTR with an explicit IV has about one-third of the overhead as 707 AES-CBC, and the overhead is constant for each packet. 709 The inclusion of the nonce provides a weak countermeasure against 710 precomputation attacks. For this countermeasure to be effective, the 711 attacker must not be able to predict the value of the nonce well in 712 advance of security association establishment. The use of long keys 713 provides a strong countermeasure to precomputation attacks, and AES 714 offers key sizes that thwart these attacks for many decades to come. 716 A 28-bit block counter value is sufficient for the generation of a 717 key stream to encrypt the largest possible IPv6 jumbogram [JUMBO]; 718 however, a 32-bit field is used. This size is convenient for both 719 hardware and software implementations. 721 9. IANA Considerations 723 IANA has assigned as the ESP transform number for AES-CTR with 724 an explicit IV. 726 10. Acknowledgements 728 This document is the result of extensive discussions and compromises. 729 While not all of the participants are completely satisfied with the 730 outcome, the document is better for their contributions. 732 The author thanks the members of the IPsec working group for their 733 contributions to the design, with special mention of the efforts of 734 (in alphabetical order) Steve Bellovin, David Black, Niels Ferguson, 735 Charlie Kaufman, Steve Kent, Paul Koning, David McGrew, Robert 736 Moskowitz, Jesse Walker, and Doug Whiting. 738 The author thanks and Alireza Hodjat, John Viega, and Doug Whiting 739 for assistance with the test vectors. 741 11. References 743 This section provides normative and informative references. 745 11.1. Normative References 747 [AES] NIST, FIPS PUB 197, "Advanced Encryption Standard 748 (AES)," November 2001. 750 [DOI] Piper, D., "The Internet IP Security Domain of 751 Interpretation for ISAKMP," RFC 2407, November 1998. 753 [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security 754 Payload (ESP)," RFC 2406, November 1998. 756 [MODES] Dworkin, M., "Recommendation for Block Cipher Modes 757 of Operation: Methods and Techniques," NIST Special 758 Publication 800-38A, December 2001. 760 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 761 Requirement Levels," RFC 2119, March 1997. 763 11.2. Informative References 765 [ARCH] Kent, S. and R. Atkinson, "Security Architecture for 766 the Internet Protocol," RFC 2401, November 1998. 768 [BDJR] Bellare, M, Desai, A., Jokipii, E., and P. Rogaway, 769 "A Concrete Security Treatment of Symmetric Encryption: 770 Analysis of the DES Modes of Operation", Proceedings 771 38th Annual Symposium on Foundations of Computer 772 Science, 1997. 774 [HMAC-SHA] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 775 within ESP and AH," RFC 2404, November 1998. 777 [IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange 778 (IKE)," RFC 2409, November 1998. 780 [JUMBO] Borman, D., Deering, S., and R. Hinden, "IPv6 781 Jumbograms," RFC 2675, August 1999. 783 [ROADMAP] Thayer, R., N. Doraswamy and R. Glenn, "IP Security 784 Document Roadmap," RFC 2411, November 1998. 786 [SECRQMTS] National Institute of Standards and Technology. 787 FIPS Pub 140-1: Security Requirements for Cryptographic 788 Modules. 11 January 1994. 790 National Institute of Standards and Technology. 791 FIPS Pub 140-2: Security Requirements for Cryptographic 792 Modules. 25 May 2001. [Supercedes FIPS Pub 140-1] 794 12. Author's Address 796 Russell Housley 797 Vigil Security, LLC 798 918 Spring Knoll Drive 799 Herndon, VA 20170 800 USA 801 housley@vigilsec.com 803 13. Full Copyright Statement 805 Copyright (C) The Internet Society 2003. All Rights Reserved. 807 This document and translations of it may be copied and furnished to 808 others, and derivative works that comment on or otherwise explain it 809 or assist in its implementation may be prepared, copied, published 810 and distributed, in whole or in part, without restriction of any 811 kind, provided that the above copyright notice and this paragraph are 812 included on all such copies and derivative works. However, this 813 document itself may not be modified in any way, such as by removing 814 the copyright notice or references to the Internet Society or other 815 Internet organizations, except as needed for the purpose of 816 developing Internet standards in which case the procedures for 817 copyrights defined in the Internet Standards process must be 818 followed, or as required to translate it into languages other than 819 English. 821 The limited permissions granted above are perpetual and will not be 822 revoked by the Internet Society or its successors or assigns. 824 This document and the information contained herein is provided on an 825 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 826 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 827 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 828 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 829 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.