Internet Draft The ESP IDEA Algorithm 23 June 1997 Security Working Group Ipsec Working Group INTERNET DRAFT Rob Adams Cisco Systems Inc. 23 June 1997 Expires in Six Months The ESP IDEA-CBC Algorithm Using Explicit IV Status of this Memo This document is a submission to the IETF Internet Protocol Security (IPSEC) Working Group. Comments are solicited and should be addressed to the working group mailing list (ipsec@tis.com) or to the editor. 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 draft documents are valid for a maximum of six months and may be updated, replaced, or obsolete 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 learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. Abstract This draft describes the use of the IDEA [Schneier] block cipher algorithm in CBC mode with the IPSec Encapsulating Security Payload (ESP) [Kent97]. R. Adams [Page 1] Internet Draft The ESP IDEA Algorithm 23 June 1997 Table of Contents: 1. Introduction.................................................2 1.1 Specification of Requirements.............................2 2. Cipher Algorithm.............................................2 2.1 Rounds....................................................3 2.2 Background................................................3 2.3 Performance...............................................3 3. Key Size.....................................................5 3.1 Weak Keys.................................................5 4. ESP Payload..................................................5 4.1 Block Size and Padding....................................5 4.2 Interaction with Authentication...........................5 5. Keying Material..............................................5 6. Security Considerations......................................6 7. Reference....................................................6 8. Acknowledgments..............................................7 9. Editor's Address.............................................7 1. Introduction This draft describes the use of the IDEA cipher algorithm in CBC mode to provide confidentiality in conjunction with the IPsec ESP protocol [Kent97]. This document assumes readers are familiar with the terms and concepts in [RFC-1825] and in [Kent97]. 1.1 Specification of Requirements The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", and "MAY" that appear in this document are to be interpreted as described in [RFC-2119]. 2. Cipher Algorithm This document gives implementers specific instructions for using the IDEA block cipher algorithm in CBC mode with a block size of 64 bits as described in [Schneier] to secure ESP. The IDEA algorithm is patented in Europe and in the United States with patent application pending in Japan. Licenses are required for commercial uses of IDEA. R. Adams [Page 2] Internet Draft The ESP IDEA Algorithm 23 June 1997 For patent and licensing information, contact: Ascom Systec AG, Dept. CMVV Gewerbepark, CH-5506 Magenwil, Switzerland Phone: +41 64 56 59 83 Fax: +41 64 56 59 90 idea@ascom.ch or see http://www.ascom.ch/Web/systec/policy/normal/exhibit1.html 2.1 Rounds Compliant implementations may use either four or eight round IDEA. The key exchange protocol SHOULD negotiate the number of rounds for IDEA. Only four and eight round IDEA are valid. If the key exchange protocol does not negotiate the number rounds, eight round IDEA is the default. Although there are no known attacks against four round IDEA, those choosing to use four round IDEA for performance reasons, may wish shorten key lifetimes via site specific policy. 2.2 Background Xuejia Lai and James Massey developed the IDEA (International Data Encryption Algorithm) algorithm. The algorithm is described in detail in [Lai] and [Schneier]. 2.3 Performance Normal eight round IDEA is approximately twice as fast DES on 386 and 486 processors. However on a Pentium, both eight round IDEA and 56 bit key, 16 round DES require about the same number of clock cycles per byte encrypted. Four round IDEA is twice as fast as eight round IDEA. For a comparison table of the speed of IDEA and other cipher algorithms, see [Schneier97]. R. Adams [Page 3] Internet Draft The ESP IDEA Algorithm 23 June 1997 3. Key Size IDEA accepts 128 bits of keying material to generate sub-keys. IDEA may also accept keying material of sufficient length to set its sub-keys directly. Eight round IDEA uses 52, 16 bit sub-keys or 832 bits of keying material. Four round IDEA uses 28, 16 bit sub-keys or 448 bits of keying material. Implementations MAY accept keys shorter or longer than 128 bits. Implementations MUST not accept keying material shorter than 40 bits in length. 3.1 Weak Keys IDEA has weak keys of the following form: 0000,0000,0x00,0000,0000,000x,xxxx,x000 where "x" can be any hexadecimal number. Keys of this form guarantee the value of bit-wise XOR of resultant ciphertext pairs from the bit-wise XOR of certain plaintext pairs. Implementations MUST prohibit weak keys even though the probability of randomly generating such a key is quite small. If the key manager provides the implementation with a weak key, the implementation MUST XOR each of the generated encryption sub-keys with the value 0x0dae before generating the decryption sub-key set [Cryto93]. Implementations may choose to prohibit weak keys by rejecting weak keys altogether and requesting new keying material. Weak keys cannot be detected if the sub-keys are set directly. 4. ESP Payload IDEA in CBC mode requires an initialization vector of eight octets for use with ESP [Kent97]. The IV MUST precede the data to be encrypted in the packet and must be eight octets (64 bits) in length. The IV SHOULD be chosen at random. Common practice is to use random data for the first IV and the last eight octets of encrypted data from an encryption process as the IV for the next encryption process. R. Adams [Page 4] Internet Draft The ESP IDEA Algorithm 23 June 1997 The payload field, as defined in [Kent97], is broken down according to the following diagram: +---------------+---------------+---------------+---------------+ | | + Initialization Vector + | | +---------------+---------------+---------------+---------------+ | | ~ Encrypted Payload (Variable length) ~ | | +---------------+---------------+---------------+---------------+ 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 4.1 Block Size and Padding The IDEA-CBC cipher algorithm MUST use a block size of eight octets (64 bits). Padding is used to align the payload type and pad length octets as specified in [Kent97]. Padding must be sufficient to align the data to be encrypted to an eight octet (64 bit) boundary. 4.2 Interaction with Authentication This IDEA-CBC ESP document does not limit which authentication algorithm ESP uses. 5. Keying Material The key exchange protocol MUST provide this ESP algorithm with a number of key material bits greater than or equal to the required key size. If the key exchange protocol does not negotiate key size, the key MUST be 128 bits in length. This ESP algorithm will take the IDEA-CBC key from the first bits of keying material, where represents the required key size in bits. If the required key size is less than 128 bits, the implementation MUST extend the keying material by concatenating it with itself until the concatenated length is greater than or equal to 128 bits. If the concatenated length is greater than 128 bits, implementations MUST truncate the new keying material to 128 bits. Note however that this technique significantly weakens IDEA. It is suggested that any keys derived in this manner should have short lifetimes. R. Adams [Page 5] Internet Draft The ESP IDEA Algorithm 23 June 1997 If the required key size is 128 bits, derive the key schedule normally, according the IDEA specification [Lai]. Two keying material sizes above 128 bits are valid. 448 bits of keying material is valid for four round IDEA. 832 bits of keying material is valid for eight round IDEA. If the required key size is between 128 bits and the valid size for the number of rounds being used, implementations MUST ignore bits of keying material beyond 128 bits. If the required key size is greater than 128 bits and valid for the number of rounds being used, implementations MUST set the IDEA encryption key schedule directly from the keying material provided by the key exchange protocol. Set the first IDEA encryption sub- key from the first 16 bits of keying material, and so on. In this case, implementations MUST set the decryption key schedule from the encryption key schedule normally. Implementations MUST ignore bits of keying material beyond the number of valid bits for the number of rounds being used. 6. Security Considerations IDEA is thought to be a secure encryption algorithm. Currently there are no known attacks on four or eight round IDEA [Schneier]. 7. Reference [Crypto93] Daeman, J., Govaerts, R., and Vandewalle, J. "Weak Keys for IDEA", Advances in Cryptology, CRYPTO 93 Proceedings, Springer-Verlag, 1994, pp. 224-230. [Kent97] Kent, S., Atkinson, R., "IP Encapsulating Security Payload (ESP)", ftp://ietf.org/internet-drafts/draft-ietf-ipsec- new-esp-00.txt, March 1997 [Lai] Lai, X. "On the Design and Security of Block Ciphers", ETH Series in Information Processing, v. 1, Konstanz: Hartung-Gorre Verlag, 1992. [RFC-1825] Atkinson, R. "Security Architecture for the Internet Protocol", ftp://ds.internic.net/rfc/rfc1825.txt, August 1995. [RFC-2085] Oehler, M., Glenn, R., "HMAC-MD5 IP Authentication with Replay Prevention," ftp://ds.internic.net/rfc/rfc2085.txt, February 1997. R. Adams [Page 6] Internet Draft The ESP IDEA Algorithm 23 June 1997 [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate Requirement Levels", ftp://ds.internic.net/rfc/rfc2119.txt, March 1997 [Schneier] Schneier, B., "Applied Cryptography Second Edition", John Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7 [Scheier97] Scheier, B. "Speed Comparisons of Block Ciphers on a Pentium." February 1997, http://www.counterpane.com/speed.html 8. Acknowledgments This document is based on work done in the IPsec working group and suggestions from Roy Pereira. The IPSec working group can be contacted through its chairs: Robert Moskowitz Rgm3@chrysler.com Chrysler Corporation Theodore Y. Tso Tytso@MIT.EDU Massachusetts Institute of Technology or via the IPSec working group's mailing list (ipsec@tis.com). 9. Editors Address Rob Adams adams@cisco.com cisco Systems Inc. 101 Cooper St. Santa Cruz, CA 95060 United States of America +1 408 457 5397 R. Adams [Page 7]