idnits 2.17.1 draft-moskowitz-aes128-ctr-00.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- == There are 6 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([ESP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 203 -- Looks like a reference, but probably isn't: '2' on line 203 -- Looks like a reference, but probably isn't: '0' on line 117 == Unused Reference: 'MENEZES' is defined on line 225, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) -- Possible downref: Non-RFC (?) normative reference: ref. 'MENEZES' -- Possible downref: Non-RFC (?) normative reference: ref. 'MODES' Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft J. Walker, Intel 2 September 2001 R. Moskowitz, TruSecure 3 Expiration Date: April 2002 5 The AES128 CTR Mode of Operation and Its Use With IPsec 6 draft-moskowitz-aes128-ctr-00.txt 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as 21 reference 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 Table of Contents 31 1. Abstract...........................................................1 32 2. Conventions used in this document..................................2 33 3. Introduction.......................................................2 34 4. CTR rules in ESP...................................................3 35 4.1. Padding..........................................................3 36 4.2. The Counter......................................................3 37 4.3. Keying Material for AES128-CTR...................................4 38 4.4. Data Authenticity for AES128-CTR.................................4 39 5. Security Considerations............................................4 40 6. IANA Considerations................................................5 41 7. ICANN Considerations...............................................5 42 8. References.........................................................5 43 9. Acknowledgments....................................................5 44 APPENDIX A. Test Vectors for AES128 CTR Mode..........................5 45 11. Author's Address..................................................8 46 16. Copyright Statement...............................................9 48 1. Abstract 50 This document describes the use of the AES Cipher Algorithm with 128 51 bit key in Counter (CTR) Mode, with an implicit counter, as a 53 Moskowitz, Walker 1 54 confidentiality mechanism within the context of the IPsec 55 Encapsulating Security Payload [ESP]. 57 CTR is a parallelizable block-cipher mode of operation. It uses the 58 underlying block cipher as a stream cipher. Accordingly, great care 59 must be exercised to utilize it appropriately within IPsec. 61 2. Conventions used in this document 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 65 this document are to be interpreted as described in [RFC-2119]. 67 3. Introduction 69 Counter mode (CTR) is a block-cipher mode of operation. It uses a 70 block cipher as a stream cipher. Although it has not yet been 71 standardized, it is one of the oldest modes of operation. It is 72 particularly easy to implement, and parallelizable. The size of the 73 generated ciphertext increases only by the size of the counter value 74 over that for the plaintext. Furthermore, it only uses the block 75 cipher encryption primitive for both encryption and decryption. 76 Counter mode also guarantees a high level of privacy when the 77 underlying block cipher does and it is used correctly. Thus, counter 78 mode has many properties that make it attractive for use with AES 79 and high-speed networking. 81 Counter mode also has properties that render it harder to use than 82 other modes of operation. Being a stream cipher, any reuse of the 83 counter (from which the mode is named) with the same key is 84 catastrophic, in that it immediately leaks information about the 85 encrypted plaintext. Hence it is inappropriate to use this mode of 86 operation with statically configured keys, unless the implementation 87 takes extraordinary measures to prevent reuse of a counter value 88 with the key. Also, it is trivial to use any valid ciphertext to 89 forge other valid ciphertexts, so it is equally catastrophic to use 90 the mode of operation without message authentication. 92 Counter mode is easy to describe abstractly. Assume the cipher block 93 E uses a block size of B bits; for AES, B = 128. The encrypting 94 party establishes a counter C when the session key is fixed: 96 C := 0 98 To encrypt a message M, the sender partitions M into B-bit blocks M 99 = M[1] M[2] � M[n-1] M[n]. Each block of M is then XOR�d with an 100 encrypted counter value: 102 C[0] := C 103 for i := 1 to n-1 do 104 C := C + 1 106 Walker, Moskowitz 2 107 C[i] := M[i] XOR E(C) 108 C := C + 1 109 C[n] := M[n] XOR Chop(E(C)) 110 output C[0] C[1] � C[n] as the ciphertext 112 Here, if block M[n] consists of k bits, the function Chop() 113 truncates its argument to the k most significant bits. To decrypt a 114 counter mode-encrypted ciphertext C[0] C[1] � C[n], this process is 115 reversed: 117 C := C[0] 118 for i := 1 to n-1 do 119 C := C + 1 120 M[i] := C[i] XOR E(C) 121 C := C + 1 122 M[n] := C[n] XOR Chop(E(C)) 123 output M[1] � M[n] as the recovered plaintext 125 4. CTR rules in ESP 127 For CTR to be used in ESP, four factors MUST be standardize. These 128 are the padding rules, the construction of the counter, the keying 129 material, and data authentication. 131 4.1. Padding 133 CTR mode does not require padding of the cleartext. However, ESP 134 does. ESP uses padding to 32-bit word-align the authentication data. 135 The padding, Pad Length, and the Next Header MUST be concatenated 136 with the cleartext before encrypting, as per ESP rules. 138 4.2. The Counter 140 Each ESP datagram must convey the counter used to encrypt the 141 payload. When AES is used as the block cipher, the counter consists 142 of 128 bits. This specification defines the CTR mode counter 143 implicitly: 145 Counter ::= (0x0000000000000 || SPI || Seq# || 0x000) 147 where SPI identifies the security association, Seq# is the ESP 148 sequence number, represented as a big-Endian integer value, and the 149 12 least significant bits of the counter begins with the value 0, 150 again represented as a big-Endian integer value. The first 128-bit 151 block of the datagram plaintext is encrypted by XORing the plaintext 152 block with the value AES(Counter+1), the second by XORing the second 153 block of plaintext with AES(Counter+2), etc. This construction 154 permits each datagram to consist of up to 2^12 = 4096 128-bit 155 blocks, or 65536 bytes of total encrypted data, including padding. 157 Walker, Moskowitz 3 158 4.3. Keying Material for AES128-CTR 160 Provide the 128 most-significant bits as the encryption key size to 161 the keying material extraction process. The remaining bits are 162 applied to the ESP authentication method. 164 4.4. Data Authenticity for AES128-CTR 166 Since it is trivial to construct one valid ciphertext from any other 167 valid ciphertext when counter mode is used, implementations MUST 168 require the use of a non-NULL ESP authentication method with counter 169 mode. 171 5. Security Considerations 173 When used properly, AES-CTR mode provides strong confidentiality 174 guarantees. Bellare et. al. show in [MODES] that the privacy 175 guarantees under counter mode are at least as strong as those for 176 CBC mode when using the same block cipher for both. 178 However, it is very easy to misuse this construction. If a counter 179 value is ever reused with a key, the confidentiality guarantees are 180 voided. This is very easy to see: if the same counter value i is 181 used to encrypt two plaintexts P[1] and P[2], then it is trivial to 182 recover information about the plaintexts: 184 C[i] := E(i) 185 C[1] := P[1] XOR C[i] 186 C[2] := P[2] XOR C[i] 187 C[1] XOR C[2] = (P[1] XOR C[i]) XOR (P[2] XOR C[i]) 188 = P[1] XOR P[2] 190 Practically, this implies this mode of operation should not be used 191 with statically configured keys. ESP implementations therefore 192 SHOULD NOT support CTR mode with statically configured keys; if it 193 does, the implementation MUST take other precautions to assure the 194 implementation will never reuse a counter value with a key. 196 Similarly, data forgery is trivial with CTR mode. The argument is 197 very similar to the privacy case: if a known plaintext P[1] is 198 counter mode encrypted under i, then it can be replaced with 199 plaintext P[2], since 201 C[i] := E(i) 202 C[1] := P[1] XOR C[i] 203 C[2] = (P[2] XOR P[1]) XOR C[1] 205 Accordingly, implementations MUST NOT allow the use of CTR mode 206 without ESP authentication. 208 Walker, Moskowitz 4 209 6. IANA Considerations 211 IANA has assigned ESP transform number XX to AES128-CTR. 213 7. ICANN Considerations 215 There are no ICANN considerations here. 217 8. References 219 [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate 220 Requirement Levels", RFC 2119, March 1997. 222 [ESP], Kent, S., and Atkinson, R., "IP Encapsulating Security 223 Payload", RFC 2406, November 1998. 225 [MENEZES], Menezes, A., van Oorschot, P., and Vanstone, S., 226 "Handbook of Applied Cryptography", CRC Press, 1997. 228 [MODES], Bellare, M, Desai, A., Jokipii, E., and Rogaway, P., �A 229 Concrete Security Treatment of Symmetric Encryption: Analysis of the 230 DES Modes of Operation�, Proceedings 38th Annual Symposium on 231 Foundations of Computer Science, 1997 233 9. Acknowledgments 235 TBS 237 APPENDIX A. Test Vectors for AES128 CTR Mode 239 The following test vectors were computed using the algorithm from 240 Section 3 above. The counter value was constructed as in Section 241 4.2. These two conditions mean the counter value is incremented and 242 then transformed into a Big-Endian value prior to encryption. 244 key = 00000000000000000000000000000000 245 counter = 1000 246 plaintext = 00000000000000000000000000000000 247 ciphertext = 8eaedd7f7b46339c7589ae9d73498648 249 key = c34c052cc0da8d73451afe5f03be297f 250 counter = 2000 251 plaintext = 8eaedd7f7b46339c7589ae9d73498648 252 ciphertext = be70f1bd31cf5671269ef79935d7e58b 254 key = c98d5fb63b68c027e88317d8233c5b9d 255 counter = 3000 256 plaintext = be70f1bd31cf5671269ef79935d7e58b 258 Walker, Moskowitz 5 259 ciphertext = db7a53c1fe52d21a25048df2e0ef5684 261 key = 6a5964499d35cea7e1ac707b37b923ed 262 counter = 4000 263 plaintext = db7a53c1fe52d21a25048df2e0ef5684 264 ciphertext = 0293c3e5e8f70561eb875bfd1e8ccd9d 266 key = 5f060d3716b345c253f6749abac10917 267 counter = 5000 268 plaintext = 0293c3e5e8f70561eb875bfd1e8ccd9d 269 00000000000000000000000000000000 270 ciphertext = f86217238848f2428924a5e23a30d41e 271 fda94a058c491959ca2bc0b546c612b1 273 key = f3ce6e546edba6223b2489f48fc94c5d 274 counter = 6000 275 plaintext = f86217238848f2428924a5e23a30d41e 276 fda94a058c491959ca2bc0b546c612b1 277 ciphertext = e18800d55abfa320e7688f847c765fe6 278 e61d9e4035caf76839ce1f3f5666d432 280 key = 9591f146c6ff55f71138f822aec4182d 281 counter = 7000 282 plaintext = e18800d55abfa320e7688f847c765fe6 283 e61d9e4035caf76839ce1f3f5666d432 284 ciphertext = 1bde1ed88f361135eb0af3aac4f04695 285 f714185babc5f7f1b373d7a534a67a3d 287 key = 0eb6c75b7a7103eff9d178145b69589d 288 counter = 8000 289 plaintext = 1bde1ed88f361135eb0af3aac4f04695 290 f714185babc5f7f1b373d7a534a67a3d 291 ciphertext = 40a828ac02241e92677754784010ad83 292 85a6c61123e66b50bb1ed9c1894e3b6d 294 key = 2f6f7a25c070604d6a23ad786a05e5ab 295 counter = 9000 296 plaintext = 40a828ac02241e92677754784010ad83 297 85a6c61123e66b50bb1ed9c1894e3b6d 298 00000000000000000000000000000000 299 00000000000000000000000000000000 300 ciphertext = a306bd9d74436128027eac3f80c60a55 301 e32ed7e95ec3bf14542c594c24191fc5 302 1bb2bba73511d1195d65109ce2c08aaf 303 d1362f2c8ee6a438ee996f7ec9aa6ef6 305 key = 11ef4d8c58fe48b2ebd10a6d20c87415 306 counter = a000 307 plaintext = a306bd9d74436128027eac3f80c60a55 308 e32ed7e95ec3bf14542c594c24191fc5 309 1bb2bba73511d1195d65109ce2c08aaf 310 d1362f2c8ee6a438ee996f7ec9aa6ef6 311 ciphertext = da6816cc4bdbc9e70f182e2ef003764a 313 Walker, Moskowitz 6 314 bc6cc452169986c1aab6bab49a7cfb8c 315 2dea11fc8031110fffc699e3286f14f8 316 62945e21dc2d9a3bf566f20dea27fd0a 318 key = 10a1acc3425688664fab789cb73ca8a5 319 counter = b000 320 plaintext = da6816cc4bdbc9e70f182e2ef003764a 321 bc6cc452169986c1aab6bab49a7cfb8c 322 2dea11fc8031110fffc699e3286f14f8 323 62945e21dc2d9a3bf566f20dea27fd0a 324 ciphertext = 84f937044a5aa566a5d1792e0591609a 325 36cd91ddc2a78d9c7e58d030cd81bf13 326 d38385e80804f15ca51cf219918c1c44 327 1d1491689e9264edaf40e3a56c052e39 329 key = 1bf58c409996b2f0e5abb93919646154 330 counter = c000 331 plaintext = 84f937044a5aa566a5d1792e0591609a 332 36cd91ddc2a78d9c7e58d030cd81bf13 333 d38385e80804f15ca51cf219918c1c44 334 1d1491689e9264edaf40e3a56c052e39 335 ciphertext = 6a8888ff1501f99ed8a23426ffebb918 336 b12b4a52e801a79a3984208577ea0aba 337 6909a93e7d9186af2b7f2d39283e8ad1 338 479a1979b53a3bbe0e293e3535c433c8 340 key = 68b539de87ad0bd1f94adecbc7d9d1c4 341 counter = d000 342 plaintext = 6a8888ff1501f99ed8a23426ffebb918 343 b12b4a52e801a79a3984208577ea0aba 344 6909a93e7d9186af2b7f2d39283e8ad1 345 479a1979b53a3bbe0e293e3535c433c8 346 00000000000000000000000000000000 347 00000000000000000000000000000000 348 00000000000000000000000000000000 349 00000000000000000000000000000000 350 ciphertext = 87849e665e824d5b63ebcdd2f3e5f8d9 351 7fca7d994f32bd625c8045b6adad1bbf 352 d62794d947ac071f9d1891a2ef7b041c 353 43b2840a5d86c3294d996b2e08fe8b66 354 5dce18e88feca383914967de9770de83 355 c25102a433467d712a0c75cb1a537c0a 356 8d8bf7452eb508cb108042f46f3c04e6 357 173d915cbf1fa272273e56f09ac34353 359 key = 0f5566ab94f6a3e53287113baf8dca7a 360 counter = e000 361 plaintext = 87849e665e824d5b63ebcdd2f3e5f8d9 362 7fca7d994f32bd625c8045b6adad1bbf 363 d62794d947ac071f9d1891a2ef7b041c 364 43b2840a5d86c3294d996b2e08fe8b66 365 5dce18e88feca383914967de9770de83 366 c25102a433467d712a0c75cb1a537c0a 368 Walker, Moskowitz 7 369 8d8bf7452eb508cb108042f46f3c04e6 370 173d915cbf1fa272273e56f09ac34353 371 ciphertext = 54114ffde7ef68e65861557d8d29949e 372 9e5d369d566217dd7e86eee61504099f 373 05242d6d1a8c6f1bb747361e145f64ac 374 a8cf780493ab5e26156c11e5cc9c9853 375 29688343a3b73a68acaeb50dc144c938 376 e9d6e8cd8f20c5bd18c001900d49a0bd 377 409cd49bc4f08873231eb345328ed32c 378 514be68d572ff3f53fbe92f1c8de23d1 380 key = 8480339a9135f39e3880ec88fe3f9135 381 counter = f000 382 plaintext = 54114ffde7ef68e65861557d8d29949e 383 9e5d369d566217dd7e86eee61504099f 384 05242d6d1a8c6f1bb747361e145f64ac 385 a8cf780493ab5e26156c11e5cc9c9853 386 29688343a3b73a68acaeb50dc144c938 387 e9d6e8cd8f20c5bd18c001900d49a0bd 388 409cd49bc4f08873231eb345328ed32c 389 514be68d572ff3f53fbe92f1c8de23d1 390 ciphertext = 8e98f31a8c36a2189c45d2cc820c91e5 391 2289d925838a0caeb598d5ee82ea9e76 392 cf5e414bdba0f8a33f0df20ce37aba97 393 a4a787412871120a36ec7ddb44823e5b 394 3cf23e687d5995c3ac2ddd74f68d489c 395 f7dd8c73e4506d6fd7f22d7b84900589 396 0494c0bfe59a879dd5e75c7a7ae32e19 397 e16528837b102df9f3004d48a4eed298 399 key = e01f358504f55405eb8682771b8ded9e 400 counter = 10000 401 plaintext = 8e98f31a8c36a2189c45d2cc820c91e5 402 2289d925838a0caeb598d5ee82ea9e76 403 cf5e414bdba0f8a33f0df20ce37aba97 404 a4a787412871120a36ec7ddb44823e5b 405 3cf23e687d5995c3ac2ddd74f68d489c 406 f7dd8c73e4506d6fd7f22d7b84900589 407 0494c0bfe59a879dd5e75c7a7ae32e19 408 e16528837b102df9f3004d48a4eed298 409 ciphertext = 1d3389c2986ee4f53346ddc8a1539562 410 e58e6f8ba0a78cd6de78579caac8b632 411 4f5611959f6071a4700245e4500516db 412 11e8f73c8588f109557e9a60f1bc8757 413 946184932bce426376844ec72a124b3e 414 0f4917f01b13b34a16757c4f8348d90b 415 00e53f7777ce7889f2d90716add0eaed 416 a950aefa0ac515c8955050366194fee3 418 11. Author's Address 420 Walker, Moskowitz 8 421 Robert Moskowitz 422 TruSecure Corporation 423 1200 Walnut Bottom Rd. 424 Carlisle, PA 17013 425 Email: rgm@trusecure.com 427 Jesse Walker 428 Intel Corporation 429 2111 N.E. 25th Avenue 430 Hillsboro, Oregon 97229 431 Email: jesse.walker@intel.com 433 16. Copyright Statement 435 Copyright (c) The Internet Society (2001). All Rights Reserved. 436 This document and translations of it may be copied and furnished to 437 others, and derivative works that comment on or otherwise explain it 438 or assist in its implementation may be prepared, copied, published 439 and distributed, in whole or in part, without restriction of any 440 kind, provided that the above copyright notice and this paragraph 441 are included on all such copies and derivative works. However, this 442 document itself may not be modified in any way, such as by removing 443 the copyright notice or references to the Internet Society or other 444 Internet organizations, except as needed for the purpose of 445 developing Internet standards in which case the procedures for 446 copyrights defined in the Internet Standards process must be 447 followed, or as required to translate it into languages other than 448 English. 450 The limited permissions granted above are perpetual and will not be 451 revoked by the Internet Society or its successors or assigns. 453 This document and the information contained herein is provided on an 454 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 455 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 456 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 457 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 458 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 460 Walker, Moskowitz 9