From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6476.txt | 843 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 843 insertions(+) create mode 100644 doc/rfc/rfc6476.txt (limited to 'doc/rfc/rfc6476.txt') diff --git a/doc/rfc/rfc6476.txt b/doc/rfc/rfc6476.txt new file mode 100644 index 0000000..32d7060 --- /dev/null +++ b/doc/rfc/rfc6476.txt @@ -0,0 +1,843 @@ + + + + + + +Internet Engineering Task Force (IETF) P. Gutmann +Request for Comments: 6476 University of Auckland +Category: Standards Track January 2012 +ISSN: 2070-1721 + + + Using Message Authentication Code (MAC) Encryption + in the Cryptographic Message Syntax (CMS) + +Abstract + + This document specifies the conventions for using Message + Authentication Code (MAC) encryption with the Cryptographic Message + Syntax (CMS) authenticated-enveloped-data content type. This mirrors + the use of a MAC combined with an encryption algorithm that's already + employed in IPsec, Secure Socket Layer / Transport Layer Security + (SSL/TLS) and Secure SHell (SSH), which is widely supported in + existing crypto libraries and hardware and has been extensively + analysed by the crypto community. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6476. + +Copyright Notice + + Copyright (c) 2012 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + +Gutmann Standards Track [Page 1] + +RFC 6476 MAC Encryption in CMS January 2012 + + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Conventions Used in This Document ..........................2 + 2. Background ......................................................2 + 3. CMS Encrypt-and-Authenticate Overview ...........................3 + 3.1. Rationale ..................................................3 + 4. CMS Encrypt-and-Authenticate ....................................4 + 4.1. Encrypt-and-Authenticate Message Processing ................5 + 4.2. Rationale ..................................................6 + 4.3. Test Vectors ...............................................8 + 5. SMIMECapabilities Attribute ....................................12 + 6. Security Considerations ........................................12 + 7. IANA Considerations ............................................13 + 8. Acknowledgements ...............................................14 + 9. References .....................................................14 + 9.1. Normative References ......................................14 + 9.2. Informative References ....................................14 + +1. Introduction + + This document specifies the conventions for using MAC-authenticated + encryption with the Cryptographic Message Syntax (CMS) authenticated- + enveloped-data content type. This mirrors the use of a MAC combined + with an encryption algorithm that's already employed in IPsec, SSL/ + TLS and SSH, which is widely supported in existing crypto libraries + and hardware and has been extensively analysed by the crypto + community. + +1.1. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +2. Background + + Integrity-protected encryption is a standard feature of session- + oriented security protocols like [IPsec], [SSH], and [TLS]. Until + recently, however, integrity-protected encryption wasn't available + for message-based security protocols like CMS, although [OpenPGP] + added a form of integrity protection by encrypting a SHA-1 hash of + the message alongside the message contents to provide authenticate- + and-encrypt protection. Usability studies have shown that users + expect encryption to provide integrity protection [Garfinkel], + creating cognitive dissonance problems when the security mechanisms + don't in fact provide this assurance. + + + + +Gutmann Standards Track [Page 2] + +RFC 6476 MAC Encryption in CMS January 2012 + + + This document applies the same encrypt-and-authenticate mechanism + already employed in IPsec, SSH, and SSL/TLS to CMS (technically some + of these actually use authenticate-and-encrypt rather than encrypt- + and-authenticate, since what's authenticated is the plaintext and not + the ciphertext). This mechanism is widely supported in existing + crypto libraries and hardware and has been extensively analysed by + the crypto community [EncryptThenAuth]. + +3. CMS Encrypt-and-Authenticate Overview + + Conventional CMS encryption uses a content-encryption key (CEK) to + encrypt a message payload, with the CEK typically being in turn + encrypted by a key-encryption key (KEK). Authenticated encryption + requires two keys: one for encryption and a second one for + authentication. Like other mechanisms that use authenticated + encryption, this document employs a pseudorandom function (PRF) to + convert a single block of keying material into the two keys required + for encryption and authentication. This converts the standard CMS + encryption operation: + + KEK( CEK ) || CEK( data ) + + into: + + KEK( master_secret ) || MAC( CEK( data ) ) + + where the MAC key MAC-K and encryption key CEK-K are derived from the + master_secret via: + + MAC-K := PRF( master_secret, "authentication" ); + CEK-K := PRF( master_secret, "encryption" ); + +3.1. Rationale + + There are several possible means of deriving the two keys required + for the encrypt-and-authenticate process from the single key normally + provided by the key exchange or key transport mechanisms. Several of + these, however, have security or practical issues. For example, any + mechanism that uses the single exchanged key in its entirety for + encryption (using, perhaps, PRF( key ) as the MAC key) can be + converted back to unauthenticated data by removing the outer MAC + layer and rewriting the CMS envelope back to plain EnvelopedData or + EncryptedData. By applying the PRF intermediate step, any attempt at + a rollback attack will result in a decryption failure. + + + + + + + +Gutmann Standards Track [Page 3] + +RFC 6476 MAC Encryption in CMS January 2012 + + + The option chosen here -- the use of a PRF to derive the necessary + sets of keying material from a master secret -- is well-established + through its use in IPsec, SSH, and SSL/TLS and is widely supported in + both crypto libraries and in encryption hardware. + + The PRF used is Password-Based Key Derivation Function 2 (PBKDF2) + because its existing use in CMS makes it the most obvious candidate + for such a function. In the future, if a universal PRF -- for + example, [HKDF] -- is adopted, then this can be substituted for + PBKDF2 by specifying it in the prfAlgorithm field covered in + Section 4. + + The resulting processing operations consist of a combination of the + operations used for the existing CMS content types EncryptedData and + AuthenticatedData, allowing them to be implemented relatively simply + using existing code. + +4. CMS Encrypt-and-Authenticate + + The encrypt-and-authenticate mechanism is implemented within the + existing CMS RecipientInfo framework by defining a new pseudo- + algorithm type, authEnc, which is used in place of a monolithic + encrypt and hash algorithm. The RecipientInfo is used as a key + container for the master secret used by the pseudo-algorithm from + which the encryption and authentication keys for existing single- + purpose encrypt-only and MAC-only algorithms are derived. Thus, + instead of using the RecipientInfo to communicate (for example) an + AES or HMAC-SHA1 key, it communicates a master secret from which the + required AES encryption and HMAC-SHA1 authentication keys are + derived. + + The authEnc pseudo-algorithm comes in two forms: one conveying + 128 bits of keying material and one conveying 256 bits: + + id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) + us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 } + + id-alg OBJECT IDENTIFIER ::= { id-smime 3 } + + id-alg-authEnc-128 OBJECT IDENTIFIER ::= { id-alg 15 } + id-alg-authEnc-256 OBJECT IDENTIFIER ::= { id-alg 16 } + + + + + + + + + + +Gutmann Standards Track [Page 4] + +RFC 6476 MAC Encryption in CMS January 2012 + + + The algorithm parameters are as follows: + + AuthEncParams ::= SEQUENCE { + prfAlgorithm [0] AlgorithmIdentifier DEFAULT PBKDF2, + encAlgorithm AlgorithmIdentifier, + macAlgorithm AlgorithmIdentifier + } + + prfAlgorithm is the PRF algorithm used to convert the master + secret into the encryption and MAC keys. The default PRF is + [PBKDF2], which in turn has a default PRF algorithm of HMAC-SHA1. + When this default setting is used, the PBKDF2-params 'salt' + parameter is an empty string, and the 'iterationCount' parameter + is one, turning the KDF into a pure PRF. + + encAlgorithm is the encryption algorithm and associated parameters + to be used to encrypt the content. + + macAlgorithm is the MAC algorithm and associated parameters to be + used to authenticate/integrity-protect the content. + + When the prfAlgorithm AlgorithmIdentifier is used in conjunction with + PBKDF2 to specify a PRF other than the default PBKDF2-with-HMAC-SHA1 + one, the PBKDF2-params require that two additional algorithm + parameters be specified. The 'salt' parameter MUST be an empty + (zero-length) string, and the 'iterationCount' parameter MUST be one, + since these values aren't used in the PRF process. In their encoded + form as used for the PBKDF2-params, these two parameters have the + value 08 00 02 01 01. + + As a guideline for authors specifying the use of PRFs other than + PBKDF2, any additional parameters such as salts, tags, and + identification strings SHOULD be set to empty strings, and any + iteration count SHOULD be set to one. + +4.1. Encrypt-and-Authenticate Message Processing + + The randomly generated master secret to be communicated via the + RecipientInfo(s) is converted to separate encryption and + authentication keys and applied to the encrypt-and-authenticate + process as follows. The notation "PRF( key, salt, iterations )" is + used to denote an application of the PRF to the given keying value + and salt, for the given number of iterations: + + + + + + + + +Gutmann Standards Track [Page 5] + +RFC 6476 MAC Encryption in CMS January 2012 + + + 1. The MAC algorithm key is derived from the master secret via: + + MAC-K ::= PRF( master_secret, "authentication", 1 ); + + 2. The encryption algorithm key is derived from the master + secret via: + + Enc-K ::= PRF( master_secret, "encryption", 1 ); + + 3. The data is processed as described in [AuthEnv], and specifically + since the mechanisms used are a union of EncryptedData + and AuthenticatedData, as per [CMS]. The one exception to + this is that the + EncryptedContentInfo.ContentEncryptionAlgorithmIdentifier data is + MACed before the encrypted content is MACed. The EncryptedData + processing is applied to the data first, and then the + AuthenticatedData processing is applied to the result, so that + the nesting is as follows: + + MAC( contentEncrAlgoID || encrypt( content ) ); + + 4. If authenticated attributes are present, then they are encoded as + described in [AuthEnv] and MACed after the encrypted content, so + that the processing is as follows: + + MAC( contentEncrAlgoID || encrypt( content ) || authAttr ); + +4.2. Rationale + + When choosing between encrypt-and-authenticate and authenticate-and- + encrypt, the more secure option is encrypt-and-authenticate. There + has been extensive analysis of this in the literature; the best + coverage is probably [EncryptThenAuth]. + + The EncryptedContentInfo.ContentEncryptionAlgorithmIdentifier is the + SEQUENCE containing the id-alg-authEnc-128/id-alg-authEnc-256 OBJECT + IDENTIFIER and its associated AuthEncParams. This data is MACed + exactly as encoded, without any attempt to re-code it into a + canonical form like DER. + + The EncryptedContentInfo.ContentEncryptionAlgorithmIdentifier must be + protected alongside the encrypted content; otherwise, an attacker + could manipulate the encrypted data indirectly by manipulating the + encryption algorithm parameters, which wouldn't be detected through + MACing the encrypted content alone. For example, by changing the + encryption IV, it's possible to modify the results of the decryption + after the encrypted data has been verified via a MAC check. + + + + +Gutmann Standards Track [Page 6] + +RFC 6476 MAC Encryption in CMS January 2012 + + + The authEnc pseudo-algorithm has two "key sizes" rather than the one- + size-fits-all that the PRF impedance-matching would provide. This is + done to address real-world experience in the use of AES keys, where + users demanded AES-256 alongside AES-128 because of some perception + that the former was "twice as good" as the latter. Providing an + option for keys that go to 11 avoids potential user acceptance + problems when someone notices that the authEnc pseudo-key has "only" + 128 bits when they expect their AES keys to be 256 bits long. + + Using a fixed-length key rather than making it a user-selectable + parameter is done for the same reason as AES's quantised key lengths: + there's no benefit to allowing, say, 137-bit keys over basic 128- and + 256-bit lengths; it adds unnecessary complexity; if the lengths are + user-defined, then there'll always be someone who wants keys that go + up to 12. Providing a choice of two commonly used lengths gives + users the option of choosing a "better" key size should they feel the + need, while not overloading the system with unneeded flexibility. + + The use of the PRF AlgorithmIdentifier presents some problems, + because it's usually not specified in a manner that allows it to be + easily used as a straight KDF. For example, PBKDF2 has the following + parameters: + + PBKDF2-params ::= SEQUENCE { + salt OCTET STRING, + iterationCount INTEGER (1..MAX), + prf AlgorithmIdentifier {{PBKDF2-PRFs}} + DEFAULT algid-hmacWithSHA1 + } + + of which only the prf AlgorithmIdentifier is used here. In order to + avoid having to define new AlgorithmIdentifiers for each possible + PRF, this specification sets any parameters not required for KDF + functionality to no-op values. In the case of PBKDF2, this means + that the salt has length zero and the iteration count is set to one, + with only the prf AlgorithmIdentifier playing a part in the + processing. Although it's not possible to know what form other + PRFs-as-KDFs will take, a general note for their application within + this specification is that any non-PRF parameters should similarly be + set to no-op values. + + Specifying a MAC key size gets a bit tricky; most MAC algorithms have + some de facto standard key size, and for HMAC algorithms, this is + usually the same as the hash output size. For example, for HMAC-MD5, + it's 128 bits; for HMAC-SHA1, it's 160 bits; and for HMAC-SHA256, + it's 256 bits. Other MAC algorithms also have de facto standard key + sizes. For example, for AES-based MACs, it's the AES key size -- + 128 bits for AES-128 and 256 bits for AES-256. This situation makes + + + +Gutmann Standards Track [Page 7] + +RFC 6476 MAC Encryption in CMS January 2012 + + + it difficult to specify the key size in a normative fashion, since + it's dependent on the algorithm type that's being used. If there is + any ambiguity over which key size should be used, then it's + RECOMMENDED that either the size be specified explicitly in the + macAlgorithm AlgorithmIdentifier or that an RFC or similar standards + document be created that makes the key sizes explicit. + + As with other uses of PRFs for crypto impedance-matching in + protocols, like IPsec, SSL/TLS, and SSH, the amount of input to the + PRF generally doesn't match the amount of output. The general + philosophical implications of this are covered in various analyses of + the properties and uses of PRFs. If you're worried about this, then + you can try and approximately match the authEnc "key size" to the key + size of the encryption algorithm being used, although even there, a + perfect match for algorithms like Blowfish (448 bits) or RC5 + (832 bits) is going to be difficult. + + The term "master secret" comes from its use in SSL/TLS, which uses a + similar PRF-based mechanism to convert its master_secret value into + encryption and MAC keys (as do SSH and IPsec). The master_secret + value isn't a key in the conventional sense, but merely a secret + value that's then used to derive two (or, in the cases of SSL/TLS, + SSH, and IPsec, several) keys and related cryptovariables. + + Apart from the extra step added to key management, all of the + processing is already specified as part of the definition of the + standard CMS content-types Encrypted/EnvelopedData and + AuthenticatedData. This significantly simplifies both the + specification and the implementation task, as no new content- + processing mechanisms are introduced. + +4.3. Test Vectors + + The following test vectors may be used to verify an implementation of + MAC-authenticated encryption. This represents a text string + encrypted and authenticated using the ever-popular password + "password" via CMS PasswordRecipientInfo. The encryption algorithm + used for the first value is triple DES, whose short block size + (compared to AES) makes it easier to corrupt arbitrary bytes for + testing purposes within the self-healing Cipher Block Chaining (CBC) + mode, which will result in correct decryption but a failed MAC check. + The encryption algorithm used for the second value is AES. + + For the triple DES-encrypted data, corrupting a byte at positions + 192-208 can be used to check that payload-data corruption is + detected, and corrupting a byte at positions 168-174 can be used to + + + + + +Gutmann Standards Track [Page 8] + +RFC 6476 MAC Encryption in CMS January 2012 + + + check that metadata corruption is detected. The corruption in these + byte ranges doesn't affect normal processing and so wouldn't normally + be detected. + + The test data has the following characteristics: + + version is set to 0. + + originatorInfo isn't needed and is omitted. + + recipientInfo uses passwordRecipientInfo to allow easy testing + with a fixed text string. + + authEncryptedContentInfo uses the authEnc128 pseudo-algorithm + with a key of 128 bits used to derive triple DES/AES and + HMAC-SHA1 keys. + + authAttrs aren't used and are omitted. + + mac is the 20-byte HMAC-SHA1 MAC value. + + unauthAttrs aren't used and are omitted. + + 0 227: SEQUENCE { + 3 11: OBJECT IDENTIFIER id-ct-authEnvelopedData + (1 2 840 113549 1 9 16 1 23) + 16 211: [0] { + 19 208: SEQUENCE { + 22 1: INTEGER 0 + 25 97: SET { + 27 95: [3] { + 29 1: INTEGER 0 + 32 27: [0] { + 34 9: OBJECT IDENTIFIER pkcs5PBKDF2 + (1 2 840 113549 1 5 12) + 45 14: SEQUENCE { + 47 8: OCTET STRING B7 EB 23 A7 6B D2 05 16 + 57 2: INTEGER 5000 + : } + : } + 61 35: SEQUENCE { + 63 11: OBJECT IDENTIFIER pwriKEK + (1 2 840 113549 1 9 16 3 9) + + + + + + + + +Gutmann Standards Track [Page 9] + +RFC 6476 MAC Encryption in CMS January 2012 + + + 76 20: SEQUENCE { + 78 8: OBJECT IDENTIFIER des-EDE3-CBC + (1 2 840 113549 3 7) + 88 8: OCTET STRING 66 91 02 45 6B 73 BB 99 + : } + : } + 98 24: OCTET STRING + : 30 A3 7A B5 D8 F2 87 50 EC 41 04 AE 89 99 26 F0 + : 2E AE 4F E3 F3 52 2B A3 + : } + : } + 124 82: SEQUENCE { + 126 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) + 137 51: SEQUENCE { + 139 11: OBJECT IDENTIFIER authEnc128 + (1 2 840 113549 1 9 16 3 15) + 152 36: SEQUENCE { + 154 20: SEQUENCE { + 156 8: OBJECT IDENTIFIER des-EDE3-CBC + (1 2 840 113549 3 7) + 166 8: OCTET STRING D2 D0 81 71 4D 3D 9F 11 + : } + 176 12: SEQUENCE { + 178 8: OBJECT IDENTIFIER hmacSHA (1 3 6 1 5 5 8 1 2) + 188 0: NULL + : } + : } + : } + 190 16: [0] 3A C6 06 61 41 5D 00 7D 11 35 CD 69 E1 56 CA 10 + : } + 208 20: OCTET STRING + : 33 65 E8 F0 F3 07 06 86 1D A8 47 2C 6D 3A 1D 94 + : 21 40 64 7E + : } + : } + : } + + -----BEGIN PKCS7----- + MIHjBgsqhkiG9w0BCRABF6CB0zCB0AIBADFho18CAQCgGwYJKoZIhvcNAQUMMA4E + CLfrI6dr0gUWAgITiDAjBgsqhkiG9w0BCRADCTAUBggqhkiG9w0DBwQIZpECRWtz + u5kEGDCjerXY8odQ7EEEromZJvAurk/j81IrozBSBgkqhkiG9w0BBwEwMwYLKoZI + hvcNAQkQAw8wJDAUBggqhkiG9w0DBwQI0tCBcU09nxEwDAYIKwYBBQUIAQIFAIAQ + OsYGYUFdAH0RNc1p4VbKEAQUM2Xo8PMHBoYdqEcsbTodlCFAZH4= + -----END PKCS7----- + + + + + + + +Gutmann Standards Track [Page 10] + +RFC 6476 MAC Encryption in CMS January 2012 + + + 0 253: SEQUENCE { + 3 11: OBJECT IDENTIFIER id-ct-authEnvelopedData + (1 2 840 113549 1 9 16 1 23) + 16 237: [0] { + 19 234: SEQUENCE { + 22 1: INTEGER 0 + 25 114: SET { + 27 112: [3] { + 29 1: INTEGER 0 + 32 27: [0] { + 34 9: OBJECT IDENTIFIER pkcs5PBKDF2 + (1 2 840 113549 1 5 12) + 45 14: SEQUENCE { + 47 8: OCTET STRING E7 B7 87 DF 82 1D 12 CC + 57 2: INTEGER 5000 + : } + : } + 61 44: SEQUENCE { + 63 11: OBJECT IDENTIFIER pwriKEK + (1 2 840 113549 1 9 16 3 9) + 76 29: SEQUENCE { + 78 9: OBJECT IDENTIFIER aes128-CBC + (2 16 840 1 101 3 4 1 2) + 89 16: OCTET STRING + : 11 D9 5C 52 0A 3A BF 22 B2 30 70 EF F4 7D 6E F6 + : } + : } + 107 32: OCTET STRING + : 18 39 22 27 C3 C2 2C 2A A6 9F 2A B0 77 24 75 AA + : D8 58 9C CD BB 4C AE D3 0D C2 CB 1D 83 94 6C 37 + : } + : } + 141 91: SEQUENCE { + 143 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) + 154 60: SEQUENCE { + 156 11: OBJECT IDENTIFIER authEnc128 + (1 2 840 113549 1 9 16 3 15) + 169 45: SEQUENCE { + 171 29: SEQUENCE { + 173 9: OBJECT IDENTIFIER aes128-CBC + (2 16 840 1 101 3 4 1 2) + 184 16: OCTET STRING + : B7 25 02 76 84 3C 58 1B A5 30 E2 40 27 EE C3 06 + : } + + + + + + + +Gutmann Standards Track [Page 11] + +RFC 6476 MAC Encryption in CMS January 2012 + + + 202 12: SEQUENCE { + 204 8: OBJECT IDENTIFIER hmacSHA (1 3 6 1 5 5 8 1 2) + 214 0: NULL + : } + : } + : } + 216 16: [0] 98 36 0F 0C 79 62 36 B5 2D 2D 9E 1C 62 85 1E 10 + : } + 234 20: OCTET STRING + : 88 A4 C1 B2 BA 78 1B CA F9 14 B0 E5 FC D1 8D F8 + : 02 E2 B2 9E + : } + : } + : } + + -----BEGIN PKCS7----- + MIH9BgsqhkiG9w0BCRABF6CB7TCB6gIBADFyo3ACAQCgGwYJKoZIhvcNAQUMMA4E + COe3h9+CHRLMAgITiDAsBgsqhkiG9w0BCRADCTAdBglghkgBZQMEAQIEEBHZXFIK + Or8isjBw7/R9bvYEIBg5IifDwiwqpp8qsHckdarYWJzNu0yu0w3Cyx2DlGw3MFsG + CSqGSIb3DQEHATA8BgsqhkiG9w0BCRADDzAtMB0GCWCGSAFlAwQBAgQQtyUCdoQ8 + WBulMOJAJ+7DBjAMBggrBgEFBQgBAgUAgBCYNg8MeWI2tS0tnhxihR4QBBSIpMGy + ungbyvkUsOX80Y34AuKyng== + -----END PKCS7----- + +5. SMIMECapabilities Attribute + + An S/MIME client SHOULD announce the set of cryptographic functions + that it supports by using the SMIMECapabilities attribute [SMIME]. + If the client wishes to indicate support for MAC-authenticated + encryption, the capabilities attribute MUST contain the authEnc128 + and/or authEnc256 OID specified above with algorithm parameters + ABSENT. The other algorithms used in the authEnc algorithm, such as + the MAC and encryption algorithm, are selected based on the presence + of these algorithms in the SMIMECapabilities attribute or by mutual + agreement. + +6. Security Considerations + + Unlike other CMS authenticated-data mechanisms, such as SignedData + and AuthenticatedData, AuthEnv's primary transformation isn't + authentication but encryption; so AuthEnvData may decrypt + successfully (in other words, the primary data transformation present + in the mechanism will succeed), but the secondary function of + authentication using the MAC value that follows the encrypted data + could still fail. This can lead to a situation in which an + implementation might output decrypted data before it reaches and + verifies the MAC value. In other words, decryption is performed + inline and the result is available immediately, while the + + + +Gutmann Standards Track [Page 12] + +RFC 6476 MAC Encryption in CMS January 2012 + + + authentication result isn't available until all of the content has + been processed. If the implementation prematurely provides data to + the user and later comes back to inform them that the earlier data + was, in retrospect, tainted, this may cause users to act prematurely + on the tainted data. + + This situation could occur in a streaming implementation where data + has to be made available as soon as possible (so that the initial + plaintext is emitted before the final ciphertext and MAC value are + read), or one where the quantity of data involved rules out buffering + the recovered plaintext until the MAC value can be read and verified. + In addition, an implementation that tries to be overly helpful may + treat missing non-payload trailing data as non-fatal, allowing an + attacker to truncate the data somewhere before the MAC value and + thereby defeat the data authentication. This is complicated even + further by the fact that an implementation may not be able to + determine, when it encounters truncated data, whether the remainder + (including the MAC value) will arrive presently (a non-failure) or + whether it's been truncated by an attacker and should therefore be + treated as a MAC failure. (Note that this same issue affects other + types of data authentication like signed and MACed data as well, + since an over-optimistic implementation may return data to the user + before checking for a verification failure is possible.) + + The exact solution to these issues is somewhat implementation- + specific, with some suggested mitigations being as follows: + implementations should buffer the entire message if possible and + verify the MAC before performing any decryption. If this isn't + possible due to streaming or message-size constraints, then + implementations should consider breaking long messages into a + sequence of smaller ones, each of which can be processed atomically + as above. If even this isn't possible, then implementations should + make obvious to the caller or user that an authentication failure has + occurred and that the previously returned or output data shouldn't be + used. Finally, any data-formatting problem, such as obviously + truncated data or missing trailing data, should be treated as a MAC + verification failure even if the rest of the data was processed + correctly. + +7. IANA Considerations + + This document contains two algorithm identifiers defined by the + S/MIME Working Group Registrar in an arc delegated by RSA to the + S/MIME Working Group: iso(1) member-body(2) us(840) rsadsi(113549) + pkcs(1) pkcs-9(9) smime(16) modules(0). + + + + + + +Gutmann Standards Track [Page 13] + +RFC 6476 MAC Encryption in CMS January 2012 + + +8. Acknowledgements + + The author would like to thank Jim Schaad and the members of the + S/MIME mailing list for their feedback on this document, and David + Ireland for help with the test vectors. + +9. References + +9.1. Normative References + + [AuthEnv] Housley, R., "Cryptographic Message Syntax (CMS) + Authenticated-Enveloped-Data Content Type", RFC 5083, + November 2007. + + [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", + STD 70, RFC 5652, September 2009. + + [PBKDF2] Kaliski, B., "PKCS #5: Password-Based Cryptography + Specification Version 2", RFC 2898, September 2000. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [SMIME] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet + Mail Extensions (S/MIME) Version 3.2 Message + Specification", RFC 5751, January 2010. + +9.2. Informative References + + [EncryptThenAuth] + Krawczyk, H., "The Order of Encryption and Authentication + for Protecting Communications (or: How Secure Is SSL?)", + Springer-Verlag LNCS 2139, August 2001. + + [Garfinkel] Garfinkel, S., "Design Principles and Patterns for + Computer Systems That Are Simultaneously Secure and + Usable", May 2005. + + [HKDF] Krawczyk, H. and P. Eronen, "HMAC-based + Extract-and-Expand Key Derivation Function (HKDF)", + RFC 5869, May 2010. + + [IPsec] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + [OpenPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. + Thayer, "OpenPGP Message Format", RFC 4880, + November 2007. + + + +Gutmann Standards Track [Page 14] + +RFC 6476 MAC Encryption in CMS January 2012 + + + [SSH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) + Transport Layer Protocol", RFC 4253, January 2006. + + [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + +Author's Address + + Peter Gutmann + University of Auckland + Department of Computer Science + New Zealand + + EMail: pgut001@cs.auckland.ac.nz + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Gutmann Standards Track [Page 15] + -- cgit v1.2.3