draft-ietf-smime-idea-00.txt   draft-ietf-smime-idea-01.txt 
Internet Draft S. Teiwes, Internet Draft S. Teiwes,
draft-ietf-smime-idea-00.txt P. Hartmann, draft-ietf-smime-idea-01.txt P. Hartmann,
March 29, 1999 D. Kuenzi, August 26, 1999 D. Kuenzi,
Expires in six months Ascom Systec Ltd. Expires in six months iT_Security Ltd.
Incorporation of IDEA encryption algorithm in S/MIME Incorporation of the IDEA Encryption Algorithm in S/MIME
Status of this memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft and is in full conformance with
documents of the Internet Engineering Task Force (IETF), its areas, all provisions of section 10 of RFC2026. Internet-Drafts are
and its working groups. Note that other groups may also distribute working documents of the Internet Engineering Task Force (IETF),
working documents as Internet-Drafts. 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 Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
To view the entire list of current Internet-Drafts, please check the To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 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). Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
1. Introduction 1. Introduction
This memo describes how to incorporate the IDEA (International Data S/MIME (Secure/Multipurpose Internet Mail Extensions) [SMIME2,
Encryption Algorithm) [IDEA] encryption algorithm into S/MIME SMIME3] is a specification for secure sending and receiving of MIME
(Secure/Multipurpose Internet Mail Extensions) [SMIME2, SMIME3]. The [MIME] data. Based on the Internet MIME standard, S/MIME provides
S/MIME standard provides a consistent way to send and receive secure cryptographic services for authentication, message integrity and
MIME [MIME] data. Information security services are implemented on non-repudiation of origin by using digital signatures. It also
the basis of a set of cryptographic functions. Thus, digital supports privacy and data security by using encryption. The S/MIME
signatures are used for secure authentication, non-repudiation of framework can be flexibly extended to meet future requirements.
origin, and data integrity, whereas data encryption is used to assure However, its extentability can also be used to introduce specific
data security and privacy. add-on functionality which might be desired in messaging applications.
S/MIME is constructed as an open system. Its functionality for This memo specifies how to incorporate IDEA (International Data
information security purposes can be flexibly extended to meet new Encryption Algorithm) into S/MIME as an additional algorithm for
requirements. At the same time it is assured that extended systems symmetric encryption. Today, IDEA is widely applied in e-business
will be compatible with non-extended systems. applications. However, it is not part of the S/MIME specification given
in [SMIME3]. Often, encryption algorithms are part of a security policy,
and organizations usually have their own preferences in this respect.
Therefore, it is beneficial to have the choice between different
well-known encryption algorithms. Especially for those organization
who make already use of IDEA on a wide scale it is of high interest
that IDEA is also available S/MIME. It is the intention of this memo
to provide the OIDs and algorithms required to include IDEA in S/MIME
for symmetric content and key encryption.
The general functional capabilities and preferences of S/MIME are The general functional capabilities and preferences of S/MIME are
specified by the registered list of S/MIME object identifiers (OIDs). specified by the registered list of S/MIME object identifiers (OIDs).
This list of OIDs is maintained by the Internet Mail Consortium at This list of OIDs is maintained by the Internet Mail Consortium at
<http://www.imc.org/ietf-smime/oids.html>. <http://www.imc.org/ietf-smime/oids.html>.
The set of S/MIME functions provided by a client is expressed by the 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 S/MIME capabilities attribute. This attribute contains a list of OIDs
of supported cryptographic functions. 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 This draft is being discussed on the "ietf-smime" mailing list. To
subscribe, send a message to: subscribe, send a message to:
ietf-smime-request@imc.org ietf-smime-request@imc.org
with the single word with the single word
subscribe subscribe
in the body of the message. There is a Web site for the mailing list in the body of the message. There is a Web site for the mailing list
at <http://www.imc.org/ietf-smime/> at <http://www.imc.org/ietf-smime/>
2. Comments On The IDEA Encryption Algorithm 2. Object Identifier for Content and Key Encryption
The IDEA algorithm was developed in a joint project involving the The Cryptographic Message Syntax [CMS], derived from PKCS#7 [PKCS7],
Swiss Federal Institute of Technology in Zurich (Dr. X. Lai and is the framework for the implementation of cryptographic functions in
Prof. J.L. Massey) and Ascom Ltd. The aim of the project was to S/MIME. It specifies data formats and encryption processes without
develop an encryption algorithm which would replace the DES naming the cryptographic algorithms. Each algorithm which is used for
algorithm. IDEA uses a 128-bit secret key and encrypts one 64-bit encryption purposes must be specified by a unique algorithm identifier.
block at a time. The algorithm is generally considered to be very For example, in the special case of content encryption, the
secure. It was particularly strengthened to protect against ContentEncryptionAlgorithmIdentifier specifies the algorithm to be
differential cryptoanalysis attacks. applied. However, according to [CMS] any symmetric encryption algorithm
that a CMS implementation includes as a content-encryption algorithm
must also be included as a key-encryption algorithm.
IDEA permits the implementation of standard Electronic Data IDEA is added to the set of optional symmetric encryption algorithms
Interchange applications. It has been entered in the ISO/IEC register in S/MIME by providing two unique object identifiers (OIDs). One OID
for encryption algorithms and incorporated in the "SECURITY GUIDE defines content encryption and the other one key encryption. Thus an
LINES" code list by the UNI/EDIFACT "SECURITY JOINT WORKING GROUP". S/MIME agent can apply IDEA either for content or key encryption by
selecting the corresponding object identifier, supplying the required
parameter, and starting the program code.
More information on IDEA and source code can be found at For content encryption the use of IDEA in cipher block chaining (CBC)
<http://www.ascom.ch/infosec/idea.html>. mode is recommended. The key length is fixed to 128 bits.
3. IDEA Object Identifier For S/MIME The IDEA content-encryption algorithm in CBC mode has the object
identifier
The PKCS #7 message format [PKCS7] is the framework for the IDEA-CBC OBJECT IDENTIFIER
implementation of cryptographic functions in S/MIME. It specifies ::= { iso(1) identified-organization(3)
data formats and encryption processes without naming the usdod(6) oid(1) private(4) enterprises(1)
cryptographic algorithms. A concrete algorithm which is used for ascom(188) systec(7) security(1) algorithms(1) 2 }
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 The identifier's parameters field contains the initial
content encryption, whereas RC2/40-bit is specified as optional. vector IV as an optional parameter.
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 IDEA-CBCPar ::= SEQUENCE {
chaining (CBC) mode is recommended. The key length is fixed to 128 IV OCTET STRING OPTIONAL -- exactly 8 octets }
bits. The object identifier for IDEA in CBC mode is given by
IDEA-CBC OBJECT IDENTIFIER 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
considered as the initial vector.
The key-wrap/unwrap algorithms used to encrypt/decrypt an IDEA
content-encryption key with an IDEA key-encryption key are
specified in the following section. Generation and distribution
of IDEA key-encryption keys are beyond the scope of this memo.
The IDEA key-encryption algorithm has the object identifier
id-alg-CMSIDEAwrap OBJECT IDENTIFIER
::= {iso(1) identified-organization(3) ::= {iso(1) identified-organization(3)
usdod(6) oid(1) private(4) enterprises(1) usdod(6) oid(1) private(4) enterprises(1)
as(188) sys(7) sec(1) alg(1) 2} ascom(188) systec(7) security(1) algorithms(1) 6 }
The algorithm's initial vector iv is an optional parameter The identifier's parameters field must be NULL.
IDEA-CBCPar ::= SEQUENCE { 3. Key-Wrapping and Unwrapping
iv OCTET STRING OPTIONAL -- 8 octets }
If iv is specified as above, it MUST be used as initial vector. In In the following subsections IDEA key-wrap and key-unwrap algorithms
this case, the ciphertext MUST NOT include the initial vector. If are specified in conformance with [CMS], section 12.3.
iv is not specified, the first 64 bits of the ciphertext MUST be
taken as the initial vector.
4. Consequence On S/MIME Capabilities Attribute 3.1 IDEA Key Wrap
An S/MIME client SHOULD announce the set of cryptographic functions The IDEA key-wrap algorithm encrypts an IDEA content-encryption key
with an IDEA key-encryption key. The IDEA key-wrap algorithm is defined
by:
1. Let the content-encryption key (16 octets) be called CEK
2. Compute an 8 octet key checksum value on CEK as described
in [CMS], section 12.6.1, call the result ICV.
3. Let CEKICV := CEK || ICV.
4. Generate 8 octets at random, call the result IV.
5. Encrypt CEKICV using IDEA in CBC mode and the key-encryption key.
Use the random value generated in the previous step as the
initialization vector (IV). Call the ciphertext TEMP1.
6. Let TEMP2 = IV || TEMP1.
7. Reverse the order of the octets in TEMP2. That is, the most
significant (first) octet is swapped with the least significant
(last) octet, and so on. Call the result TEMP3.
8. Encrypt TEMP3 using IDEA in CBC mode and the key-encryption key.
Use an initialization vector (IV) of 0x4adda22c79e82105.
The ciphertext is 32 octets long.
3.2 IDEA Key Unwrap
The IDEA key-unwrap algorithm decrypts an IDEA content-encryption key
using an IDEA key-encryption key. The IDEA key-unwrap algorithm is
defined by:
1. If the wrapped content-encryption key is not 32 octets, then
error.
2. Decrypt the wrapped content-encryption key using IDEA in CBC mode
with the key-encryption key. Use an initialization vector (IV)
of 0x4adda22c79e82105. Call the output TEMP3.
3. Reverse the order of the octets in TEMP3. That is, the most
significant (first) octet is swapped with the least significant
(last) octet, and so on. Call the result TEMP2.
4. Decompose the TEMP2 into IV and TEMP1. IV is the most significant
(first) 8 octets, and TEMP1 is the remaining (last) 24 octets.
5. Decrypt TEMP1 using IDEA in CBC mode with the key-encryption key.
Use the IV value from the previous step as the initialization
vector. Call the plaintext CEKICV.
6. Decompose the CEKICV into CEK and ICV. CEK is the most significant
(first) 16 octets, and ICV is the least significant (last) 8 octets.
7. Compute an 8 octet key checksum value on CEK as described
in [CMS], section 12.6.1. If the computed key checksum value
does not match the decrypted key checksum value, ICV, then error.
8. Use CEK as the content-encryption key.
4. 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 it supports by using the S/MIME capabilities attribute. This
attribute provides a partial list of OIDs of cryptographic functions attribute provides a partial list of OIDs of cryptographic functions
and MUST be signed by the client. The function's OIDs SHOULD be and must be signed by the client. The functions' OIDs should be
logically separated in functional categories and MUST be ordered with logically separated in functional categories and must be ordered with
respect to their preference. If an S/MIME client is required to respect to their preference. If an S/MIME client is required to
support strong encryption by IDEA-CBC, the capabilities attribute support symmetric encryption with IDEA, the capabilities attribute
MUST contain the above specified OID in the category of symmetric must contain the above specified OIDs in the category of symmetric
algorithms. IDEA-CBC does not require additional OID parameters as a algorithms. IDEA does not require additional OID parameters as it
fixed key length of 128 bits is propagated. uses a fixed key length of 128 bits.
5. Activation of IDEA In S/MIME 5. Activation of IDEA in S/MIME
When a sending agent creates an encrypted message, it has to decide When a sending agent creates an encrypted message, it has to decide
which type of encryption algorithm to use. In general, the decision which type of encryption algorithm to use. In general the decision
process involves using information obtained from the capabilities process involves information obtained from the capabilities lists
lists included in messages received from the recipient, as well as included in messages received from the recipient, as well as other
out-of-band information such as private agreements, user preferences, information such as private agreements, user preferences, legal
legal restrictions, etc. restrictions, etc. If users require IDEA for symmetric encryption,
it must be supported by the S/MIME clients on both the sending and
For example, in the broad field of electronic commerce weak receiving side, and it must be set in the user preferences.
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 A. References
[IDEA] X. Lai, "On the design and security of block ciphers", ETH [IDEA] X. Lai, "On the design and security of block ciphers", ETH
Series in Information Processing, J.L. Massey (editor), vol. 1, Series in Information Processing, J.L. Massey (editor), vol. 1,
Hartung-Gorre Verlag Konstanz, Technische Hochschule (Zurich), 1992. Hartung-Gorre Verlag Konstanz, Technische Hochschule (Zurich), 1992.
A. J. Menezes, P.C. v. Oorschot, S.A. Vanstone, "Handbook of Applied
Cryptography," CRC Press New York, 1997, p. 265.
B. Schneier, "Applied Cryptography," 2nd ed., John Wiley & Sons Inc.
New York, 1996, pp. 319-325.
[SMIME2] "S/MIME Version 2 Message Specification", RFC 2311, and [SMIME2] "S/MIME Version 2 Message Specification", RFC 2311, and
"S/MIME Version 2 Certificate Handling", RFC 2312. "S/MIME Version 2 Certificate Handling", RFC 2312.
[SMIME3] "S/MIME Version 3 Message Specification", Internet Draft [SMIME3] "S/MIME Version 3 Certificate Handling", RFC 2632, and
draft-ietf-smime-msg-xx, and "S/MIME Version 3 Certificate "S/MIME Version 3 Message Specification", RFC 2633.
Handling", Internet Draft draft-ietf-smime-cert-xx.
[MIME-SPEC] The primary definition of MIME. [MIME] The primary definition of MIME.
"MIME Part 1: Format of Internet Message Bodies", RFC 2045; "MIME Part 1: Format of Internet Message Bodies", RFC 2045.
"MIME Part 2: Media Types", RFC 2046; "MIME Part 2: Media Types", RFC 2046.
"MIME Part 3: Message Header Extensions for Non-ASCII Text", "MIME Part 3: Message Header Extensions for Non-ASCII Text", RFC 2047.
RFC 2047; "MIME Part 4: Registration Procedures", RFC 2048.
"MIME Part 4: Registration Procedures", RFC 2048; "MIME Part 5: Conformance Criteria and Examples", RFC 2049.
"MIME Part 5: Conformance Criteria and Examples", RFC 2049
[3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES," [CMS] "Cryptographic Message Syntax", RFC 2630.
IEEE Spectrum, vol. 16, no. 7, July 1979, pp. 40-41.
[DES] ANSI X3.106, "American National Standard for Information [PKCS7] "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315.
Systems- Data Link Encryption," American National Standards
Institute, 1983.
[RC2] "A Description of the RC2 (r) Encryption Algorithm", RFC 2268 B. Comments on IDEA Security and Standards
[MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement The IDEA algorithm was developed in a joint project involving the
Levels", RFC 2119 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.
[PKCS7] "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315 IDEA uses 128-bit secret keys and encrypts one 64-bit block at a
time. Experts in cryptography consider IDEA to be a highly secure
symmetric cipher [IDEA]. It was particularly strengthened to protect
against differential cryptoanalysis attacks. For the full 8-round
IDEA there is no attack known which is better than exhaustive search
on the total 128-bit key space.
B. Intellectual Property Notice 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.com/infosec/idea.html>.
C. Intellectual Property Notice
IDEA (TM) is protected by international copyright law and in addition 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 it has been patented in the United States, Japan, and in most of the
countries. The patent is held by Ascom Ltd. European countries. The patent is held by Ascom Ltd.
Non-commercial use of IDEA is free. Non-commercial use of IDEA is free.
Commercial licenses can be obtained by contacting idea@ascom.ch. Commercial licenses can be easily obtained via online order or by
contacting idea@ascom.ch. Detailed licensing information can be found
at <http://www.ascom.com/infosec/idea.html>.
C. Authors' Address D. Authors' Address
Ascom Systec Ltd. iT_Security Ltd.
Gewerbepark Badenerstrasse 530
P.O.Box
5506 Maegenwil, Switzerland
Phone: +41 62 889 5964 CH-8048 Zurich, Switzerland
Email: {stephan.teiwes,peter.hartmann,diego.kuenzi}@ascom.ch
Phone: +41 1 236 9900
Fax : +41 1 236 9990
Email: {stephan.teiwes,peter.hartmann,diego.kuenzi}@itsec.ch
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/