idnits 2.17.1 draft-ietf-smime-cms-aes-ccm-and-gcm-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 460. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 469. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 476. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 482. 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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (September 2007) is 6061 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: 'AuthEnv' is mentioned on line 43, but not defined == Missing Reference: 'KeyMgmt' is mentioned on line 132, but not defined == Unused Reference: 'KEYMGMT' is defined on line 357, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' ** Downref: Normative reference to an Informational RFC: RFC 3610 (ref. 'CCM') ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) -- Possible downref: Non-RFC (?) normative reference: ref. 'GCM' Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT R. Housley 3 S/MIME Working Group Vigil Security 4 Expires March 2008 September 2007 6 Using AES-CCM and AES-GCM Authenticated Encryption 7 in the Cryptographic Message Syntax (CMS) 8 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Abstract 34 This document specifies the conventions for using the AES-CCM and the 35 AES-GCM authenticated encryption algorithms with the Cryptographic 36 Message Syntax (CMS) authenticated-enveloped-data content type. 38 1. Introduction 40 This document specifies the conventions for using AES-CCM and AES-GCM 41 authenticated encryption algorithms as the content-authenticated- 42 encryption algorithm with the Cryptographic Message Syntax [CMS] 43 authenticated-enveloped-data content type [AuthEnv]. 45 1.1. Terminology 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119 [STDWORDS]. 51 1.2. ASN.1 53 CMS values are generated using ASN.1 [X.208-88], using the Basic 54 Encoding Rules (BER) [X.209-88] and the Distinguished Encoding Rules 55 (DER) [X.509-88]. 57 1.3. AES 59 Dr. Joan Daemen and Dr. Vincent Rijmen, both from Belgium, developed 60 the Rijndael block cipher algorithm, and they submitted it for 61 consideration as the Advanced Encryption Standard (AES). Rijndael 62 was selected by the National Institute for Standards and Technology 63 (NIST), and it is specified in a U.S. Federal Information Processing 64 Standard (FIPS) Publication [AES]. NIST selected the Rijndael 65 algorithm for AES because it offers a combination of security, 66 performance, efficiency, ease of implementation, and flexibility. 67 Specifically, the algorithm performs well in both hardware and 68 software across a wide range of computing environments. Also, the 69 very low memory requirements of the algorithm make it very well 70 suited for restricted-space environments. The AES is widely used by 71 organizations, institutions, and individuals outside of the U.S. 72 Government. 74 The AES specifies three key sizes: 128, 192, and 256 bits. 76 1.4. AES-CCM 78 The Counter with CBC-MAC (CCM) mode of operation is specified in 79 [CCM]. CCM is a generic authenticated encryption block cipher mode. 80 CCM is defined for use with any 128-bit block cipher, but in this 81 document, CCM is used with the AES block cipher. 83 AES-CCM has four inputs: an AES key, a nonce, a plaintext, and 84 optional additional authenticated data (AAD). AES-CCM generates two 85 outputs: a ciphertext and a message authentication code (also called 86 an authentication tag). 88 The nonce is generated by the party performing the authenticated 89 encryption operation. Within the scope of any authenticated- 90 encryption key, the nonce value MUST be unique. That is, the set of 91 nonce values used with any given key MUST NOT contain any duplicate 92 values. Using the same nonce for two different messages encrypted 93 with the same key destroys the security properties. 95 AAD is authenticated but not encrypted. Thus, the AAD is not 96 included in the AES-CCM output. It can be used to authenticate 97 plaintext packet headers. In the CMS authenticated-enveloped-data 98 content type, authenticated attributes comprise the AAD. 100 1.5. AES-GCM 102 The Galois/Counter Mode (GCM) is specified in [GCM]. GCM is a 103 generic authenticated encryption block cipher mode. GCM is defined 104 for use with any 128-bit block cipher, but in this document, GCM is 105 used with the AES block cipher. 107 AES-GCM has four inputs: an AES key, an initialization vector (IV), a 108 plaintext content, and optional additional authenticated data (AAD). 109 AES-GCM generates two outputs: a ciphertext and message 110 authentication code (also called an authentication tag). To have a 111 common set of terms for AES-CCM and AES-GCM, the AES-GCM IV is 112 referred to as a nonce in the remainder of this document. 114 The nonce is generated by the party performing the authenticated 115 encryption operation. Within the scope of any authenticated- 116 encryption key, the nonce value MUST be unique. That is, the set of 117 nonce values used with any given key MUST NOT contain any duplicate 118 values. Using the same nonce for two different messages encrypted 119 with the same key destroys the security properties. 121 AAD is authenticated but not encrypted. Thus, the AAD is not 122 included in the AES-GCM output. It can be used to authenticate 123 plaintext packet headers. In the CMS authenticated-enveloped-data 124 content type, authenticated attributes comprise the AAD. 126 2. Automated Key Management 128 The reuse of an AES-CCM or AES-GCM nonce/key combination destroys the 129 security guarantees. As a result, it can be extremely difficult to 130 use AES-CCM or AES-GCM securely when using statically configured 131 keys. For safety's sake, implementations MUST use an automated key 132 management system [KeyMgmt]. 134 The CMS authenticated-enveloped-data content type supports four 135 general key management techniques: 137 Key Transport: the content-authenticated-encryption key is 138 encrypted in the recipient's public key; 140 Key Agreement: the recipient's public key and the sender's 141 private key are used to generate a pairwise symmetric key, then 142 the content-authenticated-encryption key is encrypted in the 143 pairwise symmetric key; 145 Symmetric Key-Encryption Keys: the content-authenticated- 146 encryption key is encrypted in a previously distributed 147 symmetric key-encryption key; and 149 Passwords: the content-authenticated-encryption key is encrypted 150 in a key-encryption key that is derived from a password or 151 other shared secret value. 153 All of these key management techniques meet the automated key 154 management system requirement as long as a fresh content- 155 authenticated-encryption key is generated for the protection of each 156 content. Note that some of these key management techniques use one 157 key-encryption key to encrypt more than one content-authenticated- 158 encryption key during the system life cycle. As long as fresh 159 content-authenticated-encryption key is used each time, AES-CCM and 160 AES-GCM can be used safely with the CMS authenticated-enveloped-data 161 content type. 163 In addition to these four general key management techniques, CMS 164 supports other key management techniques. See Section 6.2.5 of 165 [CMS]. Since the properties of these key management techniques are 166 unknown, no statement can be made about whether these key management 167 techniques meet the automated key management system requirement. 168 Designers and implementers must perform their own analysis if one of 169 these other key management techniques is supported. 171 3. Content Authenticated Encryption Algorithms 173 This section specifies the conventions employed by CMS 174 implementations that support content authenticated encryption using 175 AES-CCM or AES-GCM. 177 Content authenticated encryption algorithm identifiers are located in 178 the AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm 179 field. 181 Content authenticated encryption algorithms are used to encipher the 182 content located in the AuthEnvelopedData EncryptedContentInfo 183 encryptedContent field and to provide the message authentication code 184 for the AuthEnvelopedData mac field. Note that the message 185 authentication code provides integrity protection for both the 186 AuthEnvelopedData authAttrs and the AuthEnvelopedData 187 EncryptedContentInfo encryptedContent. 189 3.1. AES-CCM 191 The AES-CCM authenticated encryption algorithm is described in [CCM]. 192 A brief summary of the properties of AES-CCM is provided in Section 193 1.4. 195 Neither the plaintext content nor the optional AAD inputs need to be 196 padded prior to invoking AES-CCM. 198 There are three algorithm identifiers for AES-CCM, one for each AES 199 key size: 201 aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) 202 organization(1) gov(101) csor(3) nistAlgorithm(4) 1 } 204 id-aes128-CCM OBJECT IDENTIFIER ::= { aes 7 } 206 id-aes192-CCM OBJECT IDENTIFIER ::= { aes 27 } 208 id-aes256-CCM OBJECT IDENTIFIER ::= { aes 47 } 210 With all three AES-CCM algorithm identifiers, the AlgorithmIdentifier 211 parameters field MUST be present, and the parameters field must 212 contain a CCMParameter: 214 CCMParameters ::= SEQUENCE { 215 aes-nonce OCTET STRING (SIZE(7..13)), 216 aes-ICVlen AES-CCM-ICVlen DEFAULT 12 } 218 AES-CCM-ICVlen ::= INTEGER (4 | 6 | 8 | 10 | 12 | 14 | 16) 220 The aes-nonce parameter field contains 15-L octets, where L is the 221 size of the length field. With the CMS, the normal situation is for 222 the content-authenticated-encryption key to be used for a single 223 content, therefore L=8 is RECOMMENDED. See [CCM] for a discussion of 224 the trade-off between the maximum content size and the size of the 225 Nonce. Within the scope of any content-authenticated-encryption key, 226 the nonce value MUST be unique. That is, the set of nonce values 227 used with any given key MUST NOT contain any duplicate values. 229 The aes-ICVlen parameter field tells the size of the message 230 authentication code. It MUST match the size in octets of the value 231 in the AuthEnvelopedData mac field. A length of 12 octets is 232 RECOMMENDED. 234 3.2. AES-GCM 236 The AES-GCM authenticated encryption algorithm is described in [GCM]. 237 A brief summary of the properties of AES-CCM is provided in Section 238 1.5. 240 Neither the plaintext content nor the optional AAD inputs need to be 241 padded prior to invoking AES-GCM. 243 There are three algorithm identifiers for AES-GCM, one for each AES 244 key size: 246 aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) 247 organization(1) gov(101) csor(3) nistAlgorithm(4) 1 } 249 id-aes128-GCM OBJECT IDENTIFIER ::= { aes 6 } 251 id-aes192-GCM OBJECT IDENTIFIER ::= { aes 26 } 253 id-aes256-GCM OBJECT IDENTIFIER ::= { aes 46 } 255 With all three AES-GCM algorithm identifiers, the AlgorithmIdentifier 256 parameters field MUST be present, and the parameters field must 257 contain a GCMParameter: 259 GCMParameters ::= SEQUENCE { 260 aes-nonce OCTET STRING, -- recommended size is 12 octets 261 aes-ICVlen AES-GCM-ICVlen DEFAULT 12 } 263 AES-GCM-ICVlen ::= INTEGER (12 | 13 | 14 | 15 | 16) 265 The aes-nonce is the AES-GCM initialization vector. The algorithm 266 specification permits the nonce to have any number of bits between 1 267 and 2^64. However, the use of OCTET STRING within GCMParameters 268 requires the nonce to be a multiple of 8 bits. Within the scope of 269 any content-authenticated-encryption key, the nonce value MUST be 270 unique, but need not have equal lengths. A nonce value of 12 octets 271 can be processed more efficiently, so that length is RECOMMENDED. 273 The aes-ICVlen parameter field tells the size of the message 274 authentication code. It MUST match the size in octets of the value 275 in the AuthEnvelopedData mac field. A length of 12 octets is 276 RECOMMENDED. 278 4. Security Considerations 280 AES-CCM and AES-GCM make use of the AES block cipher in counter mode 281 to provide encryption. When used properly, counter mode provides 282 strong confidentiality. Bellare, Desai, Jokipii, Rogaway show in 283 [BDJR] that the privacy guarantees provided by counter mode are at 284 least as strong as those for CBC mode when using the same block 285 cipher. 287 Unfortunately, it is easy to misuse counter mode. If counter block 288 values are ever used for more that one encryption operation with the 289 same key, then the same key stream will be used to encrypt both 290 plaintexts, and the confidentiality guarantees are voided. 292 Fortunately, the CMS AuthEnvelopedData provides all of the tools 293 needed to avoid misuse of counter mode. Automated key management is 294 discussed in Section 2. 296 There are fairly generic precomputation attacks against the use of 297 any block cipher in counter mode that allow a meet-in-the-middle 298 attack against the key [H][B][MF]. AES-CCM and AES-GCM both make use 299 of counter mode for encryption. These precomputation attacks require 300 the creation and searching of huge tables of ciphertext associated 301 with known plaintext and known keys. Assuming that the memory and 302 processor resources are available for a precomputation attack, then 303 the theoretical strength of any block cipher in counter mode is 304 limited to 2^(n/2) bits, where n is the number of bits in the key. 305 The use of long keys is the best countermeasure to precomputation 306 attacks. Use of an unpredictable nonce value in the counter block 307 significantly increases the size of the table that the attacker must 308 compute to mount a successful precomputation attack. 310 Implementations must randomly generate content-authenticated- 311 encryption keys. The use of inadequate pseudo-random number 312 generators (PRNGs) to generate cryptographic keys can result in 313 little or no security. An attacker may find it much easier to 314 reproduce the PRNG environment that produced the keys, searching the 315 resulting small set of possibilities, rather than brute force 316 searching the whole key space. The generation of quality random 317 numbers is difficult. RFC 4086 [RANDOM] offers important guidance in 318 this area. 320 5. References 322 5.1. Normative References 324 [AES] NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)", 325 November 2001. 327 [CCM] Whiting, D., Housley, R., and N. Ferguson, "Counter with 328 CBC-MAC (CCM)", RFC 3610, September 2003. 330 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 331 RFC 3852, July 2004. 333 [GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of 334 Operation (GCM)", Submission to NIST, May 2005. 335 http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ 336 gcm/gcm-revised-spec.pdf. 338 [STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate 339 Requirement Levels", BCP 14, RFC 2119, March 1997. 341 5.2. Informative References 343 [B] Biham, E., "How to Forge DES-Encrypted Messages in 344 2^28 Steps", Technion Computer Science Department 345 Technical Report CS0884, 1996. 347 [BDJR] Bellare, M, Desai, A., Jokipii, E., and P. Rogaway, 348 "A Concrete Security Treatment of Symmetric Encryption: 349 Analysis of the DES Modes of Operation", Proceedings 350 38th Annual Symposium on Foundations of Computer 351 Science, 1997. 353 [H] Hellman, M. E., "A cryptanalytic time-memory trade-off", 354 IEEE Transactions on Information Theory, July 1980, 355 pp. 401-406. 357 [KEYMGMT] Bellovin, S. and R. Housley, "Guidelines for 358 Cryptographic Key Management", RFC 4107, BCP 107, 359 June 2005. 361 [MF] McGrew, D., and S. Fluhrer, "Attacks on Additive 362 Encryption of Redundant Plaintext and Implications on 363 Internet Security", The Proceedings of the Seventh 364 Annual Workshop on Selected Areas in Cryptography 365 (SAC 2000), Springer-Verlag, August, 2000. 367 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 368 Recommendations for Security", RFC 4086, June 2005. 370 6. IANA Considerations 372 None. 374 {{{ RFC Editor: Please remove this section prior to publication. }}} 376 Appendix: ASN.1 Module 378 CMS-AES-CCM-and-AES-GCM 379 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 380 pkcs-9(9) smime(16) modules(0) cms-aes-ccm-and-gcm(32) } 382 DEFINITIONS IMPLICIT TAGS ::= BEGIN 384 -- EXPORTS All 386 -- Object Identifiers 388 aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) 389 organization(1) gov(101) csor(3) nistAlgorithm(4) 1 } 391 id-aes128-CCM OBJECT IDENTIFIER ::= { aes 7 } 393 id-aes192-CCM OBJECT IDENTIFIER ::= { aes 27 } 395 id-aes256-CCM OBJECT IDENTIFIER ::= { aes 47 } 397 id-aes128-GCM OBJECT IDENTIFIER ::= { aes 6 } 399 id-aes192-GCM OBJECT IDENTIFIER ::= { aes 26 } 401 id-aes256-GCM OBJECT IDENTIFIER ::= { aes 46 } 403 -- Parameters for AigorithmIdentifier 405 CCMParameters ::= SEQUENCE { 406 aes-nonce OCTET STRING (SIZE(7..13)), 407 aes-ICVlen AES-CCM-ICVlen DEFAULT 12 } 409 AES-CCM-ICVlen ::= INTEGER (4 | 6 | 8 | 10 | 12 | 14 | 16) 411 GCMParameters ::= SEQUENCE { 412 aes-nonce OCTET STRING, -- recommended size is 12 octets 413 aes-ICVlen AES-GCM-ICVlen DEFAULT 12 } 415 AES-GCM-ICVlen ::= INTEGER (12 | 13 | 14 | 15 | 16) 417 END 419 Authors' Addresses 421 Russell Housley 422 Vigil Security, LLC 423 918 Spring Knoll Drive 424 Herndon, VA 20170 425 USA 427 EMail: housley@vigilsec.com 429 Copyright and IPR Statements 431 Copyright (C) The IETF Trust (2007). 433 This document is subject to the rights, licenses and restrictions 434 contained in BCP 78, and except as set forth therein, the authors 435 retain all their rights. 437 This document and translations of it may be copied and furnished to 438 others, and derivative works that comment on or otherwise explain it 439 or assist in its implementation may be prepared, copied, published 440 and distributed, in whole or in part, without restriction of any 441 kind, provided that the above copyright notice and this paragraph are 442 included on all such copies and derivative works. However, this 443 document itself may not be modified in any way, such as by removing 444 the copyright notice or references to the Internet Society or other 445 Internet organizations, except as needed for the purpose of 446 developing Internet standards in which case the procedures for 447 copyrights defined in the Internet Standards process must be 448 followed, or as required to translate it into languages other than 449 English. 451 The limited permissions granted above are perpetual and will not be 452 revoked by the Internet Society or its successors or assigns. 454 This document and the information contained herein are provided on an 455 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 456 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 457 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 458 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 459 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 460 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 462 The IETF takes no position regarding the validity or scope of any 463 Intellectual Property Rights or other rights that might be claimed to 464 pertain to the implementation or use of the technology described in 465 this document or the extent to which any license under such rights 466 might or might not be available; nor does it represent that it has 467 made any independent effort to identify any such rights. Information 468 on the procedures with respect to rights in RFC documents can be 469 found in BCP 78 and BCP 79. 471 Copies of IPR disclosures made to the IETF Secretariat and any 472 assurances of licenses to be made available, or the result of an 473 attempt made to obtain a general license or permission for the use of 474 such proprietary rights by implementers or users of this 475 specification can be obtained from the IETF on-line IPR repository at 476 http://www.ietf.org/ipr. 478 The IETF invites any interested party to bring to its attention any 479 copyrights, patents or patent applications, or other proprietary 480 rights that may cover technology that may be required to implement 481 this standard. Please address the information to the IETF at 482 ietf-ipr@ietf.org.