draft-ietf-smime-rcek-00.txt   draft-ietf-smime-rcek-01.txt 
INTERNET-DRAFT S. Farrell INTERNET-DRAFT S. Farrell
Expires in six months Baltimore Technologies Expires in six months Baltimore Technologies
S. Turner S. Turner
IECA IECA
September 2000 February 2001
Reuse of CMS Content Encryption Keys Reuse of CMS Content Encryption Keys
<draft-ietf-smime-rcek-00.txt> <draft-ietf-smime-rcek-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC2026]. all provisions of Section 10 of [RFC2026].
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of Drafts. Internet-Drafts are draft documents valid for a maximum of
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Table Of Contents Table Of Contents
Status of this Memo.............................................1 Status of this Memo.............................................1
Abstract........................................................1 Abstract........................................................1
Table Of Contents...............................................1 Table Of Contents...............................................1
1. Introduction.................................................2 1. Introduction.................................................2
2. Applicability................................................2 2. Applicability................................................2
3. How to do it.................................................3 3. How to do it.................................................3
4. Using different CEK and KEK algorithms.......................4 4. Using different CEK and KEK algorithms.......................4
5. Security Considerations......................................5 5. Security Considerations......................................5
6. References...................................................6 6. References...................................................5
Author's Addresses..............................................6 Author's Addresses..............................................5
Full Copyright Statement........................................6 Full Copyright Statement........................................6
Appendix A: ASN.1 Module........................................6
Appendix B: Revision History....................................7
1. Introduction 1. Introduction
<<Editorial comments are in angle-brackets, like this.>>
CMS [CMS] specifies EnvelopedData. EnvelopedData supports data CMS [CMS] specifies EnvelopedData. EnvelopedData supports data
encryption using either symmetric or asymmetric key management encryption using either symmetric or asymmetric key management
techniques. Since asymmetric key establishment is relatively techniques. Since asymmetric key establishment is relatively
expensive, it is desirable in some environments to re-use a shared expensive, it is desirable in some environments to re-use a shared
content-encryption key established using asymmetric mechanisms for content-encryption key established using asymmetric mechanisms for
encryption operations in subsequent messages. encryption operations in subsequent messages.
The basic idea here is to reuse the content encryption key (CEK) The basic idea here is to reuse the content encryption key (CEK)
from a message (say message 1) to derive the key encryption key from a message (say message 1) to derive the key encryption key
(KEK) for a later message, (message 2), by including a reference (KEK) for a later message, (message 2), by including a reference
skipping to change at page 3, line 6 skipping to change at page 3, line 6
only used by the originator for encryption and the recipient for only used by the originator for encryption and the recipient for
decryption, recipients must not expect originators to be able to decryption, recipients must not expect originators to be able to
decrypt using (anything derived from) the referenced CEK. This decrypt using (anything derived from) the referenced CEK. This
means that the referenced CEK MUST NOT be considered to be a means that the referenced CEK MUST NOT be considered to be a
shared secret between many parties (i.e. this specification is not shared secret between many parties (i.e. this specification is not
sufficient for group keying schemes). This also means that sufficient for group keying schemes). This also means that
originators may have discarded the referenced CEK by the time the originators may have discarded the referenced CEK by the time the
recipient receives the first message containing the reference. recipient receives the first message containing the reference.
Recipients MUST NOT use the referenced CEK when replying to the Recipients MUST NOT use the referenced CEK when replying to the
originator. <<Is this too restrictive?>> originator.
- The underlying cryptographic API is suitable: it is very likely - The underlying cryptographic API is suitable: it is very likely
that any cryptographic API that completely "hides" the bits of that any cryptographic API that completely "hides" the bits of
cryptographic keys from the CMS layer will prevent reuse of a cryptographic keys from the CMS layer will prevent reuse of a
referenced CEK (since they won't have a primitive that allows referenced CEK (since they won't have a primitive that allows
MSG1.CEK to be transformed to MSG2.KEK). MSG1.CEK to be transformed to MSG2.KEK).
- The algorithms for content and key encryption have compatible key - The algorithms for content and key encryption have compatible key
values and strengths, that is, if MSG1.contentEncryptionAlgorithm values and strengths, that is, if MSG1.contentEncryptionAlgorithm
is a 40bit cipher and MSG2.keyEncryptionAlgorithm requires 168 is a 40bit cipher and MSG2.keyEncryptionAlgorithm requires 168
skipping to change at page 3, line 30 skipping to change at page 3, line 30
In particular, this specification is not intended to be a general In particular, this specification is not intended to be a general
specification for group key management. specification for group key management.
3. How to do it 3. How to do it
In order to reference the content-encryption key (CEK) used in an In order to reference the content-encryption key (CEK) used in an
EnvelopedData (call this MSG1) a key identifier can be included in EnvelopedData (call this MSG1) a key identifier can be included in
the unprotectedAttrs field of MSG1. This key can then be used to the unprotectedAttrs field of MSG1. This key can then be used to
derive the key-encryption key (KEK) for other instances of derive the key-encryption key (KEK) for other instances of
EnvelopedData (say MSG2) or for other purposes. If the CEK from MSG1 EnvelopedData (say MSG2) or for other purposes. If the CEK from MSG1
is to be used to dervie the KEK for MSG2 then MSG1 MUST contain an is to be used to derive the KEK for MSG2 then MSG1 MUST contain an
unprotectedAttrs Attribute of type id-cek-reference with a single unprotectedAttrs Attribute of type id-cek-reference with a single
value using the CEKReference syntax. value using the CEKReference syntax.
MSG2.KEK is to be derived by reversing the bits of MSG1.CEK. The bit MSG2.KEK is to be derived by reversing the bits of MSG1.CEK. The bit
reversal is to avoid an attack where the attacker has a known reversal is to avoid an attack where the attacker has a known
plaintext and the related ciphertext (encrypted with MSG1.CEK) that plaintext and the related ciphertext (encrypted with MSG1.CEK) that
(otherwise) could be directly used as a MSG2.KEK. (otherwise) could be directly used as a MSG2.KEK.
The application MUST ensure that the relevant algorithms are The application MUST ensure that the relevant algorithms are
compatible. That is, a CEKReference attribute alone can only be used compatible. That is, a CEKReference attribute alone can only be used
skipping to change at page 3, line 53 skipping to change at page 3, line 53
Notes: Notes:
1) There is nothing to prevent inclusion of a CEKReference attribute 1) There is nothing to prevent inclusion of a CEKReference attribute
in MSG2 as well as in MSG1. That is, an originator could "roll" in MSG2 as well as in MSG1. That is, an originator could "roll"
the referenced CEK with every message. the referenced CEK with every message.
2) The CEKReference attribute can occur in any of the choices for 2) The CEKReference attribute can occur in any of the choices for
RecipientInfo: ktri, kari or kekri. Implementors MUST NOT assume RecipientInfo: ktri, kari or kekri. Implementors MUST NOT assume
that CEKReference can only occur where ktri or kari is used. that CEKReference can only occur where ktri or kari is used.
id-cek-reference ::= OBJECT IDENTIFIER { TBD } id-rcek-attrs ::= OBJECT IDENTIFIER { TBD }
id-cek-reference ::= OBJECT IDENTIFIER { id-rcek-attrs 1}
CEKReference ::= OCTET STRING CEKReference ::= OCTET STRING
In order to allow the originator of MSG1 to indicate the "lifetime" In order to allow the originator of MSG1 to indicate the "lifetime"
of the CEK, the originator MAY include a CEKMaxDecrypts attribute, of the CEK, the originator MAY include a CEKMaxDecrypts attribute,
also in the unprotectedAttrs field of EnvelopedData. This attribute also in the unprotectedAttrs field of EnvelopedData. This attribute
has an INTEGER syntax (the value MUST be >=1), and indicates to the has an INTEGER syntax (the value MUST be >=1), and indicates to the
recipient the maximum number of messages (including this one) that recipient the maximum number of messages (including this one) that
will use the referenced CEK. This Attribute MUST only be sent when a will use the referenced CEK. This Attribute MUST only be sent when a
CEKReference attribute is also included. CEKReference attribute is also included.
The recipient SHOULD maintain the CEKReference information The recipient SHOULD maintain the CEKReference information
(minimally the key identifier and the CEK value) while less than (minimally the key identifier and the CEK value) while less than
maxDecrypt messages have been successfully received. Recipients maxDecrypt messages have been successfully received. Recipients
SHOULD delete the CEKReference information after some locally SHOULD delete the CEKReference information after some locally
configured period. configured period.
id-cek-maxDecrypts ::= OBJECT IDENTIFIER { TBD } id-cek-maxDecrypts ::= OBJECT IDENTIFIER { id-rcek-attrs 2}
CEKMaxDecrypts ::= INTEGER CEKMaxDecrypts ::= INTEGER
<<The unknown reference attribute is probably not needed, since the
consuming application probably has to do the signalling at the
application layer and not the "CMS" layer, but if we did need
it... Unless there's a specific reason, this will disappear in the
next draft.>>
When a recipient receives a message that contains a CEKReference
that it cannot use (for whatever reason), then the recipient MAY
respond to the originator with a message containing an
UnknownReference attribute. This attribute SHOULD be in either
signedAttrs or authenticatedAttrs, but MAY be in unsignedAttrs in an
otherwise empty SignedData.
id-kek-unknownReference::= OBJECT IDENTIFIER { TBD }
UnknownReference ::= OCTET STRING
The value of this MUST be the KEKIdentifier from the message that
caused the problem.
4. Using different CEK and KEK algorithms 4. Using different CEK and KEK algorithms
Where MSG1.content-encryption algorithm and MSG2.key-encryption Where MSG1.content-encryption algorithm and MSG2.key-encryption
algorithm are the same then the MSG2.KEK is the bit-reversal of algorithm are the same then the MSG2.KEK is the bit-reversal of
MSG1.CEK. However, in general, these algorithms MAY differ, e.g. MSG1.CEK. However, in general, these algorithms MAY differ, e.g.
requiring different key lengths. This section specifies a generic requiring different key lengths. This section specifies a generic
way to derive MSG2.KEK for such cases. way to derive MSG2.KEK for such cases.
Implementations MAY include this functionality. Implementations MAY include this functionality.
In this case the originator MUST include a KEKDerivationAlgorithm The basic approach is to use the PBKDF2 key derivation function
attribute in MSG1, which indicates how to derive MSG2.KEK from defined in PKCS#5 [RFC2898], but using MSG1.CEK as input instead of
MSG1.CEK. This attribute has the following syntax: a password. The output of the PBKDF2 function is MSG2.KEK. To this
end, a new attribute type is defined which allows passing of the
required parameters.
id-kek-derivation-algorithm ::= OBJECT IDENTIFIER { TBD } id-kek-derivation-algorithm ::= OBJECT IDENTIFIER { id-rcek-attrs 3}
KEKDerivationAlgorithm ::= SEQUENCE { KEKDerivationAlgorithm ::= SEQUENCE {
algorithm OBJECT IDENTIFIER, kekAlg AlgorithmIdentifier,
iv OCTET STRING OPTIONAL, pbkdf2Param PBKDF2-params
padding OCTET STRING OPTIONAL, }
kekAlg AlgorithmIdentifier }
<<It's not clear that this specification needs to define its own key keyAlg is the algorithm identifier (and associated parameters, if
derivation scheme for this case (since itĘs a MAY, not a SHOULD or any), for the MSG2 key encryption algorithm. Note that it is not
MUST). If we have to, it would certainly be better if we could necessary to protect this field MSG.KEK is only used by the
reference an existing derivation algorithm. In other words, this originator.
section is likely to change, a lot.>>
In order to derive MSG2.KEK from MSG1.CEK the following algorithm is The PBKDF2 algorithm parameters are to be handled as follows:
used:
1. Randomly pick an IV if necessary and some padding bytes - The salt MUST use the "specified" element of the CHOICE.
2. DER encode the kekAlg value, producing kek-alg-d. kek-alg-d does - The message originator selects the iterationCount.
include the full DER encoding, that is, it begins with the '30'H - The value of keyLength is determined by the kekAlg and MUST be
from the ASN.1 SEQUENCE. present.
3. Catenate the following values to produce CEK-input:
CEK-input = "padding-bytes||CEK||CEKReference||key-alg-d" - The prf field MUST use the DEFAULT algorithm specified in
Note: the padding and CEKReference are both transmitted in the [RFC2898] which is algid-hmacWithSHA1.
KEKDerivationAlgorithm structure as ASN.1 OCTET STRINGS, but
CEK-input MUST NOT include OCTET STRING tags or lengths for
either.
4. Encrypt CEK-input using MSG1.content-encryption algorithm and
the CEK as key, with the IV generated in step 1, (if an IV is
necessary), giving KEK-input.
5. The KEK is the rightmost bits of KEK-input, as required by
MSG2.key-encryption-algorithm.
5. Security Considerations 5. Security Considerations
Encryption does not provide authentication, for example, if the Encryption does not provide authentication, for example, if the
encryptedContent is essentially random then recipients MUST NOT encryptedContent is essentially random then recipients MUST NOT
assume that "knowing" a CEKReference value proves anything - anyone assume that "knowing" a CEKReference value proves anything - anyone
could have created the EnvelopedData. This is relevant both for could have created the EnvelopedData. This is relevant both for
security (the recovered plaintext should not be entirely random) and security (the recovered plaintext should not be entirely random) and
for avoiding denial of service (the recipient MUST NOT assume that for avoiding denial of service (the recipient MUST NOT assume that
using the right CEKReference means that message originator is using the right CEKReference means that message originator is
skipping to change at page 6, line 5 skipping to change at page 5, line 32
The maxDecrypts field presents a potential denial-of-service attack The maxDecrypts field presents a potential denial-of-service attack
if a very large value is included by an originator in an attempt to if a very large value is included by an originator in an attempt to
get a recipient to consume memory by storing the referenced CEKs for get a recipient to consume memory by storing the referenced CEKs for
a long period or if the originator never sends the indicated number a long period or if the originator never sends the indicated number
of ciphertexts. Recipients SHOULD therefore drop referenced CEKs of ciphertexts. Recipients SHOULD therefore drop referenced CEKs
where the maxDecrypts value is too large (according to local where the maxDecrypts value is too large (according to local
configuration) or the referenced CEK has been held for too long a configuration) or the referenced CEK has been held for too long a
period. period.
<<More TBS no doubt.>>
6. References 6. References
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630. [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, February 2001.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC 2026, BCP 9, October 1996. 3", RFC 2026, BCP 9, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119. Requirement Levels", RFC 2119.
Author's Addresses Author's Addresses
Stephen Farrell, Stephen Farrell,
Baltimore Technologies, Baltimore Technologies,
61/62 Fitzwilliam Lane, 39 Parkgate Street,
Dublin 2, Dublin 8
IRELAND IRELAND
tel: +353-1-647-3000 tel: +353-1-881-6000
email: stephen.farrell@baltimore.ie email: stephen.farrell@baltimore.ie
Sean Turner Sean Turner
IECA, Inc. IECA, Inc.
9010 Edgepark Road 9010 Edgepark Road
Vienna, VA 22182 Vienna, VA 22182
USA USA
tel: +1.703.628.3180 tel: +1.703.628.3180
email: turners@ieca.com email: turners@ieca.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (date). All Rights Reserved. Copyright (C) The Internet Society (date). All Rights Reserved.
skipping to change at line 318 skipping to change at page 6, line 40
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. This revoked by the Internet Society or its successors or assigns. This
document and the information contained herein is provided on an "AS document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Appendix A: ASN.1 Module
SMIMERcek
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) rcek(TBD) }
DEFINITIONS EXPLICIT --<<IMPLICIT??>>-- TAGS ::=
BEGIN
-- EXPORTS ALL --
IMPORTS
PBKDF2-Params FROM
PKCS5 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-5(5) } ;
id-rcek-attrs ::= OBJECT IDENTIFIER { TBD }
id-cek-reference ::= OBJECT IDENTIFIER { id-rcek-attrs 1}
CEKReference ::= OCTET STRING
id-cek-maxDecrypts ::= OBJECT IDENTIFIER { id-rcek-attrs 2}
CEKMaxDecrypts ::= INTEGER
id-kek-derivation-algorithm ::= OBJECT IDENTIFIER
{ id-rcek-attrs 3}
KEKDerivationAlgorithm ::= SEQUENCE {
kekAlg AlgorithmIdentifier,
pbkdf2Param PBKDF2-params }
END
Appendix B: Revision History
Changes from -00 to -01:
- Removed error flag attribute, since this is the responsibility of
a consuming protocol
- Change the key derivation from home-grown to use pkcs#5 scheme
- Added compilable ASN.1 module
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/