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