draft-ietf-smime-cms-auth-enveloped-00.txt   draft-ietf-smime-cms-auth-enveloped-01.txt 
S/MIME Working Group R. Housley S/MIME Working Group R. Housley
Internet-Draft Vigil Security Internet-Draft Vigil Security
Updates: 3852 (if approved) January 2007 Updates: 3852 (if approved) January 2007
The CMS AuthEnvelopedData Content Type Cryptographic Message Syntax (CMS)
<draft-ietf-smime-cms-auth-enveloped-00.txt> Authenticated-Enveloped-Data Content Type
<draft-ietf-smime-cms-auth-enveloped-01.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 37
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Abstract Abstract
This document describes an additional content type for the This document describes an additional content type for the
Cryptographic Message Syntax (CMS). The AuthEnvelopedData content Cryptographic Message Syntax (CMS). The authenticated-enveloped-data
type is intended for use with authenticated encryption modes. All of content type is intended for use with authenticated encryption modes.
the various key management techniques that are supported in the All of the various key management techniques that are supported in
EnvelopedData content type are also supported by the the CMS enveloped-data content type are also supported by the CMS
AuthEnvelopedData content type. authenticated-enveloped-data content type.
1. Introduction 1. Introduction
This document describes an additional content type for the This document describes an additional content type for the
Cryptographic Message Syntax (CMS) [CMS]. The AuthEnvelopedData Cryptographic Message Syntax (CMS) [CMS]. The authenticated-
content type is intended for use with authenticated encryption modes, enveloped-data content type is intended for use with authenticated
where an arbitrary content is both authenticated and encrypted. encryption modes, where an arbitrary content is both authenticated
Also, some associated data, in the form of authenticated attributes and encrypted. Also, some associated data, in the form of
can also be authenticated. All of the various key management authenticated attributes can also be authenticated. All of the
techniques that are supported in the EnvelopedData content type are various key management techniques that are supported in the CMS
also supported by the AuthEnvelopedData content type. enveloped-data content type are also supported by the CMS
authenticated-enveloped-data content type.
The AuthEnvelopedData content type, like all of the other CMS content The conventions for using the AES-CCM and the AES-GCM authenticated
types, employs ASN.1 [X.208-88], and it uses both the Basic Encoding encryption algorithms with the CMS authenticated-enveloped-data
Rules [X.209-88] and the Distinguished Encoding Rules (DER) content type defined in this document can be found in [AEALGS].
[X.509-88].
The authenticated-enveloped-data content type, like all of the other
CMS content types, employs ASN.1 [X.208-88], and it uses both the
Basic Encoding Rules [X.209-88] and the Distinguished Encoding Rules
(DER) [X.509-88].
1.1 Terminology 1.1 Terminology
In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD, In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as
described in [STDWORDS]. described in [STDWORDS].
1.2 Version Numbers 1.2 Version Numbers
The major data structure (AuthEnvelopedData) includes a version The major data structure (AuthEnvelopedData) includes a version
number as the first item in the data structure. The version number number as the first item in the data structure. The version number
is intended to avoid ASN.1 decode errors. Some implementations do is intended to avoid ASN.1 decode errors. Some implementations do
not check the version number prior to attempting a decode, and if a not check the version number prior to attempting a decode, and then
decode error occurs, then the version number is checked as part of if a decode error occurs, the version number is checked as part of
the error handling routine. This is a reasonable approach; it places the error handling routine. This is a reasonable approach; it places
error processing outside of the fast path. This approach is also error processing outside of the fast path. This approach is also
forgiving when an incorrect version number is used by the sender. forgiving when an incorrect version number is used by the sender.
Whenever the structure is updated, a higher version number will be Whenever the structure is updated, a higher version number will be
assigned. However, to ensure maximum interoperability the higher assigned. However, to ensure maximum interoperability the higher
version number is only used when the new syntax feature is employed. version number is only used when the new syntax feature is employed.
That is, the lowest version number that supports the generated syntax That is, the lowest version number that supports the generated syntax
is used. is used.
2. Authenticated-enveloped-data Content Type 2. Authenticated-enveloped-data Content Type
The authenticated-enveloped-data content type consists of an The authenticated-enveloped-data content type consists of an
authenticated and encrypted content of any type and encrypted authenticated and encrypted content of any type and encrypted
content-encryption keys for one or more recipients. The combination content-authenticated-encryption keys for one or more recipients.
of the authenticated and encrypted content and one encrypted content- The combination of the authenticated and encrypted content and one
authenticated-encryption key for a recipient is a "digital envelope" encrypted content-authenticated-encryption key for a recipient is a
for that recipient. Any type of content can be enveloped for an "digital envelope" for that recipient. Any type of content can be
arbitrary number of recipients using any of the supported key enveloped for an arbitrary number of recipients using any of the
management techniques for each recipient. In addition, authenticated supported key management techniques for each recipient. In addition,
but not encrypted attributes may be provided by the originator. authenticated but not encrypted attributes may be provided by the
originator.
The typical application of the authenticated-enveloped-data content The typical application of the authenticated-enveloped-data content
type will represent one or more recipients' digital envelopes on an type will represent one or more recipients' digital envelopes on an
encapsulated content. encapsulated content.
Authenticated-enveloped-data is constructed by the following steps: Authenticated-enveloped-data is constructed by the following steps:
1. A content-encryption key for a particular content- 1. A content-authenticated-encryption key for a particular
authenticated-encryption algorithm is generated at random. content-authenticated-encryption algorithm is generated at random.
2. The content-authenticated-encryption key is encrypted for each 2. The content-authenticated-encryption key is encrypted for each
recipient. The details of this encryption depend on the key recipient. The details of this encryption depend on the key
management algorithm used, but four general techniques are management algorithm used, but four general techniques are
supported: supported:
key transport: the content-authenticated-encryption key is key transport: the content-authenticated-encryption key is
encrypted in the recipient's public key; encrypted in the recipient's public key;
key agreement: the recipient's public key and the sender's key agreement: the recipient's public key and the sender's
private key are used to generate a pairwise symmetric key, private key are used to generate a pairwise symmetric key-
then the content-authenticated-encryption key is encrypted encryption key, then the content-authenticated-encryption
in the pairwise symmetric key; key is encrypted in the pairwise symmetric key-encryption
key;
symmetric key-encryption keys: the content-authenticated- symmetric key-encryption keys: the content-authenticated-
encryption key is encrypted in a previously distributed encryption key is encrypted in a previously distributed
symmetric key-encryption key; and symmetric key-encryption key; and
passwords: the content-authenticated-encryption key is passwords: the content-authenticated-encryption key is
encrypted in a key-encryption key that is derived from a encrypted in a key-encryption key that is derived from a
password or other shared secret value. password or other shared secret value.
3. For each recipient, the encrypted content-authenticated- 3. For each recipient, the encrypted content-authenticated-
encryption key and other recipient-specific information are encryption key and other recipient-specific information are
collected into a RecipientInfo value, defined in Section 6.2 of collected into a RecipientInfo value, defined in Section 6.2 of
[CMS]. [CMS].
4. Any attributes that are to be authenticated but not encrypted 4. Any attributes that are to be authenticated but not encrypted
are collected in the authenticated attributes. are collected in the authenticated attributes.
5. The attributes collected in step 4 are authenticated and the 5. The attributes collected in step 4 are authenticated and the
content is authenticated and encrypted with the content- content is authenticated and encrypted with the content-
authenticated-encryption key. If the authenticated encryption authenticated-encryption key. If the authenticated encryption
algorithm requires the content to be padded to a multiple of some algorithm requires either the additional authenticated data (AAD)
block size, then the padding is added as described in Section 6.3 or the content to be padded to a multiple of some block size, then
of [CMS]. the padding is added as described in Section 6.3 of [CMS].
6. Any attributes that are to be provided without authentication 6. Any attributes that are to be provided without authentication
or encryption are collected in the unauthenticated attributes. or encryption are collected in the unauthenticated attributes.
7. The RecipientInfo values for all the recipients, the 7. The RecipientInfo values for all the recipients, the
authenticated attributes, then unauthenticated attributes, and the authenticated attributes, then unauthenticated attributes, and the
authenticated and encrypted content are collected together to form authenticated and encrypted content are collected together to form
an AuthEnvelopedData value as defined in Section 2.1. an AuthEnvelopedData value as defined in Section 2.1.
A recipient opens the digital envelope by decrypting one of the A recipient opens the digital envelope by decrypting one of the
skipping to change at page 4, line 44 skipping to change at page 5, line 4
AuthEnvelopedData: AuthEnvelopedData:
AuthEnvelopedData ::= SEQUENCE { AuthEnvelopedData ::= SEQUENCE {
version CMSVersion, version CMSVersion,
originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL, originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
recipientInfos RecipientInfos, recipientInfos RecipientInfos,
authAttrs [1] IMPLICIT AuthAttributes OPTIONAL, authAttrs [1] IMPLICIT AuthAttributes OPTIONAL,
authEncryptedContentInfo EncryptedContentInfo, authEncryptedContentInfo EncryptedContentInfo,
mac MessageAuthenticationCode, mac MessageAuthenticationCode,
unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL } unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL }
The fields of type AuthEnvelopedData have the following meanings: The fields of type AuthEnvelopedData have the following meanings:
version is the syntax version number. It MUST be set to 0. version is the syntax version number. It MUST be set to 0.
originatorInfo optionally provides information about the originatorInfo optionally provides information about the
originator. It is present only if required by the key management originator. It is present only if required by the key
algorithm. It may contain certificates and CRLs, and the management algorithm. It may contain certificates and CRLs,
OriginatorInfo type is defined in Section 6.1 of [CMS]. and the OriginatorInfo type is defined in Section 6.1 of [CMS].
recipientInfos is a collection of per-recipient information. recipientInfos is a collection of per-recipient information.
There MUST be at least one element in the collection. The There MUST be at least one element in the collection. The
RecipientInfo type is defined in Section 6.2 of [CMS]. RecipientInfo type is defined in Section 6.2 of [CMS].
authAttrs optionally contains the authenticated attributes. The authAttrs optionally contains the authenticated attributes. The
AuthenticatedData content type uses the same type to carry CMS authenticated-data content type uses the same type to carry
authenticated attributes. The AuthAttributes type is defined in authenticated attributes. The AuthAttributes type is defined
Section 9.1 of [CMS]. Useful attribute types are defined in in Section 9.1 of [CMS]. Useful attribute types are defined in
Section 11 of [CMS]. Section 11 of [CMS].
authEncryptedContentInfo is the authenticated and encrypted authEncryptedContentInfo is the authenticated and encrypted
content. The EnvelopedData content type uses the same type to content. The CMS enveloped-data content type uses the same
carry the encrypted content. The EncryptedContentInfo type is type to carry the encrypted content. The EncryptedContentInfo
defined in Section 6.1 of [CMS]. type is defined in Section 6.1 of [CMS].
mac is the integrity check value (ICV) or message authentication mac is the integrity check value (ICV) or message authentication
code (MAC) that is generated by the authenticated encryption code (MAC) that is generated by the authenticated encryption
algorithm. The AuthenticatedData content type uses the same type algorithm. The CMS authenticated-data content type uses the
to carry a MAC. In this case, the MAC covers the authenticated same type to carry a MAC. In this case, the MAC covers the
attributes and the content directly, and a digest algorithm is not authenticated attributes and the content directly, and a digest
used. The MessageAuthenticationCode type is defined in Section 9.1 algorithm is not used. The MessageAuthenticationCode type is
of [CMS]. defined in Section 9.1 of [CMS].
unauthAttrs optionally contains the unauthenticated attributes. unauthAttrs optionally contains the unauthenticated attributes.
The AuthenticatedData content type uses the same type to carry The CMS authenticated-data content type uses the same type to
unauthenticated attributes. The UnauthAttributes type is defined carry unauthenticated attributes. The UnauthAttributes type is
in Section 9.1 of [CMS]. Useful attribute types are defined in defined in Section 9.1 of [CMS]. Useful attribute types are
Section 11 of [CMS]. defined in Section 11 of [CMS].
2.2. Authentication and Encryption Process 2.2. Authentication and Encryption Process
The content-authenticated-encryption key for the desired content- The content-authenticated-encryption key for the desired content-
authenticated-encryption algorithm is randomly generated. authenticated-encryption algorithm is randomly generated.
If the authenticated encryption algorithm requires the content to be If the authenticated encryption algorithm requires the content to be
padded to a multiple of some block size, then the padding MUST be padded to a multiple of some block size, then the padding MUST be
added as described in Section 6.3 of [CMS]. This padding method is added as described in Section 6.3 of [CMS]. This padding method is
well defined if and only if number of octets in the block size is well defined if and only if the number of octets in the block size is
less than 256. less than 256.
If optional authenticated attributes are present, then they are DER If optional authenticated attributes are present, then they are DER
encoded. The result will be used as the authenticated associated encoded. The result will be used as the authenticated associated
data (AAD) input to the authenticated encryption algorithm. data (AAD) input to the authenticated encryption algorithm. If the
authenticated encryption algorithm requires the AAD to be padded to a
multiple of some block size, then the padding MUST be added as
described in Section 6.3 of [CMS]. This padding method is well
defined if and only if number of octets in the block size is less
than 256.
The inputs to the authenticated encryption algorithm are the content The inputs to the authenticated encryption algorithm are the content
(the data, which is padded if necessary), the DER-encoded (the data, which is padded if necessary), the DER-encoded
authenticated attributes (the AAD), and the content-authenticated- authenticated attributes (the AAD, which is padded if necessary), and
encryption key. Under control of a content-authenticated-encryption the content-authenticated-encryption key. Under control of a
key, the authenticated encryption operation maps an arbitrary string content-authenticated-encryption key, the authenticated encryption
of octets (the data) to another string of octets (the ciphertext) and operation maps an arbitrary string of octets (the data) to another
it computes an authentication tag over the AAD and the data. The string of octets (the ciphertext) and it computes an authentication
encrypted data is included in the AuthEnvelopedData tag over the AAD and the data. The encrypted data is included in the
encryptedContentInfo encryptedContent OCTET STRING, and the AuthEnvelopedData authEncryptedContentInfo encryptedContent as an
authentication tag is included in the AuthEnvelopedData mac. OCTET STRING, and the authentication tag is included in the
AuthEnvelopedData mac.
2.3. Key Encryption Process 2.3. Key Encryption Process
The input to the key encryption process -- the value supplied to the The input to the key encryption process -- the value supplied to the
recipient's key-encryption algorithm -- is just the "value" of the recipient's key-encryption algorithm -- is just the "value" of the
content-authenticated-encryption key. content-authenticated-encryption key.
Any of the aforementioned key management techniques can be used for Any of the aforementioned key management techniques can be used for
each recipient of the same encrypted content. each recipient of the same encrypted content.
3. Security Considerations 3. Security Considerations
This specification defines and additional CMS content type. The This specification defines an additional CMS content type. The
security considerations provided in [CMS] apply to this content type security considerations provided in [CMS] apply to this content type
as well. as well.
Many authenticated encryption algorithms make use of a block cipher Many authenticated encryption algorithms make use of a block cipher
in counter mode to provide encryption. When used properly, counter in counter mode to provide encryption. When used properly, counter
mode provides strong confidentiality. Bellare, Desai, Jokipii, mode provides strong confidentiality. Bellare, Desai, Jokipii,
Rogaway show in [BDJR] that the privacy guarantees provided by Rogaway show in [BDJR] that the privacy guarantees provided by
counter mode are at least as strong as those for CBC mode when using counter mode are at least as strong as those for CBC mode when using
the same block cipher. the same block cipher.
Unfortunately, it is easy to misuse counter mode. If counter block Unfortunately, it is easy to misuse counter mode. If counter block
values are ever used for more that one encryption operation with the values are ever used for more that one encryption operation with the
same key, then the same key stream will be used to encrypt both same key, then the same key stream will be used to encrypt both
plaintexts, and the confidentiality guarantees are voided. plaintexts, and the confidentiality guarantees are voided.
Fortunately, the CMS AuthEnvelopedData provides all of the tools Fortunately, the CMS authenticated-enveloped-data content type
needed to avoid misuse of counter mode. When using key transport or provides all of the tools needed to avoid misuse of counter mode.
key agreement, a fresh key should be generated for each content. When using key transport or key agreement, a fresh key should be
However, when using symmetric key-encryption keys or passwords, one generated for each content. However, when using symmetric key-
cannot assume that a fresh key is generated. Therefore, encryption keys or passwords, one cannot assume that a fresh key is
authenticated encryption algorithms that make use of counter mode generated. Therefore, authenticated encryption algorithms that make
must support the use of an unpredictable nonce value in the counter use of counter mode must support the use of an unpredictable nonce
block, and this unpredictable nonce value (sometimes called a "salt") value in the counter block, and this unpredictable nonce value
must be carried as an algorithm identifier parameter. (sometimes called a "salt") must be carried as an algorithm
identifier parameter.
There are fairly generic precomputation attacks against all block There are fairly generic precomputation attacks against all block
cipher modes that allow a meet-in-the-middle attack against the key. cipher modes that allow a meet-in-the-middle attack against the key.
These attacks require the creation and searching of huge tables of These attacks require the creation and searching of huge tables of
ciphertext associated with known plaintext and known keys. Assuming ciphertext associated with known plaintext and known keys. Assuming
that the memory and processor resources are available for a that the memory and processor resources are available for a
precomputation attack, then the theoretical strength of any block precomputation attack, then the theoretical strength of any block
cipher mode is limited to 2^(n/2) bits, where n is the number of bits cipher mode is limited to 2^(n/2) bits, where n is the number of bits
in the key. The use of long keys is the best countermeasure to in the key. The use of long keys is the best countermeasure to
precomputation attacks. Use of an unpredictable nonce value in the precomputation attacks. Use of an unpredictable nonce value in the
skipping to change at page 8, line 35 skipping to change at page 9, line 7
[X.209-88] CCITT. Recommendation X.209: Specification of Basic [X.209-88] CCITT. Recommendation X.209: Specification of Basic
Encoding Rules for Abstract Syntax Notation One (ASN.1). Encoding Rules for Abstract Syntax Notation One (ASN.1).
1988. 1988.
[X.509-88] CCITT. Recommendation X.509: The Directory - [X.509-88] CCITT. Recommendation X.509: The Directory -
Authentication Framework. 1988. Authentication Framework. 1988.
6. Informative References 6. Informative References
[BDJR] Bellare, M, Desai, A., Jokipii, E., and P. Rogaway, [AEALGS] Housley, R., "Using AES-CCM and AES-GCM Authenticated
Encryption in the Cryptographic Message Syntax (CMS)",
work in progress. draft-ietf-smime-cms-aes-ccm-and-gcm.
[BDJR] Bellare, M., Desai, A., Jokipii, E., and P. Rogaway,
"A Concrete Security Treatment of Symmetric Encryption: "A Concrete Security Treatment of Symmetric Encryption:
Analysis of the DES Modes of Operation", Proceedings Analysis of the DES Modes of Operation", Proceedings
38th Annual Symposium on Foundations of Computer 38th Annual Symposium on Foundations of Computer
Science, 1997. Science, 1997.
[RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Recommendations for Security", RFC 4086, June 2005. Recommendations for Security", RFC 4086, June 2005.
7. Authors' Address 7. Authors' Address
Russell Housley Russell Housley
Vigil Security, LLC Vigil Security, LLC
918 Spring Knoll Drive 918 Spring Knoll Drive
Herndon, VA 20170 Herndon, VA 20170
USA USA
EMail: housley@vigilsec.com EMail: housley@vigilsec.com
Full Copyright Statement Copyright and IPR Statements
Copyright (C) The Internet Society (2007). Copyright (C) The Internet Society (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and or assist in its implementation may be prepared, copied, published and
 End of changes. 22 change blocks. 
76 lines changed or deleted 94 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/