idnits 2.17.1 draft-ietf-smime-idea-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 291 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 are 10 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** 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 109: '...IV OCTET STRING OPTIONAL -- exactly 8...' 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? 'MIME' on line 223 looks like a reference -- Missing reference section? 'SMIME3' on line 220 looks like a reference -- Missing reference section? 'CMS' on line 230 looks like a reference -- Missing reference section? 'PKCS7' on line 232 looks like a reference -- Missing reference section? 'IDEA' on line 244 looks like a reference -- Missing reference section? 'SMIME2' on line 217 looks like a reference Summary: 9 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-01.txt P. Hartmann, 3 August 26, 1999 D. Kuenzi, 4 Expires in six months iT_Security Ltd. 6 Incorporation of the IDEA Encryption Algorithm in S/MIME 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 S/MIME (Secure/Multipurpose Internet Mail Extensions) [SMIME2, 36 SMIME3] is a specification for secure sending and receiving of MIME 37 [MIME] data. Based on the Internet MIME standard, S/MIME provides 38 cryptographic services for authentication, message integrity and 39 non-repudiation of origin by using digital signatures. It also 40 supports privacy and data security by using encryption. The S/MIME 41 framework can be flexibly extended to meet future requirements. 42 However, its extentability can also be used to introduce specific 43 add-on functionality which might be desired in messaging applications. 45 This memo specifies how to incorporate IDEA (International Data 46 Encryption Algorithm) into S/MIME as an additional algorithm for 47 symmetric encryption. Today, IDEA is widely applied in e-business 48 applications. However, it is not part of the S/MIME specification given 49 in [SMIME3]. Often, encryption algorithms are part of a security policy, 50 and organizations usually have their own preferences in this respect. 51 Therefore, it is beneficial to have the choice between different 52 well-known encryption algorithms. Especially for those organization 53 who make already use of IDEA on a wide scale it is of high interest 54 that IDEA is also available S/MIME. It is the intention of this memo 55 to provide the OIDs and algorithms required to include IDEA in S/MIME 56 for symmetric content and key encryption. 58 The general functional capabilities and preferences of S/MIME are 59 specified by the registered list of S/MIME object identifiers (OIDs). 60 This list of OIDs is maintained by the Internet Mail Consortium at 61 . 62 The set of S/MIME functions provided by a client is expressed by the 63 S/MIME capabilities attribute. This attribute contains a list of OIDs 64 of supported cryptographic functions. 66 This draft is being discussed on the "ietf-smime" mailing list. To 67 subscribe, send a message to: 68 ietf-smime-request@imc.org 69 with the single word 70 subscribe 71 in the body of the message. There is a Web site for the mailing list 72 at 74 2. Object Identifier for Content and Key Encryption 76 The Cryptographic Message Syntax [CMS], derived from PKCS#7 [PKCS7], 77 is the framework for the implementation of cryptographic functions in 78 S/MIME. It specifies data formats and encryption processes without 79 naming the cryptographic algorithms. Each algorithm which is used for 80 encryption purposes must be specified by a unique algorithm identifier. 81 For example, in the special case of content encryption, the 82 ContentEncryptionAlgorithmIdentifier specifies the algorithm to be 83 applied. However, according to [CMS] any symmetric encryption algorithm 84 that a CMS implementation includes as a content-encryption algorithm 85 must also be included as a key-encryption algorithm. 87 IDEA is added to the set of optional symmetric encryption algorithms 88 in S/MIME by providing two unique object identifiers (OIDs). One OID 89 defines content encryption and the other one key encryption. Thus an 90 S/MIME agent can apply IDEA either for content or key encryption by 91 selecting the corresponding object identifier, supplying the required 92 parameter, and starting the program code. 94 For content encryption the use of IDEA in cipher block chaining (CBC) 95 mode is recommended. The key length is fixed to 128 bits. 97 The IDEA content-encryption algorithm in CBC mode has the object 98 identifier 100 IDEA-CBC OBJECT IDENTIFIER 101 ::= { iso(1) identified-organization(3) 102 usdod(6) oid(1) private(4) enterprises(1) 103 ascom(188) systec(7) security(1) algorithms(1) 2 } 105 The identifier's parameters field contains the initial 106 vector IV as an optional parameter. 108 IDEA-CBCPar ::= SEQUENCE { 109 IV OCTET STRING OPTIONAL -- exactly 8 octets } 111 If IV is specified as above, it must be used as initial vector. In 112 this case, the ciphertext must not include the initial vector. If 113 IV is not specified, the first 64 bits of the ciphertext must be 114 considered as the initial vector. 116 The key-wrap/unwrap algorithms used to encrypt/decrypt an IDEA 117 content-encryption key with an IDEA key-encryption key are 118 specified in the following section. Generation and distribution 119 of IDEA key-encryption keys are beyond the scope of this memo. 121 The IDEA key-encryption algorithm has the object identifier 123 id-alg-CMSIDEAwrap OBJECT IDENTIFIER 124 ::= { iso(1) identified-organization(3) 125 usdod(6) oid(1) private(4) enterprises(1) 126 ascom(188) systec(7) security(1) algorithms(1) 6 } 128 The identifier's parameters field must be NULL. 130 3. Key-Wrapping and Unwrapping 132 In the following subsections IDEA key-wrap and key-unwrap algorithms 133 are specified in conformance with [CMS], section 12.3. 135 3.1 IDEA Key Wrap 137 The IDEA key-wrap algorithm encrypts an IDEA content-encryption key 138 with an IDEA key-encryption key. The IDEA key-wrap algorithm is defined 139 by: 141 1. Let the content-encryption key (16 octets) be called CEK 142 2. Compute an 8 octet key checksum value on CEK as described 143 in [CMS], section 12.6.1, call the result ICV. 144 3. Let CEKICV := CEK || ICV. 145 4. Generate 8 octets at random, call the result IV. 146 5. Encrypt CEKICV using IDEA in CBC mode and the key-encryption key. 147 Use the random value generated in the previous step as the 148 initialization vector (IV). Call the ciphertext TEMP1. 149 6. Let TEMP2 = IV || TEMP1. 150 7. Reverse the order of the octets in TEMP2. That is, the most 151 significant (first) octet is swapped with the least significant 152 (last) octet, and so on. Call the result TEMP3. 153 8. Encrypt TEMP3 using IDEA in CBC mode and the key-encryption key. 154 Use an initialization vector (IV) of 0x4adda22c79e82105. 155 The ciphertext is 32 octets long. 157 3.2 IDEA Key Unwrap 159 The IDEA key-unwrap algorithm decrypts an IDEA content-encryption key 160 using an IDEA key-encryption key. The IDEA key-unwrap algorithm is 161 defined by: 163 1. If the wrapped content-encryption key is not 32 octets, then 164 error. 165 2. Decrypt the wrapped content-encryption key using IDEA in CBC mode 166 with the key-encryption key. Use an initialization vector (IV) 167 of 0x4adda22c79e82105. Call the output TEMP3. 168 3. Reverse the order of the octets in TEMP3. That is, the most 169 significant (first) octet is swapped with the least significant 170 (last) octet, and so on. Call the result TEMP2. 171 4. Decompose the TEMP2 into IV and TEMP1. IV is the most significant 172 (first) 8 octets, and TEMP1 is the remaining (last) 24 octets. 173 5. Decrypt TEMP1 using IDEA in CBC mode with the key-encryption key. 174 Use the IV value from the previous step as the initialization 175 vector. Call the plaintext CEKICV. 176 6. Decompose the CEKICV into CEK and ICV. CEK is the most significant 177 (first) 16 octets, and ICV is the least significant (last) 8 octets. 178 7. Compute an 8 octet key checksum value on CEK as described 179 in [CMS], section 12.6.1. If the computed key checksum value 180 does not match the decrypted key checksum value, ICV, then error. 181 8. Use CEK as the content-encryption key. 183 4. Consequence on S/MIME Capabilities Attribute 185 An S/MIME client should announce the set of cryptographic functions 186 it supports by using the S/MIME capabilities attribute. This 187 attribute provides a partial list of OIDs of cryptographic functions 188 and must be signed by the client. The functions' OIDs should be 189 logically separated in functional categories and must be ordered with 190 respect to their preference. If an S/MIME client is required to 191 support symmetric encryption with IDEA, the capabilities attribute 192 must contain the above specified OIDs in the category of symmetric 193 algorithms. IDEA does not require additional OID parameters as it 194 uses a fixed key length of 128 bits. 196 5. Activation of IDEA in S/MIME 198 When a sending agent creates an encrypted message, it has to decide 199 which type of encryption algorithm to use. In general the decision 200 process involves information obtained from the capabilities lists 201 included in messages received from the recipient, as well as other 202 information such as private agreements, user preferences, legal 203 restrictions, etc. If users require IDEA for symmetric encryption, 204 it must be supported by the S/MIME clients on both the sending and 205 receiving side, and it must be set in the user preferences. 207 A. References 209 [IDEA] X. Lai, "On the design and security of block ciphers", ETH 210 Series in Information Processing, J.L. Massey (editor), vol. 1, 211 Hartung-Gorre Verlag Konstanz, Technische Hochschule (Zurich), 1992. 212 A. J. Menezes, P.C. v. Oorschot, S.A. Vanstone, "Handbook of Applied 213 Cryptography," CRC Press New York, 1997, p. 265. 214 B. Schneier, "Applied Cryptography," 2nd ed., John Wiley & Sons Inc. 215 New York, 1996, pp. 319-325. 217 [SMIME2] "S/MIME Version 2 Message Specification", RFC 2311, and 218 "S/MIME Version 2 Certificate Handling", RFC 2312. 220 [SMIME3] "S/MIME Version 3 Certificate Handling", RFC 2632, and 221 "S/MIME Version 3 Message Specification", RFC 2633. 223 [MIME] The primary definition of MIME. 224 "MIME Part 1: Format of Internet Message Bodies", RFC 2045. 225 "MIME Part 2: Media Types", RFC 2046. 226 "MIME Part 3: Message Header Extensions for Non-ASCII Text", RFC 2047. 227 "MIME Part 4: Registration Procedures", RFC 2048. 228 "MIME Part 5: Conformance Criteria and Examples", RFC 2049. 230 [CMS] "Cryptographic Message Syntax", RFC 2630. 232 [PKCS7] "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315. 234 B. Comments on IDEA Security and Standards 236 The IDEA algorithm was developed in a joint project involving the 237 Swiss Federal Institute of Technology in Zurich (Dr. X. Lai and 238 Prof. J.L. Massey) and Ascom Ltd. The aim of the project was to 239 develop an encryption algorithm which would replace the DES 240 algorithm. 242 IDEA uses 128-bit secret keys and encrypts one 64-bit block at a 243 time. Experts in cryptography consider IDEA to be a highly secure 244 symmetric cipher [IDEA]. It was particularly strengthened to protect 245 against differential cryptoanalysis attacks. For the full 8-round 246 IDEA 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 More information on IDEA and source code can be found at 255 . 257 C. Intellectual Property Notice 259 IDEA (TM) is protected by international copyright law and in addition 260 it has been patented in the United States, Japan, and in most of the 261 European countries. The patent is held by Ascom Ltd. 263 Non-commercial use of IDEA is free. 264 Commercial licenses can be easily obtained via online order or by 265 contacting idea@ascom.ch. Detailed licensing information can be found 266 at . 268 D. Authors' Address 270 iT_Security Ltd. 271 Badenerstrasse 530 273 CH-8048 Zurich, Switzerland 275 Phone: +41 1 236 9900 276 Fax : +41 1 236 9990 277 Email: {stephan.teiwes,peter.hartmann,diego.kuenzi}@itsec.ch