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