idnits 2.17.1 draft-ietf-smime-password-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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 394 lines 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. ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- 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 (December 1999) is 8899 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) -- Missing reference section? 'CMS' on line 45 looks like a reference -- Missing reference section? 'ASN1' on line 47 looks like a reference -- Missing reference section? 'RFC2119' on line 52 looks like a reference -- Missing reference section? '1' on line 68 looks like a reference -- Missing reference section? '2' on line 69 looks like a reference -- Missing reference section? '3' on line 70 looks like a reference -- Missing reference section? 'PKCS5v2' on line 133 looks like a reference -- Missing reference section? 'PACKAGE' on line 167 looks like a reference -- Missing reference section? 'RC2' on line 239 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Editor: Peter Gutmann 2 draft-ietf-smime-password-00.txt University of Auckland 3 June 15, 1999 4 Expires December 1999 6 Password-based Encryption for S/MIME 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 The Cryptographic Message Syntax data format doesn't currently contain 31 any provisions for password-based data encryption. This document 32 provides a method of encrypting data using user-supplied passwords 33 (and, by extension, any form of variable-length keying material which 34 isn't necessarily an algorithm-specific fixed-format key). 36 This draft is being discussed on the "ietf-smime" mailing list. To 37 join the list, send a message to with the 38 single word "subscribe" in the body of the message. Also, there is a 39 Web site for the mailing list at . 41 1. Introduction 43 This document describes a password-based content encryption mechanism 44 for S/MIME. This is implemented as a new RecipientInfo type and is an 45 extension to the RecipientInfo types currently defined in CMS [CMS]. 47 The format of the messages are described in ASN.1:1994 [ASN1]. 49 The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", 50 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 51 interpreted as described in [RFC2119]. 53 1.1 Password-based Content Encryption 55 CMS currently defined three recipient information types for public-key 56 key wrapping (KeyTransRecipientInfo), conventional key wrapping 57 (KEKRecipientInfo), and key agreement (KeyAgreeRecipientInfo). The 58 recipient information described here adds a fourth type, 59 PasswordRecipientInfo, which provides for password-based key wrapping. 61 1.2 RecipientInfo Types 63 The new recipient information type is an extension to the RecipientInfo 64 type defined in section 6.2 of CMS, extending the types to: 66 RecipientInfo ::= CHOICE { 67 ktri KeyTransRecipientInfo, 68 kari [1] KeyAgreeRecipientInfo, 69 kekri [2] KEKRecipientInfo, 70 pwri [3] PasswordRecipientinfo -- New RecipientInfo type 71 } 73 Although the recipient information generation process is described in 74 terms of a password-based operation (since this will be its most common 75 use), the transformation employed is a general-purpose key derivation 76 one which allows any type of keying material to be converted into a key 77 specific to a particular content-encryption algorithm. 79 1.2.1 PasswordRecipientInfo Type 81 Recipient information using a user-supplied password is represented in 82 the type PasswordRecipientInfo. Each instance of PasswordRecipientInfo 83 will transfer the content-encryption key (CEK) to one or more 84 recipients who have the previously agreed-upon password. 86 PasswordRecipientInfo ::= SEQUENCE { 87 version CMSVersion, -- Always set to 0 88 keyDerivationAlgorithm KeyDerivationAlgorithmIdentifier, 89 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 90 encryptedKey EncryptedKey } 92 The fields of type PasswordRecipientInfo have the following meanings: 94 version is the syntax version number. It shall always be 0. 96 keyDerivationAlgorithm identifies the key-derivation algorithm, and 97 any associated parameters, used to derive the key-encryption key 98 (KEK) from the user-supplied password. 100 keyEncryptionAlgorithm identifies the content-encryption algorithm, 101 and any associated parameters, used to encrypt the CEK with the 102 password-derived KEK. 104 encryptedKey is the result of encrypting the content-encryption key 105 with the password-derived KEK. 107 1.2.2 Rationale 109 Password-based key wrapping is a two-stage process, a first stage in 110 which the user-supplied password is converted into a KEK, and a second 111 stage in which the KEK is used to encrypt a CEK. These two stages are 112 identified by the two algorithm identifiers. Although the PKCS #5 113 standard goes one step further to wrap these up into a single algorithm 114 identifier, this design is particular to that standard and may not be 115 applicable for other password-based key wrapping standards. For this 116 reason the two steps are specified separately. 118 2 Supported Algorithms 120 This section lists the algorithms that must be implemented. Additional 121 algorithms that should be implemented are also included. 123 2.1 Key Derivation Algorithms 125 These algorithms are used to convert the password into a KEK. The key 126 derivation algorithms are: 128 KeyDerivationAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= { 129 { SYNTAX PBKDF2-params IDENTIFIED BY id-PBKDF2 }, 130 ... 131 } 133 CMS implementations must include PBKDF2 [PKCS5v2]. 135 2.2 Key Encryption Algorithms 137 These algorithms are used to encrypt the content (the key) using the 138 derived KEK. The content encryption algorithms are: 140 KeyEncryptionAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= PBES2-Encs 142 CMS implementations must include Triple-DES in CBC mode, should include 143 RC2 in CBC mode, and may include other algorithms such as CAST-128, 144 RC5, IDEA, Skipjack, and encryption modes as required. CMS 145 implementations should not include any KSG ciphers such as RC4 or a 146 block cipher in OFB mode, and should not include a block cipher in ECB 147 mode. The use of RC2 has special requirements, see section 2.4 for 148 details. 150 2.3 Symmetric Key Encryption Algorithms 152 The key wrap algorithm is used to wrap the CEK with the KEK. There is 153 no requirement that the content-encryption algorithm match the KEK 154 algorithm, although care should be taken to ensure that, if different 155 algorithms are used, they offer an equivalent level of security (for 156 example wrapping a Triple-DES key with an RC2/40 key leads to a severe 157 impedance mismatch in encryption strength). 159 The key wrap algorithm specified below is independent of the 160 content-encryption or wrapping algorithms, relying only on the use of a 161 block cipher to perform the wrapping. 163 2.3.1 Key Wrap 165 The key wrap algorithm encrypts a CEK with a KEK in a manner which 166 ensures that every bit of plaintext effects every bit of ciphertext. 167 This makes it equivalent in function to the package transform [PACKAGE] 168 without requiring additional mechanisms or resources such as hash 169 functions or cryptographically strong random numbers. The key wrap 170 algorithm is as follows: 172 1. Pad the key out to a multiple of the KEK cipher block size using 173 random data so that the total data size is at least two KEK cipher 174 blocks long. The padding data does not have to be 175 cryptographically strong, although unpredictability helps. 177 2. Encrypt the padded key using the KEK. 179 3. Without resetting the IV (that is, using the last ciphertext block 180 as the IV), encrypt the encrypted padded key a second time. 182 The resulting double-encrypted data is the EncryptedKey. 184 2.3.2 Key Unwrap 186 1. Using the n-1'th ciphertext block as the IV, decrypt the n'th 187 ciphertext block. 189 2. Using the decrypted n'th ciphertext block as the IV, decrypt the 190 1st ... n-1'th ciphertext blocks. This strips the outer layer of 191 encryption. 193 3. Decrypt the inner layer of encryption using the KEK. 195 The size of the key in the padded data is determined by the algorithm 196 specified in the ContentEncryptionAlgorithmIdentifier. 198 2.3.3 Example 200 Given a content-encryption algorithm of Skipjack and a KEK algorithm of 201 Triple-DES, the wrap steps are as follows: 203 1. Pad the 80-bit (10-byte) Skipjack CEK to 16 bytes (two triple-DES 204 blocks) using 6 bytes of random data. 206 2. Using the IV given in the KeyEncryptionAlgorithmIdentifer, 207 encrypted the padded Skipjack key. 209 3. Without resetting the IV, encrypt the encrypted padded key a 210 second time. 212 The unwrap steps are as follows: 214 1. Using the first 8 bytes of the double-encrypted key as the IV, 215 decrypt the second 8 bytes. 217 2. Without resetting the IV, decrypt the first 8 bytes. 219 3. Decrypt the inner layer of encryption using the the IV given in 220 the KeyEncryptionAlgorithmIdentifer to recover the padded Skipjack 221 key. 223 2.3.4 Rationale for the Double Wrapping 225 If many CEK's are encrypted in a standard way with the same KEK and the 226 KEK has a 64-bit block size then after about 2^32 encryptions there is 227 a high probability of a collision between different blocks of encrypted 228 CEK's. If an opponent manages to obtain a CEK, they may be able to 229 solve for other CEK's. The double-encryption wrapping process, which 230 makes every bit of ciphertext dependent on every bit of the CEK, 231 eliminates this collision problem. Since the IV is applied to the 232 inner layer of encryption, even wrapping the same CEK with the same KEK 233 will result in a completely different wrapped key each time. 235 2.4 Special Handling for RC2 Keys 237 For a variety of historical, political, and software-peculiarity 238 reasons which are beyond the scope of this document, the handling of 239 keys for the RC2 algorithm [RC2] by different implementations is 240 somewhat arbitrary. In particular, the choice of actual vs effective 241 key bits used in the algorithm is often unclear. The standard RC2 242 AlgorithmIdentifier only allows the effective key bits to be specified, 243 leaving the actual key bits to be communicated via out-of-band means, 244 which in some cases means hardcoding them into applications. Solving 245 this problem requires two things, a precise definition of how keys 246 represented with the standard RC2 AlgorithmIdentifier are handled, and 247 a new RC2 AlgorithmIdentifier which allows keys currently in use by 248 different applications to be handled. 250 2.4.1 Handling of RC2 with RFC 2268 AlgorithmIdentifier 252 RFC 2268 defines the following AlgorithmIdentifier for RC2: 254 rc2CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) US(840) 255 rsadsi(113549) encryptionAlgorithm(3) 2} 257 RC2-CBCParameter ::= CHOICE { 258 iv IV, 259 params SEQUENCE { 260 version INTEGER, 261 iv OCTET STRING 262 } 263 } 265 where the version field encodes the effective key size in a complex 266 manner specified in the RFC. Where this algorithm identifier is used, 267 the actual key size shall be 128 bits, and the effective key size is 268 given by the version field. When RC2 is to be used, implementations 269 should use this AlgorithmIdentifier and parameters, and when this 270 AlgorithmIdentifier is used the actual key size must not be a value 271 other than 128 bits (to use a different size, see section 2.4.2). 273 2.4.2 Handling of RC2 with Other Key Sizes 275 If the use of an actual key size of other than 128 bits is required, 276 implementations must use the following AlgorithmIdentifier: 278 rc2CBC OBJECT IDENTIFIER ::= {1 3 6 1 4 1 3029 666 13} (provisional) 279 RC2-CBCParameter ::= SEQUENCE { 280 actualKeySize INTEGER, -- Actual key size in bits 281 effectiveKeySize INTEGER, -- Effective key size in bits 282 iv OCTET STRING 283 } 285 This allows arbitrary actual and effective key sizes to be specified 286 for compatibility with existing usage. Although implementations should 287 not use this alternative (using instead the one in section 2.4.1) 288 experience has shown that implementors will continue to use oddball RC2 289 parameters anyway, so new implementations should be prepared to 290 encounter and handle actual and effective key sizes ranging from 40 up 291 to around 200 bits. 293 2.4.3 Rationale 295 The reason for providing for the handling of oddball key sizes is 296 compatibility with existing applications, for example a mailing-list 297 exploder or mail gateway may take an RSA-wrapped CEK generated by a 298 current application and repackage it with a KEK, so we need a mechanism 299 for handling strange key lengths in a manner which is compatible with 300 existing usage. The alternative RC2 AlgorithmIdentifier, although not 301 recommended, provides a means of ensuring this compatibility. 303 3. Security Considerations 305 The security of this recipient information type rests on the security 306 of the underlying mechanisms employed, for which further information 307 can be found in CMS and PKCS5v2. 309 Author Address 311 Peter Gutmann 312 University of Auckland 313 Private Bag 92019 314 Auckland, New Zealand 315 pgut001@cs.auckland.ac.nz 317 References 319 ASN1 Recommendation X.680: Specification of Abstract Syntax Notation 320 One (ASN.1), 1994. 322 CMS Cryptographic Message Syntax, draft-ietf-smime-cms-11.txt, Russ 323 Housley, April 1999. 325 PKCS5v2 PKCS #5 v2.0: Password-Based Cryptography Standard, RSA 326 Laboratories, 25 March 1999. 328 RFC2119 Key Words for Use in RFC's to Indicate Requirement Levels, 329 S.Bradner, March 1997. 331 RFC2268 A Description of the RC2(r) Encryption Algorithm, R.Rivest, 332 March 1998. 334 PACKAGE All-or-Nothing Encryption and the Package Transform, 335 R.Rivest, Proceedings of Fast Software Encryption '97, Haifa, 336 Israel, January 1997. 338 Appendix A: ASN.1 Module 340 PasswordRecipientInfo 341 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 342 smime(16) modules(0) pwri(n+1) } 344 DEFINITIONS IMPLICIT TAGS ::= 345 BEGIN 347 IMPORTS 349 FROM PKCS5 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 350 pkcs-5(5) } 351 PBKDF2-params, PBES2-Encs; 353 PasswordRecipientInfo ::= SEQUENCE { 354 version CMSVersion, -- Always set to 0 355 keyDerivationAlgorithm KeyDerivationAlgorithmIdentifier, 356 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier, 357 encryptedKey EncryptedKey } 359 KeyDerivationAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= { 360 { SYNTAX PBKDF2-params IDENTIFIED BY id-PBKDF2 }, 361 ... 362 } 364 KeyEncryptionAlgorithmIdentifer ALGORITHM-IDENTIFIER ::= PBES2-Encs 366 END 368 Full Copyright Statement 370 Copyright (C) The Internet Society 1999. All Rights Reserved. 372 This document and translations of it may be copied and furnished to 373 others, and derivative works that comment on or otherwise explain it or 374 assist in its implementation may be prepared, copied, published and 375 distributed, in whole or in part, without restriction of any kind, 376 provided that the above copyright notice and this paragraph are 377 included on all such copies and derivative works. However, this 378 document itself may not be modified in any way, such as by removing the 379 copyright notice or references to the Internet Society or other 380 Internet organizations, except as needed for the purpose of developing 381 Internet standards in which case the procedures for copyrights defined 382 in the Internet Standards process must be followed, or as required to 383 translate it into languages other than English. 385 The limited permissions granted above are perpetual and will not be 386 revoked by the Internet Society or its successors or assigns. 388 This document and the information contained herein is provided on an 389 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 390 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 391 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 392 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 393 FITNESS FOR A PARTICULAR PURPOSE.