Internet Draft                                         S. Teiwes,
draft-ietf-smime-idea-00.txt                           P. Hartmann,
March 29, 1999                                         D. Kuenzi,
Expires in six months                                  Ascom Systec Ltd.



         Incorporation of IDEA encryption algorithm in S/MIME

Status of this memo

   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).


. Introduction

   This memo describes how to incorporate the IDEA (International Data
   Encryption Algorithm) [IDEA] encryption algorithm into S/MIME
   (Secure/Multipurpose Internet Mail Extensions) [SMIME2, SMIME3]. The
   S/MIME standard provides a consistent way to send and receive secure
   MIME [MIME] data. Information security services are implemented on
   the basis of a set of cryptographic functions. Thus, digital
   signatures are used for secure authentication, non-repudiation of
   origin, and data integrity, whereas data encryption is used to assure
   data security and privacy.

   S/MIME is constructed as an open system. Its functionality for
   information security purposes can be flexibly extended to meet new
   requirements. At the same time it is assured that extended systems
   will be compatible with non-extended systems.

   The general functional capabilities and preferences of S/MIME are
   specified by the registered list of S/MIME object identifiers (OIDs).
   This list of OIDs is maintained by the Internet Mail Consortium at
   <http://www.imc.org/ietf-smime/oids.html>.
   The set of S/MIME functions provided by a client is expressed by the
   S/MIME capabilities attribute. This attribute contains a list of OIDs
   of supported cryptographic functions.

   According to S/MIME v3 [SMIME3] sending and receiving agents MUST
   provide the DES EDE3 CBC [3DES] [DES] for content encryption and
   decryption. Receiving agents SHOULD also support RC2 [RC2] at a key
   size of 40 bits. However, there are no general restrictions on the
   application of encryption algorithms in S/MIME as long as they are
   specified by a valid object identifier. The ability of strong
   encryption is of general interest, but it is of particular interest
   for instance in electronic commerce applications. Thus, the extension
   of the S/MIME capabilities by the strong and efficient IDEA
   encryption algorithm is benificial.

   Throughout this draft, the terms MUST, MUST NOT, SHOULD, and SHOULD
   NOT are used in capital letters. This conforms to the definitions in
   [MUSTSHOULD].

   This draft is being discussed on the "ietf-smime" mailing list. To
   subscribe, send a message to:
        ietf-smime-request@imc.org
   with the single word
        subscribe
   in the body of the message. There is a Web site for the mailing list
   at <http://www.imc.org/ietf-smime/>


. Comments On The IDEA Encryption Algorithm

   The IDEA algorithm was developed in a joint project involving the
   Swiss Federal Institute of Technology in Zurich (Dr. X. Lai and
   Prof. J.L. Massey) and Ascom Ltd. The aim of the project was to
   develop an encryption algorithm which would replace the DES
   algorithm. IDEA uses a 128-bit secret key and encrypts one 64-bit
   block at a time. The algorithm is generally considered to be very
   secure. It was particularly strengthened to protect against
   differential cryptoanalysis attacks.

   IDEA permits the implementation of standard Electronic Data
   Interchange applications. It has been entered in the ISO/IEC register
   for encryption algorithms and incorporated in the "SECURITY GUIDE
   LINES" code list by the UNI/EDIFACT "SECURITY JOINT WORKING GROUP".

   More information on IDEA and source code can be found at
   <http://www.ascom.ch/infosec/idea.html>.


. IDEA Object Identifier For S/MIME

   The PKCS #7 message format [PKCS7] is the framework for the
   implementation of cryptographic functions in S/MIME. It specifies
   data formats and encryption processes without naming the
   cryptographic algorithms. A concrete algorithm which is used for
   encryption purposes MUST be specified by a unique algorithm
   identifier. In the special case of content encryption, the
   ContentEncryptionAlgorithmIdentifier specifies the applied algorithm.

   S/MIME v3 requires only that agents MUST provide DES EDE3 CBC for
   content encryption, whereas RC2/40-bit is specified as optional.
   IDEA can be simply added to the set of optional content encryption
   algorithms by providing its unique S/MIME object identifier. This
   corresponds to the ContentEncryptionAlgorithmIdentifier of PKCS #7.
   An S/MIME agent can apply the IDEA algorithm for content encryption
   simply by selecting its object identifier, supplying the required
   parameter, and starting the corresponding program code.

   For strong content encryption the use of IDEA in cipher block
   chaining (CBC) mode is recommended. The key length is fixed to 128
   bits. The object identifier for IDEA in CBC mode is given by

   IDEA-CBC OBJECT IDENTIFIER
      ::= {iso(1) identified-organization(3)
           usdod(6) oid(1) private(4) enterprises(1)
           as(188) sys(7) sec(1) alg(1) 2}

   The algorithm's initial vector iv is an optional parameter

   IDEA-CBCPar ::= SEQUENCE {
     iv  OCTET STRING OPTIONAL -- 8 octets }

   If iv is specified as above, it MUST be used as initial vector. In
   this case, the ciphertext MUST NOT include the initial vector. If
   iv is not specified, the first 64 bits of the ciphertext MUST be
   taken as the initial vector.


