[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 6476

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

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   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


   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

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

1.1.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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 )


        KEK( master_secret ) || HMAC( encrypt( data ) )

   where the HMAC and encryption keys are derived from the master_secret

        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

   The authEnc pseudo-algorithm comes in two forms, one providing 128
   bits of keying material and one providing 256 bits:

        authEnc128 ::= OBJECT IDENTIFIER <TBD>
        authEnc256 ::= OBJECT IDENTIFIER <TBD>

   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
      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, 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

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

   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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Gutmann                   Expires June 12, 2008                [Page 13]

Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/