idnits 2.17.1 draft-ietf-smime-idea-04.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 341 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 60: '...ument, the terms MUST, MUST NOT, SHOUL...' RFC 2119 keyword, line 99: '...IV OCTET STRING OPTIONAL -- exactly 8...' RFC 2119 keyword, line 101: '...ied as above, it MUST be used as initi...' RFC 2119 keyword, line 102: '..., the ciphertext MUST NOT include the ...' RFC 2119 keyword, line 103: '...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 252 looks like a reference -- Missing reference section? 'SMIME2' on line 229 looks like a reference -- Missing reference section? 'SMIME3' on line 232 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 235 looks like a reference -- Missing reference section? 'CMS' on line 238 looks like a reference -- Missing reference section? 'PKCS7' on line 240 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-04.txt P. Hartmann, 3 May 22, 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 S/MIME [SMIME2, SMIME3] as 37 an additional strong algorithm for symmetric encryption. For 38 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 maintained by 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 This draft is being discussed on the "ietf-smime" mailing list. To 53 subscribe, send a message to: 54 ietf-smime-request@imc.org 55 with the single word 56 subscribe 57 in the body of the message. There is a Web site for the mailing list 58 at 60 In this document, the terms MUST, MUST NOT, SHOULD, and SHOULD NOT 61 are used in capital letters. This conforms to the definitions in 62 [MUSTSHOULD]. 64 2. Object Identifier for Content and Key Encryption 66 The Cryptographic Message Syntax [CMS], derived from PKCS#7 [PKCS7], 67 is the framework for the implementation of cryptographic functions in 68 S/MIME. It specifies data formats and encryption processes without 69 naming the cryptographic algorithms. Each algorithm which is used 70 for encryption purposes must be specified by a unique algorithm 71 identifier. For example, in the special case of content encryption 72 the ContentEncryptionAlgorithmIdentifier specifies the algorithm to 73 be applied. However, according to [CMS] any symmetric encryption 74 algorithm that a CMS implementation includes as a content-encryption 75 algorithm must also be included as a key-encryption algorithm. 77 IDEA is added to the set of optional symmetric encryption algorithms 78 in S/MIME by providing two unique object identifiers (OIDs). One OID 79 defines content encryption and the other one key encryption. Thus an 80 S/MIME agent can apply IDEA either for content or key encryption by 81 selecting the corresponding object identifier, supplying the required 82 parameter, and starting the program code. 84 For content encryption the use of IDEA in cipher block chaining (CBC) 85 mode is recommended. The key length is fixed to 128 bits. 87 The IDEA content-encryption algorithm in CBC mode has the object 88 identifier 90 IDEA-CBC OBJECT IDENTIFIER 91 ::= { iso(1) identified-organization(3) 92 usdod(6) oid(1) private(4) enterprises(1) 93 ascom(188) systec(7) security(1) algorithms(1) 2 } 95 The identifier's parameters field contains the initial 96 vector IV as an optional parameter. 98 IDEA-CBCPar ::= SEQUENCE { 99 IV OCTET STRING OPTIONAL -- exactly 8 octets } 101 If IV is specified as above, it MUST be used as initial vector. In 102 this case, the ciphertext MUST NOT include the initial vector. If 103 IV is not specified, the first 64 bits of the ciphertext MUST be 104 considered as the initial vector. However, this alternative of not 105 including the IV SHOULD NOT be applied in S/MIME. 107 The key-wrap/unwrap algorithms used to encrypt/decrypt an IDEA 108 content-encryption key with an IDEA key-encryption key are 109 specified in the following section. Generation and distribution 110 of IDEA key-encryption keys are beyond the scope of this document. 112 The IDEA key-encryption algorithm has the object identifier 114 id-alg-CMSIDEAwrap OBJECT IDENTIFIER 115 ::= { iso(1) identified-organization(3) 116 usdod(6) oid(1) private(4) enterprises(1) 117 ascom(188) systec(7) security(1) algorithms(1) 6 } 119 The identifier's parameters field MUST be NULL. 121 3. Key-Wrapping and Unwrapping 123 In the following subsections IDEA key-wrap and key-unwrap algorithms 124 are specified in conformance with [CMS], section 12.3. 126 3.1 IDEA Key Wrap 128 The IDEA key-wrap algorithm encrypts an IDEA content-encryption key 129 with an IDEA key-encryption key. The IDEA key-wrap algorithm is 130 defined by: 132 1. Let the content-encryption key (16 octets) be called CEK 133 2. Compute an 8 octet key checksum value on CEK as described 134 in [CMS], section 12.6.1, call the result ICV. 135 3. Let CEKICV := CEK || ICV. 136 4. Generate 8 octets at random, call the result IV. 137 5. Encrypt CEKICV using IDEA in CBC mode and the key-encryption key. 138 Use the random value generated in the previous step as the 139 initialization vector (IV). Call the ciphertext TEMP1. 140 6. Let TEMP2 = IV || TEMP1. 141 7. Reverse the order of the octets in TEMP2. That is, the most 142 significant (first) octet is swapped with the least significant 143 (last) octet, and so on. Call the result TEMP3. 144 8. Encrypt TEMP3 using IDEA in CBC mode and the key-encryption key. 145 Use an initialization vector (IV) of 0x4adda22c79e82105. 146 The ciphertext is 32 octets long. 148 3.2 IDEA Key Unwrap 150 The IDEA key-unwrap algorithm decrypts an IDEA content-encryption key 151 using an IDEA key-encryption key. The IDEA key-unwrap algorithm is 152 defined by: 154 1. If the wrapped content-encryption key is not 32 octets, then 155 error. 156 2. Decrypt the wrapped content-encryption key using IDEA in CBC mode 157 with the key-encryption key. Use an initialization vector (IV) 158 of 0x4adda22c79e82105. Call the output TEMP3. 159 3. Reverse the order of the octets in TEMP3. That is, the most 160 significant (first) octet is swapped with the least significant 161 (last) octet, and so on. Call the result TEMP2. 162 4. Decompose the TEMP2 into IV and TEMP1. IV is the most significant 163 (first) 8 octets, and TEMP1 is the remaining (last) 24 octets. 164 5. Decrypt TEMP1 using IDEA in CBC mode with the key-encryption key. 165 Use the IV value from the previous step as the initialization 166 vector. Call the plaintext CEKICV. 167 6. Decompose the CEKICV into CEK and ICV. CEK is the most 168 significant (first) 16 octets, and ICV is the least significant 169 (last) 8 octets. 170 7. Compute an 8 octet key checksum value on CEK as described 171 in [CMS], section 12.6.1. If the computed key checksum value 172 does not match the decrypted key checksum value, ICV, then error. 173 8. Use CEK as the content-encryption key. 175 4. SMIMECapabilities Attribute 177 An S/MIME client can announce the set of cryptographic functions 178 it supports by using the S/MIME capabilities attribute as specified 179 in [SMIME3]. This attribute provides a partial list of OIDs of 180 cryptographic functions and must be signed by the client. These OIDs 181 should be logically separated in functional categories and MUST be 182 ordered with respect to their preference. If an S/MIME client is 183 required to support symmetric encryption and key wrapping based on 184 IDEA, the capabilities attribute MUST contain the above specified 185 OIDs in the category of symmetric algorithms and key encipherment 186 algorithms. IDEA does not require additional OID parameters since 187 it has a fixed key length of 128 bits. 189 The SMIMECapability SEQUENCE representing the IDEA symmetric 190 encryption algorithm MUST include the IDEA-CBC OID in the capabilityID 191 field and the parameters field MUST be absent. The SMIMECapability 192 SEQUENCE for IDEA encryption SHOULD be included in the symmetric 193 encryption algorithms portion of the SMIMECapabilities list. The 194 SMIMECapability SEQUENCE representing IDEA MUST be DER-encoded as 195 follows: 300F 060B 2B06 0104 0181 3C07 0101 0205 00. 197 The SMIMECapability SEQUENCE representing the IDEA key wrapping 198 algorithm MUST include the id-alg-CMSIDEAwrap OID in the capabilityID 199 field and the parameters field of KeyWrapAlgorithm MUST be absent. 200 The SMIMECapability SEQUENCE for IDEA key wrapping SHOULD be included 201 in the key encipherment algorithms portion of the SMIMECapabilities 202 list. The SMIMECapability SEQUENCE representing IDEA key wrapping 203 MUST be DER-encoded as follows: 300F 060B 2B06 0104 0181 3C07 0101 204 0605 00. 206 5. Activation of IDEA in S/MIME Clients 208 When a sending agent creates an encrypted message, it has to decide 209 which type of encryption algorithm to use. In general the decision 210 process involves information obtained from the capabilities lists 211 included in messages received from the recipient, as well as other 212 information such as private agreements, user preferences, legal 213 restrictions, etc. If users require IDEA for symmetric encryption, 214 it must be supported by the S/MIME clients on both the sending and 215 receiving side, and it must be set in the user preferences. 217 A. References 219 [IDEA] X. Lai, "On the design and security of block ciphers", ETH 220 Series in Information Processing, J.L. Massey (editor), vol. 1, 221 Hartung-Gorre Verlag Konstanz, Technische Hochschule (Zurich), 1992. 222 A. J. Menezes, P.C. v. Oorschot, S.A. Vanstone, "Handbook of Applied 223 Cryptography," CRC Press New York, 1997, p. 265. 224 B. Schneier, "Applied Cryptography," 2nd ed., John Wiley & Sons Inc. 225 New York, 1996, pp. 319-325. 226 IPR: see the "IETF Page of Intellectual Property Rights Notices", 227 http://www.ietf.org/ipr.html 229 [SMIME2] "S/MIME Version 2 Message Specification", RFC 2311, and 230 "S/MIME Version 2 Certificate Handling", RFC 2312. 232 [SMIME3] "S/MIME Version 3 Certificate Handling", RFC 2632, and 233 "S/MIME Version 3 Message Specification", RFC 2633. 235 [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement 236 Levels", RFC 2119. 238 [CMS] "Cryptographic Message Syntax", RFC 2630. 240 [PKCS7] "PKCS #7: Cryptographic Message Syntax Version 1.5", 241 RFC 2315. 243 B. Comments on IDEA Security and Standards 245 The IDEA algorithm was developed in a joint project involving the 246 Swiss Federal Institute of Technology in Zurich (Dr. X. Lai and 247 Prof. J.L. Massey) and Ascom Ltd. The aim of the project was to 248 develop a strong encryption algorithm that could replace the DES 249 algorithm. 251 IDEA uses 128-bit secret keys and encrypts one 64-bit block at a 252 time [IDEA]. It was particularly strengthened to protect against 253 differential cryptoanalysis attacks. For the full 8-round IDEA 254 there is no attack known which is better than exhaustive search 255 on the total 128-bit key space. 257 IDEA permits the implementation of standard Electronic Data 258 Interchange applications. It has been entered in the ISO/IEC register 259 for encryption algorithms and incorporated in the "SECURITY GUIDE 260 LINES" code list by the UNI/EDIFACT "SECURITY JOINT WORKING GROUP". 262 More information on IDEA and an implementation in C code can be found 263 at . 265 C. Intellectual Property Rights Notice 267 Ascom AG (Ltd.) holds the patent to IDEA. In accordance with the 268 intellectual property rights procedures of the IETF standards 269 process, Ascom offers a non-exclusive license under reasonable and 270 non-discriminatory terms and conditions. 272 IDEA(TM) is protected by international copyright law and in addition 273 has been patented in several countries. Because Ascom wants to make 274 this highly secure algorithm widely available, the non-commercial use 275 of this algorithm is free. 277 Any party wishing to request a license should visit the web site 278 or send an e-mail to Idea@it-sec.com. 280 Detailed licensing information can be found at 281 . 283 D. Acknowledgements 285 We would like to thank Jim Schaad and Francois Zeller for their 286 contributions to this document. 288 E. Authors' Address 290 iT_Security AG (Ltd.) 291 Badenerstrasse 530 293 CH-8048 Zurich, Switzerland 295 Phone: +41 1 404 8200 296 Fax : +41 1 404 8201 297 Email: {stephan.teiwes,peter.hartmann}@it-sec.com 299 F. Full Copyright Statement 301 Copyright (C) The Internet Society (date). All Rights Reserved. 302 This document and translations of it may be copied and furnished to 303 others, and derivative works that comment on or otherwise explain it 304 or assist in its implementation may be prepared, copied, published 305 and distributed, in whole or in part, without restriction of any 306 kind, provided that the above copyright notice and this paragraph 307 are included on all such copies and derivative works. However, this 308 document itself may not be modified in any way, such as by removing 309 the copyright notice or references to the Internet Society or other 310 Internet organizations, except as needed for the purpose of 311 developing Internet standards in which case the procedures for 312 copyrights defined in the Internet Standards process shall be 313 followed, or as required to translate it into languages other than 314 English. 316 The limited permissions granted above are perpetual and will not be 317 revoked by the Internet Society or its successors or assigns. This 318 document and the information contained herein is provided on an "AS 319 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 320 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 321 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 322 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 323 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.