idnits 2.17.1 draft-ietf-ipsec-ciph-cast128-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-19) 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 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (July 2, 1997) is 9788 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) ** Downref: Normative reference to an Informational RFC: RFC 2144 (ref. 'Adams97') == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-arch-sec-01 -- Unexpected draft version: The latest known version of draft-ietf-ipsec-new-esp is -00, but you're referring to -01. -- Possible downref: Normative reference to a draft: ref. 'Kent97' Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force R. Pereira 2 IP Security Working Group TimeStep Corporation 3 Internet Draft G. Carter 4 Expires in six months Entrust Technologies 5 July 2, 1997 7 The ESP CAST128-CBC Algorithm 8 10 Status of this Memo 12 This document is a submission to the IETF Internet Protocol 13 Security (IPSEC) Working Group. Comments are solicited and should 14 be addressed to the working group mailing list (ipsec@tis.com) or 15 to the editor. 17 This document is an Internet-Draft. Internet Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, 19 and its working Groups. Note that other groups may also distribute 20 working documents as Internet Drafts. 22 Internet-Drafts draft documents are valid for a maximum of six 23 months and may be updated, replaced, or obsolete by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in 26 progress." 28 To learn the current status of any Internet-Draft, please check the 29 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 30 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 31 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 32 ftp.isi.edu (US West Coast). 34 Distribution of this memo is unlimited. 36 Abstract 38 This document describes the CAST-128 block cipher algorithm as to 39 be used with the IPSec Encapsulating Security Payload (ESP). 41 Table of Contents 43 1. Introduction...................................................2 44 1.1 Specification of Requirements...............................2 45 2. Cipher Algorithm...............................................2 46 2.1 Rounds......................................................2 47 2.2 Background on CAST-128......................................3 48 2.3 Performance.................................................3 49 3. Key Sizes......................................................3 50 3.1 Weak Keys...................................................4 51 4. ESP Payload....................................................4 52 4.1 Block Size and Padding......................................4 53 4.2 Interaction with Authentication Algorithms..................4 54 5. Keying Material................................................5 55 6. Security Considerations........................................5 56 7. References.....................................................5 57 8. Acknowledgments................................................5 58 9. Editors' Addresses.............................................6 60 1. Introduction 62 This document describes how the CAST-128 cipher algorithm may be 63 used with the IPSec ESP protocol. 65 It is assumed that the reader is familiar with the terms and 66 concepts described in the "Security Architecture for the Internet 67 Protocol" [Atkinson95] and "IP Encapsulating Security Payload 68 (ESP)" [Kent97] documents. 70 Furthermore, this document is a companion to [Kent97] and MUST be 71 read in its context. 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 [Bradner97]. 79 2. Cipher Algorithm 81 The symmetric block cipher algorithm used to secure ESP is CAST-128 82 in CBC mode with a block size of 64 bits as described in [Adams97]. 84 2.1 Rounds 86 For key sizes up to and including 80 bits (i.e., 40, 48, 56, 64, 87 72, and 80 bits), the algorithm is exactly as specified but MUST 88 use 12 rounds. 90 For key sizes greater than 80 bits, the algorithm MUST use the full 91 16 rounds. 93 2.2 Background on CAST-128 95 The CAST design procedure was originally developed by Carlisle 96 Adams and Stafford Travares at Queen's University, Kingston, 97 Ontario, Canada. Subsequent enhancements have been made over the 98 years by Carlisle Adams and Michael Wiener of Entrust Technologies. 99 CAST-128 is the result of applying the CAST Design Procedure as 100 outlined in [Adams97]. 102 2.3 Performance 104 CAST-128 runs approximately 3 times faster than a highly optimized 105 DES implementation and runs 5-6 times faster than the DES 106 implementations found in typical applications. This is based on a 107 non optimized C++ implementation of CAST-128. It can therefore be 108 tuned to give even higher performance, if this is required. 110 The following performance tests were run on a Pentium 90 MHz 111 running the Windows NT operating system using 20 Kbyte buffers and 112 do not include file I/O. The DES-CBC implementation was not 113 optimized for a 32 bit environment. 115 CAST-128 64 bit key CBC encryption ........... 2,640,000 bytes/sec 116 DES CBC encryption ............................. 504,000 bytes/sec 118 3. Key Sizes 120 The CAST-128 encryption algorithm [Adams97] has been designed to 121 allow a key size which can vary from 40 bits to 128 bits, in 8-bit 122 increments (that is, the allowable key sizes are 40, 48, 56, 64, 123 ..., 112, 120, and 128 bits. To facilitate interoperability, it is 124 recommended that key sizes SHOULD be chosen from the set of 40, 64, 125 80 and 128. 127 For key sizes less than 128 bits, the key is padded with zeros in 128 the rightmost, or least significant, positions out to 128 bits 129 since the CAST-128 key schedule assumes an input key of 128 bits. 130 Thus if you had a key with a size of 80 bits `3B5D831CFE', it would 131 be padded to produce a key with a size of 128 bits 132 `3B5D831CFE000000'. 134 In order to avoid confusion, when variable key size operation is 135 used, the name CAST-128 is to be considered synonymous with the 136 name CAST5; this allows a keysize to be appended without ambiguity. 138 Thus, for example, CAST-128 with a 40 bit key is referred to as 139 CAST5-40; where a 128 bit key is explicitly intended, the name 140 CAST5-128 should be used. 142 3.1 Weak Keys 144 CAST-128 no known weak keys. 146 4. ESP Payload 148 CAST128-CBC requires an explicit Initialization Vector (IV) of 8 149 octets (64 bits). Thus the payload is made up of the 8 octet IV 150 followed by raw cipher-text. The IV SHOULD be chosen at random. 151 Common practice is to use random data for the first IV and the last 152 8 octets of encrypted data from an encryption process as the IV for 153 the next encryption process. 155 The payload field, as defined in [Kent97], is broken down according 156 to the following diagram: 158 +---------------+---------------+---------------+---------------+ 159 | | 160 + Initialization Vector (IV) + 161 | | 162 +---------------+---------------+---------------+---------------+ 163 | | 164 ~ Encrypted Payload (variable length) ~ 165 | | 166 +---------------------------------------------------------------+ 167 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 169 4.1 Block Size and Padding 171 The ESP CAST-128 algorithm described in this document MUST use a 172 block size of 8 octets (64 bits). 174 When padding is required, it MUST be done according to the 175 conventions specified in [Kent97]. 177 4.2 Interaction with Authentication Algorithms 179 This CAST-128 ESP document has no limitations on what 180 authentication algorithm is used in ESP. 182 5. Keying Material 184 The minimum number of bits sent from the key exchange protocol to 185 this ESP algorithm must be greater or equal to the key size. 187 The CAST-128 key is taken from the first bits of the keying 188 material, where represents the required key size. 190 6. Security Considerations 192 The ESP CAST-128 algorithm described in this document has the same 193 security considerations as in [Adams97]. 195 Care should be taken when using small key sizes. Smaller key sizes 196 of 56 bits and below make brute force type attacks practical 197 regardless of the cipher algorithm used. It is therefore 198 recommended that the ESP CAST-128 key size be at least 80 bits. 199 Use of key sizes less than 80 bits is permitted, but careful 200 considerations should be taken before its use. 202 7. References 204 [Adams97] Adams, C., "The CAST-128 Encryption Algorithm_, RFC2144, 205 1997. 207 [Atkinson95] Atkinson, R., "Security Architecture for the Internet 208 Protocol", draft-ietf-ipsec-arch-sec-01 210 [Bradner97] Bradner, S., "Key words for use in RFCs to indicate 211 Requirement Levels", RFC2119, March 1997 213 [Kent97] Kent, S., Atkinson, R., "IP Encapsulating Security Payload 214 (ESP)", draft-ietf-ipsec-new-esp-01 216 8. Acknowledgments 218 This document is based on suggestions from Stephen Kent and 219 discussions from the IPSec mailing list as well as other IPSec 220 drafts. 222 Special thanks for Carlisle Adams and Paul Van Oorschot both of 223 Entrust Technologies who provided input and review with respect to 224 CAST-128. 226 9. Editors' Addresses 228 Roy Pereira 229 230 TimeStep Corporation 231 (613) 599-3610 x 4808 233 Greg Carter 234 235 Entrust Technologies 236 (613) 763-1358 238 The IPSec working group can be contacted via the IPSec working 239 group's mailing list (ipsec@tis.com) or through its chairs: 241 Robert Moskowitz 242 rgm@chrysler.com 243 Chrysler Corporation 245 Theodore Y. Ts'o 246 tytso@MIT.EDU 247 Massachusetts Institute of Technology