INTERNET-DRAFT S. Farrell Expires in six months Baltimore Technologies S. Turner IECA September 2000 Reuse of CMS Content Encryption Keys Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This note describes a way to include a key identifier in a CMS enveloped data structure, so that the content encryption key can be re-used for further enveloped data packets. Table Of Contents Status of this Memo.............................................1 Abstract........................................................1 Table Of Contents...............................................1 1. Introduction.................................................2 2. Applicability................................................2 3. How to do it.................................................3 4. Using different CEK and KEK algorithms.......................4 5. Security Considerations......................................5 6. References...................................................6 Author's Addresses..............................................6 Full Copyright Statement........................................6 Farrell & Turner [Page 1] INTERNET-DRAFT September 2000 1. Introduction <> CMS [CMS] specifies EnvelopedData. EnvelopedData supports data encryption using either symmetric or asymmetric key management techniques. Since asymmetric key establishment is relatively expensive, it is desirable in some environments to re-use a shared content-encryption key established using asymmetric mechanisms for encryption operations in subsequent messages. The basic idea here is to reuse the content encryption key (CEK) from a message (say message 1) to derive the key encryption key (KEK) for a later message, (message 2), by including a reference value for the CEK in message 1, and that same value as the KEKIdentifier for message 2. The CEK from message 1 is called the "referenced CEK". The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in [RFC2119]. 2. Applicability This specification is intended to be used to provide more efficient selective field confidentiality between communicating peers, in particular in the cases where: - The originator is a client that wishes to send a number of fields to a server (the recipient) in a single transaction, where the referenced CEK is used for the separate encryption of each field. - The originator and recipient are servers that communicate very frequently and use this specification purely for efficiency. This specification is not intended to be applicable in all cases. It is suited for use where: - Its use is further scoped: that is, this specification doesn't define a system but merely a trick that can be used in a larger context and additional specification will be needed for each such case. In particular, in order to use this specification, it is REQUIRED to define the originators' and recipients' behavior where a referenced CEK has been "lost". - Key encryption is "unidirectional": that is, the referenced CEK is only used by the originator for encryption and the recipient for decryption, recipients must not expect originators to be able to decrypt using (anything derived from) the referenced CEK. This means that the referenced CEK MUST NOT be considered to be a shared secret between many parties (i.e. this specification is not sufficient for group keying schemes). This also means that originators may have discarded the referenced CEK by the time the recipient receives the first message containing the reference. Farrell & Turner [Page 2] INTERNET-DRAFT September 2000 Recipients MUST NOT use the referenced CEK when replying to the originator. <> - The underlying cryptographic API is suitable: it is very likely that any cryptographic API that completely "hides" the bits of cryptographic keys from the CMS layer will prevent reuse of a referenced CEK (since they won't have a primitive that allows MSG1.CEK to be transformed to MSG2.KEK). - The algorithms for content and key encryption have compatible key values and strengths, that is, if MSG1.contentEncryptionAlgorithm is a 40bit cipher and MSG2.keyEncryptionAlgorithm requires 168 bits of keying material, then this specification SHOULD NOT be used. In particular, this specification is not intended to be a general specification for group key management. 3. How to do it In order to reference the content-encryption key (CEK) used in an EnvelopedData (call this MSG1) a key identifier can be included in the unprotectedAttrs field of MSG1. This key can then be used to derive the key-encryption key (KEK) for other instances of 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 unprotectedAttrs Attribute of type id-cek-reference with a single value using the CEKReference syntax. 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 plaintext and the related ciphertext (encrypted with MSG1.CEK) that (otherwise) could be directly used as a MSG2.KEK. The application MUST ensure that the relevant algorithms are compatible. That is, a CEKReference attribute alone can only be used where the content-encryption algorithm from MSG1 employs the same type of symmetric key as the key-encryption algorithm from MSG2. Notes: 1) There is nothing to prevent inclusion of a CEKReference attribute in MSG2 as well as in MSG1. That is, an originator could "roll" the referenced CEK with every message. 2) The CEKReference attribute can occur in any of the choices for RecipientInfo: ktri, kari or kekri. Implementors MUST NOT assume that CEKReference can only occur where ktri or kari is used. id-cek-reference ::= OBJECT IDENTIFIER { TBD } CEKReference ::= OCTET STRING Farrell & Turner [Page 3] INTERNET-DRAFT September 2000 In order to allow the originator of MSG1 to indicate the "lifetime" of the CEK, the originator MAY include a CEKMaxDecrypts attribute, also in the unprotectedAttrs field of EnvelopedData. This attribute has an INTEGER syntax (the value MUST be >=1), and indicates to the recipient the maximum number of messages (including this one) that will use the referenced CEK. This Attribute MUST only be sent when a CEKReference attribute is also included. The recipient SHOULD maintain the CEKReference information (minimally the key identifier and the CEK value) while less than maxDecrypt messages have been successfully received. Recipients SHOULD delete the CEKReference information after some locally configured period. id-cek-maxDecrypts ::= OBJECT IDENTIFIER { TBD } CEKMaxDecrypts ::= INTEGER <> 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 Where MSG1.content-encryption algorithm and MSG2.key-encryption algorithm are the same then the MSG2.KEK is the bit-reversal of MSG1.CEK. However, in general, these algorithms MAY differ, e.g. requiring different key lengths. This section specifies a generic way to derive MSG2.KEK for such cases. Implementations MAY include this functionality. In this case the originator MUST include a KEKDerivationAlgorithm attribute in MSG1, which indicates how to derive MSG2.KEK from MSG1.CEK. This attribute has the following syntax: id-kek-derivation-algorithm ::= OBJECT IDENTIFIER { TBD } KEKDerivationAlgorithm ::= SEQUENCE { algorithm OBJECT IDENTIFIER, iv OCTET STRING OPTIONAL, Farrell & Turner [Page 4] INTERNET-DRAFT September 2000 padding OCTET STRING OPTIONAL, kekAlg AlgorithmIdentifier } <> In order to derive MSG2.KEK from MSG1.CEK the following algorithm is used: 1. Randomly pick an IV if necessary and some padding bytes 2. DER encode the kekAlg value, producing kek-alg-d. kek-alg-d does include the full DER encoding, that is, it begins with the '30'H from the ASN.1 SEQUENCE. 3. Catenate the following values to produce CEK-input: CEK-input = "padding-bytes||CEK||CEKReference||key-alg-d" Note: the padding and CEKReference are both transmitted in the 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 Encryption does not provide authentication, for example, if the encryptedContent is essentially random then recipients MUST NOT assume that "knowing" a CEKReference value proves anything - anyone could have created the EnvelopedData. This is relevant both for security (the recovered plaintext should not be entirely random) and for avoiding denial of service (the recipient MUST NOT assume that using the right CEKReference means that message originator is genuine). Similarly, using the correct CEKReference does not mean that a message has not been replayed or inserted, and recipients MUST NOT assume that replay has been avoided. The maxDecrypts field presents a potential denial-of-service attack 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 a long period or if the originator never sends the indicated number of ciphertexts. Recipients SHOULD therefore drop referenced CEKs where the maxDecrypts value is too large (according to local configuration) or the referenced CEK has been held for too long a period. Farrell & Turner [Page 5] INTERNET-DRAFT September 2000 <> 6. References [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, BCP 9, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119. Author's Addresses Stephen Farrell, Baltimore Technologies, 61/62 Fitzwilliam Lane, Dublin 2, IRELAND tel: +353-1-647-3000 email: stephen.farrell@baltimore.ie Sean Turner IECA, Inc. 9010 Edgepark Road Vienna, VA 22182 USA tel: +1.703.628.3180 email: turners@ieca.com Full Copyright Statement Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. In addition, the ASN.1 module presented in Appendix B may be used in whole or in part without inclusion of the copyright notice. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process shall be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS Farrell & Turner [Page 6] INTERNET-DRAFT September 2000 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Farrell & Turner [Page 7]