idnits 2.17.1 draft-ietf-smime-cms-auth-enveloped-06.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 484. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 442. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 449. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 455. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3852, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC3852, updated by this document, for RFC5378 checks: 2004-03-16) -- 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 (21 March 2008) is 5877 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) -- Looks like a reference, but probably isn't: '0' on line 378 -- Looks like a reference, but probably isn't: '1' on line 381 -- Looks like a reference, but probably isn't: '2' on line 383 ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 S/MIME Working Group R. Housley 3 Internet-Draft Vigil Security 4 Updates: 3852 (if approved) 21 September 2007 5 Intended status: Proposed Standard 6 Expiration: 21 March 2008 8 Cryptographic Message Syntax (CMS) 9 Authenticated-Enveloped-Data Content Type 10 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Abstract 36 This document describes an additional content type for the 37 Cryptographic Message Syntax (CMS). The authenticated-enveloped-data 38 content type is intended for use with authenticated encryption modes. 39 All of the various key management techniques that are supported in 40 the CMS enveloped-data content type are also supported by the CMS 41 authenticated-enveloped-data content type. 43 1. Introduction 45 This document describes an additional content type for the 46 Cryptographic Message Syntax (CMS) [CMS]. The authenticated- 47 enveloped-data content type is intended for use with authenticated 48 encryption modes, where an arbitrary content is both authenticated 49 and encrypted. Also, some associated data, in the form of 50 authenticated attributes can also be authenticated. All of the 51 various key management techniques that are supported in the CMS 52 enveloped-data content type are also supported by the CMS 53 authenticated-enveloped-data content type. 55 The conventions for using the AES-CCM and the AES-GCM authenticated 56 encryption algorithms with the CMS authenticated-enveloped-data 57 content type defined in this document can be found in [AESALGS]. 59 The authenticated-enveloped-data content type, like all of the other 60 CMS content types, employs ASN.1 [X.208-88], and it uses both the 61 Basic Encoding Rules [X.209-88] and the Distinguished Encoding Rules 62 (DER) [X.509-88]. 64 1.1 Terminology 66 In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, 67 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as 68 described in [STDWORDS]. 70 1.2 Version Numbers 72 The major data structure (AuthEnvelopedData) includes a version 73 number as the first item in the data structure. The version number 74 is intended to avoid ASN.1 decode errors. Some implementations do 75 not check the version number prior to attempting a decode, and then 76 if a decode error occurs, the version number is checked as part of 77 the error handling routine. This is a reasonable approach; it places 78 error processing outside of the fast path. This approach is also 79 forgiving when an incorrect version number is used by the sender. 81 Whenever the structure is updated, a higher version number will be 82 assigned. However, to ensure maximum interoperability the higher 83 version number is only used when the new syntax feature is employed. 84 That is, the lowest version number that supports the generated syntax 85 is used. 87 2. Authenticated-enveloped-data Content Type 89 The authenticated-enveloped-data content type consists of an 90 authenticated and encrypted content of any type and encrypted 91 content-authenticated-encryption keys for one or more recipients. 92 The combination of the authenticated and encrypted content and one 93 encrypted content-authenticated-encryption key for a recipient is a 94 "digital envelope" for that recipient. Any type of content can be 95 enveloped for an arbitrary number of recipients using any of the 96 supported key management techniques for each recipient. In addition, 97 authenticated but not encrypted attributes may be provided by the 98 originator. 100 The typical application of the authenticated-enveloped-data content 101 type will represent one or more recipients' digital envelopes on an 102 encapsulated content. 104 Authenticated-enveloped-data is constructed by the following steps: 106 1. A content-authenticated-encryption key for a particular 107 content-authenticated-encryption algorithm is generated at random. 109 2. The content-authenticated-encryption key is encrypted for each 110 recipient. The details of this encryption depend on the key 111 management algorithm used, but four general techniques are 112 supported: 114 key transport: the content-authenticated-encryption key is 115 encrypted in the recipient's public key; 117 key agreement: the recipient's public key and the sender's 118 private key are used to generate a pairwise symmetric key- 119 encryption key, then the content-authenticated-encryption 120 key is encrypted in the pairwise symmetric key-encryption 121 key; 123 symmetric key-encryption keys: the content-authenticated- 124 encryption key is encrypted in a previously distributed 125 symmetric key-encryption key; and 127 passwords: the content-authenticated-encryption key is 128 encrypted in a key-encryption key that is derived from a 129 password or other shared secret value. 131 3. For each recipient, the encrypted content-authenticated- 132 encryption key and other recipient-specific information are 133 collected into a RecipientInfo value, defined in Section 6.2 of 134 [CMS]. 136 4. Any attributes that are to be authenticated but not encrypted 137 are collected in the authenticated attributes. 139 5. The attributes collected in step 4 are authenticated and the 140 CMS content is authenticated and encrypted with the content- 141 authenticated-encryption key. If the authenticated encryption 142 algorithm requires either the additional authenticated data (AAD) 143 or the content to be padded to a multiple of some block size, then 144 the padding is added as described in Section 6.3 of [CMS]. 146 6. Any attributes that are to be provided without authentication 147 or encryption are collected in the unauthenticated attributes. 149 7. The RecipientInfo values for all the recipients, the 150 authenticated attributes, then unauthenticated attributes, and the 151 authenticated and encrypted content are collected together to form 152 an AuthEnvelopedData value as defined in Section 2.1. 154 A recipient opens the digital envelope by decrypting one of the 155 encrypted content-authenticated-encryption keys, and then using the 156 recovered key to decrypt and verify the integrity of the 157 authenticated and encrypted content as well as verifying the 158 integrity of the authenticated attributes. 160 The recipient MUST verify the integrity of the received content 161 before releasing any information, especially the plaintext of the 162 content. If the integrity verification fails, the receiver MUST 163 destroy all of the plaintext of the content. 165 This section is divided into three parts. The first part describes 166 the AuthEnvelopedData content type, the second part describes the 167 authentication and encryption process, and third part describes the 168 key encryption process. 170 2.1 AuthEnvelopedData Type 172 The following object identifier identifies the authenticated- 173 enveloped-data content type: 175 id-ct-authEnvelopedData OBJECT IDENTIFIER ::= { iso(1) 176 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 177 smime(16) ct(1) 23 } 179 The authenticated-enveloped-data content type MUST have ASN.1 type 180 AuthEnvelopedData: 182 AuthEnvelopedData ::= SEQUENCE { 183 version CMSVersion, 184 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 185 recipientInfos RecipientInfos, 186 authEncryptedContentInfo EncryptedContentInfo, 187 authAttrs [1] IMPLICIT AuthAttributes OPTIONAL, 188 mac MessageAuthenticationCode, 189 unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL } 191 The fields of type AuthEnvelopedData have the following meanings: 193 version is the syntax version number. It MUST be set to 0. 195 originatorInfo optionally provides information about the 196 originator. It is present only if required by the key 197 management algorithm. It may contain certificates and CRLs, 198 and the OriginatorInfo type is defined in Section 6.1 of [CMS]. 200 recipientInfos is a collection of per-recipient information. 201 There MUST be at least one element in the collection. The 202 RecipientInfo type is defined in Section 6.2 of [CMS]. 204 authEncryptedContentInfo is the authenticated and encrypted 205 content. The CMS enveloped-data content type uses the same 206 type to carry the encrypted content. The EncryptedContentInfo 207 type is defined in Section 6.1 of [CMS]. 209 authAttrs optionally contains the authenticated attributes. The 210 CMS authenticated-data content type uses the same type to carry 211 authenticated attributes. The authAttrs MUST be present if the 212 content type carried in EncryptedContentInfo is not id-data. 213 AuthAttributes MUST be DER encoded, even if the rest of the 214 AuthEnvelopedData structure is BER encoded. The AuthAttributes 215 type is defined in Section 9.1 of [CMS]; however, in this case, 216 the message-digest attribute SHOULD NOT be included. Useful 217 attribute types are defined in Section 11 of [CMS]. 219 mac is the integrity check value (ICV) or message authentication 220 code (MAC) that is generated by the authenticated encryption 221 algorithm. The CMS authenticated-data content type uses the 222 same type to carry a MAC. In this case, the MAC covers the 223 authenticated attributes and the content directly, and a digest 224 algorithm is not used. The MessageAuthenticationCode type is 225 defined in Section 9.1 of [CMS]. 227 unauthAttrs optionally contains the unauthenticated attributes. 228 The CMS authenticated-data content type uses the same type to 229 carry unauthenticated attributes. The UnauthAttributes type is 230 defined in Section 9.1 of [CMS]. Useful attribute types are 231 defined in Section 11 of [CMS]. 233 2.2. Authentication and Encryption Process 235 The content-authenticated-encryption key for the desired content- 236 authenticated-encryption algorithm is randomly generated. 238 If the authenticated encryption algorithm requires the content to be 239 padded to a multiple of some block size, then the padding MUST be 240 added as described in Section 6.3 of [CMS]. This padding method is 241 well defined if and only if the block size is less than 256 octets. 243 If optional authenticated attributes are present, then they are DER 244 encoded. A separate encoding of the authAttrs field is performed to 245 construct the authenticated associated data (AAD) input to the 246 authenticated encryption algorithm. For the purposes of constructing 247 the AAD, the IMPLICIT [1] tag in for authAttrs field is not used for 248 the DER encoding, rather an universal SET OF tag is used. That is, 249 the DER encoding of the SET OF tag, rather than of the IMPLICIT [1] 250 tag, is to be included in the construction for the AAD along with the 251 length and content octets of the authAttrs value. If the 252 authenticated encryption algorithm requires the AAD to be padded to a 253 multiple of some block size, then the padding MUST be added as 254 described in Section 6.3 of [CMS]. This padding method is well 255 defined if and only if block size is less than 256 octets. 257 If optional authenticated attributes are absent, then zero bits of 258 input are provided for the AAD input to the authenticated encryption 259 algorithm. 261 The inputs to the authenticated encryption algorithm are the content 262 (the data, which is padded if necessary), the DER-encoded 263 authenticated attributes (the AAD, which is padded if necessary), and 264 the content-authenticated-encryption key. Under control of a 265 content-authenticated-encryption key, the authenticated encryption 266 operation maps an arbitrary string of octets (the data) to another 267 string of octets (the ciphertext) and it computes an authentication 268 tag over the AAD and the data. The encrypted data is included in the 269 AuthEnvelopedData authEncryptedContentInfo encryptedContent as an 270 OCTET STRING, and the authentication tag is included in the 271 AuthEnvelopedData mac. 273 2.3. Key Encryption Process 275 The input to the key encryption process -- the value supplied to the 276 recipient's key-encryption algorithm -- is just the "value" of the 277 content-authenticated-encryption key. 279 Any of the aforementioned key management techniques can be used for 280 each recipient of the same encrypted content. 282 3. Security Considerations 284 This specification defines an additional CMS content type. The 285 security considerations provided in [CMS] apply to this content type 286 as well. 288 Many authenticated encryption algorithms make use of a block cipher 289 in counter mode to provide encryption. When used properly, counter 290 mode provides strong confidentiality. Bellare, Desai, Jokipii, 291 Rogaway show in [BDJR] that the privacy guarantees provided by 292 counter mode are at least as strong as those for CBC mode when using 293 the same block cipher. 295 Unfortunately, it is easy to misuse counter mode. If counter block 296 values are ever used for more that one encryption operation with the 297 same key, then the same key stream will be used to encrypt both 298 plaintexts, and the confidentiality guarantees are voided. 300 Fortunately, the CMS authenticated-enveloped-data content type 301 provides all of the tools needed to avoid misuse of counter mode. 302 All of the existing key management techniques permit a fresh content- 303 encryption key to be generated for each content. In addition, 304 existing authenticated encryption algorithms that make use of counter 305 mode support the use of an unpredictable nonce value in the counter 306 block. This unpredictable nonce value (sometimes called a "salt") 307 should be carried in an algorithm identifier parameter. 309 Implementations must randomly generate content-authenticated- 310 encryption keys, padding, and unpredictable nonce values. Also, the 311 generation of public/private key pairs relies on a random numbers. 312 The use of inadequate pseudo-random number generators (PRNGs) to 313 generate cryptographic keys can result in little or no security. An 314 attacker may find it much easier to reproduce the PRNG environment 315 that produced the keys, searching the resulting small set of 316 possibilities, rather than brute force searching the whole key space. 317 The generation of quality random numbers is difficult. RFC 4086 318 [RANDOM] offers important guidance in this area. 320 If the message-digest attribute is included in the AuthAttributes, 321 then the attribute value will contain the unencrypted one-way hash 322 value of the plaintext of the content. Disclosure of this hash value 323 enables content tracking, and it can be used to determine if the 324 plaintext matches one or more candidate contents. For these reasons, 325 the AuthAttributes SHOULD NOT contain the message-digest attribute. 327 CMS is often used to provide encryption in messaging environments. 328 In messaging environments, various forms of unsolicited messages 329 (such as spam and phishing) represent a significant volume of 330 unwanted traffic. Present mitigation strategies for unwanted message 331 traffic involve analysis of message plaintext. When recipients 332 accept unsolicited encrypted messages, they become even more 333 vulnerable to unwanted traffic since the present mitigation 334 strategies will be unable to access the plaintext. Therefore, 335 software that receives messages that have been encrypted using CMS 336 needs to provide one or more mechanisms to handle the unwanted 337 message traffic. One approach that does not require disclosure of 338 keying material to a server is to reject or discard encrypted 339 messages unless they purport to come from a member of a white list. 341 4. IANA Considerations 343 None. 345 {{{ RFC Editor: Please remove this section prior to publication. }}} 347 5. ASN.1 Module 349 CMS-AuthEnvelopedData-2007 350 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 351 pkcs-9(9) smime(16) modules(0) cms-authEnvelopedData(31) } 353 DEFINITIONS IMPLICIT TAGS ::= 354 BEGIN 356 -- EXPORTS All 357 -- The types and values defined in this module are exported for use 358 -- in the other ASN.1 modules. Other applications may use them for 359 -- their own purposes. 361 IMPORTS 363 -- Imports from RFC 3852 [CMS], Section 12.1 364 AuthAttributes, CMSVersion, EncryptedContentInfo, 365 MessageAuthenticationCode, OriginatorInfo, RecipientInfos, 366 UnauthAttributes 367 FROM CryptographicMessageSyntax2004 368 { iso(1) member-body(2) us(840) rsadsi(113549) 369 pkcs(1) pkcs-9(9) smime(16) modules(0) 370 cms-2004(24) } ; 372 id-ct-authEnvelopedData OBJECT IDENTIFIER ::= { iso(1) 373 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 374 smime(16) ct(1) 23 } 376 AuthEnvelopedData ::= SEQUENCE { 377 version CMSVersion, 378 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 379 recipientInfos RecipientInfos, 380 authEncryptedContentInfo EncryptedContentInfo, 381 authAttrs [1] IMPLICIT AuthAttributes OPTIONAL, 382 mac MessageAuthenticationCode, 383 unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL } 385 END -- of CMS-AuthEnvelopedData-2007 387 6. References 389 6.1. Normative References 391 [CMS] Housley, R., "Cryptographic Message Syntax", 392 RFC 3852, July 2004. 394 [STDWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate 395 Requirement Levels", BCP 14, RFC 2119, March 1997. 397 [X.208-88] CCITT. Recommendation X.208: Specification of Abstract 398 Syntax Notation One (ASN.1). 1988. 400 [X.209-88] CCITT. Recommendation X.209: Specification of Basic 401 Encoding Rules for Abstract Syntax Notation One (ASN.1). 402 1988. 404 [X.509-88] CCITT. Recommendation X.509: The Directory - 405 Authentication Framework. 1988. 407 6.2. Informative References 409 [AESALGS] Housley, R., "Using AES-CCM and AES-GCM Authenticated 410 Encryption in the Cryptographic Message Syntax (CMS)", 411 work in progress. draft-ietf-smime-cms-aes-ccm-and-gcm. 413 [BDJR] Bellare, M., Desai, A., Jokipii, E., and P. Rogaway, 414 "A Concrete Security Treatment of Symmetric Encryption: 415 Analysis of the DES Modes of Operation", Proceedings 416 38th Annual Symposium on Foundations of Computer 417 Science, 1997. 419 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 420 Recommendations for Security", RFC 4086, June 2005. 422 7. Authors' Address 424 Russell Housley 425 Vigil Security, LLC 426 918 Spring Knoll Drive 427 Herndon, VA 20170 428 USA 429 EMail: housley@vigilsec.com 431 Copyright and IPR Statements 433 Copyright (C) The IETF Trust (2007). 435 The IETF takes no position regarding the validity or scope of any 436 Intellectual Property Rights or other rights that might be claimed to 437 pertain to the implementation or use of the technology described in 438 this document or the extent to which any license under such rights 439 might or might not be available; nor does it represent that it has 440 made any independent effort to identify any such rights. Information 441 on the procedures with respect to rights in RFC documents can be 442 found in BCP 78 and BCP 79. 444 Copies of IPR disclosures made to the IETF Secretariat and any 445 assurances of licenses to be made available, or the result of an 446 attempt made to obtain a general license or permission for the use of 447 such proprietary rights by implementers or users of this 448 specification can be obtained from the IETF on-line IPR repository at 449 http://www.ietf.org/ipr. 451 The IETF invites any interested party to bring to its attention any 452 copyrights, patents or patent applications, or other proprietary 453 rights that may cover technology that may be required to implement 454 this standard. Please address the information to the IETF at ietf- 455 ipr@ietf.org. 457 This document is subject to the rights, licenses and restrictions 458 contained in BCP 78, and except as set forth therein, the authors 459 retain all their rights. 461 This document and translations of it may be copied and furnished to 462 others, and derivative works that comment on or otherwise explain it 463 or assist in its implementation may be prepared, copied, published 464 and distributed, in whole or in part, without restriction of any 465 kind, provided that the above copyright notice and this paragraph are 466 included on all such copies and derivative works. However, this 467 document itself may not be modified in any way, such as by removing 468 the copyright notice or references to the Internet Society or other 469 Internet organizations, except as needed for the purpose of 470 developing Internet standards in which case the procedures for 471 copyrights defined in the Internet Standards process must be 472 followed, or as required to translate it into languages other than 473 English. 475 The limited permissions granted above are perpetual and will not be 476 revoked by the Internet Society or its successors or assigns. 478 This document and the information contained herein are provided on an 479 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 480 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 481 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 482 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 483 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 484 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 486 Expiration: 21 March 2008