idnits 2.17.1 draft-ietf-smime-cms-aes-ccm-and-gcm-00.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 3979, Section 5, paragraph 1 on line 436. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 443. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 449. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 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 2007) is 6310 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 44, but not defined -- 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: 7 errors (**), 0 flaws (~~), 3 warnings (==), 8 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 July 2007 January 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 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than a "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Abstract 35 This document specifies the conventions for using the AES-CCM and the 36 AES-GCM authenticated encryption algorithms with the Cryptographic 37 Message Syntax (CMS) authenticated-enveloped-data content type. 39 1. Introduction 41 This document specifies the conventions for using AES-CCM and AES-GCM 42 authenticated encryption algorithms as the content-authenticated- 43 encryption algorithm with the Cryptographic Message Syntax [CMS] 44 authenticated-enveloped-data content type [AuthEnv]. 46 1.1. Terminology 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC 2119 [STDWORDS]. 52 1.2. ASN.1 54 CMS values are generated using ASN.1 [X.208-88], using the Basic 55 Encoding Rules (BER) [X.209-88] and the Distinguished Encoding Rules 56 (DER) [X.509-88]. 58 1.3. AES 60 Dr. Joan Daemen and Dr. Vincent Rijmen, both from Belgium, developed 61 the Rijndael block cipher algorithm, and they submitted it for 62 consideration as the Advanced Encryption Standard (AES). Rijndael 63 was selected by the National Institute for Standards and Technology 64 (NIST), and it is specified in a U.S. Federal Information Processing 65 Standard (FIPS) Publication [AES]. NIST selected the Rijndael 66 algorithm for AES because it offers a combination of security, 67 performance, efficiency, ease of implementation, and flexibility. 68 Specifically, the algorithm performs well in both hardware and 69 software across a wide range of computing environments. Also, the 70 very low memory requirements of the algorithm make it very well 71 suited for restricted-space environments. The AES is widely used by 72 organizations, institutions, and individuals outside of the U.S. 73 Government. 75 The AES specifies three key sizes: 128, 192, and 256 bits. 77 1.4. AES-CCM 79 The Counter with CBC-MAC (CCM) mode of operation is specified in 80 [CCM]. CCM is a generic authenticated encryption block cipher mode. 81 CCM is only defined for use with any 128-bit block cipher, but in 82 this document, CCM is only used with the AES block cipher. 84 AES-CCM has four inputs: an AES key, a nonce, a plaintext, and 85 optional additional authenticated data (AAD). AES-CCM generates two 86 outputs: a ciphertext and an authentication tag. 88 Within the scope of any authenticated-encryption key, the nonce value 89 MUST be unique. That is, the set of nonce values used with any given 90 key MUST NOT contain any duplicate values. Using the same nonce for 91 two different messages encrypted with the same key destroys the 92 security properties. 94 AAD is authenticated but not encrypted. Thus, the AAD is not 95 included in the AES-CCM output. It can be used to authenticate 96 plaintext packet headers. In CMS, authenticated attributes comprise 97 the AAD. 99 1.5. AES-GCM 101 The Galois/Counter Mode (GCM) is specified in [GCM]. GCM is a 102 generic authenticated encryption block cipher mode. GCM is only 103 defined for use with any 128-bit block cipher, but in this document, 104 GCM is only used with the AES block cipher. 106 AES-GCM has four inputs: an AES key, an initialization vector (IV), a 107 plaintext content, and optional additional authenticated data (AAD). 108 AES-GCM generates two outputs: a ciphertext and an authentication 109 tag. To have a common set of terms for AES-CCM and AES-GCM, the AES- 110 GCM IV is referred to as a nonce in the remainder of this document. 112 Within the scope of any authenticated-encryption key, the nonce value 113 MUST be unique. That is, the set of nonce values used with any given 114 key MUST NOT contain any duplicate values. Using the same nonce for 115 two different messages encrypted with the same key destroys the 116 security properties. 118 AAD is authenticated but not encrypted. Thus, the AAD is not 119 included in the AES-GCM output. It can be used to authenticate 120 plaintext packet headers. In CMS, authenticated attributes comprise 121 the AAD. 123 2. Automatic Key Management 125 The reuse of an AES-CCM or AES-GCM nonce/key combination destroys the 126 security guarantees. As a result, it can be extremely difficult to 127 use AES-CCM or AES-GCM securely when using statically configured 128 keys. For safety's sake, implementations MUST use an automated key 129 management system. 131 The CMS authenticated-enveloped-data content type supports four 132 general key management techniques: 134 Key Transport: the content-authenticated-encryption key is 135 encrypted in the recipient's public key; 137 Key Agreement: the recipient's public key and the sender's 138 private key are used to generate a pairwise symmetric key, then 139 the content-authenticated-encryption key is encrypted in the 140 pairwise symmetric key; 142 Symmetric Key-Encryption Keys: the content-authenticated- 143 encryption key is encrypted in a previously distributed 144 symmetric key-encryption key; and 146 Passwords: the content-authenticated-encryption key is encrypted 147 in a key-encryption key that is derived from a password or 148 other shared secret value. 150 All of these key management techniques meet the automated key 151 management system requirement as long as a fresh content- 152 authenticated-encryption key is generated for the protection of each 153 content. Note that some of these key management techniques use one 154 key-encryption key to encrypt more than one content-authenticated- 155 encryption key during the system life cycle. As long as fresh 156 content-authenticated-encryption key is used each time, AES-CCM and 157 AES-GCM can be used safely with the CMS authenticated-enveloped-data 158 content type. 160 In addition to these four general key management techniques, CMS 161 supports other key management techniques. See Section 6.2.5 of 162 [CMS]. Since the properties of these key management techniques are 163 unknown, no statement can be made about whether these key management 164 techniques meet the automated key management system requirement. 165 Designers and implementers must perform their own analysis if one of 166 these other key management techniques is supported. 168 3. Content Authenticated Encryption Algorithms 170 This section specifies the conventions employed by CMS 171 implementations that support content authenticated encryption using 172 AES-CCM or AES-GCM. 174 Content authenticated encryption algorithm identifiers are located in 175 the AuthEnvelopedData EncryptedContentInfo contentEncryptionAlgorithm 176 field. 178 Content authenticated encryption algorithms are used to encipher the 179 content located in the AuthEnvelopedData EncryptedContentInfo 180 encryptedContent field and to provide the message authentication code 181 for the AuthEnvelopedData mac field. Note that the message 182 authentication code provides integrity protection for both the 183 AuthEnvelopedData authAttrs and the AuthEnvelopedData 184 EncryptedContentInfo encryptedContent. 186 3.1. AES-CCM 188 The AES-CCM authenticated encryption algorithm is described in [CCM]. 189 A brief summary of the properties of AES-CCM is provided in Section 190 1.4. There are three algorithm identifiers for AES-CCM, one for each 191 AES key size: 193 aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) 194 organization(1) gov(101) csor(3) nistAlgorithm(4) 1 } 196 id-aes128-CCM OBJECT IDENTIFIER ::= { aes 5 } 198 id-aes192-CCM OBJECT IDENTIFIER ::= { aes 25 } 200 id-aes256-CCM OBJECT IDENTIFIER ::= { aes 45 } 202 With all three AES-CCM algorithm identifiers, the AlgorithmIdentifier 203 parameters field MUST be present, and the parameters field must 204 contain a CCMParameter: 206 CCMParameters ::= SEQUENCE { 207 aes-nonce OCTET STRING (SIZE(7..13)), 208 aes-ICVlen AES-CCM-ICVlen DEFAULT 12 } 210 AES-CCM-ICVlen ::= INTEGER (4 | 6 | 8 | 10 | 12 | 14 | 16) 212 The aes-nonce parameter field contains 15-L octets, where L is the 213 size of the length field. With CMS, the normal situation is for the 214 content-authenticated-encryption key to be used for a single content, 215 therefore L=8 is RECOMMENDED. See [CCM] for a discussion of the 216 trade-off between the maximum content size and the size of the Nonce. 217 Within the scope of any content-authenticated-encryption key, the 218 nonce value MUST be unique. That is, the set of nonce values used 219 with any given key MUST NOT contain any duplicate values. 221 The aes-ICVlen parameter field tells the size of the message 222 authentication code. It MUST match the size in octets of the value 223 in the AuthEnvelopedData mac field. A length of 12 octets is 224 RECOMMENDED. 226 3.2. AES-GCM 228 The AES-GCM authenticated encryption algorithm is described in [GCM]. 229 A brief summary of the properties of AES-CCM is provided in Section 230 1.5. There are three algorithm identifiers for AES-GCM, one for each 231 AES key size: 233 aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) 234 organization(1) gov(101) csor(3) nistAlgorithm(4) 1 } 236 id-aes128-GCM OBJECT IDENTIFIER ::= { aes 6 } 238 id-aes192-GCM OBJECT IDENTIFIER ::= { aes 26 } 240 id-aes256-GCM OBJECT IDENTIFIER ::= { aes 46 } 242 With all three AES-GCM algorithm identifiers, the AlgorithmIdentifier 243 parameters field MUST be present, and the parameters field must 244 contain a GCMParameter: 246 GCMParameters ::= SEQUENCE { 247 aes-nonce OCTET STRING, -- recommended size is 12 octets 248 aes-ICVlen AES-GCM-ICVlen DEFAULT 12 } 250 AES-GCM-ICVlen ::= INTEGER (12 | 13 | 14 | 15 | 16) 252 The aes-nonce is the AES-GCM initialization vector. The algorithm 253 specification permits the nonce to have any number of bits between 1 254 and 2^64. However, the use of OCTET STRING requires the nonce to be 255 a multiple of 8 bits. Within the scope of any content-authenticated- 256 encryption key, the nonce value MUST be unique, but need not have 257 equal lengths. A nonce value of 12 octets can be processed more 258 efficiently, so that length is RECOMMENDED. 260 The aes-ICVlen parameter field tells the size of the message 261 authentication code. It MUST match the size in octets of the value 262 in the AuthEnvelopedData mac field. A length of 12 octets is 263 RECOMMENDED. 265 4. Security Considerations 267 AES-CCM and AES-GCM make use of the AES block cipher in counter mode 268 to provide encryption. When used properly, counter mode provides 269 strong confidentiality. Bellare, Desai, Jokipii, Rogaway show in 270 [BDJR] that the privacy guarantees provided by counter mode are at 271 least as strong as those for CBC mode when using the same block 272 cipher. 274 Unfortunately, it is easy to misuse counter mode. If counter block 275 values are ever used for more that one encryption operation with the 276 same key, then the same key stream will be used to encrypt both 277 plaintexts, and the confidentiality guarantees are voided. 279 Fortunately, the CMS AuthEnvelopedData provides all of the tools 280 needed to avoid misuse of counter mode. Automated key management is 281 discussed in Section 2. 283 There are fairly generic precomputation attacks against all block 284 cipher modes that allow a meet-in-the-middle attack against the key. 285 These attacks require the creation and searching of huge tables of 286 ciphertext associated with known plaintext and known keys. Assuming 287 that the memory and processor resources are available for a 288 precomputation attack, then the theoretical strength of any block 289 cipher mode is limited to 2^(n/2) bits, where n is the number of bits 290 in the key. The use of long keys is the best countermeasure to 291 precomputation attacks. Use of an unpredictable nonce value in the 292 counter block significantly increases the size of the table that the 293 attacker must compute to mount a successful precomputation attack. 295 Implementations must randomly generate content-authenticated- 296 encryption keys. The use of inadequate pseudo-random number 297 generators (PRNGs) to generate cryptographic keys can result in 298 little or no security. An attacker may find it much easier to 299 reproduce the PRNG environment that produced the keys, searching the 300 resulting small set of possibilities, rather than brute force 301 searching the whole key space. The generation of quality random 302 numbers is difficult. RFC 4086 [RANDOM] offers important guidance in 303 this area. 305 5. References 307 5.1. Normative References 309 [AES] NIST, FIPS PUB 197, "Advanced Encryption Standard (AES)", 310 November 2001. 312 [CCM] Whiting, D., Housley, R., and N. Ferguson, "Counter with 313 CBC-MAC (CCM)", RFC 3610, September 2003. 315 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 316 RFC 3852, July 2004. 318 [GCM] McGrew, D. and J. Viega, "The Galois/Counter Mode of 319 Operation (GCM)", Submission to NIST. January 2004. 320 http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/ 321 gcm/gcm-spec.pdf. 323 [STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate 324 Requirement Levels", BCP 14, RFC 2119, March 1997. 326 5.2. Informative References 328 [BDJR] Bellare, M, Desai, A., Jokipii, E., and P. Rogaway, 329 "A Concrete Security Treatment of Symmetric Encryption: 330 Analysis of the DES Modes of Operation", Proceedings 331 38th Annual Symposium on Foundations of Computer 332 Science, 1997. 334 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 335 Recommendations for Security", RFC 4086, June 2005. 337 6. IANA Considerations 339 None. 341 {{{ RFC Editor: Please remove this section prior to publication. }}} 343 Appendix: ASN.1 Module 345 CMS-AES-CCM-and-AES-GCM 346 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 347 pkcs-9(9) smime(16) modules(0) cms-aes-ccm-and-gcm(32) } 349 DEFINITIONS IMPLICIT TAGS ::= BEGIN 351 -- EXPORTS All 353 -- Object Identifiers 355 aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) 356 organization(1) gov(101) csor(3) nistAlgorithm(4) 1 } 358 id-aes128-CCM OBJECT IDENTIFIER ::= { aes 5 } 360 id-aes192-CCM OBJECT IDENTIFIER ::= { aes 25 } 362 id-aes256-CCM OBJECT IDENTIFIER ::= { aes 45 } 364 id-aes128-GCM OBJECT IDENTIFIER ::= { aes 6 } 366 id-aes192-GCM OBJECT IDENTIFIER ::= { aes 26 } 368 id-aes256-GCM OBJECT IDENTIFIER ::= { aes 46 } 369 -- Parameters for AigorithmIdentifier 371 CCMParameters ::= SEQUENCE { 372 aes-nonce OCTET STRING (SIZE(7..13)), 373 aes-ICVlen AES-CCM-ICVlen DEFAULT 12 } 375 AES-CCM-ICVlen ::= INTEGER (4 | 6 | 8 | 10 | 12 | 14 | 16) 377 GCMParameters ::= SEQUENCE { 378 aes-nonce OCTET STRING, -- recommended size is 12 octets 379 aes-ICVlen AES-GCM-ICVlen DEFAULT 12 } 381 AES-GCM-ICVlen ::= INTEGER (12 | 13 | 14 | 15 | 16) 383 END 385 Authors' Addresses 387 Russell Housley 388 Vigil Security, LLC 389 918 Spring Knoll Drive 390 Herndon, VA 20170 391 USA 393 EMail: housley(at)vigilsec.com 395 Copyright and IPR Statements 397 Copyright (C) The Internet Society (2007). 399 This document is subject to the rights, licenses and restrictions 400 contained in BCP 78, and except as set forth therein, the authors 401 retain all their rights. 403 This document and translations of it may be copied and furnished to 404 others, and derivative works that comment on or otherwise explain it 405 or assist in its implementation may be prepared, copied, published 406 and distributed, in whole or in part, without restriction of any 407 kind, provided that the above copyright notice and this paragraph are 408 included on all such copies and derivative works. However, this 409 document itself may not be modified in any way, such as by removing 410 the copyright notice or references to the Internet Society or other 411 Internet organizations, except as needed for the purpose of 412 developing Internet standards in which case the procedures for 413 copyrights defined in the Internet Standards process must be 414 followed, or as required to translate it into languages other than 415 English. 417 The limited permissions granted above are perpetual and will not be 418 revoked by the Internet Society or its successors or assigns. 420 This document and the information contained herein are provided on an 421 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 422 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, (THE IETF TRUST) 423 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 424 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 425 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 426 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 427 PURPOSE. 429 The IETF takes no position regarding the validity or scope of any 430 Intellectual Property Rights or other rights that might be claimed to 431 pertain to the implementation or use of the technology described in 432 this document or the extent to which any license under such rights 433 might or might not be available; nor does it represent that it has 434 made any independent effort to identify any such rights. Information 435 on the procedures with respect to rights in RFC documents can be 436 found in BCP 78 and BCP 79. 438 Copies of IPR disclosures made to the IETF Secretariat and any 439 assurances of licenses to be made available, or the result of an 440 attempt made to obtain a general license or permission for the use of 441 such proprietary rights by implementers or users of this 442 specification can be obtained from the IETF on-line IPR repository at 443 http://www.ietf.org/ipr. 445 The IETF invites any interested party to bring to its attention any 446 copyrights, patents or patent applications, or other proprietary 447 rights that may cover technology that may be required to implement 448 this standard. Please address the information to the IETF at 449 ietf-ipr@ietf.org.