idnits 2.17.1 draft-ietf-smime-cms-aes-ccm-and-gcm-02.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 444. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 453. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 460. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 466. 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 (May 2007) is 6188 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 347, 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 November 2007 May 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 all block 297 cipher modes that allow a meet-in-the-middle attack against the key. 298 These attacks require the creation and searching of huge tables of 299 ciphertext associated with known plaintext and known keys. Assuming 300 that the memory and processor resources are available for a 301 precomputation attack, then the theoretical strength of any block 302 cipher mode is limited to 2^(n/2) bits, where n is the number of bits 303 in the key. The use of long keys is the best countermeasure to 304 precomputation attacks. Use of an unpredictable nonce value in the 305 counter block significantly increases the size of the table that the 306 attacker must compute to mount a successful precomputation attack. 308 Implementations must randomly generate content-authenticated- 309 encryption keys. The use of inadequate pseudo-random number 310 generators (PRNGs) to generate cryptographic keys can result in 311 little or no security. An attacker may find it much easier to 312 reproduce the PRNG environment that produced the keys, searching the 313 resulting small set of possibilities, rather than brute force 314 searching the whole key space. The generation of quality random 315 numbers is difficult. RFC 4086 [RANDOM] offers important guidance in 316 this area. 318 5. References 320 5.1. Normative References 322 [AES] NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)", 323 November 2001. 325 [CCM] Whiting, D., Housley, R., and N. Ferguson, "Counter with 326 CBC-MAC (CCM)", RFC 3610, September 2003. 328 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 329 RFC 3852, July 2004. 331 [GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of 332 Operation (GCM)", Submission to NIST, May 2005. 333 http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ 334 gcm/gcm-revised-spec.pdf. 336 [STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate 337 Requirement Levels", BCP 14, RFC 2119, March 1997. 339 5.2. Informative References 341 [BDJR] Bellare, M, Desai, A., Jokipii, E., and P. Rogaway, 342 "A Concrete Security Treatment of Symmetric Encryption: 343 Analysis of the DES Modes of Operation", Proceedings 344 38th Annual Symposium on Foundations of Computer 345 Science, 1997. 347 [KEYMGMT] Bellovin, S. and R. Housley, "Guidelines for 348 Cryptographic Key Management", RFC 4107, BCP 107, 349 June 2005. 351 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 352 Recommendations for Security", RFC 4086, June 2005. 354 6. IANA Considerations 356 None. 358 {{{ RFC Editor: Please remove this section prior to publication. }}} 360 Appendix: ASN.1 Module 362 CMS-AES-CCM-and-AES-GCM 363 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 364 pkcs-9(9) smime(16) modules(0) cms-aes-ccm-and-gcm(32) } 366 DEFINITIONS IMPLICIT TAGS ::= BEGIN 368 -- EXPORTS All 370 -- Object Identifiers 372 aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) 373 organization(1) gov(101) csor(3) nistAlgorithm(4) 1 } 375 id-aes128-CCM OBJECT IDENTIFIER ::= { aes 7 } 377 id-aes192-CCM OBJECT IDENTIFIER ::= { aes 27 } 379 id-aes256-CCM OBJECT IDENTIFIER ::= { aes 47 } 381 id-aes128-GCM OBJECT IDENTIFIER ::= { aes 6 } 383 id-aes192-GCM OBJECT IDENTIFIER ::= { aes 26 } 385 id-aes256-GCM OBJECT IDENTIFIER ::= { aes 46 } 387 -- Parameters for AigorithmIdentifier 389 CCMParameters ::= SEQUENCE { 390 aes-nonce OCTET STRING (SIZE(7..13)), 391 aes-ICVlen AES-CCM-ICVlen DEFAULT 12 } 393 AES-CCM-ICVlen ::= INTEGER (4 | 6 | 8 | 10 | 12 | 14 | 16) 395 GCMParameters ::= SEQUENCE { 396 aes-nonce OCTET STRING, -- recommended size is 12 octets 397 aes-ICVlen AES-GCM-ICVlen DEFAULT 12 } 399 AES-GCM-ICVlen ::= INTEGER (12 | 13 | 14 | 15 | 16) 401 END 403 Authors' Addresses 405 Russell Housley 406 Vigil Security, LLC 407 918 Spring Knoll Drive 408 Herndon, VA 20170 409 USA 411 EMail: housley(at)vigilsec.com 413 Copyright and IPR Statements 415 Copyright (C) The IETF Trust (2007). 417 This document is subject to the rights, licenses and restrictions 418 contained in BCP 78, and except as set forth therein, the authors 419 retain all their rights. 421 This document and translations of it may be copied and furnished to 422 others, and derivative works that comment on or otherwise explain it 423 or assist in its implementation may be prepared, copied, published 424 and distributed, in whole or in part, without restriction of any 425 kind, provided that the above copyright notice and this paragraph are 426 included on all such copies and derivative works. However, this 427 document itself may not be modified in any way, such as by removing 428 the copyright notice or references to the Internet Society or other 429 Internet organizations, except as needed for the purpose of 430 developing Internet standards in which case the procedures for 431 copyrights defined in the Internet Standards process must be 432 followed, or as required to translate it into languages other than 433 English. 435 The limited permissions granted above are perpetual and will not be 436 revoked by the Internet Society or its successors or assigns. 438 This document and the information contained herein are provided on an 439 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 440 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 441 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 442 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 443 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 444 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 446 The IETF takes no position regarding the validity or scope of any 447 Intellectual Property Rights or other rights that might be claimed to 448 pertain to the implementation or use of the technology described in 449 this document or the extent to which any license under such rights 450 might or might not be available; nor does it represent that it has 451 made any independent effort to identify any such rights. Information 452 on the procedures with respect to rights in RFC documents can be 453 found in BCP 78 and BCP 79. 455 Copies of IPR disclosures made to the IETF Secretariat and any 456 assurances of licenses to be made available, or the result of an 457 attempt made to obtain a general license or permission for the use of 458 such proprietary rights by implementers or users of this 459 specification can be obtained from the IETF on-line IPR repository at 460 http://www.ietf.org/ipr. 462 The IETF invites any interested party to bring to its attention any 463 copyrights, patents or patent applications, or other proprietary 464 rights that may cover technology that may be required to implement 465 this standard. Please address the information to the IETF at 466 ietf-ipr@ietf.org.