idnits 2.17.1 draft-ietf-ipsec-ciph-idea-cbc-00.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-25) 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. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The abstract seems to contain references ([Kent97], [Schneier]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 107: '...xchange protocol SHOULD negotiate the ...' RFC 2119 keyword, line 142: '... Implementations MAY accept keys short...' RFC 2119 keyword, line 143: '... Implementations MUST not accept keyin...' RFC 2119 keyword, line 156: '... Implementations MUST prohibit weak ke...' RFC 2119 keyword, line 159: '... implementation MUST XOR each of the ...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Implementations MAY accept keys shorter or longer than 128 bits. Implementations MUST not accept keying material shorter than 40 bits in length. -- 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.) -- The document date (23 June 1997) is 9803 days in the past. Is this intentional? 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? 'Schneier' on line 278 looks like a reference -- Missing reference section? 'Kent97' on line 259 looks like a reference -- Missing reference section? 'RFC-1825' on line 267 looks like a reference -- Missing reference section? 'RFC-2119' on line 274 looks like a reference -- Missing reference section? 'Lai' on line 263 looks like a reference -- Missing reference section? 'Schneier97' on line 132 looks like a reference -- Missing reference section? 'Cryto93' on line 161 looks like a reference -- Missing reference section? 'Crypto93' on line 255 looks like a reference -- Missing reference section? 'RFC-2085' on line 270 looks like a reference -- Missing reference section? 'Scheier97' on line 281 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft The ESP IDEA Algorithm 23 June 1997 4 Security Working Group Ipsec Working Group 5 INTERNET DRAFT Rob Adams 6 Cisco Systems Inc. 7 23 June 1997 8 Expires in Six Months 10 The ESP IDEA-CBC Algorithm Using Explicit IV 11 13 Status of this Memo 15 This document is a submission to the IETF Internet Protocol 16 Security (IPSEC) Working Group. Comments are solicited and should 17 be addressed to the working group mailing list (ipsec@tis.com) or 18 to the editor. 20 This document is an Internet-Draft. Internet Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its 22 areas, and its working Groups. Note that other groups may also 23 distribute working documents as Internet Drafts. 25 Internet-Drafts draft documents are valid for a maximum of six 26 months and may be updated, replaced, or obsolete by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 To learn the current status of any Internet-Draft, please check 32 the "1id-abstracts.txt" listing contained in the Internet-Drafts 33 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 34 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 35 Coast), or ftp.isi.edu (US West Coast). 37 Distribution of this memo is unlimited. 39 Abstract 41 This draft describes the use of the IDEA [Schneier] block cipher 42 algorithm in CBC mode with the IPSec Encapsulating Security 43 Payload (ESP) [Kent97]. 45 Table of Contents: 47 1. Introduction.................................................2 48 1.1 Specification of Requirements.............................2 49 2. Cipher Algorithm.............................................2 50 2.1 Rounds....................................................3 51 2.2 Background................................................3 52 2.3 Performance...............................................3 53 3. Key Size.....................................................5 54 3.1 Weak Keys.................................................5 55 4. ESP Payload..................................................5 56 4.1 Block Size and Padding....................................5 57 4.2 Interaction with Authentication...........................5 58 5. Keying Material..............................................5 59 6. Security Considerations......................................6 60 7. Reference....................................................6 61 8. Acknowledgments..............................................7 62 9. Editor's Address.............................................7 64 1. Introduction 66 This draft describes the use of the IDEA cipher algorithm in CBC 67 mode to provide confidentiality in conjunction with the IPsec ESP 68 protocol [Kent97]. 70 This document assumes readers are familiar with the terms and 71 concepts in [RFC-1825] and in [Kent97]. 73 1.1 Specification of Requirements 75 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 76 NOT", and "MAY" that appear in this document are to be interpreted 77 as described in [RFC-2119]. 79 2. Cipher Algorithm 81 This document gives implementers specific instructions for using 82 the IDEA block cipher algorithm in CBC mode with a block size of 83 64 bits as described in [Schneier] to secure ESP. 85 The IDEA algorithm is patented in Europe and in the United States 86 with patent application pending in Japan. Licenses are required 87 for commercial uses of IDEA. 89 For patent and licensing information, contact: 91 Ascom Systec AG, 92 Dept. CMVV 93 Gewerbepark, CH-5506 94 Magenwil, Switzerland 95 Phone: +41 64 56 59 83 96 Fax: +41 64 56 59 90 97 idea@ascom.ch 99 or see 101 http://www.ascom.ch/Web/systec/policy/normal/exhibit1.html 103 2.1 Rounds 105 Compliant implementations may use either four or eight round IDEA. 107 The key exchange protocol SHOULD negotiate the number of rounds 108 for IDEA. Only four and eight round IDEA are valid. If the key 109 exchange protocol does not negotiate the number rounds, eight 110 round IDEA is the default. 112 Although there are no known attacks against four round IDEA, those 113 choosing to use four round IDEA for performance reasons, may wish 114 shorten key lifetimes via site specific policy. 116 2.2 Background 118 Xuejia Lai and James Massey developed the IDEA (International Data 119 Encryption Algorithm) algorithm. The algorithm is described in 120 detail in [Lai] and [Schneier]. 122 2.3 Performance 124 Normal eight round IDEA is approximately twice as fast DES on 386 125 and 486 processors. However on a Pentium, both eight round IDEA 126 and 56 bit key, 16 round DES require about the same number of 127 clock cycles per byte encrypted. 129 Four round IDEA is twice as fast as eight round IDEA. 131 For a comparison table of the speed of IDEA and other cipher 132 algorithms, see [Schneier97]. 134 3. Key Size 136 IDEA accepts 128 bits of keying material to generate sub-keys. 137 IDEA may also accept keying material of sufficient length to set 138 its sub-keys directly. Eight round IDEA uses 52, 16 bit sub-keys 139 or 832 bits of keying material. Four round IDEA uses 28, 16 bit 140 sub-keys or 448 bits of keying material. 142 Implementations MAY accept keys shorter or longer than 128 bits. 143 Implementations MUST not accept keying material shorter than 40 144 bits in length. 146 3.1 Weak Keys 148 IDEA has weak keys of the following form: 150 0000,0000,0x00,0000,0000,000x,xxxx,x000 152 where "x" can be any hexadecimal number. 154 Keys of this form guarantee the value of bit-wise XOR of resultant 155 ciphertext pairs from the bit-wise XOR of certain plaintext pairs. 156 Implementations MUST prohibit weak keys even though the 157 probability of randomly generating such a key is quite small. If 158 the key manager provides the implementation with a weak key, the 159 implementation MUST XOR each of the generated encryption sub-keys 160 with the value 0x0dae before generating the decryption sub-key set 161 [Cryto93]. Implementations may choose to prohibit weak keys by 162 rejecting weak keys altogether and requesting new keying material. 164 Weak keys cannot be detected if the sub-keys are set directly. 166 4. ESP Payload 168 IDEA in CBC mode requires an initialization vector of eight octets 169 for use with ESP [Kent97]. The IV MUST precede the data to be 170 encrypted in the packet and must be eight octets (64 bits) in 171 length. The IV SHOULD be chosen at random. Common practice is to 172 use random data for the first IV and the last eight octets of 173 encrypted data from an encryption process as the IV for the next 174 encryption process. 176 The payload field, as defined in [Kent97], is broken down 177 according to the following diagram: 179 +---------------+---------------+---------------+---------------+ 180 | | 181 + Initialization Vector + 182 | | 183 +---------------+---------------+---------------+---------------+ 184 | | 185 ~ Encrypted Payload (Variable length) ~ 186 | | 187 +---------------+---------------+---------------+---------------+ 188 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 190 4.1 Block Size and Padding 192 The IDEA-CBC cipher algorithm MUST use a block size of eight 193 octets (64 bits). 195 Padding is used to align the payload type and pad length octets as 196 specified in [Kent97]. Padding must be sufficient to align the 197 data to be encrypted to an eight octet (64 bit) boundary. 199 4.2 Interaction with Authentication 201 This IDEA-CBC ESP document does not limit which authentication 202 algorithm ESP uses. 204 5. Keying Material 206 The key exchange protocol MUST provide this ESP algorithm with a 207 number of key material bits greater than or equal to the required 208 key size. 210 If the key exchange protocol does not negotiate key size, the key 211 MUST be 128 bits in length. 213 This ESP algorithm will take the IDEA-CBC key from the first 214 bits of keying material, where represents the required key 215 size in bits. 217 If the required key size is less than 128 bits, the implementation 218 MUST extend the keying material by concatenating it with itself 219 until the concatenated length is greater than or equal to 128 220 bits. If the concatenated length is greater than 128 bits, 221 implementations MUST truncate the new keying material to 128 bits. 222 Note however that this technique significantly weakens IDEA. It is 223 suggested that any keys derived in this manner should have short 224 lifetimes. 226 If the required key size is 128 bits, derive the key schedule 227 normally, according the IDEA specification [Lai]. 229 Two keying material sizes above 128 bits are valid. 448 bits of 230 keying material is valid for four round IDEA. 832 bits of keying 231 material is valid for eight round IDEA. 233 If the required key size is between 128 bits and the valid size 234 for the number of rounds being used, implementations MUST ignore 235 bits of keying material beyond 128 bits. 237 If the required key size is greater than 128 bits and valid for 238 the number of rounds being used, implementations MUST set the IDEA 239 encryption key schedule directly from the keying material provided 240 by the key exchange protocol. Set the first IDEA encryption sub- 241 key from the first 16 bits of keying material, and so on. In this 242 case, implementations MUST set the decryption key schedule from 243 the encryption key schedule normally. 245 Implementations MUST ignore bits of keying material beyond the 246 number of valid bits for the number of rounds being used. 248 6. Security Considerations 250 IDEA is thought to be a secure encryption algorithm. Currently 251 there are no known attacks on four or eight round IDEA [Schneier]. 253 7. Reference 255 [Crypto93] Daeman, J., Govaerts, R., and Vandewalle, J. "Weak Keys 256 for IDEA", Advances in Cryptology, CRYPTO 93 Proceedings, 257 Springer-Verlag, 1994, pp. 224-230. 259 [Kent97] Kent, S., Atkinson, R., "IP Encapsulating Security 260 Payload (ESP)", ftp://ietf.org/internet-drafts/draft-ietf-ipsec- 261 new-esp-00.txt, March 1997 263 [Lai] Lai, X. "On the Design and Security of Block Ciphers", ETH 264 Series in Information Processing, v. 1, Konstanz: Hartung-Gorre 265 Verlag, 1992. 267 [RFC-1825] Atkinson, R. "Security Architecture for the Internet 268 Protocol", ftp://ds.internic.net/rfc/rfc1825.txt, August 1995. 270 [RFC-2085] Oehler, M., Glenn, R., "HMAC-MD5 IP Authentication with 271 Replay Prevention," ftp://ds.internic.net/rfc/rfc2085.txt, 272 February 1997. 274 [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate 275 Requirement Levels", ftp://ds.internic.net/rfc/rfc2119.txt, March 276 1997 278 [Schneier] Schneier, B., "Applied Cryptography Second Edition", 279 John Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7 281 [Scheier97] Scheier, B. "Speed Comparisons of Block Ciphers on a 282 Pentium." February 1997, http://www.counterpane.com/speed.html 284 8. Acknowledgments 286 This document is based on work done in the IPsec working group and 287 suggestions from Roy Pereira. 289 The IPSec working group can be contacted through its chairs: 291 Robert Moskowitz 292 Rgm3@chrysler.com 293 Chrysler Corporation 295 Theodore Y. Tso 296 Tytso@MIT.EDU 297 Massachusetts Institute of Technology 299 or via the IPSec working group's mailing list (ipsec@tis.com). 301 9. Editors Address 303 Rob Adams 304 adams@cisco.com 305 cisco Systems Inc. 306 101 Cooper St. 307 Santa Cruz, CA 95060 308 United States of America 309 +1 408 457 5397