idnits 2.17.1 draft-ietf-smime-idea-06.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 Internet-Drafts being working documents. == 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 331 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** 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.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 52: '...ument, the terms MUST, MUST NOT, SHOUL...' RFC 2119 keyword, line 91: '...iv OCTET STRING OPTIONAL } -- exactly...' RFC 2119 keyword, line 93: '...ied as above, it MUST be used as initi...' RFC 2119 keyword, line 94: '..., the ciphertext MUST NOT include the ...' RFC 2119 keyword, line 95: '...irst 64 bits of the ciphertext MUST be...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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? 'IDEA' on line 244 looks like a reference -- Missing reference section? 'CMS' on line 221 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 229 looks like a reference -- Missing reference section? 'PKCS7' on line 232 looks like a reference -- Missing reference section? 'SMIME3' on line 226 looks like a reference -- Missing reference section? 'SMIME2' on line 223 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft S. Teiwes, 2 draft-ietf-smime-idea-06.txt P. Hartmann, 3 August 7, 2000 D. Kuenzi 4 Expires in six months iT_Security AG (Ltd.) 6 Use of the IDEA Encryption Algorithm in CMS 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of section 10 of RFC2026. Internet-Drafts are 12 working documents of the Internet Engineering Task Force (IETF), 13 its areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other documents 18 at any time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 To view the entire list of current Internet-Drafts, please check the 28 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 29 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 30 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 31 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 33 1. Introduction 35 This memo specifies how to incorporate IDEA (International Data 36 Encryption Algorithm) [IDEA] into CMS [CMS] or S/MIME [SMIME2, 37 SMIME3] as an additional strong algorithm for symmetric encryption. 38 For organizations who make use of IDEA for data security purposes 39 it is of high interest that IDEA is also available in S/MIME. 40 The intention of this memo is to provide the OIDs and algorithms 41 required that IDEA can be included in S/MIME for symmetric content 42 and key encryption. 44 The general functional capabilities and preferences of S/MIME are 45 specified by the registered list of S/MIME object identifiers (OIDs). 46 This list of OIDs is available from the Internet Mail Consortium at 47 . 48 The set of S/MIME functions provided by a client is expressed by the 49 S/MIME capabilities attribute. This attribute contains a list of OIDs 50 of supported cryptographic functions. 52 In this document, the terms MUST, MUST NOT, SHOULD, and SHOULD NOT 53 are used in capital letters. This conforms to the definitions in 54 [MUSTSHOULD]. 56 2. Object Identifier for Content and Key Encryption 58 The Cryptographic Message Syntax [CMS], derived from PKCS#7 [PKCS7], 59 is the framework for the implementation of cryptographic functions in 60 S/MIME. It specifies data formats and encryption processes without 61 naming the cryptographic algorithms. Each algorithm which is used 62 for encryption purposes must be specified by a unique algorithm 63 identifier. For example, in the special case of content encryption 64 the ContentEncryptionAlgorithmIdentifier specifies the algorithm to 65 be applied. However, according to [CMS] any symmetric encryption 66 algorithm that a CMS implementation includes as a content-encryption 67 algorithm must also be included as a key-encryption algorithm. 69 IDEA is added to the set of optional symmetric encryption algorithms 70 in S/MIME by providing two unique object identifiers (OIDs). One OID 71 defines content encryption and the other one key encryption. Thus an 72 S/MIME agent can apply IDEA either for content or key encryption by 73 selecting the corresponding object identifier, supplying the required 74 parameter, and starting the program code. 76 For content encryption the use of IDEA in cipher block chaining (CBC) 77 mode is recommended. The key length is fixed to 128 bits. 79 The IDEA content-encryption algorithm in CBC mode has the object 80 identifier 82 IDEA-CBC OBJECT IDENTIFIER 83 ::= { iso(1) identified-organization(3) 84 usdod(6) oid(1) private(4) enterprises(1) 85 ascom(188) systec(7) security(1) algorithms(1) 2 } 87 The identifier's parameters field contains the initialization 88 vector (IV) as an optional parameter. 90 IDEA-CBCPar ::= SEQUENCE { 91 iv OCTET STRING OPTIONAL } -- exactly 8 octets 93 If IV is specified as above, it MUST be used as initial vector. In 94 this case, the ciphertext MUST NOT include the initial vector. If 95 IV is not specified, the first 64 bits of the ciphertext MUST be 96 considered as the initial vector. However, this alternative of not 97 including the IV SHOULD NOT be applied in CMS or S/MIME. 99 The key-wrap/unwrap algorithms used to encrypt/decrypt an IDEA 100 content-encryption key with an IDEA key-encryption key are 101 specified in the following section. Generation and distribution 102 of IDEA key-encryption keys are beyond the scope of this document. 104 The IDEA key-encryption algorithm has the object identifier 106 id-alg-CMSIDEAwrap OBJECT IDENTIFIER 107 ::= { iso(1) identified-organization(3) 108 usdod(6) oid(1) private(4) enterprises(1) 109 ascom(188) systec(7) security(1) algorithms(1) 6 } 111 The identifier's parameters field MUST be NULL. 113 3. Key-Wrapping and Unwrapping 115 In the following subsections IDEA key-wrap and key-unwrap algorithms 116 are specified in conformance with [CMS], section 12.3. 118 3.1 IDEA Key Wrap 120 The IDEA key-wrap algorithm encrypts an IDEA content-encryption key 121 with an IDEA key-encryption key. The IDEA key-wrap algorithm is 122 defined by: 124 1. Let the content-encryption key (16 octets) be called CEK 125 2. Compute an 8 octet key checksum value on CEK as described 126 in [CMS], section 12.6.1, call the result ICV. 127 3. Let CEKICV := CEK || ICV. 128 4. Generate 8 octets at random, call the result IV. 129 5. Encrypt CEKICV using IDEA in CBC mode and the key-encryption key. 130 Use the random value generated in the previous step as the 131 initialization vector (IV). Call the ciphertext TEMP1. 132 6. Let TEMP2 = IV || TEMP1. 133 7. Reverse the order of the octets in TEMP2. That is, the most 134 significant (first) octet is swapped with the least significant 135 (last) octet, and so on. Call the result TEMP3. 136 8. Encrypt TEMP3 using IDEA in CBC mode and the key-encryption key. 137 Use an initialization vector (IV) of 0x4adda22c79e82105. 138 The ciphertext is 32 octets long. 140 3.2 IDEA Key Unwrap 142 The IDEA key-unwrap algorithm decrypts an IDEA content-encryption key 143 using an IDEA key-encryption key. The IDEA key-unwrap algorithm is 144 defined by: 146 1. If the wrapped content-encryption key is not 32 octets, then 147 error. 148 2. Decrypt the wrapped content-encryption key using IDEA in CBC mode 149 with the key-encryption key. Use an initialization vector (IV) 150 of 0x4adda22c79e82105. Call the output TEMP3. 151 3. Reverse the order of the octets in TEMP3. That is, the most 152 significant (first) octet is swapped with the least significant 153 (last) octet, and so on. Call the result TEMP2. 154 4. Decompose the TEMP2 into IV and TEMP1. IV is the most significant 155 (first) 8 octets, and TEMP1 is the remaining (last) 24 octets. 156 5. Decrypt TEMP1 using IDEA in CBC mode with the key-encryption key. 157 Use the IV value from the previous step as the initialization 158 vector. Call the plaintext CEKICV. 159 6. Decompose the CEKICV into CEK and ICV. CEK is the most 160 significant (first) 16 octets, and ICV is the least significant 161 (last) 8 octets. 162 7. Compute an 8 octet key checksum value on CEK as described 163 in [CMS], section 12.6.1. If the computed key checksum value 164 does not match the decrypted key checksum value, ICV, then error. 165 8. Use CEK as the content-encryption key. 167 4. SMIMECapabilities Attribute 169 An S/MIME client can announce the set of cryptographic functions 170 it supports by using the S/MIME capabilities attribute as specified 171 in [SMIME3]. This attribute provides a partial list of OIDs of 172 cryptographic functions and must be signed by the client. These OIDs 173 should be logically separated in functional categories and MUST be 174 ordered with respect to their preference. If an S/MIME client is 175 required to support symmetric encryption and key wrapping based on 176 IDEA, the capabilities attribute MUST contain the above specified 177 OIDs in the category of symmetric algorithms and key encipherment 178 algorithms. IDEA does not require additional OID parameters since 179 it has a fixed key length of 128 bits. 181 The SMIMECapability SEQUENCE representing the IDEA symmetric 182 encryption algorithm MUST include the IDEA-CBC OID in the capabilityID 183 field and the parameters field MUST be absent. The SMIMECapability 184 SEQUENCE for IDEA encryption SHOULD be included in the symmetric 185 encryption algorithms portion of the SMIMECapabilities list. The 186 SMIMECapability SEQUENCE representing IDEA MUST be DER-encoded as 187 follows: 300F 060B 2B06 0104 0181 3C07 0101 0205 00. 189 The SMIMECapability SEQUENCE representing the IDEA key wrapping 190 algorithm MUST include the id-alg-CMSIDEAwrap OID in the capabilityID 191 field and the parameters field of KeyWrapAlgorithm MUST be absent. 192 The SMIMECapability SEQUENCE for IDEA key wrapping SHOULD be included 193 in the key encipherment algorithms portion of the SMIMECapabilities 194 list. The SMIMECapability SEQUENCE representing IDEA key wrapping 195 MUST be DER-encoded as follows: 300F 060B 2B06 0104 0181 3C07 0101 196 0605 00. 198 5. Activation of IDEA in S/MIME Clients 200 When a sending agent creates an encrypted message, it has to decide 201 which type of encryption algorithm to use. In general the decision 202 process involves information obtained from the capabilities lists 203 included in messages received from the recipient, as well as other 204 information such as private agreements, user preferences, legal 205 restrictions, etc. If users require IDEA for symmetric encryption, 206 it must be supported by the S/MIME clients on both the sending and 207 receiving side, and it must be set in the user preferences. 209 A. References 211 [IDEA] X. Lai, "On the design and security of block ciphers", ETH 212 Series in Information Processing, J.L. Massey (editor), vol. 1, 213 Hartung-Gorre Verlag Konstanz, Technische Hochschule (Zurich), 1992. 214 A. J. Menezes, P.C. v. Oorschot, S.A. Vanstone, "Handbook of Applied 215 Cryptography," CRC Press New York, 1997, p. 265. 216 B. Schneier, "Applied Cryptography," 2nd ed., John Wiley & Sons Inc. 217 New York, 1996, pp. 319-325. 218 IPR: see the "IETF Page of Intellectual Property Rights Notices", 219 http://www.ietf.org/ipr.html 221 [CMS] "Cryptographic Message Syntax", RFC 2630. 223 [SMIME2] "S/MIME Version 2 Message Specification", RFC 2311, and 224 "S/MIME Version 2 Certificate Handling", RFC 2312. 226 [SMIME3] "S/MIME Version 3 Certificate Handling", RFC 2632, and 227 "S/MIME Version 3 Message Specification", RFC 2633. 229 [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement 230 Levels", RFC 2119. 232 [PKCS7] "PKCS #7: Cryptographic Message Syntax Version 1.5", 233 RFC 2315. 235 B. Comments on IDEA Security and Standards 237 The IDEA algorithm was developed in a joint project involving the 238 Swiss Federal Institute of Technology in Zurich (Dr. X. Lai and 239 Prof. J.L. Massey) and Ascom Ltd. The aim of the project was to 240 develop a strong encryption algorithm that could replace the DES 241 algorithm. 243 IDEA uses 128-bit secret keys and encrypts one 64-bit block at a 244 time [IDEA]. It was particularly strengthened to protect against 245 differential cryptoanalysis attacks. For the full 8-round IDEA 246 there is no attack known which is better than exhaustive search 247 on the total 128-bit key space. 249 IDEA permits the implementation of standard Electronic Data 250 Interchange applications. It has been entered in the ISO/IEC register 251 for encryption algorithms and incorporated in the "SECURITY GUIDE 252 LINES" code list by the UNI/EDIFACT "SECURITY JOINT WORKING GROUP". 254 C. Intellectual Property Rights Notice 256 Ascom Ltd. holds the patent to IDEA. In accordance with the 257 intellectual property rights procedures of the IETF standards 258 process, Ascom offers a non-exclusive license under reasonable and 259 non-discriminatory terms and conditions. 261 IDEA(TM) is protected by international copyright law and in addition 262 has been patented in several countries. Because Ascom wants to make 263 this highly secure algorithm widely available, the non-commercial use 264 of this algorithm is free. 266 Any party wishing to know more about IDEA or to request a license 267 should visit the web sites 268 , 269 or send an e-mail to 270 info@media-crypt.com or info@it-sec.com. 272 D. Acknowledgements 274 We would like to thank Jim Schaad and Francois Zeller for their 275 contributions to this document. 277 E. Authors' Address 279 iT_Security AG (Ltd.) 280 Badenerstrasse 530 282 CH-8048 Zurich, Switzerland 284 Phone: +41 1 404 8200 285 Fax : +41 1 404 8201 286 Email: {stephan.teiwes,peter.hartmann,diego.kuenzi}@it-sec.com 288 F. Full Copyright Statement 290 Copyright (C) The Internet Society (date). All Rights Reserved. 291 This document and translations of it may be copied and furnished to 292 others, and derivative works that comment on or otherwise explain it 293 or assist in its implementation may be prepared, copied, published 294 and distributed, in whole or in part, without restriction of any 295 kind, provided that the above copyright notice and this paragraph 296 are included on all such copies and derivative works. However, this 297 document itself may not be modified in any way, such as by removing 298 the copyright notice or references to the Internet Society or other 299 Internet organizations, except as needed for the purpose of 300 developing Internet standards in which case the procedures for 301 copyrights defined in the Internet Standards process shall be 302 followed, or as required to translate it into languages other than 303 English. 305 The limited permissions granted above are perpetual and will not be 306 revoked by the Internet Society or its successors or assigns. This 307 document and the information contained herein is provided on an "AS 308 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 309 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 310 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 311 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 312 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.