idnits 2.17.1 draft-ietf-smime-rcek-01.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? == 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 (February 2001) is 8468 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) ** Obsolete normative reference: RFC 2898 (Obsoleted by RFC 8018) Summary: 7 errors (**), 0 flaws (~~), 2 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 February 2001 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...................................................5 48 Author's Addresses..............................................5 49 Full Copyright Statement........................................6 50 Appendix A: ASN.1 Module........................................6 51 Appendix B: Revision History....................................7 53 1. Introduction 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 derive 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-rcek-attrs ::= OBJECT IDENTIFIER { TBD } 154 id-cek-reference ::= OBJECT IDENTIFIER { id-rcek-attrs 1} 155 CEKReference ::= OCTET STRING 156 In order to allow the originator of MSG1 to indicate the "lifetime" 157 of the CEK, the originator MAY include a CEKMaxDecrypts attribute, 158 also in the unprotectedAttrs field of EnvelopedData. This attribute 159 has an INTEGER syntax (the value MUST be >=1), and indicates to the 160 recipient the maximum number of messages (including this one) that 161 will use the referenced CEK. This Attribute MUST only be sent when a 162 CEKReference attribute is also included. 164 The recipient SHOULD maintain the CEKReference information 165 (minimally the key identifier and the CEK value) while less than 166 maxDecrypt messages have been successfully received. Recipients 167 SHOULD delete the CEKReference information after some locally 168 configured period. 170 id-cek-maxDecrypts ::= OBJECT IDENTIFIER { id-rcek-attrs 2} 171 CEKMaxDecrypts ::= INTEGER 173 4. Using different CEK and KEK algorithms 175 Where MSG1.content-encryption algorithm and MSG2.key-encryption 176 algorithm are the same then the MSG2.KEK is the bit-reversal of 177 MSG1.CEK. However, in general, these algorithms MAY differ, e.g. 178 requiring different key lengths. This section specifies a generic 179 way to derive MSG2.KEK for such cases. 181 Implementations MAY include this functionality. 183 The basic approach is to use the PBKDF2 key derivation function 184 defined in PKCS#5 [RFC2898], but using MSG1.CEK as input instead of 185 a password. The output of the PBKDF2 function is MSG2.KEK. To this 186 end, a new attribute type is defined which allows passing of the 187 required parameters. 189 id-kek-derivation-algorithm ::= OBJECT IDENTIFIER { id-rcek-attrs 3} 190 KEKDerivationAlgorithm ::= SEQUENCE { 191 kekAlg AlgorithmIdentifier, 192 pbkdf2Param PBKDF2-params 193 } 195 keyAlg is the algorithm identifier (and associated parameters, if 196 any), for the MSG2 key encryption algorithm. Note that it is not 197 necessary to protect this field MSG.KEK is only used by the 198 originator. 200 The PBKDF2 algorithm parameters are to be handled as follows: 202 - The salt MUST use the "specified" element of the CHOICE. 203 - The message originator selects the iterationCount. 204 - The value of keyLength is determined by the kekAlg and MUST be 205 present. 207 - The prf field MUST use the DEFAULT algorithm specified in 208 [RFC2898] which is algid-hmacWithSHA1. 210 5. Security Considerations 212 Encryption does not provide authentication, for example, if the 213 encryptedContent is essentially random then recipients MUST NOT 214 assume that "knowing" a CEKReference value proves anything - anyone 215 could have created the EnvelopedData. This is relevant both for 216 security (the recovered plaintext should not be entirely random) and 217 for avoiding denial of service (the recipient MUST NOT assume that 218 using the right CEKReference means that message originator is 219 genuine). 221 Similarly, using the correct CEKReference does not mean that a 222 message has not been replayed or inserted, and recipients MUST NOT 223 assume that replay has been avoided. 225 The maxDecrypts field presents a potential denial-of-service attack 226 if a very large value is included by an originator in an attempt to 227 get a recipient to consume memory by storing the referenced CEKs for 228 a long period or if the originator never sends the indicated number 229 of ciphertexts. Recipients SHOULD therefore drop referenced CEKs 230 where the maxDecrypts value is too large (according to local 231 configuration) or the referenced CEK has been held for too long a 232 period. 234 6. References 236 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630. 237 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 238 Specification Version 2.0", RFC 2898, February 2001. 239 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 240 3", RFC 2026, BCP 9, October 1996. 241 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 242 Requirement Levels", RFC 2119. 244 Author's Addresses 246 Stephen Farrell, 247 Baltimore Technologies, 248 39 Parkgate Street, 249 Dublin 8 250 IRELAND 252 tel: +353-1-881-6000 253 email: stephen.farrell@baltimore.ie 255 Sean Turner 256 IECA, Inc. 258 9010 Edgepark Road 259 Vienna, VA 22182 260 USA 262 tel: +1.703.628.3180 263 email: turners@ieca.com 265 Full Copyright Statement 267 Copyright (C) The Internet Society (date). All Rights Reserved. 269 This document and translations of it may be copied and furnished to 270 others, and derivative works that comment on or otherwise explain it 271 or assist in its implementation may be prepared, copied, published 272 and distributed, in whole or in part, without restriction of any 273 kind, provided that the above copyright notice and this paragraph 274 are included on all such copies and derivative works. In addition, 275 the ASN.1 module presented in Appendix B may be used in whole or in 276 part without inclusion of the copyright notice. However, this 277 document itself may not be modified in any way, such as by removing 278 the copyright notice or references to the Internet Society or other 279 Internet organizations, except as needed for the purpose of 280 developing Internet standards in which case the procedures for 281 copyrights defined in the Internet Standards process shall be 282 followed, or as required to translate it into languages other than 283 English. 285 The limited permissions granted above are perpetual and will not be 286 revoked by the Internet Society or its successors or assigns. This 287 document and the information contained herein is provided on an "AS 288 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 289 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 290 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 291 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 292 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 294 Appendix A: ASN.1 Module 296 SMIMERcek 297 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 298 smime(16) modules(0) rcek(TBD) } 300 DEFINITIONS EXPLICIT --<>-- TAGS ::= 302 BEGIN 304 -- EXPORTS ALL -- 306 IMPORTS 308 PBKDF2-Params FROM 309 PKCS5 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 310 pkcs-5(5) } ; 312 id-rcek-attrs ::= OBJECT IDENTIFIER { TBD } 314 id-cek-reference ::= OBJECT IDENTIFIER { id-rcek-attrs 1} 315 CEKReference ::= OCTET STRING 317 id-cek-maxDecrypts ::= OBJECT IDENTIFIER { id-rcek-attrs 2} 318 CEKMaxDecrypts ::= INTEGER 320 id-kek-derivation-algorithm ::= OBJECT IDENTIFIER 321 { id-rcek-attrs 3} 322 KEKDerivationAlgorithm ::= SEQUENCE { 323 kekAlg AlgorithmIdentifier, 324 pbkdf2Param PBKDF2-params } 326 END 328 Appendix B: Revision History 330 Changes from -00 to -01: 332 - Removed error flag attribute, since this is the responsibility of 333 a consuming protocol 334 - Change the key derivation from home-grown to use pkcs#5 scheme 335 - Added compilable ASN.1 module