S/MIME Working Group P. Gutmann
Internet-Draft University of Auckland
Intended status: Standards Track November 18, 2010
Expires: May 22, 2011
Using MAC-authenticated Encryption in the Cryptographic Message Syntax(CMS)draft-gutmann-cms-hmac-enc-02.txt
Abstract
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on May 22, 2011.
Copyright Notice
Copyright (c) 2010 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
Gutmann Expires May 22, 2011 [Page 1]

Internet-Draft MAC-Enc-in-CMS November 20101. 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].
Gutmann Expires May 22, 2011 [Page 3]

Internet-Draft MAC-Enc-in-CMS November 20102. Background
Integrity-protected encryption is a standard feature of session-
oriented security protocols like [IPsec], [SSH], and [TLS], but until
recently 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.
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].
Gutmann Expires May 22, 2011 [Page 4]

Internet-Draft MAC-Enc-in-CMS November 20103. 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 ) || MAC( CEK( data ) )
where the MAC and encryption keys 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.
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 PBKDF2 because its existing use in CMS makes it the
most obvious candidate for such a function. If in the future a
universal PRF, for example [HKDF], is adopted then this can be
substituted for PBKDF2 by specifying it in the prfAlgo 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
Gutmann Expires May 22, 2011 [Page 5]

Internet-Draft MAC-Enc-in-CMS November 20104. 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 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:
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 }
The algorithm parameters are:
AuthEncParams ::= SEQUENCE {
prfAlgo [0] AlgorithmIdentifier DEFAULT PBKDF2,
encAlgo AlgorithmIdentifier,
macAlgo 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.
macAlgo is the MAC algorithm and associated parameters to be used
to authenticate/integrity-protect the content.
When the PRF AlgorithmIdentifier is used to specify a non-default PRF
function, the salt parameter MUST be an empty (zero-length) string
and the iterationCount MUST be one, since these values aren't used in
the PRF process. In their encoded form, these two parameters have
the value 08 00 02 01 01.
Gutmann Expires May 22, 2011 [Page 7]

Internet-Draft MAC-Enc-in-CMS November 20104.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 MAC algorithm key is derived from the authEnc key via:
MAC-K ::= PRF( authEnc_key, "authentication", 1 );
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:
MAC( 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:
MAC( 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 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
Gutmann Expires May 22, 2011 [Page 8]

Internet-Draft MAC-Enc-in-CMS November 2010
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 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 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.
As with other uses of PRFs for cryto 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.
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.
Gutmann Expires May 22, 2011 [Page 9]

Internet-Draft MAC-Enc-in-CMS November 20105. 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 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 or by mutual agreement.
Gutmann Expires May 22, 2011 [Page 12]

Internet-Draft MAC-Enc-in-CMS November 20106. Security Considerations
Unlike other CMS authenticated-data mechanisms like SignedData and
AuthenticatedData, AuthEnv's primary transformation isn't
authentication but encryption, so that 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
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 MACd 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,
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 implementations should make
obvious to the caller or user that an authentication failure has
occurred and 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
Gutmann Expires May 22, 2011 [Page 13]

Internet-Draft MAC-Enc-in-CMS November 2010
verification failure even if the rest of the data was processed
correctly.
Gutmann Expires May 22, 2011 [Page 14]

Internet-Draft MAC-Enc-in-CMS November 20107. IANA Considerations
This document contains two algorithm identifiers defined by the SMIME
Working Group Registrar in an arc delegated by RSA to the SMIME
Working Group: iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0). No action by IANA is necessary for
this document or any anticipated updates.
Gutmann Expires May 22, 2011 [Page 15]

Internet-Draft MAC-Enc-in-CMS November 20108. Acknowledgements
The author would like to thank Jim Schaad and the members of the
S/MIME mailing list for their feedback on this document.
Gutmann Expires May 22, 2011 [Page 16]