idnits 2.17.1 draft-ietf-smime-rcek-03.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 (May 2001) is 8381 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 2633 (ref. 'CMS-MSG') (Obsoleted by RFC 3851) ** Obsolete normative reference: RFC 2898 (Obsoleted by RFC 8018) Summary: 8 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 May 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. Conformance..................................................5 47 6. Security Considerations......................................5 48 7. References...................................................6 49 Author's Addresses..............................................6 50 Full Copyright Statement........................................6 51 Appendix A: ASN.1 Module........................................7 52 Appendix B: Revision History....................................9 54 1. Introduction 56 CMS [CMS] specifies EnvelopedData. EnvelopedData supports data 57 encryption using either symmetric or asymmetric key management 58 techniques. Since asymmetric key establishment is relatively 59 expensive, it is desirable in some environments to re-use a shared 60 content-encryption key established using asymmetric mechanisms for 61 encryption operations in subsequent messages. 63 The basic idea here is to reuse the content encryption key (CEK) 64 from a message (say MSG1) to derive the key encryption key (KEK) for 65 a later message, (MSG2), by including a reference value for the CEK 66 in message 1, and that same value as the KEKIdentifier for message 67 2. The CEK from message 1 is called the "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 protocol 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 - This specification is not suitable for general group key 96 management. 98 - The underlying cryptographic API is suitable: it is very likely 99 that any cryptographic API that completely "hides" the bits of 100 cryptographic keys from the CMS layer will prevent reuse of a 101 referenced CEK (since they won't have a primitive that allows 102 MSG1.CEK to be transformed to MSG2.KEK). 104 - The algorithms for content and key encryption have compatible key 105 values and strengths, that is, if MSG1.contentEncryptionAlgorithm 106 is a 40bit cipher and MSG2.keyEncryptionAlgorithm requires 168 107 bits of keying material, then this specification SHOULD NOT be 108 used. 110 There are other ways that could be envisaged to establish the 111 required symmetric keying material, e.g. by leveraging a group 112 keying scheme or by defining a content type that contains a KEK 113 value. Although this scheme is much simpler than generic group key 114 management, if an implementation already supports group key 115 management then this scheme doesn't add value. This scheme is also 116 suitable for inclusion in CMS libraries (though the addition of new 117 state might be a problem for some implementations), which can offer 118 some advantages over application layer schemes (e.g. where the 119 content includes MSG2.KEK). 121 3. How to do it 123 In order to reference the content-encryption key (CEK) used in an 124 EnvelopedData, a key identifier can be included in the 125 unprotectedAttrs field of MSG1. This key can then be used to derive 126 the key-encryption key (KEK) for other instances of EnvelopedData or 127 for other purposes. If the CEK from MSG1 is to be used to derive the 128 KEK for MSG2 then MSG1 MUST contain an unprotectedAttrs Attribute of 129 type id-aa-CEKReference with a single value using the CEKReference 130 syntax. 132 MSG2.KEK is to be derived by reversing the bytes of MSG1.CEK. The 133 byte reversal is to avoid an attack where the attacker has a known 134 plaintext and the related ciphertext (encrypted with MSG1.CEK) that 135 (otherwise) could be directly used as a MSG2.KEK. 137 The application MUST ensure that the relevant algorithms are 138 compatible. That is, a CEKReference attribute alone can only be used 139 where the content-encryption algorithm from MSG1 employs the same 140 type of symmetric key as the key-encryption algorithm from MSG2. 142 Notes: 144 1) There is nothing to prevent inclusion of a CEKReference attribute 145 in MSG2 as well as in MSG1. That is, an originator could "roll" 146 the referenced CEK with every message. 147 2) The CEKReference attribute can occur with any of the choices for 148 RecipientInfo: ktri, kari or kekri. Implementors MUST NOT assume 149 that CEKReference can only occur where ktri or kari is used. 151 id-aa-CEKReference OBJECT IDENTIFIER ::= { id-aa 30 } 152 CEKReference ::= OCTET STRING 154 id-aa is an object identifier defined in [CMS-MSG]. 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 maximally 2^31), 160 and indicates to the recipient the maximum number of messages 161 (excluding MSG1) that will use the referenced CEK. This Attribute 162 MUST only be sent when a 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 When this attribute is not present, originators and recipients 171 SHOULD behave as if a value of one had been sent. 173 id-aa-CEKMaxDecrypts OBJECT IDENTIFIER ::= { id-aa 31 } 174 CEKMaxDecrypts ::= INTEGER 176 4. Using different CEK and KEK algorithms 178 Where MSG1.content-encryption algorithm and MSG2.key-encryption 179 algorithm are the same then the MSG2.KEK is the byte-reverse of 180 MSG1.CEK. However, in general, these algorithms MAY differ, e.g. 181 requiring different key lengths. This section specifies a generic 182 way to derive MSG2.KEK for such cases. 184 Note: In some sense, the CEK and KEK algorithms are never the 185 "same", e.g. id-alg-CMS3DESwrap and des-ede3-cbc differ. However, 186 for the purposes of this specification, all we care about is that 187 the algorithms use the same format and size of keying material (see 188 also security considerations) and that they do not differ 189 significantly in terms of the resulting cryptographic "strength". In 190 that sense the two algorithms in the example above are the "same." 192 Implementations MAY include this functionality. 194 The basic approach is to use the PBKDF2 key derivation function 195 defined in PKCS#5 [RFC2898], but using MSG1.CEK as input instead of 196 a password. The output of the PBKDF2 function is MSG2.KEK. To this 197 end, a new attribute type is defined which allows passing of the 198 required parameters. 200 id-aa-KEKDerivationAlg OBJECT IDENTIFIER ::= { id-aa 32 } 201 KEKDerivationAlgorithm ::= SEQUENCE { 202 kekAlg AlgorithmIdentifier, 203 pbkdf2Param PBKDF2-params 204 } 206 kekAlg is the algorithm identifier (and associated parameters, if 207 any), for the MSG2 key encryption algorithm. Note that it is not 208 necessary to protect this field since modification of keyAlg only 209 represents a denial-of-service attack. 211 The PBKDF2 algorithm parameters are to be handled as follows: 213 - The salt MUST use the "specified" element of the CHOICE. 214 - The message originator selects the iterationCount. 215 - The value of keyLength is determined by the kekAlg and MUST be 216 present. 217 - The prf field MUST use the default algorithm specified in 218 [RFC2898] which is algid-hmacWithSHA1 (and so the prf field MUST 219 be omitted). 221 5. Conformance 223 This specification only applies to messages where the CEKReference 224 attribute is present. All attributes specified here SHOULD be 225 ignored unless they are present in a message containing a valid, new 226 or recognized, existing value of CEKReference. The CEKMaxDecrypts 227 attribute is to be treated by the recipient as a hint, but MUST be 228 honored by the originator. 230 The optional to implement KEKDerivationAlgorithm attribute MUST only 231 be present when MSG1.content-encryption-algorithm differs from 232 MSG2.key-encryption-algorithm, in which case it MUST be present. 233 Implementations that recognize this attribute, but do not support 234 the functionality SHOULD ignore the attribute. 236 Ignoring attributes as discussed above, will lead to decryption 237 failures. CMS implementations SHOULD be able to signal the 238 particular reason for this failure to the calling application. 240 6. Security Considerations 242 Encryption does not provide authentication, for example, if the 243 encryptedContent is essentially random then recipients MUST NOT 244 assume that "knowing" a CEKReference value proves anything - anyone 245 could have created the EnvelopedData. This is relevant both for 246 security (the recovered plaintext should not be entirely random) and 247 for avoiding denial of service (the recipient MUST NOT assume that 248 using the right CEKReference means that message originator is 249 genuine). 251 Similarly, using the correct CEKReference does not mean that a 252 message has not been replayed or inserted, and recipients MUST NOT 253 assume that replay has been avoided. 255 The maxDecrypts field presents a potential denial-of-service attack 256 if a very large value is included by an originator in an attempt to 257 get a recipient to consume memory by storing the referenced CEKs for 258 a long period or if the originator never sends the indicated number 259 of ciphertexts. Recipients SHOULD therefore drop referenced CEKs 260 where the maxDecrypts value is too large (according to local 261 configuration) or the referenced CEK has been held for too long a 262 period. 264 Suppose MSG1 is sent to a set S1 of users. In the case where MSG2 is 265 sent to only a subset of users in S1, all users from S1 will still 266 be able to decrypt MSG2 (since MSG2.KEK is computed only from 267 MSG1.CEK). Implementers should be aware that in such cases, all 268 members of the original set of recipients (S1) can access the 269 plaintext of MSG2 and subsequent messages. 271 The reason for the byte reversal is as follows: without the byte 272 reversal, an attacker knowing some of MSG1.plaintext (a prefix in a 273 field for instance) can use the corresponding ciphertext block as 274 the next encrypted CEK, i.e. as MSG2.KEKRecipientInfo.encryptedKey. 275 Now the attacker knows the next CEK. This attacks something this 276 note is not claiming to protect (origin authentication), but is 277 easily avoided using the byte reversal. Byte-reversal was chosen 278 over bit-reversal since bit-reversal would cause parity bits from 279 MSG1.CEK to be used as keying bits for MSG2.KEK for DES-based 280 algorithms. Note that byte reversal would similarly affect parity if 281 parity checks spanned more than one octet, however no well-known 282 algorithms operate in this way. 284 7. References 286 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630. 287 [CMS-MSG] Ramsdell, B. "S/MIME Version 3 Message Specification", 288 RFC 2633. 289 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 290 Specification Version 2.0", RFC 2898, September 2000. 291 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 292 3", RFC 2026, BCP 9, October 1996. 293 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 294 Requirement Levels", RFC 2119. 296 Author's Addresses 298 Stephen Farrell, 299 Baltimore Technologies, 300 39 Parkgate Street, 301 Dublin 8 302 IRELAND 304 tel: +353-1-881-6000 305 email: stephen.farrell@baltimore.ie 307 Sean Turner 308 IECA, Inc. 309 9010 Edgepark Road 310 Vienna, VA 22182 311 USA 313 tel: +1.703.628.3180 314 email: turners@ieca.com 316 Full Copyright Statement 317 Copyright (C) The Internet Society (date). All Rights Reserved. 319 This document and translations of it may be copied and furnished to 320 others, and derivative works that comment on or otherwise explain it 321 or assist in its implementation may be prepared, copied, published 322 and distributed, in whole or in part, without restriction of any 323 kind, provided that the above copyright notice and this paragraph 324 are included on all such copies and derivative works. In addition, 325 the ASN.1 module presented in Appendix B may be used in whole or in 326 part without inclusion of the copyright notice. However, this 327 document itself may not be modified in any way, such as by removing 328 the copyright notice or references to the Internet Society or other 329 Internet organizations, except as needed for the purpose of 330 developing Internet standards in which case the procedures for 331 copyrights defined in the Internet Standards process shall be 332 followed, or as required to translate it into languages other than 333 English. 335 The limited permissions granted above are perpetual and will not be 336 revoked by the Internet Society or its successors or assigns. This 337 document and the information contained herein is provided on an "AS 338 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 339 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 340 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 341 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 342 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 344 Appendix A: ASN.1 Module 346 SMIMERcek 347 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 348 smime(16) modules(0) rcek(13) } 350 -- This module contains the definitions of the attributes 351 -- used for re-using the content encryption key from a 352 -- message in further messages. 354 DEFINITIONS IMPLICIT TAGS ::= 356 BEGIN 358 -- EXPORTS ALL -- 360 IMPORTS 362 AlgorithmIdentifier FROM 363 AuthenticationFramework { joint-iso-itu-t ds(5) 364 module(1) authenticationFramework(7) 3 } ; 366 -- [RFC2898] uses 1993 ASN.1 to define PBKDF2-params. Since 367 -- this specification only uses 1988 ASN.1, the definition is 368 -- repeated here for completeness. 370 -- The DEFAULT prf field value, MUST be used for this 371 -- specification 372 digestAlgorithm OBJECT IDENTIFIER ::= 373 { iso(1) member-body(2) us(840) rsadsi(113549) 2} 374 id-hmacWithSHA1 OBJECT IDENTIFIER ::= {digestAlgorithm 7} 376 -- [RFC2898] defines PBKDF2-params using 1993 ASN.1, which 377 -- results in the same encoding as produced by the definition 378 -- below. See [RFC2898] for that definition. 380 PBKDF2-params ::= SEQUENCE { 381 salt CHOICE { 382 specified OCTET STRING, -- MUST BE USED 383 otherSource AlgorithmIdentifier -- DO NOT USE THIS FIELD 384 }, 385 iterationCount INTEGER (1..MAX), 386 keyLength INTEGER (1..MAX) OPTIONAL 387 } 389 -- id-aa is the arc with all new authenticated and 390 -- unauthenticated attributes produced the by S/MIME 391 -- Working Group. It is also defined in [CMS-MSG] 393 id-aa OBJECT IDENTIFIER ::= 394 {iso(1) member-body(2) usa(840) rsadsi(113549) 395 pkcs(1) pkcs-9(9) smime(16) attributes(2)} 397 -- This attribute contains what will be the key identifier 398 -- for subsequent messages 399 id-aa-CEKReference OBJECT IDENTIFIER ::= { id-aa 30 } 400 CEKReference ::= OCTET STRING 402 -- This attribute contains a "hint" to the recipient 403 -- indicating how many times the originator will use 404 -- the re-used CEK 405 id-aa-CEKMaxDecrypts OBJECT IDENTIFIER ::= { id-aa 31 } 406 CEKMaxDecrypts ::= INTEGER 408 -- This attribute specifies the key derivation function 409 -- to be used when the default byte reversal operation cannot 410 -- be used. 411 id-aa-KEKDerivationAlg OBJECT IDENTIFIER ::= { id-aa 32 } 412 KEKDerivationAlgorithm ::= SEQUENCE { 413 kekAlg AlgorithmIdentifier, 414 pbkdf2Param PBKDF2-params } 416 END 418 Appendix B: Revision History 420 Note to RFC editor: Please delete this section. 422 Changes from -00 to -01: 424 - Removed error flag attribute, since this is the responsibility of 425 a consuming protocol 426 - Change the key derivation from home-grown to use pkcs#5 scheme 427 - Added compilable ASN.1 module 429 Changes from -01 to -02: 431 - Changed default KDF from bit to byte reversal to avoid parity-bit 432 problems 433 - Added allocated OIDs for module and attributes 434 - Added more justification text to section 2 435 - Added conformance text (new section 5) 436 - Added security consideration about subset of recipients 437 - Added security consideration describing reason for byte reversal 438 - Changed from unidirectional since Diameter may need bi-directional 439 - Copied kdf params stuff from rfc2898 since it uses '93 ASN.1 440 - Changed so that max decrypts=1, implies that one more message can 441 re-use the CEK (used to be silly where a value of 1 meant no more) 443 Changes from -02 to -03 445 - Removed extra comma from ASN.1 module 446 - Reworded section 4, para 6