idnits 2.17.1 draft-ietf-ipsec-ciph-blowfish-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-26) 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 5 longer pages, the longest (page 4) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages 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. ** The abstract seems to contain references ([Kent97], [Schneier]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (23 June 1997) is 9804 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: 'Schneier97' is mentioned on line 107, but not defined == Unused Reference: 'RFC-2085' is defined on line 194, but no explicit reference was found in the text == Unused Reference: 'Scheier97' is defined on line 214, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Kent97' ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier' -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier93' -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Scheier97' Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Security Working Group Ipsec Working Group 2 INTERNET DRAFT Rob Adams 3 Cisco Systems Inc. 4 23 June 1997 6 Expires in Six Months 8 The ESP Blowfish-CBC Algorithm Using an Explicit IV 9 11 Status of this Memo 13 This document is a submission to the IETF Internet Protocol 14 Security (IPSEC) Working Group. Comments are solicited and should 15 be addressed to the working group mailing list (ipsec@tis.com) or 16 to the editor. 18 This document is an Internet-Draft. Internet Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its 20 areas, and its working Groups. Note that other groups may also 21 distribute working documents as Internet Drafts. 23 Internet-Drafts draft documents are valid for a maximum of six 24 months and may be updated, replaced, or obsolete by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 To learn the current status of any Internet-Draft, please check 30 the "1id-abstracts.txt" listing contained in the Internet-Drafts 31 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 32 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 33 Coast), or ftp.isi.edu (US West Coast). 35 Distribution of this memo is unlimited. 37 Abstract 39 This draft describes the use of the Blowfish [Schneier] block 40 cipher algorithm to be used with the IPSec Encapsulating Security 41 Payload (ESP) [Kent97]. 43 Table of Contents 45 1. Introduction..................................................2 46 1.1 Specification of Requirements..............................2 47 2. Cipher Algorithm..............................................2 48 2.1 Rounds.....................................................2 49 2.2 Background.................................................3 50 2.3 Performance................................................3 51 3. Key Size......................................................3 52 3.1 Weak Keys..................................................3 53 4. ESP Payload...................................................3 54 4.1 Block Size and Padding.....................................4 55 4.2 Interaction with Authentication............................4 56 5. Keying Material...............................................4 57 6. Security Considerations.......................................4 58 7. References....................................................5 59 8. Acknowledgements..............................................5 60 9. Editor's Address..............................................6 62 1. Introduction 64 This draft describes the use of the Blowfish cipher algorithm in 65 CBC mode to provide confidentiality in conjunction with the IPsec 66 ESP protocol [Kent97]. 68 This document assumes readers are familiar with the terms and 69 concepts in [RFC-1825] and in [Kent97]. 71 Blowfish is described in detail in [Schneier] and [Schneier93]. 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 Blowfish block cipher algorithm in CBC mode with a block size 83 of 64 bits as described in [Schneier93] to secure ESP. 85 2.1 Rounds 87 Compliant implementations MUST use only 16 round Blowfish. Fewer 88 rounds are open to several different sorts of attacks outlined in 89 [Schneier95]. 91 2.2 Background 93 Bruce Schneier of Counterpane Systems developed the Blowfish block 94 cipher algorithm. The algorithm is described in detail in 95 [Schneier93]. 97 2.3 Performance 99 Blowfish is designed to encrypt data very efficiently on 32 bit 100 processors. Although setting up the keys for Blowfish is complex 101 and time consuming, actual encryption is efficient. Sixteen round 102 Blowfish uses only 18 clock cycles per byte encrypted on a Pentium 103 versus 45 clock cycles for 16 round DES with a 56 bit key, and 108 104 for 48 round Triple-DES. 106 For a comparison table of the speed of Blowfish and other cipher 107 algorithms, see [Schneier97]. 109 3. Key Size 111 Blowfish accepts keying material of varying lengths up to 448 bits 112 inclusive. Implementations MUST prohibit the use of a zero length 113 key for this transform. Implementations SHOULD prohibit the use of 114 a key of length less than 40 bits. Implementations SHOULD support 115 keys longer than 128 bits up to 448 bits. Implementations MUST 116 only allow key sizes in 8 bit increments for interoperability 117 purposes. For example, implementations should allow 40, 48, 56, 118 64, ? 440, and 448 bit keys. The number of bits of keying material 119 required for Blowfish is a host specific policy issue. 121 3.1 Weak Keys 123 Weak keys for Blowfish have been discovered. Weak keys are keys 124 that produce the identical entries in a given S-box. 125 Unfortunately, there is no way to test for weak keys before the S- 126 box values are generated. However, the chances of randomly 127 generating such a key are small. 129 4. ESP Payload 131 Blowfish in CBC mode requires an initialization vector of eight 132 octet for use with ESP [Kent97]. The IV MUST precede the data to 133 be encrypted in the packet and must be eight octets (64 bits) in 134 length. The IV SHOULD be chosen at random. Common practice is to 135 use random data for the first IV and the last eight octets of 136 encrypted data from an encryption process as the IV for the next 137 encryption process. 139 The payload field, as defined in [Kent97], is broken down 140 according to the following diagram: 142 +---------------+---------------+---------------+---------------+ 143 | | 144 + Initialization Vector + 145 | | 146 +---------------+---------------+---------------+---------------+ 147 | | 148 ~ Encrypted Payload (Variable length) ~ 149 | | 150 +---------------+---------------+---------------+---------------+ 151 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 153 4.1 Block Size and Padding 155 The Blowfish-CBC cipher algorithm MUST use a block size of eight 156 octets (64 bits). 158 Padding is used to align the payload type and pad length octets as 159 specified in [Kent97]. Padding must be sufficient to align the 160 data to be encrypted to an eight octet (64 bit) boundary. 162 4.2 Interaction with Authentication 164 This Blowfish-CBC ESP document does not limit which authentication 165 algorithm ESP uses. 167 5. Keying Material 169 The key exchange protocol MUST provide this ESP algorithm with a 170 number of key material bits greater than or equal to the required 171 key size. 173 If the key exchange protocol does not negotiate key size, the key 174 must be 128 bits in length. 176 This ESP algorithm will take the Blowfish-CBC key from the first 177 bits of keying material, where represents the required key 178 size in bits. 180 6. Security Considerations 182 Blowfish is thought to be a secure encryption algorithm. Currently 183 there are no known attacks on 16 round Blowfish [Schneier]. 185 7. References 187 [Kent97] Kent, S., Atkinson, R., "IP Encapsulating Security 188 Payload (ESP)", ftp://ietf.org/internet-drafts/draft-ietf-ipsec- 189 new-esp-00.txt, March 1997 191 [RFC-1825] Atkinson, R. "Security Architecture for the Internet 192 Protocol", ftp://ds.internic.net/rfc/rfc1825.txt, August 1995. 194 [RFC-2085] Oehler, M., Glenn, R., "HMAC-MD5 IP Authentication with 195 Replay Prevention," ftp://ds.internic.net/rfc/rfc2085.txt, 196 February 1997. 198 [RFC-2119] Bradner, S., "Key words for use in RFCs to indicate 199 Requirement Levels", ftp://ds.internic.net/rfc/rfc2119.txt, March 200 1997 202 [Schneier] Schneier, B., "Applied Cryptography Second Edition", 203 John Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7 205 [Schneier93] Schneier, B., "Description of a New Variable-Length 206 Key, 64-Bit Block Cipher", from "Fast Software Encryption, 207 Cambridge Security Workshop Proceedings", Springer-Verlag, 1994, 208 pp. 191-204. http://www.counterpane.com/bfsverlag.html 210 [Schneier95] Schneier, B., "THE BLOWFISH ENCRYPTION ALGORITHM-- 211 ONE YEAR LATER", Dr. Dobb's Journal, September 1995, 212 http://www.counterpane.com/bfdobsoyl.html 214 [Scheier97] Scheier, B. "Speed Comparisons of Block Ciphers on a 215 Pentium." February 1997, http://www.counterpane.com/speed.html 217 8. Acknowledgements 219 This document is based on work done in the IPsec working group and 220 suggestions from Roy Pereira and Stephen Kent. 222 The IPSec working group can be contacted through its chairs: 224 Robert Moskowitz 225 Rgm3@chrysler.com 226 Chrysler Corporation 228 Theodore Y. Ts'o 229 Tytso@MIT.EDU 230 Massachusetts Institute of Technology 232 or via the IPSec working group's mailing list (ipsec@tis.com). 234 9. Editor's Address 236 Rob Adams 237 adams@cisco.com 238 cisco Systems Inc. 239 101 Cooper St. 240 Santa Cruz, CA 95060 241 United States of America 243 +1 408 457 5397