idnits 2.17.00 (12 Aug 2021) /tmp/idnits58514/draft-ietf-ipsec-ciph-aes-ccm-00.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 7065 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) == Missing Reference: 'CCM' is mentioned on line 64, but not defined == Missing Reference: 'JUMBO' is mentioned on line 226, but not defined == Unused Reference: 'CMM' is defined on line 427, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'ESP' -- Possible downref: Non-RFC (?) normative reference: ref. 'CMM' -- 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. 'ROAD') (Obsoleted by RFC 6071) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 8 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 January 2003 6 Using AES CCM 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 CCM Mode, with an explicit 38 initialization vector, as an IPsec Encapsulating Security Payload 39 (ESP) mechanism to provide confidentiality, data origin 40 authentication, connectionless integrity. 42 1. Introduction 44 The Advanced Encryption Standard (AES) [AES] is a block cipher, and it 45 can be used in many different modes. This document describes the use 46 of AES in CCM (Counter with CBC-MAC) mode (AES-CMM), with an explicit 47 initialization vector (IV), as an IPsec Encapsulating Security Payload 48 (ESP) [ESP] mechanism to provide confidentiality, data origin 49 authentication, connectionless integrity. 51 This document does not provide an overview of IPsec. However, 52 information about how the various components of IPsec and the way in 53 which they collectively provide security services is available in 54 [ARCH] and [ROAD]. 56 1.1. Conventions Used In This Document 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in [STDWORDS]. 62 2. AES-CCM Mode 64 CCM is a generic authenticate-and-encrypt block cipher mode [CCM]. In 65 this specification, CCM is used with the AES [AES] block cipher. 67 AES-CCM has two parameters: 69 M M indicates the size of the integrity check value (ICV). 70 CCM defines values of 4, 6, 8, 10, 12, 14, and 16 octets; 71 However, to maintain alignment and provide adequate 72 security, only the values that are a multiple of four and 73 are at least eight are permitted. Implementations MUST 74 support M values of 8 octets and 16 octets, and 75 implementations MAY support an M value of 12 octets. 77 L L indicates the size of the length field in octets. CCM 78 defines values of L between 2 octets and 8 octets. 79 Implementations MUST support an L value of 4 octets, which 80 accommodates a full Jumbogram [JUMBO]; however, the length 81 includes all of the encrypted data, which also includes 82 the ESP Padding, Pad Length, and Next Header fields. 84 There are four inputs to CCM originator processing: 86 key 87 A single key is used to calculate the ICV using CBC-MAC and to 88 perform payload encryption using counter mode. AES supports 89 key sizes of 128 bits, 192 bits, and 256 bits. The default key 90 size is 128 bits, and implementations MUST support this key 91 size. Implementations MAY also support key sizes of 192 bits 92 and 256 bits. 94 nonce 95 The size of the nonce depends on the value selected for the 96 parameter L. It is 15-L octets. Implementations MUST support 97 a nonce of 11 octets. The construction of the nonce is 98 described in section 4. 100 payload 102 The payload of the ESP packet. The payload MUST NOT be longer 103 than 4,294,967,295 octets, which is the maximum size of a 104 Jumbogram [JUMBO]; however, the ESP Padding, Pad Length, and 105 Next Header fields are also part of the payload. 107 AAD 108 CCM provides data integrity and data origin authentication for 109 some data outside the payload. CCM does not allow additional 110 authenticated data (AAD) to be longer than 111 18,446,744,073,709,551,615 octets. The ICV is computed from 112 the ESP header, Payload, and ESP trailer fields, which is 113 significantly smaller than the CCM imposed limit. The 114 construction of the AAD described in section 5. 116 AES-CCM requires the encryptor to generate a unique per-packet value, 117 and communicate this value to the decryptor. This per-packet value 118 is one of the component parts of the nonce, and it is referred to as 119 the initialization vector (IV). The same IV and key combination MUST 120 NOT be used more than once. The encryptor can generate the IV in any 121 manner that ensures uniqueness. Common approaches to IV generation 122 include incrementing a counter for each packet and linear feedback 123 shift registers (LFSRs). 125 AES-CCM employs counter mode for encryption. As with any stream 126 cipher, reuse of the IV same value with the same key is catastrophic. 127 An IV collision immediately leaks information about the plaintext in 128 both packets. For this reason, it is inappropriate to use this CCM 129 with statically configured keys. Extraordinary measures would be 130 needed to prevent reuse of an IV value with the static key across 131 power cycles. To be safe, implementations MUST use fresh keys with 132 AES-CCM. The Internet Key Exchange (IKE) [IKE] protocol can be used 133 to establish fresh keys. 135 3. ESP Payload 137 The ESP payload is comprised of the IV followed by the ciphertext. 139 The payload field, as defined in [ESP], is structured as shown in 140 Figure 1. 142 0 1 2 3 143 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 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Initialization Vector | 146 | (8 octets) | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | | 149 ~ Encrypted Payload (variable) ~ 150 | | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | | 153 ~ Authentication Data (variable) ~ 154 | | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 Figure 1. ESP Payload Encrypted with AES-CCM 159 3.1. Initialization Vector (IV) 161 The AES-CCM IV field MUST be eight octets. The IV MUST be chosen by 162 the encryptor in a manner that ensures that the same IV value is used 163 only once for a given key. The encryptor can generate the IV in any 164 manner that ensures uniqueness. Common approaches to IV generation 165 include incrementing a counter for each packet and linear feedback 166 shift registers (LFSRs). 168 Including the IV in each packet ensures that the decryptor can 169 generate the key stream needed for decryption, even when some 170 datagrams are lost or reordered. 172 3.2. Encrypted Payload 174 The encrypted payload contains the ciphertext. 176 AES-CCM mode does not require plaintext padding. However, ESP does 177 require padding to 32-bit word-align the authentication data. The 178 Padding, Pad Length, and Next Header fields MUST be concatenated with 179 the plaintext before performing encryption, as described in [ESP]. 181 3.3. Authentication Data 183 AES-CCM provides an encrypted ICV. The ICV provided by CCM is 184 carried in the Authentication Data fields without further encryption. 185 Implementations MUST support ICV sizes of 8 octets and 16 octets. 186 Implementations MAY also support ICV 12 octets. 188 4. Nonce Format 190 Each packet conveys the IV that is necessary to construct the 191 sequence of counter blocks used by counter mode to generate the key 192 stream. The AES counter block 16 octets. One octet is used for the 193 CCM Flags, and 4 octets are used for the block counter, as specified 194 by the CCM L parameter. The remaining ee octets are the nonce. 195 These octets occupy the second through the twelfth octets in the 196 counter block. Figure 2 shows the format of the nonce. 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Truncated SPI | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Initialization Vector | 204 | | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Figure 2. Nonce Format 209 The components of the nonce are as follows: 211 Truncated SPI 212 The truncated SPI field is 24 bits. As the name implies, it 213 contains the least significant 24 bits of the ESP SPI. 215 Initialization Vector 216 The IV field is 64 bits. As described in section 3.1, the IV 217 MUST be chosen by the encryptor in a manner that ensures that 218 the same IV value is used only once for a given key. 220 This construction permits each packet to consist of up to: 222 2^32 blocks = 4,294,967,296 blocks 223 = 68,719,476,736 octets 225 This construction provides more key stream for each packet than is 226 needed to handle any IPv6 Jumbogram [JUMBO]. 228 5. AAD Construction 230 The data integrity and data origin authentication for the SPI and 231 (Extended) Sequence Number fields is provided without encrypting 232 them. Two formats are defined: one for 32-bit sequence numbers and 233 one for 64-bit extended sequence numbers. The format with 32-bit 234 sequence numbers is shown in Figure 3, and the format with 64-bit 235 extended sequence numbers is shown in Figure 4. 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | SPI | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | 32-bit Sequence Number | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 3. AAD Format with 32-bit Sequence Number 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | SPI | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | 64-bit Extended Sequence Number | 253 | | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 Figure 4. AAD Format with 64-bit Extended Sequence Number 258 4. Packet Expansion 260 The initialization vector (IV) and the integrity check value (ICV) is 261 the only sources of packet expansion. The IV always adds 8 octets to 262 the front of the payload. The ICV is added at the end of the 263 payload, and the CCM parameter M determines the size of the ICV. 264 Implementations MUST support M values of 8 octets and 16 octets, and 265 implementations MAY also support an M value of 12 octets. 267 5. Test Vectors 269 To be supplied. 271 6. Security Considerations 273 AES-CCM employs counter (CTR) mode for confidentiality. If a counter 274 value is ever used for more that one packet with the same key, then 275 the same key stream will be used to encrypt both packets, and the 276 confidentiality guarantees are voided. 278 What happens if the encryptor XORs the same key stream with two 279 different packet plaintexts? Suppose two packets are defined by two 280 plaintext byte sequences P1, P2, P3 and Q1, Q2, Q3, then both are 281 encrypted with key stream K1, K2, K3. The two corresponding 282 ciphertexts are: 284 (P1 XOR K1), (P2 XOR K2), (P3 XOR K3) 286 (Q1 XOR K1), (Q2 XOR K2), (Q3 XOR K3) 288 If both of these two ciphertext streams are exposed to an attacker, 289 then a catastrophic failure of confidentiality results, since: 291 (P1 XOR K1) XOR (Q1 XOR K1) = P1 XOR Q1 292 (P2 XOR K2) XOR (Q2 XOR K2) = P2 XOR Q2 293 (P3 XOR K3) XOR (Q3 XOR K3) = P3 XOR Q3 295 Once the attacker obtains the two plaintexts XORed together, it is 296 relatively straightforward to separate them. Thus, using any stream 297 cipher, including AES-CTR, to encrypt two plaintexts under the same 298 key stream leaks the plaintext. 300 Therefore, AES-CCM should not be used with statically configured 301 keys. Extraordinary measures would be needed to prevent the reuse of 302 a counter block value with the static key across power cycles. To be 303 safe, implementations MUST use fresh keys with AES-CCM. The Internet 304 Key Exchange (IKE) [IKE] protocol can be used to establish fresh 305 keys. 307 When IKE is used to establish fresh keys between two peer entities, 308 separate keys are established for the two traffic flows. If a 309 different mechanism is used to establish fresh keys, one that 310 establishes only a single key to encrypt packets, then there is a 311 high probability that the peers will select the same IV values for 312 some packets. Thus, to avoid counter block collisions, ESP 313 implementations that permit use of the same key for encrypting and 314 decrypting packets with the same peer MUST ensure that the two peers 315 assign different SPI values to the security association (SA). 316 Further, since the counter block only contains the least significant 317 24 bits of the SPI, such implementations MUST ensure that the two SPI 318 values differ in the least significant 24 bits. 320 AES with a 128-bit key is vulnerable to the birthday attack after 321 2^64 blocks are encrypted with a single key, regardless of the mode 322 used. Since ESP with Extended Sequence Numbers allows for up to 2^64 323 packets in a single security association (SA), there is real 324 potential for more than 2^64 blocks to be encrypted with one key. 325 Implementations SHOULD generate a fresh key before 2^64 blocks are 326 encrypted with the same key, or implementations SHOULD make use of 327 the longer AES key sizes. Note that ESP with 32-bit Sequence Numbers 328 will not exceed 2^64 blocks even if all of the packets are maximum- 329 length Jumbograms. 331 7. Design Rationale 333 In the development of this specification, the use of the ESP sequence 334 number field instead of an explicit IV field was considered. This 335 section documents the rationale for the selection of an explicit IV. 336 This selection is not a cryptographic security issue, as either 337 approach will prevent counter block collisions. 339 The use of the explicit IV does not dictate the manner that the 340 encryptor uses to assign the per-packet value in the counter block. 341 This is desirable for several reasons. 343 1. Only the encryptor can ensure that the value is not used for 344 more than one packet, so there is no advantage to selecting a 345 mechanism that allows the decryptor to determine whether counter 346 block values collide. Damage from the collision is done, whether 347 the decryptor detects it or not. 349 2. The use of explicit IVs allows adders, LFSRs, and any other 350 technique that meets the time budget of the encryptor, so long as 351 the technique results in a unique value for each packet. Adders 352 are simple and straightforward to implement, but due to carries, 353 they do not execute in constant time. LSFRs offer an alternative 354 that executes in constant time. 356 3. Complexity is in control of the implementer. Further, the 357 decision made by the implementer of the encryptor does not make 358 the decryptor more (or less) complex. 360 4. The assignment of the per-packet counter block value needs to 361 be inside the assurance boundary. Some implementations assign the 362 sequence number inside the assurance boundary, but others do not. 363 A sequence number collision does not have the dire consequences, 364 but, as described in section 6, a collision in counter block 365 values has disastrous consequences. 367 5. Using the sequence number as the IV is possible in those 368 architectures where the sequence number assignment is performed 369 within the assurance boundary. In this situation, the sequence 370 number and the IV field will contain the same value. 372 6. By decoupling the IV and the sequence number, architectures 373 where the sequence number assignment is performed outside the 374 assurance boundary are accommodated. 376 The use of an explicit IV field directly follows from the decoupling 377 of the sequence number and the per-packet counter block value. The 378 additional overhead (64 bits for the IV field) is acceptable. This 379 overhead is significantly less overhead associated with Cipher Block 380 Chaining (CBC) mode. As normally employed, CBC requires a full block 381 for the IV and, on average, half of a block for padding. AES-CMM 382 confidentiality processing with an explicit IV has about one-third of 383 the overhead as AES-CBC, and the overhead is constant for each 384 packet. 386 8. IANA Considerations 388 IANA has assigned nine ESP transform numbers for use with AES-CCM 389 with an explicit IV: 391 for AES-CCM with a 128 bit AES key and an 8 octet ICV; 392 for AES-CCM with a 192 bit AES key and a 12 octet ICV; 393 for AES-CCM with a 256 bit AES key and a 16 octet ICV; 394 for AES-CCM with a 128 bit AES key and an 8 octet ICV; 395 for AES-CCM with a 192 bit AES key and a 12 octet ICV; 396 for AES-CCM with a 256 bit AES key and a 16 octet ICV; 397 for AES-CCM with a 128 bit AES key and an 8 octet ICV; 398 for AES-CCM with a 192 bit AES key and a 12 octet ICV; and 399 for AES-CCM with a 256 bit AES key and a 16 octet ICV. 401 9. Acknowledgements 403 Doug Whiting and Niels Ferguson worked with me to develop CCM mode. 404 We developed CCM mode as part of the IEEE 802.11i security effort. 405 One of the most attractive aspects of CCM mode is that it is 406 unencumbered by patents. I acknowledge the companies that supported 407 the development of an encumbered authenticated encryption mode (in 408 alphabetical order): 410 Hifn 411 Intersil 412 MacFergus 413 RSA Security 415 10. References 417 This section provides normative and informative references. 419 10.1. Normative References 421 [AES] NIST, FIPS PUB 197, "Advanced Encryption Standard 422 (AES)," November 2001. 424 [ESP] Kent, S., "IP Encapsulating Security Payload (ESP)," 425 Work In Progress. . 427 [CMM] D. Whiting, D., Housley, R., and N. Ferguson, 428 "Counter with CBC-MAC (CCM)," Work In Progress. 429 . 431 [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate 432 Requirement Levels," RFC 2119, March 1997. 434 10.2. Informative References 436 [ARCH] Kent, S. and R. Atkinson, "Security Architecture for 437 the Internet Protocol," RFC 2401, November 1998. 439 [IKE] Harkins, D. and D. Carrel, "The Internet Key Exchange 440 (IKE)," RFC 2409, November 1998. 442 [ROAD] Thayer, R., N. Doraswamy and R. Glenn, "IP Security 443 Document Roadmap," RFC 2411, November 1998. 445 11. Author's Address 447 Russell Housley 448 Vigil Security, LLC 449 918 Spring Knoll Drive 450 Herndon, VA 20170 451 USA 452 housley@vigilsec.com 454 12. Full Copyright Statement 456 Copyright (C) The Internet Society 2003. All Rights Reserved. 458 This document and translations of it may be copied and furnished to 459 others, and derivative works that comment on or otherwise explain it 460 or assist in its implementation may be prepared, copied, published 461 and distributed, in whole or in part, without restriction of any 462 kind, provided that the above copyright notice and this paragraph are 463 included on all such copies and derivative works. However, this 464 document itself may not be modified in any way, such as by removing 465 the copyright notice or references to the Internet Society or other 466 Internet organizations, except as needed for the purpose of 467 developing Internet standards in which case the procedures for 468 copyrights defined in the Internet Standards process must be 469 followed, or as required to translate it into languages other than 470 English. 472 The limited permissions granted above are perpetual and will not be 473 revoked by the Internet Society or its successors or assigns. 475 This document and the information contained herein is provided on an 476 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 477 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 478 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 479 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 480 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.