idnits 2.17.1 draft-ietf-smime-rcek-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2000) is 8623 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2630 (ref. 'CMS') (Obsoleted by RFC 3369, RFC 3370) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT S. Farrell 3 Expires in six months Baltimore Technologies 4 S. Turner 5 IECA 6 September 2000 8 Reuse of CMS Content Encryption Keys 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of [RFC2026]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. Internet-Drafts are draft documents valid for a maximum of 20 six months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This note describes a way to include a key identifier in a CMS 34 enveloped data structure, so that the content encryption key can be 35 re-used for further enveloped data packets. 37 Table Of Contents 39 Status of this Memo.............................................1 40 Abstract........................................................1 41 Table Of Contents...............................................1 42 1. Introduction.................................................2 43 2. Applicability................................................2 44 3. How to do it.................................................3 45 4. Using different CEK and KEK algorithms.......................4 46 5. Security Considerations......................................5 47 6. References...................................................6 48 Author's Addresses..............................................6 49 Full Copyright Statement........................................6 51 1. Introduction 53 <> 55 CMS [CMS] specifies EnvelopedData. EnvelopedData supports data 56 encryption using either symmetric or asymmetric key management 57 techniques. Since asymmetric key establishment is relatively 58 expensive, it is desirable in some environments to re-use a shared 59 content-encryption key established using asymmetric mechanisms for 60 encryption operations in subsequent messages. 62 The basic idea here is to reuse the content encryption key (CEK) 63 from a message (say message 1) to derive the key encryption key 64 (KEK) for a later message, (message 2), by including a reference 65 value for the CEK in message 1, and that same value as the 66 KEKIdentifier for message 2. The CEK from message 1 is called the 67 "referenced CEK". 69 The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" 70 in this document are to be interpreted as described in [RFC2119]. 72 2. Applicability 74 This specification is intended to be used to provide more efficient 75 selective field confidentiality between communicating peers, in 76 particular in the cases where: 78 - The originator is a client that wishes to send a number of fields 79 to a server (the recipient) in a single transaction, where the 80 referenced CEK is used for the separate encryption of each field. 82 - The originator and recipient are servers that communicate very 83 frequently and use this specification purely for efficiency. 85 This specification is not intended to be applicable in all cases. It 86 is suited for use where: 88 - Its use is further scoped: that is, this specification doesn't 89 define a system but merely a trick that can be used in a larger 90 context and additional specification will be needed for each such 91 case. In particular, in order to use this specification, it is 92 REQUIRED to define the originators' and recipients' behavior where 93 a referenced CEK has been "lost". 95 - Key encryption is "unidirectional": that is, the referenced CEK is 96 only used by the originator for encryption and the recipient for 97 decryption, recipients must not expect originators to be able to 98 decrypt using (anything derived from) the referenced CEK. This 99 means that the referenced CEK MUST NOT be considered to be a 100 shared secret between many parties (i.e. this specification is not 101 sufficient for group keying schemes). This also means that 102 originators may have discarded the referenced CEK by the time the 103 recipient receives the first message containing the reference. 105 Recipients MUST NOT use the referenced CEK when replying to the 106 originator. <> 108 - The underlying cryptographic API is suitable: it is very likely 109 that any cryptographic API that completely "hides" the bits of 110 cryptographic keys from the CMS layer will prevent reuse of a 111 referenced CEK (since they won't have a primitive that allows 112 MSG1.CEK to be transformed to MSG2.KEK). 114 - The algorithms for content and key encryption have compatible key 115 values and strengths, that is, if MSG1.contentEncryptionAlgorithm 116 is a 40bit cipher and MSG2.keyEncryptionAlgorithm requires 168 117 bits of keying material, then this specification SHOULD NOT be 118 used. 120 In particular, this specification is not intended to be a general 121 specification for group key management. 123 3. How to do it 125 In order to reference the content-encryption key (CEK) used in an 126 EnvelopedData (call this MSG1) a key identifier can be included in 127 the unprotectedAttrs field of MSG1. This key can then be used to 128 derive the key-encryption key (KEK) for other instances of 129 EnvelopedData (say MSG2) or for other purposes. If the CEK from MSG1 130 is to be used to dervie the KEK for MSG2 then MSG1 MUST contain an 131 unprotectedAttrs Attribute of type id-cek-reference with a single 132 value using the CEKReference syntax. 134 MSG2.KEK is to be derived by reversing the bits of MSG1.CEK. The bit 135 reversal is to avoid an attack where the attacker has a known 136 plaintext and the related ciphertext (encrypted with MSG1.CEK) that 137 (otherwise) could be directly used as a MSG2.KEK. 139 The application MUST ensure that the relevant algorithms are 140 compatible. That is, a CEKReference attribute alone can only be used 141 where the content-encryption algorithm from MSG1 employs the same 142 type of symmetric key as the key-encryption algorithm from MSG2. 144 Notes: 146 1) There is nothing to prevent inclusion of a CEKReference attribute 147 in MSG2 as well as in MSG1. That is, an originator could "roll" 148 the referenced CEK with every message. 149 2) The CEKReference attribute can occur in any of the choices for 150 RecipientInfo: ktri, kari or kekri. Implementors MUST NOT assume 151 that CEKReference can only occur where ktri or kari is used. 153 id-cek-reference ::= OBJECT IDENTIFIER { TBD } 154 CEKReference ::= OCTET STRING 155 In order to allow the originator of MSG1 to indicate the "lifetime" 156 of the CEK, the originator MAY include a CEKMaxDecrypts attribute, 157 also in the unprotectedAttrs field of EnvelopedData. This attribute 158 has an INTEGER syntax (the value MUST be >=1), and indicates to the 159 recipient the maximum number of messages (including this one) that 160 will use the referenced CEK. This Attribute MUST only be sent when a 161 CEKReference attribute is also included. 163 The recipient SHOULD maintain the CEKReference information 164 (minimally the key identifier and the CEK value) while less than 165 maxDecrypt messages have been successfully received. Recipients 166 SHOULD delete the CEKReference information after some locally 167 configured period. 169 id-cek-maxDecrypts ::= OBJECT IDENTIFIER { TBD } 170 CEKMaxDecrypts ::= INTEGER 172 <> 177 When a recipient receives a message that contains a CEKReference 178 that it cannot use (for whatever reason), then the recipient MAY 179 respond to the originator with a message containing an 180 UnknownReference attribute. This attribute SHOULD be in either 181 signedAttrs or authenticatedAttrs, but MAY be in unsignedAttrs in an 182 otherwise empty SignedData. 184 id-kek-unknownReference::= OBJECT IDENTIFIER { TBD } 185 UnknownReference ::= OCTET STRING 187 The value of this MUST be the KEKIdentifier from the message that 188 caused the problem. 190 4. Using different CEK and KEK algorithms 192 Where MSG1.content-encryption algorithm and MSG2.key-encryption 193 algorithm are the same then the MSG2.KEK is the bit-reversal of 194 MSG1.CEK. However, in general, these algorithms MAY differ, e.g. 195 requiring different key lengths. This section specifies a generic 196 way to derive MSG2.KEK for such cases. 198 Implementations MAY include this functionality. 200 In this case the originator MUST include a KEKDerivationAlgorithm 201 attribute in MSG1, which indicates how to derive MSG2.KEK from 202 MSG1.CEK. This attribute has the following syntax: 204 id-kek-derivation-algorithm ::= OBJECT IDENTIFIER { TBD } 205 KEKDerivationAlgorithm ::= SEQUENCE { 206 algorithm OBJECT IDENTIFIER, 207 iv OCTET STRING OPTIONAL, 208 padding OCTET STRING OPTIONAL, 209 kekAlg AlgorithmIdentifier } 211 <> 217 In order to derive MSG2.KEK from MSG1.CEK the following algorithm is 218 used: 220 1. Randomly pick an IV if necessary and some padding bytes 221 2. DER encode the kekAlg value, producing kek-alg-d. kek-alg-d does 222 include the full DER encoding, that is, it begins with the '30'H 223 from the ASN.1 SEQUENCE. 224 3. Catenate the following values to produce CEK-input: 225 CEK-input = "padding-bytes||CEK||CEKReference||key-alg-d" 226 Note: the padding and CEKReference are both transmitted in the 227 KEKDerivationAlgorithm structure as ASN.1 OCTET STRINGS, but 228 CEK-input MUST NOT include OCTET STRING tags or lengths for 229 either. 230 4. Encrypt CEK-input using MSG1.content-encryption algorithm and 231 the CEK as key, with the IV generated in step 1, (if an IV is 232 necessary), giving KEK-input. 233 5. The KEK is the rightmost bits of KEK-input, as required by 234 MSG2.key-encryption-algorithm. 236 5. Security Considerations 238 Encryption does not provide authentication, for example, if the 239 encryptedContent is essentially random then recipients MUST NOT 240 assume that "knowing" a CEKReference value proves anything - anyone 241 could have created the EnvelopedData. This is relevant both for 242 security (the recovered plaintext should not be entirely random) and 243 for avoiding denial of service (the recipient MUST NOT assume that 244 using the right CEKReference means that message originator is 245 genuine). 247 Similarly, using the correct CEKReference does not mean that a 248 message has not been replayed or inserted, and recipients MUST NOT 249 assume that replay has been avoided. 251 The maxDecrypts field presents a potential denial-of-service attack 252 if a very large value is included by an originator in an attempt to 253 get a recipient to consume memory by storing the referenced CEKs for 254 a long period or if the originator never sends the indicated number 255 of ciphertexts. Recipients SHOULD therefore drop referenced CEKs 256 where the maxDecrypts value is too large (according to local 257 configuration) or the referenced CEK has been held for too long a 258 period. 260 <> 262 6. References 264 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630. 265 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 266 3", RFC 2026, BCP 9, October 1996. 267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 268 Requirement Levels", RFC 2119. 270 Author's Addresses 272 Stephen Farrell, 273 Baltimore Technologies, 274 61/62 Fitzwilliam Lane, 275 Dublin 2, 276 IRELAND 278 tel: +353-1-647-3000 279 email: stephen.farrell@baltimore.ie 281 Sean Turner 282 IECA, Inc. 283 9010 Edgepark Road 284 Vienna, VA 22182 285 USA 287 tel: +1.703.628.3180 288 email: turners@ieca.com 290 Full Copyright Statement 292 Copyright (C) The Internet Society (date). All Rights Reserved. 294 This document and translations of it may be copied and furnished to 295 others, and derivative works that comment on or otherwise explain it 296 or assist in its implementation may be prepared, copied, published 297 and distributed, in whole or in part, without restriction of any 298 kind, provided that the above copyright notice and this paragraph 299 are included on all such copies and derivative works. In addition, 300 the ASN.1 module presented in Appendix B may be used in whole or in 301 part without inclusion of the copyright notice. However, this 302 document itself may not be modified in any way, such as by removing 303 the copyright notice or references to the Internet Society or other 304 Internet organizations, except as needed for the purpose of 305 developing Internet standards in which case the procedures for 306 copyrights defined in the Internet Standards process shall be 307 followed, or as required to translate it into languages other than 308 English. 310 The limited permissions granted above are perpetual and will not be 311 revoked by the Internet Society or its successors or assigns. This 312 document and the information contained herein is provided on an "AS 313 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 314 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 315 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 316 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 317 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.