idnits 2.17.1 draft-gutmann-cms-hmac-enc-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (November 23, 2011) is 4535 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 502 -- Looks like a reference, but probably isn't: '3' on line 459 ** Obsolete normative reference: RFC 2898 (ref. 'PBKDF2') (Obsoleted by RFC 8018) ** Obsolete normative reference: RFC 5751 (ref. 'SMIME') (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 S/MIME Working Group P. Gutmann 2 Internet-Draft University of Auckland 3 Intended status: Standards Track November 23, 2011 4 Expires: May 26, 2012 6 Using MAC-authenticated Encryption in the Cryptographic Message Syntax 7 (CMS) 8 draft-gutmann-cms-hmac-enc-06.txt 10 Abstract 12 This document specifies the conventions for using MAC-authenticated 13 encryption with the Cryptographic Message Syntax (CMS) authenticated- 14 enveloped-data content type. This mirrors the use of a MAC combined 15 with an encryption algorithm that's already employed in IPsec, SSL/ 16 TLS, and SSH, which is widely supported in existing crypto libraries 17 and hardware, and has been extensively analysed by the crypto 18 community. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 26, 2012. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 56 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. CMS Encrypt-and-Authenticate Overview . . . . . . . . . . . . 5 58 3.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. CMS Encrypt-and-Authenticate . . . . . . . . . . . . . . . . . 7 60 4.1. Encrypt-and-Authenticate Message Processing . . . . . . . 8 61 4.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 9 62 4.3. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . 11 63 5. SMIMECapabilities Attribute . . . . . . . . . . . . . . . . . 15 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 68 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 69 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 72 1. Introduction 74 This document specifies the conventions for using MAC-authenticated 75 encryption with the Cryptographic Message Syntax (CMS) authenticated- 76 enveloped-data content type. This mirrors the use of a MAC combined 77 with an encryption algorithm that's already employed in IPsec, SSL/ 78 TLS, and SSH, which is widely supported in existing crypto libraries 79 and hardware, and has been extensively analysed by the crypto 80 community. 82 1.1. Conventions Used in This Document 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 2. Background 90 Integrity-protected encryption is a standard feature of session- 91 oriented security protocols like [IPsec], [SSH], and [TLS], but until 92 recently wasn't available for message-based security protocols like 93 CMS, although [OpenPGP] added a form of integrity protection by 94 encrypting a SHA-1 hash of the message alongside the message contents 95 to provide authenticate-and-encrypt protection. Usability studies 96 have shown that users expect encryption to provide integrity 97 protection [Garfinkel], creating cognitive dissonance problems when 98 the security mechanisms don't in fact provide this assurance. 100 This document applies the same encrypt-and-authenticate mechanism 101 already employed in IPsec, SSH, and SSL/TLS, to CMS (technically some 102 of these actually use authenticate-and-encrypt rather than encrypt- 103 and-authenticate, since what's authenticated is the plaintext and not 104 the ciphertext). This mechanism is widely supported in existing 105 crypto libraries and hardware, and has been extensively analysed by 106 the crypto community [EncryptThenAuth]. 108 3. CMS Encrypt-and-Authenticate Overview 110 Conventional CMS encryption uses a content encryption key (CEK) to 111 encrypt a message payload, with the CEK typically being in turn 112 encrypted by a key encryption key (KEK). Authenticated encryption 113 requires two keys, one for encryption and a second one for 114 authentication. Like other mechanisms that use authenticated 115 encryption, this document employs a pseudorandom function (PRF) to 116 convert a single block of keying material into the two keys required 117 for encryption and authentication. This converts the standard CMS 118 encryption operation: 120 KEK( CEK ) || CEK( data ) 122 into: 124 KEK( master_secret ) || MAC( CEK( data ) ) 126 where the MAC key MAC-K and encryption key CEK-K is derived from the 127 master_secret via: 129 MAC-K := PRF( master_secret, "authentication" ); 130 CEK-K := PRF( master_secret, "encryption" ); 132 3.1. Rationale 134 There are several possible means of deriving the two keys required 135 for the encrypt-and-authenticate process from the single key normally 136 provided by the key exchange or key transport mechanisms. Several of 137 these however have security or practical issues. For example any 138 mechanism that uses the single exchanged key in its entirety for 139 encryption (using, perhaps, PRF( key ) as the MAC key) can be 140 converted back to unauthenticated data by removing the outer MAC 141 layer and rewriting the CMS envelope back to plain EnvelopedData or 142 EncryptedData. By applying the PRF intermediate step, any attempt at 143 a rollback attack will result in a decryption failure. 145 The option chosen here, the use of a PRF to derive the necessary sets 146 of keying material from a master secret, is well-established through 147 its use in IPsec, SSH, and SSL/TLS, and is widely supported in both 148 crypto libraries and in encryption hardware. 150 The PRF used is PBKDF2 because its existing use in CMS makes it the 151 most obvious candidate for such a function. If in the future a 152 universal PRF, for example [HKDF], is adopted then this can be 153 substituted for PBKDF2 by specifying it in the prfAlgorithm field 154 covered in Section 4. 156 The resulting processing operations consist of a combination of the 157 operations used for the existing CMS content types EncryptedData and 158 AuthenticatedData, allowing them to be implemented relatively simply 159 using existing code. 161 4. CMS Encrypt-and-Authenticate 163 The encrypt-and-authenticate mechanism is implemented within the 164 existing CMS RecipientInfo framework by defining a new pseudo- 165 algorithm type authEnc which is used in place of a monolithic encrypt 166 and hash algorithm. The RecipientInfo is used as a key container for 167 the master secret used by the pseudo-algorithm from which the 168 encryption and authentication keys for existing single-purpose 169 encrypt-only and MAC-only algorithms are derived. Thus instead of 170 using the RecipientInfo to communicate (for example) an AES or HMAC- 171 SHA1 key, it communicates a master secret from which the required AES 172 encryption and HMAC-SHA1 authentication keys are derived. 174 The authEnc pseudo-algorithm comes in two forms, one conveying 128 175 bits of keying material and one conveying 256 bits: 177 id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) 178 us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 } 180 id-alg OBJECT IDENTIFIER ::= { id-smime 3 } 182 id-alg-authEnc-128 OBJECT IDENTIFIER ::= { id-alg 15 } 183 id-alg-authEnc-256 OBJECT IDENTIFIER ::= { id-alg 16 } 185 The algorithm parameters are: 187 AuthEncParams ::= SEQUENCE { 188 prfAlgorithm [0] AlgorithmIdentifier DEFAULT PBKDF2, 189 encAlgorithm AlgorithmIdentifier, 190 macAlgorithm AlgorithmIdentifier 191 } 193 prfAlgorithm is the PRF algorithm used to convert the master 194 secret into the encryption and MAC keys. The default PRF is 195 [PBKDF2], which in turn has a default PRF algorithm of HMAC-SHA1. 196 When this default setting is used, the PBKDF2-params 'salt' 197 parameter is an empty string and the 'iterationCount' parameter is 198 one, turning the KDF into a pure PRF. 199 encAlgorithm is the encryption algorithm and associated parameters 200 to be used to encrypt the content. 201 macAlgorithm is the MAC algorithm and associated parameters to be 202 used to authenticate/integrity-protect the content. 204 When the prfAlgorithm AlgorithmIdentifier is used in conjunction with 205 PBKDF2 to specify a PRF other than the default PBKDF2-with-HMAC-SHA1 206 one, the PBKDF2-params require that two additional algorithm 207 parameters be specified. The 'salt' parameter MUST be an empty 208 (zero-length) string and the 'iterationCount' parameter MUST be one, 209 since these values aren't used in the PRF process. In their encoded 210 form as used for the PBKDF2-params, these two parameters have the 211 value 08 00 02 01 01. 213 As a guideline for authors specifying the use of PRFs other than 214 PBKDF2, any additional parameters such as salts, tags, and 215 identification strings SHOULD be set to empty strings and any 216 iteration count SHOULD be set to one. 218 4.1. Encrypt-and-Authenticate Message Processing 220 The randomly-generated master secret to be communicated via the 221 RecipientInfo(s) is converted to separate encryption and 222 authentication keys and applied to the encrypt-and-authenticate 223 process as follows. The notation "PRF( key, salt, iterations )" is 224 used to denote an application of the PRF to the given keying value 225 and salt, for the given number of iterations: 227 1. The MAC algorithm key is derived from the master secret via: 229 MAC-K ::= PRF( master_secret, "authentication", 1 ); 231 2. The encryption algorithm key is derived from the master secret 232 via: 234 Enc-K ::= PRF( master_secret, "encryption", 1 ); 236 3. The data is processed as described in [AuthEnv], and specifically 237 since the mechanisms used are a union of EncryptedData and 238 AuthenticatedData, as per [CMS]. The one exception to this is 239 that the 240 EncryptedContentInfo.ContentEncryptionAlgorithmIdentifier data is 241 MACed before the encrypted content is MAced. The EncryptedData 242 processing is applied to the data first and then the 243 AuthenticatedData processing is applied to the result, so that 244 the nesting is: 246 MAC( contentEncrAlgoID || encrypt( content ) ); 248 4. If authenticated attributes are present then they are encoded as 249 described in [AuthEnv] and MACed after the encrypted content, so 250 that the processing is: 252 MAC( contentEncrAlgoID || encrypt( content ) || authAttr ); 254 4.2. Rationale 256 When choosing between encrypt-and-authenticate and authenticate-and- 257 encrypt the more secure option is encrypt-and-authenticate. There 258 has been extensive analysis of this in the literature, the best 259 coverage is probably [EncryptThenAuth]. 261 The EncryptedContentInfo.ContentEncryptionAlgorithmIdentifier is the 262 SEQUENCE containing the id-alg-authEnc-128/id-alg-authEnc-256 OBJECT 263 IDENTIFIER and its associated AuthEncParams. This data is MACed 264 exactly as encoded, without any attempt to re-code it into a 265 canonical form like DER. 267 The EncryptedContentInfo.ContentEncryptionAlgorithmIdentifier must be 268 protected alongside the encrypted content otherwise an attacker could 269 manipulate the encrypted data indirectly by manipulating the 270 encryption algorithm parameters, which wouldn't be detected through 271 MACing the encrypted content alone. For example by changing the 272 encryption IV it's possible to modify the results of the decryption 273 after the encrypted data has been verified via a MAC check. 275 The authEnc pseudo-algorithm has two "key sizes" rather than the one- 276 size-fits-all that the PRF impedance-matching would provide. This is 277 done to address real-world experience in the use of AES keys where 278 users demanded AES-256 alongside AES-128 because of some perception 279 that the former was "twice as good" as the latter. Providing an 280 option for keys that go to 11 avoids potential user acceptance 281 problems when someone notices that the authEnc pseudo-key has "only" 282 128 bits when they expect their AES keys to be 256 bits long. 284 Using a fixed-length key rather than making it a user-selectable 285 parameter is done for the same reason as AES' quantised key lengths: 286 there's no benefit to allowing, say, 137-bit keys over basic 128- and 287 256-bit lengths, it adds unnecessary complexity, and if the lengths 288 are user-defined then there'll always be someone who wants keys that 289 go up to 12. Providing a choice of two commonly-used lengths gives 290 users the option of choosing a "better" key size should they feel the 291 need, while not overloading the system with unneeded flexibility. 293 The use of the PRF AlgorithmIdentifier presents some problems because 294 it's usually not specified in a manner that allows it to be easily 295 used as a straight KDF. For example PBKDF2 has parameters: 297 PBKDF2-params ::= SEQUENCE { 298 salt OCTET STRING, 299 iterationCount INTEGER (1..MAX), 300 prf AlgorithmIdentifier {{PBKDF2-PRFs}} 301 DEFAULT algid-hmacWithSHA1 303 } 305 of which only the prf AlgorithmIdentifier is used here. In order to 306 avoid having to define new AlgorithmIdentifiers for each possible 307 PRF, this specification sets any parameters not required for KDF 308 functionality to no-op values. In the case of PBKDF2 this means that 309 the salt has length zero and the iteration count is set to one, with 310 only the prf AlgorithmIdentifier playing a part in the processing. 311 Although it's not possible to know what form other PRFs-as-KDFs will 312 take, a general note for their application within this specification 313 is that any non-PRF parameters should similarly be set to no-op 314 values. 316 Specifying a MAC key size gets a bit tricky, most MAC algorithms have 317 some de facto standard key size and for HMAC algorithms this is 318 usually the same as the hash output size. For example for HMAC-MD5 319 it's 128 bits, for HMAC-SHA1 it's 160 bits, and for HMAC-SHA256 it's 320 256 bits. Other MAC algorithms also have de facto standard key 321 sizes, for example for AES-based MACs it's the AES key size, 128 bits 322 for AES-128 and 256 bits for AES-256. This situation makes it 323 difficult to specify the key size in a normative fashion since it's 324 dependent on the algorithm type that's being used. If there is any 325 ambiguity over which key size should be used then it's RECOMMENDED 326 that either the size be specified explicitly in the macAlgorithm 327 AlgorithmIdentifier or that an RFC or similar standards document be 328 created that makes the key sizes explicit. 330 As with other uses of PRFs for cryto impedance matching in protocols 331 like IPsec, SSL/TLS and SSH, the amount of input to the PRF generally 332 doesn't match the amount of output. The general philosophical 333 implications of this are covered in various analyses of the 334 properties and uses of PRFs. If you're worried about this then you 335 can try and approximately match the authEnc "key size" to the key 336 size of the encryption algorithm being used, although even there a 337 perfect match for algorithms like Blowfish (448 bits) or RC5 (832 338 bits) is going to be difficult. 340 The term "master secret" comes from its use in SSL/TLS, which uses a 341 similar PRF-based mechanism to convert its master_secret value into 342 encryption and MAC keys (as do SSH and IPsec). The master_secret 343 value isn't a key in the conventional sense, but merely a secret 344 value that's then used to derive two (or, in the cases of SSL/TLS, 345 SSH, and IPsec, several) keys and related cryptovariables. 347 Apart from the extra step added to key management, all of the 348 processing is already specified as part of the definition of the 349 standard CMS content-types Encrypted/EnvelopedData and 350 AuthenticatedData. This significantly simplifies both the 351 specification and the implementation task, as no new content- 352 processing mechanisms are introduced. 354 4.3. Test Vectors 356 The following test vectors may be used to verify an implementation of 357 MAC-authenticated encryption. This represents a text string 358 encrypted and authenticated using the ever-popular password 359 "password" via CMS PasswordRecipientInfo. The encryption algorithm 360 used for the first value is triple DES, whose short block size 361 (compared to AES) makes it easier to corrupt arbitrary bytes for 362 testing purposes within the self-healing CBC mode which will result 363 in correct decryption but a failed MAC check, and for the second 364 value is AES. 366 For the triple DES-encrypted data, corrupting the a byte at positions 367 192-208 can be used to check that payload-data corruption is 368 detected, and corrupting a byte at positions 168-174 can be used to 369 check that metadata corruption is detected. The corruption in these 370 byte ranges doesn't affect normal processing, so wouldn't normally be 371 detected. 373 The test data has the following characteristics: 375 version is set to 0. 376 originatorInfo isn't needed and is omitted. 377 recipientInfos uses passwordRecipientInfo to allow easy testing 378 with a fixed text string. 379 authEncryptedContentInfo uses the authEnc128 pseudo-algorithm with 380 a key of 128 bits used to derive triple DES/AES and HMAC-SHA1 381 keys. 382 authAttrs aren't used and are omitted. 383 mac is the 20-byte HMAC-SHA1 MAC value. 384 unauthAttrs aren't used and are omitted. 386 0 227: SEQUENCE { 387 3 11: OBJECT IDENTIFIER authEnvelopedData 388 (1 2 840 113549 1 9 16 1 23) 389 16 211: [0] { 390 19 208: SEQUENCE { 391 22 1: INTEGER 0 392 25 97: SET { 393 27 95: [3] { 394 29 1: INTEGER 0 395 32 27: [0] { 396 34 9: OBJECT IDENTIFIER pkcs5PBKDF2 397 (1 2 840 113549 1 5 12) 399 45 14: SEQUENCE { 400 47 8: OCTET STRING B7 EB 23 A7 6B D2 05 16 401 57 2: INTEGER 5000 402 : } 403 : } 404 61 35: SEQUENCE { 405 63 11: OBJECT IDENTIFIER pwriKEK 406 (1 2 840 113549 1 9 16 3 9) 407 76 20: SEQUENCE { 408 78 8: OBJECT IDENTIFIER des-EDE3-CBC 409 (1 2 840 113549 3 7) 410 88 8: OCTET STRING 66 91 02 45 6B 73 BB 99 411 : } 412 : } 413 98 24: OCTET STRING 414 : 30 A3 7A B5 D8 F2 87 50 EC 41 04 AE 89 99 26 F0 415 : 2E AE 4F E3 F3 52 2B A3 416 : } 417 : } 418 124 82: SEQUENCE { 419 126 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 420 137 51: SEQUENCE { 421 139 11: OBJECT IDENTIFIER authEnc128 422 (1 2 840 113549 1 9 16 3 15) 423 152 36: SEQUENCE { 424 154 20: SEQUENCE { 425 156 8: OBJECT IDENTIFIER des-EDE3-CBC 426 (1 2 840 113549 3 7) 427 166 8: OCTET STRING D2 D0 81 71 4D 3D 9F 11 428 : } 429 176 12: SEQUENCE { 430 178 8: OBJECT IDENTIFIER hmacSHA (1 3 6 1 5 5 8 1 2) 431 188 0: NULL 432 : } 433 : } 434 : } 435 190 16: [0] 3A C6 06 61 41 5D 00 7D 11 35 CD 69 E1 56 CA 10 436 : } 437 208 20: OCTET STRING 438 : 33 65 E8 F0 F3 07 06 86 1D A8 47 2C 6D 3A 1D 94 439 : 21 40 64 7E 440 : } 441 : } 442 : } 444 -----BEGIN PKCS7----- 445 MIHjBgsqhkiG9w0BCRABF6CB0zCB0AIBADFho18CAQCgGwYJKoZIhvcNAQUMMA4ECLfrI6dr 446 0gUWAgITiDAjBgsqhkiG9w0BCRADCTAUBggqhkiG9w0DBwQIZpECRWtzu5kEGDCjerXY8odQ 447 7EEEromZJvAurk/j81IrozBSBgkqhkiG9w0BBwEwMwYLKoZIhvcNAQkQAw8wJDAUBggqhkiG 448 9w0DBwQI0tCBcU09nxEwDAYIKwYBBQUIAQIFAIAQOsYGYUFdAH0RNc1p4VbKEAQUM2Xo8PMH 449 BoYdqEcsbTodlCFAZH4= 450 -----END PKCS7----- 452 0 253: SEQUENCE { 453 3 11: OBJECT IDENTIFIER authEnvelopedData 454 (1 2 840 113549 1 9 16 1 23) 455 16 237: [0] { 456 19 234: SEQUENCE { 457 22 1: INTEGER 0 458 25 114: SET { 459 27 112: [3] { 460 29 1: INTEGER 0 461 32 27: [0] { 462 34 9: OBJECT IDENTIFIER pkcs5PBKDF2 463 (1 2 840 113549 1 5 12) 464 45 14: SEQUENCE { 465 47 8: OCTET STRING E7 B7 87 DF 82 1D 12 CC 466 57 2: INTEGER 5000 467 : } 468 : } 469 61 44: SEQUENCE { 470 63 11: OBJECT IDENTIFIER pwriKEK 471 (1 2 840 113549 1 9 16 3 9) 472 76 29: SEQUENCE { 473 78 9: OBJECT IDENTIFIER aes128-CBC 474 (2 16 840 1 101 3 4 1 2) 475 89 16: OCTET STRING 476 : 11 D9 5C 52 0A 3A BF 22 B2 30 70 EF F4 7D 6E F6 477 : } 478 : } 479 107 32: OCTET STRING 480 : 18 39 22 27 C3 C2 2C 2A A6 9F 2A B0 77 24 75 AA 481 : D8 58 9C CD BB 4C AE D3 0D C2 CB 1D 83 94 6C 37 482 : } 483 : } 484 141 91: SEQUENCE { 485 143 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 486 154 60: SEQUENCE { 487 156 11: OBJECT IDENTIFIER authEnc128 488 (1 2 840 113549 1 9 16 3 15) 489 169 45: SEQUENCE { 490 171 29: SEQUENCE { 491 173 9: OBJECT IDENTIFIER aes128-CBC 492 (2 16 840 1 101 3 4 1 2) 493 184 16: OCTET STRING 494 : B7 25 02 76 84 3C 58 1B A5 30 E2 40 27 EE C3 06 495 : } 496 202 12: SEQUENCE { 497 204 8: OBJECT IDENTIFIER hmacSHA (1 3 6 1 5 5 8 1 2) 498 214 0: NULL 499 : } 500 : } 501 : } 502 216 16: [0] 98 36 0F 0C 79 62 36 B5 2D 2D 9E 1C 62 85 1E 10 503 : } 504 234 20: OCTET STRING 505 : 88 A4 C1 B2 BA 78 1B CA F9 14 B0 E5 FC D1 8D F8 506 : 02 E2 B2 9E 507 : } 508 : } 509 : } 511 -----BEGIN PKCS7----- 512 MIH9BgsqhkiG9w0BCRABF6CB7TCB6gIBADFyo3ACAQCgGwYJKoZIhvcNAQUMMA4ECOe3h9+C 513 HRLMAgITiDAsBgsqhkiG9w0BCRADCTAdBglghkgBZQMEAQIEEBHZXFIKOr8isjBw7/R9bvYE 514 IBg5IifDwiwqpp8qsHckdarYWJzNu0yu0w3Cyx2DlGw3MFsGCSqGSIb3DQEHATA8BgsqhkiG 515 9w0BCRADDzAtMB0GCWCGSAFlAwQBAgQQtyUCdoQ8WBulMOJAJ+7DBjAMBggrBgEFBQgBAgUA 516 gBCYNg8MeWI2tS0tnhxihR4QBBSIpMGyungbyvkUsOX80Y34AuKyng== 517 -----END PKCS7----- 518 5. SMIMECapabilities Attribute 520 An S/MIME client SHOULD announce the set of cryptographic functions 521 that it supports by using the S/MIME capabilities attribute [SMIME]. 522 If the client wishes to indicate support for MAC-authenticated 523 encryption, the capabilities attribute MUST contain the authEnc128 524 and/or authEnc256 OID specified above with algorithm parameters 525 ABSENT. The other algorithms used in the authEnc algorithm such as 526 the MAC and encryption algorithm are selected based on the presence 527 of these algorithms in the SMIMECapabilities or by mutual agreement. 529 6. Security Considerations 531 Unlike other CMS authenticated-data mechanisms like SignedData and 532 AuthenticatedData, AuthEnv's primary transformation isn't 533 authentication but encryption, so that AuthEnvData may decrypt 534 successfully (in other words the primary data transformation present 535 in the mechanism will succeed) but the secondary function of 536 authentication using the MAC value that follows the encrypted data 537 could still fail. This can lead to a situation in which an 538 implementation might output decrypted data before it reaches and 539 verifies the MAC value. In other words decryption is performed 540 inline and the result is available immediately, while the 541 authentication result isn't available until all of the content has 542 been processed. If the implementation prematurely provides data to 543 the user and later comes back to inform them that the earlier data 544 was, in retrospect, tainted, this may cause users to act prematurely 545 on the tainted data. 547 This situation could occur in a streaming implementation where data 548 has to be made available as soon as possible (so that the initial 549 plaintext is emitted before the final ciphertext and MAC value are 550 read), or one where the quantity of data involved rules out buffering 551 the recovered plaintext until the MAC value can be read and verified. 552 In addition an implementation that tries to be overly helpful may 553 treat missing non-payload trailing data as non-fatal, allowing an 554 attacker to truncate the data somewhere before the MAC value and 555 thereby defeat the data authentication. This is complicated even 556 further by the fact that an implementation may not be able to 557 determine, when it encounters truncated data, whether the remainder 558 (including the MAC value) will arrive presently (a non-failure) or 559 whether it's been truncated by an attacker and should therefore be 560 treated as a MAC failure. (Note that this same issue affects other 561 types of data authentication like signed and MACd data as well, since 562 an over-optimistic implementation may return data to the user before 563 checking for a verification failure is possible). 565 The exact solution to these issues is somewhat implementation- 566 specific, with some suggested mitigations being as follows: 567 Implementations should buffer the entire message if possible and 568 verify the MAC before performing any decryption. If this isn't 569 possible due to streaming or message-size constraints then 570 implementations should consider breaking long messages into a 571 sequence of smaller ones, each of which can be processed atomically 572 as above. If even this isn't possible then implementations should 573 make obvious to the caller or user that an authentication failure has 574 occurred and that the previously-returned or output data shouldn't be 575 used. Finally, any data-formatting problem such as obviously 576 truncated data or missing trailing data should be treated as a MAC 577 verification failure even if the rest of the data was processed 578 correctly. 580 7. IANA Considerations 582 This document contains two algorithm identifiers defined by the SMIME 583 Working Group Registrar in an arc delegated by RSA to the SMIME 584 Working Group: iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 585 pkcs-9(9) smime(16) modules(0). No action by IANA is necessary for 586 this document or any anticipated updates. 588 8. Acknowledgements 590 The author would like to thank Jim Schaad and the members of the 591 S/MIME mailing list for their feedback on this document and David 592 Ireland for help with the test vectors. 594 9. References 596 9.1. Normative References 598 [AuthEnv] Housley, R., "Cryptographic Message Syntax (CMS) 599 Authenticated-Enveloped-Data Content Type", RFC 5083, 600 November 2007. 602 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 603 RFC 5652, September 2009. 605 [PBKDF2] Kaliski, B., "PKCS #5: Password-Based Cryptography 606 Specification", RFC 2898, September 2000. 608 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 609 Requirement Levels", BCP 14, RFC 2119, March 1997. 611 [SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 612 Mail Extensions (S/MIME) Version 3.2 Message 613 Specification", RFC 5751, January 2010. 615 9.2. Informative References 617 [EncryptThenAuth] 618 Krawczyk, H., "The Order of Encryption and Authentication 619 for Protecting Communications (or: How Secure Is SSL?)", 620 Springer-Verlag LNCS 2139, August 2001. 622 [Garfinkel] 623 Garfinkel, S., "Design Principles and Patterns for 624 Computer Systems That Are Simultaneously Secure and 625 Usable", May 2005. 627 [HKDF] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 628 Key Derivation Function (HKDF)", RFC 5869, May 2010. 630 [IPsec] Kent, S. and K. Seo, "Security Architecture for the 631 Internet Protocol", RFC 4301, December 2005. 633 [OpenPGP] Callas, J., Donnerhacke, L., Hal, H., Shaw, D., and R. 634 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 636 [SSH] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 637 Transport Layer Protocol", RFC 4253, January 2006. 639 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 640 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 642 Author's Address 644 Peter Gutmann 645 University of Auckland 646 Department of Computer Science 647 New Zealand 649 Email: pgut001@cs.auckland.ac.nz