idnits 2.17.1 draft-ietf-smime-cms-auth-enveloped-05.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 455. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == 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 4 characters in excess of 72. -- 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 (September 2007) is 6060 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 370 -- Looks like a reference, but probably isn't: '1' on line 373 -- Looks like a reference, but probably isn't: '2' on line 375 ** Obsolete normative reference: RFC 3852 (ref. 'CMS') (Obsoleted by RFC 5652) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 8 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) September 2007 6 Cryptographic Message Syntax (CMS) 7 Authenticated-Enveloped-Data Content Type 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 describes an additional content type for the 35 Cryptographic Message Syntax (CMS). The authenticated-enveloped-data 36 content type is intended for use with authenticated encryption modes. 37 All of the various key management techniques that are supported in 38 the CMS enveloped-data content type are also supported by the CMS 39 authenticated-enveloped-data content type. 41 1. Introduction 43 This document describes an additional content type for the 44 Cryptographic Message Syntax (CMS) [CMS]. The authenticated- 45 enveloped-data content type is intended for use with authenticated 46 encryption modes, where an arbitrary content is both authenticated 47 and encrypted. Also, some associated data, in the form of 48 authenticated attributes can also be authenticated. All of the 49 various key management techniques that are supported in the CMS 50 enveloped-data content type are also supported by the CMS 51 authenticated-enveloped-data content type. 53 The conventions for using the AES-CCM and the AES-GCM authenticated 54 encryption algorithms with the CMS authenticated-enveloped-data 55 content type defined in this document can be found in [AEALGS]. 57 The authenticated-enveloped-data content type, like all of the other 58 CMS content types, employs ASN.1 [X.208-88], and it uses both the 59 Basic Encoding Rules [X.209-88] and the Distinguished Encoding Rules 60 (DER) [X.509-88]. 62 1.1 Terminology 64 In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, 65 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as 66 described in [STDWORDS]. 68 1.2 Version Numbers 70 The major data structure (AuthEnvelopedData) includes a version 71 number as the first item in the data structure. The version number 72 is intended to avoid ASN.1 decode errors. Some implementations do 73 not check the version number prior to attempting a decode, and then 74 if a decode error occurs, the version number is checked as part of 75 the error handling routine. This is a reasonable approach; it places 76 error processing outside of the fast path. This approach is also 77 forgiving when an incorrect version number is used by the sender. 79 Whenever the structure is updated, a higher version number will be 80 assigned. However, to ensure maximum interoperability the higher 81 version number is only used when the new syntax feature is employed. 82 That is, the lowest version number that supports the generated syntax 83 is used. 85 2. Authenticated-enveloped-data Content Type 87 The authenticated-enveloped-data content type consists of an 88 authenticated and encrypted content of any type and encrypted 89 content-authenticated-encryption keys for one or more recipients. 90 The combination of the authenticated and encrypted content and one 91 encrypted content-authenticated-encryption key for a recipient is a 92 "digital envelope" for that recipient. Any type of content can be 93 enveloped for an arbitrary number of recipients using any of the 94 supported key management techniques for each recipient. In addition, 95 authenticated but not encrypted attributes may be provided by the 96 originator. 98 The typical application of the authenticated-enveloped-data content 99 type will represent one or more recipients' digital envelopes on an 100 encapsulated content. 102 Authenticated-enveloped-data is constructed by the following steps: 104 1. A content-authenticated-encryption key for a particular 105 content-authenticated-encryption algorithm is generated at random. 107 2. The content-authenticated-encryption key is encrypted for each 108 recipient. The details of this encryption depend on the key 109 management algorithm used, but four general techniques are 110 supported: 112 key transport: the content-authenticated-encryption key is 113 encrypted in the recipient's public key; 115 key agreement: the recipient's public key and the sender's 116 private key are used to generate a pairwise symmetric key- 117 encryption key, then the content-authenticated-encryption 118 key is encrypted in the pairwise symmetric key-encryption 119 key; 121 symmetric key-encryption keys: the content-authenticated- 122 encryption key is encrypted in a previously distributed 123 symmetric key-encryption key; and 125 passwords: the content-authenticated-encryption key is 126 encrypted in a key-encryption key that is derived from a 127 password or other shared secret value. 129 3. For each recipient, the encrypted content-authenticated- 130 encryption key and other recipient-specific information are 131 collected into a RecipientInfo value, defined in Section 6.2 of 132 [CMS]. 134 4. Any attributes that are to be authenticated but not encrypted 135 are collected in the authenticated attributes. 137 5. The attributes collected in step 4 are authenticated and the 138 CMS content is authenticated and encrypted with the content- 139 authenticated-encryption key. If the authenticated encryption 140 algorithm requires either the additional authenticated data (AAD) 141 or the content to be padded to a multiple of some block size, then 142 the padding is added as described in Section 6.3 of [CMS]. 144 6. Any attributes that are to be provided without authentication 145 or encryption are collected in the unauthenticated attributes. 147 7. The RecipientInfo values for all the recipients, the 148 authenticated attributes, then unauthenticated attributes, and the 149 authenticated and encrypted content are collected together to form 150 an AuthEnvelopedData value as defined in Section 2.1. 152 A recipient opens the digital envelope by decrypting one of the 153 encrypted content-authenticated-encryption keys, and then using the 154 recovered key to decrypt and verify the integrity of the 155 authenticated and encrypted content as well as verifying the 156 integrity of the authenticated attributes. 158 The recipient MUST verify the integrity of the received content 159 before releasing any information, especially the plaintext of the 160 content. If the integrity verification fails, the receiver MUST 161 destroy all of the plaintext of the content. 163 This section is divided into three parts. The first part describes 164 the AuthEnvelopedData content type, the second part describes the 165 authentication and encryption process, and third part describes the 166 key encryption process. 168 2.1 AuthEnvelopedData Type 170 The following object identifier identifies the authenticated- 171 enveloped-data content type: 173 id-ct-authEnvelopedData OBJECT IDENTIFIER ::= { iso(1) 174 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 175 smime(16) ct(1) 23 } 177 The authenticated-enveloped-data content type MUST have ASN.1 type 178 AuthEnvelopedData: 180 AuthEnvelopedData ::= SEQUENCE { 181 version CMSVersion, 182 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 183 recipientInfos RecipientInfos, 184 authEncryptedContentInfo EncryptedContentInfo, 185 authAttrs [1] IMPLICIT AuthAttributes OPTIONAL, 186 mac MessageAuthenticationCode, 187 unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL } 189 The fields of type AuthEnvelopedData have the following meanings: 191 version is the syntax version number. It MUST be set to 0. 193 originatorInfo optionally provides information about the 194 originator. It is present only if required by the key 195 management algorithm. It may contain certificates and CRLs, 196 and the OriginatorInfo type is defined in Section 6.1 of [CMS]. 198 recipientInfos is a collection of per-recipient information. 199 There MUST be at least one element in the collection. The 200 RecipientInfo type is defined in Section 6.2 of [CMS]. 202 authEncryptedContentInfo is the authenticated and encrypted 203 content. The CMS enveloped-data content type uses the same 204 type to carry the encrypted content. The EncryptedContentInfo 205 type is defined in Section 6.1 of [CMS]. 207 authAttrs optionally contains the authenticated attributes. The 208 CMS authenticated-data content type uses the same type to carry 209 authenticated attributes. The authAttrs MUST be present if the 210 content type carried in EncryptedContentInfo is not id-data. 211 AuthAttributes MUST be DER encoded, even if the rest of the 212 AuthEnvelopedData structure is BER encoded. The AuthAttributes 213 type is defined in Section 9.1 of [CMS]; however, in this case, 214 the message-digest attribute SHOULD NOT be included. Useful 215 attribute types are defined in Section 11 of [CMS]. 217 mac is the integrity check value (ICV) or message authentication 218 code (MAC) that is generated by the authenticated encryption 219 algorithm. The CMS authenticated-data content type uses the 220 same type to carry a MAC. In this case, the MAC covers the 221 authenticated attributes and the content directly, and a digest 222 algorithm is not used. The MessageAuthenticationCode type is 223 defined in Section 9.1 of [CMS]. 225 unauthAttrs optionally contains the unauthenticated attributes. 226 The CMS authenticated-data content type uses the same type to 227 carry unauthenticated attributes. The UnauthAttributes type is 228 defined in Section 9.1 of [CMS]. Useful attribute types are 229 defined in Section 11 of [CMS]. 231 2.2. Authentication and Encryption Process 233 The content-authenticated-encryption key for the desired content- 234 authenticated-encryption algorithm is randomly generated. 236 If the authenticated encryption algorithm requires the content to be 237 padded to a multiple of some block size, then the padding MUST be 238 added as described in Section 6.3 of [CMS]. This padding method is 239 well defined if and only if the block size is less than 256 octets. 241 If optional authenticated attributes are present, then they are DER 242 encoded. A separate encoding of the authAttrs field is performed to 243 construct the authenticated associated data (AAD) input to the 244 authenticated encryption algorithm. The IMPLICIT [1] tag in the 245 authAttrs field is not used for the DER encoding, rather an EXPLICIT 246 SET OF tag is used. That is, the DER encoding of the SET OF tag, 247 rather than of the IMPLICIT [1] tag, is to be included in the 248 construction of the AAD along with the length and content octets of 249 the authAttrs value. If the authenticated encryption algorithm 250 requires the AAD to be padded to a multiple of some block size, then 251 the padding MUST be added as described in Section 6.3 of [CMS]. This 252 padding method is well defined if and only if block size is less than 253 256 octets. 255 The inputs to the authenticated encryption algorithm are the content 256 (the data, which is padded if necessary), the DER-encoded 257 authenticated attributes (the AAD, which is padded if necessary), and 258 the content-authenticated-encryption key. Under control of a 259 content-authenticated-encryption key, the authenticated encryption 260 operation maps an arbitrary string of octets (the data) to another 261 string of octets (the ciphertext) and it computes an authentication 262 tag over the AAD and the data. The encrypted data is included in the 263 AuthEnvelopedData authEncryptedContentInfo encryptedContent as an 264 OCTET STRING, and the authentication tag is included in the 265 AuthEnvelopedData mac. 267 2.3. Key Encryption Process 269 The input to the key encryption process -- the value supplied to the 270 recipient's key-encryption algorithm -- is just the "value" of the 271 content-authenticated-encryption key. 273 Any of the aforementioned key management techniques can be used for 274 each recipient of the same encrypted content. 276 3. Security Considerations 278 This specification defines an additional CMS content type. The 279 security considerations provided in [CMS] apply to this content type 280 as well. 282 Many authenticated encryption algorithms make use of a block cipher 283 in counter mode to provide encryption. When used properly, counter 284 mode provides strong confidentiality. Bellare, Desai, Jokipii, 285 Rogaway show in [BDJR] that the privacy guarantees provided by 286 counter mode are at least as strong as those for CBC mode when using 287 the same block cipher. 289 Unfortunately, it is easy to misuse counter mode. If counter block 290 values are ever used for more that one encryption operation with the 291 same key, then the same key stream will be used to encrypt both 292 plaintexts, and the confidentiality guarantees are voided. 294 Fortunately, the CMS authenticated-enveloped-data content type 295 provides all of the tools needed to avoid misuse of counter mode. 296 All of the existing key management techniques permit a fresh content- 297 encryption key to be generated for each content. In addition, 298 existing authenticated encryption algorithms that make use of counter 299 mode support the use of an unpredictable nonce value in the counter 300 block. This unpredictable nonce value (sometimes called a "salt") 301 should be carried in an algorithm identifier parameter. 303 There are fairly generic precomputation attacks against all block 304 cipher modes that allow a meet-in-the-middle attack against the key. 305 These attacks require the creation and searching of huge tables of 306 ciphertext associated with known plaintext and known keys. Assuming 307 that the memory and processor resources are available for a 308 precomputation attack, then the theoretical strength of any block 309 cipher mode is limited to 2^(n/2) bits, where n is the number of bits 310 in the key. The use of long keys is the best countermeasure to 311 precomputation attacks. Use of an unpredictable nonce value in the 312 counter block significantly increases the size of the table that the 313 attacker must compute to mount a successful precomputation attack. 315 Implementations must randomly generate content-authenticated- 316 encryption keys, padding, and unpredictable nonce values. Also, the 317 generation of public/private key pairs relies on a random numbers. 318 The use of inadequate pseudo-random number generators (PRNGs) to 319 generate cryptographic keys can result in little or no security. An 320 attacker may find it much easier to reproduce the PRNG environment 321 that produced the keys, searching the resulting small set of 322 possibilities, rather than brute force searching the whole key space. 323 The generation of quality random numbers is difficult. RFC 4086 324 [RANDOM] offers important guidance in this area. 326 If the message-digest attribute is included in the AuthAttributes, 327 then the attribute value will contain the unencrypted one-way hash 328 value of the plaintext of the content. Disclosure of this hash value 329 enables content tracking, and it can be used to determine if the 330 plaintext matches one or more candidate contents. For these reasons, 331 the AuthAttributes SHOULD NOT contain the message-digest attribute. 333 4. IANA Considerations 335 None. 337 {{{ RFC Editor: Please remove this section prior to publication. }}} 339 5. ASN.1 Module 341 CMS-AuthEnvelopedData-2007 342 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 343 pkcs-9(9) smime(16) modules(0) cms-authEnvelopedData(31) } 345 DEFINITIONS IMPLICIT TAGS ::= 346 BEGIN 348 -- EXPORTS All 349 -- The types and values defined in this module are exported for use 350 -- in the other ASN.1 modules. Other applications may use them for 351 -- their own purposes. 353 IMPORTS 355 -- Imports from RFC 3852 [CMS], Section 12.1 356 AuthAttributes, CMSVersion, EncryptedContentInfo, 357 MessageAuthenticationCode, OriginatorInfo, RecipientInfos, 358 UnauthAttributes 359 FROM CryptographicMessageSyntax2004 360 { iso(1) member-body(2) us(840) rsadsi(113549) 361 pkcs(1) pkcs-9(9) smime(16) modules(0) 362 cms-2004(24) } ; 364 id-ct-authEnvelopedData OBJECT IDENTIFIER ::= { iso(1) 365 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 366 smime(16) ct(1) 23 } 368 AuthEnvelopedData ::= SEQUENCE { 369 version CMSVersion, 370 originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, 371 recipientInfos RecipientInfos, 372 authEncryptedContentInfo EncryptedContentInfo, 373 authAttrs [1] IMPLICIT AuthAttributes OPTIONAL, 374 mac MessageAuthenticationCode, 375 unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL } 377 END -- of CMS-AuthEnvelopedData-2007 379 6. References 381 6.1. Normative References 383 [CMS] Housley, R., "Cryptographic Message Syntax", 384 RFC 3852, July 2004. 386 [STDWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate 387 Requirement Levels", BCP 14, RFC 2119, March 1997. 389 [X.208-88] CCITT. Recommendation X.208: Specification of Abstract 390 Syntax Notation One (ASN.1). 1988. 392 [X.209-88] CCITT. Recommendation X.209: Specification of Basic 393 Encoding Rules for Abstract Syntax Notation One (ASN.1). 394 1988. 396 [X.509-88] CCITT. Recommendation X.509: The Directory - 397 Authentication Framework. 1988. 399 6.2. Informative References 401 [AEALGS] Housley, R., "Using AES-CCM and AES-GCM Authenticated 402 Encryption in the Cryptographic Message Syntax (CMS)", 403 work in progress. draft-ietf-smime-cms-aes-ccm-and-gcm. 405 [BDJR] Bellare, M., Desai, A., Jokipii, E., and P. Rogaway, 406 "A Concrete Security Treatment of Symmetric Encryption: 407 Analysis of the DES Modes of Operation", Proceedings 408 38th Annual Symposium on Foundations of Computer 409 Science, 1997. 411 [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 412 Recommendations for Security", RFC 4086, June 2005. 414 7. Authors' Address 416 Russell Housley 417 Vigil Security, LLC 418 918 Spring Knoll Drive 419 Herndon, VA 20170 420 USA 421 EMail: housley@vigilsec.com 423 Copyright and IPR Statements 425 Copyright (C) The IETF Trust (2007). 427 This document is subject to the rights, licenses and restrictions 428 contained in BCP 78, and except as set forth therein, the authors 429 retain all their rights. 431 This document and translations of it may be copied and furnished to 432 others, and derivative works that comment on or otherwise explain it 433 or assist in its implementation may be prepared, copied, published and 434 distributed, in whole or in part, without restriction of any kind, 435 provided that the above copyright notice and this paragraph are 436 included on all such copies and derivative works. However, this 437 document itself may not be modified in any way, such as by removing 438 the copyright notice or references to the Internet Society or other 439 Internet organizations, except as needed for the purpose of 440 developing Internet standards in which case the procedures for 441 copyrights defined in the Internet Standards process must be 442 followed, or as required to translate it into languages other than 443 English. 445 The limited permissions granted above are perpetual and will not be 446 revoked by the Internet Society or its successors or assigns. 448 This document and the information contained herein 449 are provided on an "AS IS" basis and THE CONTRIBUTOR, THE 450 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE 451 INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE 452 DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 453 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 454 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 455 OR FITNESS FOR A PARTICULAR PURPOSE.