draft-ietf-smime-cms-auth-enveloped-05.txt   draft-ietf-smime-cms-auth-enveloped-06.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) September 2007 Updates: 3852 (if approved) 21 September 2007
Intended status: Proposed Standard
Cryptographic Message Syntax (CMS) Cryptographic Message Syntax (CMS)
Authenticated-Enveloped-Data Content Type Authenticated-Enveloped-Data Content Type
<draft-ietf-smime-cms-auth-enveloped-05.txt> <draft-ietf-smime-cms-auth-enveloped-06.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 other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 2, line 19 skipping to change at page 2, line 19
enveloped-data content type is intended for use with authenticated enveloped-data content type is intended for use with authenticated
encryption modes, where an arbitrary content is both authenticated encryption modes, where an arbitrary content is both authenticated
and encrypted. Also, some associated data, in the form of and encrypted. Also, some associated data, in the form of
authenticated attributes can also be authenticated. All of the authenticated attributes can also be authenticated. All of the
various key management techniques that are supported in the CMS various key management techniques that are supported in the CMS
enveloped-data content type are also supported by the CMS enveloped-data content type are also supported by the CMS
authenticated-enveloped-data content type. authenticated-enveloped-data content type.
The conventions for using the AES-CCM and the AES-GCM authenticated The conventions for using the AES-CCM and the AES-GCM authenticated
encryption algorithms with the CMS authenticated-enveloped-data encryption algorithms with the CMS authenticated-enveloped-data
content type defined in this document can be found in [AEALGS]. content type defined in this document can be found in [AESALGS].
The authenticated-enveloped-data content type, like all of the other 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 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 Basic Encoding Rules [X.209-88] and the Distinguished Encoding Rules
(DER) [X.509-88]. (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
skipping to change at page 6, line 32 skipping to change at page 6, line 32
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 the block size is less than 256 octets. well defined if and only if the block size is less than 256 octets.
If optional authenticated attributes are present, then they are DER If optional authenticated attributes are present, then they are DER
encoded. A separate encoding of the authAttrs field is performed to encoded. A separate encoding of the authAttrs field is performed to
construct the authenticated associated data (AAD) input to the construct the authenticated associated data (AAD) input to the
authenticated encryption algorithm. The IMPLICIT [1] tag in the authenticated encryption algorithm. For the purposes of constructing
authAttrs field is not used for the DER encoding, rather an EXPLICIT the AAD, the IMPLICIT [1] tag in for authAttrs field is not used for
SET OF tag is used. That is, the DER encoding of the SET OF tag, the DER encoding, rather an universal SET OF tag is used. That is,
rather than of the IMPLICIT [1] tag, is to be included in the the DER encoding of the SET OF tag, rather than of the IMPLICIT [1]
construction of the AAD along with the length and content octets of tag, is to be included in the construction for the AAD along with the
the authAttrs value. If the authenticated encryption algorithm length and content octets of the authAttrs value. If the
requires the AAD to be padded to a multiple of some block size, then authenticated encryption algorithm requires the AAD to be padded to a
the padding MUST be added as described in Section 6.3 of [CMS]. This multiple of some block size, then the padding MUST be added as
padding method is well defined if and only if block size is less than described in Section 6.3 of [CMS]. This padding method is well
256 octets. defined if and only if block size is less than 256 octets.
If optional authenticated attributes are absent, then zero bits of
input are provided for the AAD input to the authenticated encryption
algorithm.
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, which is padded if necessary), and authenticated attributes (the AAD, which is padded if necessary), and
the content-authenticated-encryption key. Under control of a the content-authenticated-encryption key. Under control of a
content-authenticated-encryption key, the authenticated encryption content-authenticated-encryption key, the authenticated encryption
operation maps an arbitrary string of octets (the data) to another operation maps an arbitrary string of octets (the data) to another
string of octets (the ciphertext) and it computes an authentication string of octets (the ciphertext) and it computes an authentication
tag over the AAD and the data. The encrypted data is included in the tag over the AAD and the data. The encrypted data is included in the
AuthEnvelopedData authEncryptedContentInfo encryptedContent as an AuthEnvelopedData authEncryptedContentInfo encryptedContent as an
skipping to change at page 7, line 42 skipping to change at page 7, line 46
Fortunately, the CMS authenticated-enveloped-data content type Fortunately, the CMS authenticated-enveloped-data content type
provides all of the tools needed to avoid misuse of counter mode. provides all of the tools needed to avoid misuse of counter mode.
All of the existing key management techniques permit a fresh content- All of the existing key management techniques permit a fresh content-
encryption key to be generated for each content. In addition, encryption key to be generated for each content. In addition,
existing authenticated encryption algorithms that make use of counter existing authenticated encryption algorithms that make use of counter
mode support the use of an unpredictable nonce value in the counter mode support the use of an unpredictable nonce value in the counter
block. This unpredictable nonce value (sometimes called a "salt") block. This unpredictable nonce value (sometimes called a "salt")
should be carried in an algorithm identifier parameter. should be carried in an algorithm identifier parameter.
There are fairly generic precomputation attacks against all block
cipher modes that allow a meet-in-the-middle attack against the key.
These attacks require the creation and searching of huge tables of
ciphertext associated with known plaintext and known keys. Assuming
that the memory and processor resources are available for a
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
in the key. The use of long keys is the best countermeasure to
precomputation attacks. Use of an unpredictable nonce value in the
counter block significantly increases the size of the table that the
attacker must compute to mount a successful precomputation attack.
Implementations must randomly generate content-authenticated- Implementations must randomly generate content-authenticated-
encryption keys, padding, and unpredictable nonce values. Also, the encryption keys, padding, and unpredictable nonce values. Also, the
generation of public/private key pairs relies on a random numbers. generation of public/private key pairs relies on a random numbers.
The use of inadequate pseudo-random number generators (PRNGs) to The use of inadequate pseudo-random number generators (PRNGs) to
generate cryptographic keys can result in little or no security. An generate cryptographic keys can result in little or no security. An
attacker may find it much easier to reproduce the PRNG environment attacker may find it much easier to reproduce the PRNG environment
that produced the keys, searching the resulting small set of that produced the keys, searching the resulting small set of
possibilities, rather than brute force searching the whole key space. possibilities, rather than brute force searching the whole key space.
The generation of quality random numbers is difficult. RFC 4086 The generation of quality random numbers is difficult. RFC 4086
[RANDOM] offers important guidance in this area. [RANDOM] offers important guidance in this area.
If the message-digest attribute is included in the AuthAttributes, If the message-digest attribute is included in the AuthAttributes,
then the attribute value will contain the unencrypted one-way hash then the attribute value will contain the unencrypted one-way hash
value of the plaintext of the content. Disclosure of this hash value value of the plaintext of the content. Disclosure of this hash value
enables content tracking, and it can be used to determine if the enables content tracking, and it can be used to determine if the
plaintext matches one or more candidate contents. For these reasons, plaintext matches one or more candidate contents. For these reasons,
the AuthAttributes SHOULD NOT contain the message-digest attribute. the AuthAttributes SHOULD NOT contain the message-digest attribute.
CMS is often used to provide encryption in messaging environments.
In messaging environments, various forms of unsolicited messages
(such as spam and phishing) represent a significant volume of
unwanted traffic. Present mitigation strategies for unwanted message
traffic involve analysis of message plaintext. When recipients
accept unsolicited encrypted messages, they become even more
vulnerable to unwanted traffic since the present mitigation
strategies will be unable to access the plaintext. Therefore,
software that receives messages that have been encrypted using CMS
needs to provide one or more mechanisms to handle the unwanted
message traffic. One approach that does not require disclosure of
keying material to a server is to reject or discard encrypted
messages unless they purport to come from a member of a white list.
4. IANA Considerations 4. IANA Considerations
None. None.
{{{ RFC Editor: Please remove this section prior to publication. }}} {{{ RFC Editor: Please remove this section prior to publication. }}}
5. ASN.1 Module 5. ASN.1 Module
CMS-AuthEnvelopedData-2007 CMS-AuthEnvelopedData-2007
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
skipping to change at page 10, line 27 skipping to change at page 10, line 27
[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.2. Informative References 6.2. Informative References
[AEALGS] Housley, R., "Using AES-CCM and AES-GCM Authenticated [AESALGS] Housley, R., "Using AES-CCM and AES-GCM Authenticated
Encryption in the Cryptographic Message Syntax (CMS)", Encryption in the Cryptographic Message Syntax (CMS)",
work in progress. draft-ietf-smime-cms-aes-ccm-and-gcm. work in progress. draft-ietf-smime-cms-aes-ccm-and-gcm.
[BDJR] Bellare, M., Desai, A., Jokipii, E., and P. Rogaway, [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
skipping to change at page 11, line 9 skipping to change at page 11, line 9
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
Copyright and IPR Statements Copyright and IPR Statements
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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.
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
distributed, in whole or in part, without restriction of any kind, and distributed, in whole or in part, without restriction of any
provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein This document and the information contained herein are provided on an
are provided on an "AS IS" basis and THE CONTRIBUTOR, THE "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
OR FITNESS FOR A PARTICULAR PURPOSE.
 End of changes. 10 change blocks. 
30 lines changed or deleted 58 lines changed or added

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