. Consequence On S/MIME Capabilities Attribute

   An S/MIME client SHOULD announce the set of cryptographic functions
   it supports by using the S/MIME capabilities attribute. This
   attribute provides a partial list of OIDs of cryptographic functions
   and MUST be signed by the client. The function's OIDs SHOULD be
   logically separated in functional categories and MUST be ordered with
   respect to their preference. If an S/MIME client is required to
   support strong encryption by IDEA-CBC, the capabilities attribute
   MUST contain the above specified OID in the category of symmetric
   algorithms. IDEA-CBC does not require additional OID parameters as a
   fixed key length of 128 bits is propagated.


. Activation of IDEA In S/MIME

   When a sending agent creates an encrypted message, it has to decide
   which type of encryption algorithm to use. In general, the decision
   process involves using information obtained from the capabilities
   lists included in messages received from the recipient, as well as
   out-of-band information such as private agreements, user preferences,
   legal restrictions, etc.

   For example, in the broad field of electronic commerce weak
   encryption, as represented by RC2/40, is regarded to be unacceptable.
   Strong encryption can be enforced on the basis of a security policy.
   This policy SHOULD include an agreement on at least one desired
   strong encryption algorithms to be used in S/MIME. In this case it
   is required that S/MIME clients both at the sending and the
   receiving end MUST support the desired encryption algorithms. Thus,
   if IDEA-CBC is chosen to be used as encryption algorithm, it MUST
   be supported by the S/MIME clients and it MUST be set in the user
   preferences.


A. References

   [IDEA] X. Lai, "On the design and security of block ciphers", ETH
   Series in Information Processing, J.L. Massey (editor), vol. 1,
   Hartung-Gorre Verlag Konstanz, Technische Hochschule (Zurich), 1992.

   [SMIME2] "S/MIME Version 2 Message Specification", RFC 2311, and
   "S/MIME Version 2 Certificate Handling", RFC 2312.

   [SMIME3] "S/MIME Version 3 Message Specification", Internet Draft
   draft-ietf-smime-msg-xx, and  "S/MIME Version 3 Certificate
   Handling", Internet Draft draft-ietf-smime-cert-xx.

   [MIME-SPEC] The primary definition of MIME.
   "MIME Part 1: Format of Internet Message Bodies", RFC 2045;
   "MIME Part 2: Media Types", RFC 2046;
   "MIME Part 3: Message Header Extensions for Non-ASCII Text",
   RFC 2047;
   "MIME Part 4: Registration Procedures", RFC 2048;
   "MIME Part 5: Conformance Criteria and Examples", RFC 2049

   [3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES,"
   IEEE Spectrum, vol. 16, no. 7, July 1979, pp. 40-41.

   [DES] ANSI X3.106, "American National Standard for Information
   Systems- Data Link Encryption," American National Standards
   Institute, 1983.

   [RC2] "A Description of the RC2 (r) Encryption Algorithm", RFC 2268

   [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement
   Levels", RFC 2119

   [PKCS7] "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315


B. Intellectual Property Notice

   IDEA (TM) is protected by international copyright law and in addition
   it has been patented in the United States and in most of the European
   countries. The patent is held by Ascom Ltd.

   Non-commercial use of IDEA is free.
   Commercial licenses can be obtained by contacting idea@ascom.ch.


C. Authors' Address

   Ascom Systec Ltd.
   Gewerbepark
   P.O.Box
   5506 Maegenwil, Switzerland

   Phone: +41 62 889 5964
   Email: {stephan.teiwes,peter.hartmann,diego.kuenzi}@ascom.ch