draft-ietf-smime-rcek-03.txt   draft-ietf-smime-rcek-04.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
May 2001 May 28th 2001
Reuse of CMS Content Encryption Keys Reuse of CMS Content Encryption Keys
<draft-ietf-smime-rcek-03.txt> <draft-ietf-smime-rcek-04.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 51 skipping to change at page 1, line 51
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. Conformance..................................................5 5. Conformance..................................................5
6. Security Considerations......................................5 6. Security Considerations......................................5
7. References...................................................6 7. References...................................................6
Author's Addresses..............................................6 Author's Addresses..............................................6
Full Copyright Statement........................................6 Full Copyright Statement........................................7
Appendix A: ASN.1 Module........................................7 Appendix A: ASN.1 Module........................................7
Appendix B: Revision History....................................9 Appendix B: Revision History...................................10
1. Introduction 1. Introduction
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.
skipping to change at page 4, line 20 skipping to change at page 4, line 20
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.
When this attribute is not present, originators and recipients When this attribute is not present, originators and recipients
SHOULD behave as if a value of one had been sent. SHOULD behave as if a value of one had been sent.
id-aa-CEKMaxDecrypts OBJECT IDENTIFIER ::= { id-aa 31 } id-aa-CEKMaxDecrypts OBJECT IDENTIFIER ::= { id-aa 31 }
CEKMaxDecrypts ::= INTEGER CEKMaxDecrypts ::= INTEGER
If CEKMaxDecrypts is missing, or has the value one, then each CEK
will be re-used once as the KEK for the next message. This means
that MSG[n].KEK is the byte-reversal of MSG[n-1].CEK; subsequently
MSG[n+1].KEK will be the byte-reversal of MSG[n].CEK. Note that
MSG[n-1].CEK has no impact whatsoever to MSG[n+1], so long as CEKs
are generated randomly (and not e.g. derived from KEKs somehow).
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 byte-reverse of algorithm are the same then the MSG2.KEK is the byte-reverse 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.
Note: In some sense, the CEK and KEK algorithms are never the Note: In some sense, the CEK and KEK algorithms are never the
"same", e.g. id-alg-CMS3DESwrap and des-ede3-cbc differ. However, "same", e.g. id-alg-CMS3DESwrap and des-ede3-cbc differ. However,
skipping to change at page 6, line 25 skipping to change at page 6, line 29
the next encrypted CEK, i.e. as MSG2.KEKRecipientInfo.encryptedKey. the next encrypted CEK, i.e. as MSG2.KEKRecipientInfo.encryptedKey.
Now the attacker knows the next CEK. This attacks something this Now the attacker knows the next CEK. This attacks something this
note is not claiming to protect (origin authentication), but is note is not claiming to protect (origin authentication), but is
easily avoided using the byte reversal. Byte-reversal was chosen easily avoided using the byte reversal. Byte-reversal was chosen
over bit-reversal since bit-reversal would cause parity bits from over bit-reversal since bit-reversal would cause parity bits from
MSG1.CEK to be used as keying bits for MSG2.KEK for DES-based MSG1.CEK to be used as keying bits for MSG2.KEK for DES-based
algorithms. Note that byte reversal would similarly affect parity if algorithms. Note that byte reversal would similarly affect parity if
parity checks spanned more than one octet, however no well-known parity checks spanned more than one octet, however no well-known
algorithms operate in this way. algorithms operate in this way.
Implementations should be very careful with this scheme if
MSG[n].KEK is used to derive MSG[n].CEK, e.g. if MSG[n].CEK were the
byte-reversal of MSG[n].KEK, then this scheme could result in a
fixed key being unexpectedly used.
7. References 7. References
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630. [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630.
[CMS-MSG] Ramsdell, B. "S/MIME Version 3 Message Specification", [CMS-MSG] Ramsdell, B. "S/MIME Version 3 Message Specification",
RFC 2633. RFC 2633.
[RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
Specification Version 2.0", RFC 2898, September 2000. Specification Version 2.0", RFC 2898, September 2000.
[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
skipping to change at line 447 skipping to change at page 10, line 34
- Added security consideration describing reason for byte reversal - Added security consideration describing reason for byte reversal
- Changed from unidirectional since Diameter may need bi-directional - Changed from unidirectional since Diameter may need bi-directional
- Copied kdf params stuff from rfc2898 since it uses '93 ASN.1 - Copied kdf params stuff from rfc2898 since it uses '93 ASN.1
- Changed so that max decrypts=1, implies that one more message can - Changed so that max decrypts=1, implies that one more message can
re-use the CEK (used to be silly where a value of 1 meant no more) re-use the CEK (used to be silly where a value of 1 meant no more)
Changes from -02 to -03 Changes from -02 to -03
- Removed extra comma from ASN.1 module - Removed extra comma from ASN.1 module
- Reworded section 4, para 6 - Reworded section 4, para 6
Changes from -03 to -04
- Added a clarification at end section 3 and a related security
consideration.
 End of changes. 

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