S/MIME Working Group P. Gutmann Internet-Draft University of Auckland Intended status: Standards Track December 10, 2007 Expires: June 12, 2008 Using HMAC-authenticated Encryption in the Cryptographic Message Syntax (CMS) draft-gutmann-cms-hmac-enc-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 12, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Gutmann Expires June 12, 2008 [Page 1] Internet-Draft HMAC-Enc-in-CMS December 2007 Abstract This document specifies the conventions for using HMAC-authenticated encryption with the Cryptographic Message Syntax (CMS) authenticated- enveloped-data content type. This mirrors the use of HMAC 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. CMS Encrypt-and-Authenticate Overview . . . . . . . . . . . . 5 3.1. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 5 4. CMS Encrypt-and-Authenticate . . . . . . . . . . . . . . . . . 6 4.1. Encrypt-and-Authenticate Message Processing . . . . . . . 6 4.2. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. Test Vectors . . . . . . . . . . . . . . . . . . . . . . . 7 5. SMIMECapabilities Attribute . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Gutmann Expires June 12, 2008 [Page 2] Internet-Draft HMAC-Enc-in-CMS December 2007 1. Introduction This document specifies the conventions for using HMAC-authenticated encryption with the Cryptographic Message Syntax (CMS) authenticated- enveloped-data content type. This mirrors the use of HMAC 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]. Gutmann Expires June 12, 2008 [Page 3] Internet-Draft HMAC-Enc-in-CMS December 2007 2. Background Integrity-protected encryption is a standard feature of session- oriented security protocols like IPsec [IPsec], SSH [SSH], and SSL/ TLS [TLS], but until recently wasn't available for message-based security protocols like CMS, although PGP added a form of integrity protection by encrypting a SHA-1 hash of the message alongside the message contents to provide authenticate-then-encrypt protection [OpenPGP]. 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. This document applies the same encrypt-then-authenticate mechanism already employed in IPsec, SSH, and SSL/TLS, to CMS. This mechanism is widely supported in existing crypto libraries and hardware, and has been extensively analysed by the crypto community. Gutmann Expires June 12, 2008 [Page 4] Internet-Draft HMAC-Enc-in-CMS December 2007 3. CMS Encrypt-and-Authenticate Overview Conventional CMS encryption uses a content encryption key (CEK) to encrypt a message payload. 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 ) || HMAC( encrypt( data ) ) where the HMAC and encryption keys are derived from the master_secret via: HMAC-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 HMAC key) can be converted back to unauthenticated data by removing the outer HMAC 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. 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. Finally, 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. Gutmann Expires June 12, 2008 [Page 5] Internet-Draft HMAC-Enc-in-CMS December 2007 4. CMS Encrypt-and-Authenticate The encrypt-and-authenticate mechanism is implemented with the existing CMS RecipientInfo framework by defining a new pseudo- algorithm type authEnc which is used in place of the existing single- purpose encrypt-only or HMAC-only algorithm. This pseudo-algorithm is used as a key container for the master secret from which the encryption and authentication keys are derived. Thus instead of using the RecipientInfo to communicate (for example) an AES or HMAC- SHA1 key, it communicates an authEnc keying value from which the required AES encryption and HMAC-SHA1 authentication keys are derived. The authEnc pseudo-algorithm comes in two forms, one providing 128 bits of keying material and one providing 256 bits: authEnc128 ::= OBJECT IDENTIFIER authEnc256 ::= OBJECT IDENTIFIER The algorithm parameters are: AuthEncParams ::= SEQUENCE { prfAlgo [0] AlgorithmIdentifier DEFAULT PBKDF2, encAlgo AlgorithmIdentifier, hmacAlgo AlgorithmIdentifier } prfAlgo is the PRF algorithm used to convert the authEnc value into the encryption and MAC keys. The default PRF is PBKDF2 [PBKDF2]. encAlgo is the encryption algorithm and associated parameters to be used to encrypt the content. hmacAlgo is the HMAC algorithm and associated parameters to be used to authenticate/integrity-protect the content. 4.1. Encrypt-and-Authenticate Message Processing The randomly-generated authEnc key 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: 1. The HMAC algorithm key is derived from the authEnc key via: HMAC-K ::= PRF( authEnc_key, "authentication", 1 ); Gutmann Expires June 12, 2008 [Page 6] Internet-Draft HMAC-Enc-in-CMS December 2007 2. The encryption algorithm key is derived from the authEnc key via: Enc-K ::= PRF( authEnc_key, "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 EncryptedData processing is applied first, and then the AuthenticatedData processing is applied to the result, so that the nesting is: HMAC( encrypt( content ) ); 4.2. Rationale 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 from 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' quantised key lengths: there's no benefit to allowing, say, 137-bit keys over basic 128- and 256-bit lengths, it adds unnecessary complexity, and if the lengths are user-defined 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. 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 HMAC-authenticated encryption. [Test vectors to be added] Gutmann Expires June 12, 2008 [Page 7] Internet-Draft HMAC-Enc-in-CMS December 2007 5. SMIMECapabilities Attribute An S/MIME client SHOULD announce the set of cryptographic functions that it supports by using the S/MIME capabilities attribute [SMIME]. If the client wishes to indicate support for HMAC-authenticated encryption, the capabilities attribute MUST contain the authEnc128 and/or authEnc256 OID specified above with algorithm parameters of NULL. Other parameters such as the HMAC and encryption algorithms are specified in the standard manner, for example through their own SMIMECapabilities attributes or by mutual agreement. Gutmann Expires June 12, 2008 [Page 8] Internet-Draft HMAC-Enc-in-CMS December 2007 6. Security Considerations Depending on the overall data size and the internal buffering processes of a particular implementation, it's likely that processed content data will be available some time before the HMAC tag for the data is verified. In other words decryption is performed inline and the result is available immediately, while the 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. Implementors should balance the tradeoff between making data available as quickly as possible and delaying release until the authentication check has completed. Gutmann Expires June 12, 2008 [Page 9] Internet-Draft HMAC-Enc-in-CMS December 2007 7. IANA Considerations (Need to assign OIDs for authEnc, but this will be done by S/MIME rather than IANA). Gutmann Expires June 12, 2008 [Page 10] Internet-Draft HMAC-Enc-in-CMS December 2007 8. References 8.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)", RFC 3852, July 2004. [PBKDF2] Kaliski, B., "PKCS #5: Password-Based Cryptography Specification", 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., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. 8.2. Informative References [Garfinkel] Garfinkel, S., "Design Principles and Patterns for Computer Systems That Are Simultaneously Secure and Usable", May 2005. [IPsec] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [OpenPGP] Callas, J., Donnerhacke, L., Hal, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007. [SSH] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, Janaury 2006. [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol", RFC 4346, April 2006. Gutmann Expires June 12, 2008 [Page 11] Internet-Draft HMAC-Enc-in-CMS December 2007 Author's Address Peter Gutmann University of Auckland Department of Computer Science New Zealand Email: pgut001@cs.auckland.ac.nz Gutmann Expires June 12, 2008 [Page 12] Internet-Draft HMAC-Enc-in-CMS December 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Gutmann Expires June 12, 2008 [Page 13]