idnits 2.17.1 draft-ietf-ipsec-ciph-rc5-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-03-28) 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: ---------------------------------------------------------------------------- == Line 110 has weird spacing: '...40 bits inclu...' == 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 9766 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) == Outdated reference: A later version (-06) exists of draft-ietf-ipsec-arch-sec-01 ** Downref: Normative reference to an Informational RFC: RFC 2040 (ref. 'Baldwin96') -- 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 (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Roy Pereira 2 IP Security Working Group TimeStep Corporation 3 Internet Draft R. W. Baldwin 4 Expires in six months RSA Data Security, Inc. 5 July 2, 1997 7 The ESP RC5-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 RC5 block cipher algorithm as to be 39 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......................................................3 47 2.2 Background on RC5...........................................3 48 2.3 Performance.................................................3 49 3. Key Sizes......................................................3 50 3.1 Weak Keys...................................................3 51 4. ESP Payload....................................................3 52 4.1 Block Size and Padding......................................4 53 4.2 Interaction with Authentication Algorithms..................4 54 5. Keying Material................................................4 55 6. Security Considerations........................................4 56 7. References.....................................................5 57 8. Acknowledgments................................................5 58 9. Editors' Addresses.............................................5 60 1. Introduction 62 This document describes how the RC5 cipher algorithm may be used 63 with the IPSec ESP protocol. 65 It is assumed that the reader is familiar with the terms and 66 concepts described in the document "Security Architecture for the 67 Internet Protocol" [Atkinson95] and "IP Encapsulating Security 68 Payload (ESP)" [Kent97]. 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 RC5 in 82 CBC mode with 16 rounds and a block size of 64 bits as described in 83 [Baldwin96]. 85 2.1 Rounds 87 RSA Labs recommends that RC5 be used with 16 rounds. Twelve rounds 88 is enough to make RC5 stronger than DES against differential and 89 linear cryptanalysis and sixteen rounds is sufficient to make RC5 90 secure against both forms of cryptanalysis even at a theoretical 91 level. 93 Compliant implementations MUST support 16 rounds. 95 2.2 Background on RC5 97 The RC5 encryption algorithm was developed by Ron Rivest for RSA 98 Data Security Inc. in order to address the need for a high- 99 performance software and hardware ciphering alternative to DES. 101 2.3 Performance 103 Benchmark numbers from RSA Data Security suggest that RC5-CBC runs 104 about twice as fast as Eric Young's DES-CBC implementation from 105 SSLeay on the popular 32-bit CPUs. 107 3. Key Sizes 109 RC5's key size MUST be multiple of 8 bits and MUST be from 40 to 110 2040 bits inclusive. To facilitate interoperability, it is 111 recommended that key sizes SHOULD be chosen from the set of 40, 128 112 and 160 bits. 114 If the key size is not negotiated through the key exchange 115 protocol, then a value of 128 bits MUST be used. All compliant 116 implementations MUST support a key size of 128 bits. 118 3.1 Weak Keys 120 RC5 has no known weak keys when used with 16 rounds. 122 4. ESP Payload 124 RC5-CBC requires an explicit Initialization Vector (IV) of 8 octets 125 (64 bits) that immediately precedes the cipher-text in the payload. 126 The IV SHOULD be chosen at random. Common practice is to use 127 random data for the first IV and the last 8 octets of encrypted 128 data from an encryption process as the IV for the next encryption 129 process. 131 The payload field, as defined in [Kent97], is broken down according 132 to the following diagram: 134 +---------------+---------------+---------------+---------------+ 135 | | 136 + Initialization Vector (IV) + 137 | | 138 +---------------+---------------+---------------+---------------+ 139 | | 140 ~ Encrypted Payload (variable length) ~ 141 | | 142 +---------------------------------------------------------------+ 143 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 145 4.1 Block Size and Padding 147 RC5 has a variably length block size, but for the ESP algorithm 148 described in this document, the block size MUST be 8 octets (64 149 bits). 151 When padding is required, it MUST be done according to the 152 conventions specified in [Kent97]. 154 4.2 Interaction with Authentication Algorithms 156 This ESP RC5 document has no limitations on what authentication 157 algorithm is used in ESP. 159 5. Keying Material 161 The minimum number of bits sent from the Key Exchange Protocol to 162 this ESP algorithm must be greater or equal to the key size. 164 The RC5 key is taken from the first bits of the keying 165 material. Where represents the required key size. 167 6. Security Considerations 169 The ESP RC5 algorithm described in this document has the same 170 security considerations as in [Baldwin96]. 172 Care should be taken when using small key sizes. Small key sizes 173 make brute force type attacks practical regardless of the cipher 174 algorithm used. It is therefore recommended that the ESP RC5 key 175 size be at least 80 bits. Use of key sizes less than 80 bits is 176 permitted, but careful considerations should be taken before its 177 use. 179 7. References 181 [Atkinson95] Atkinson, R., "Security Architecture for the Internet 182 Protocol", draft-ietf-ipsec-arch-sec-01 184 [Baldwin96] Baldwin, R.W., Rivest, R., "The RC5, RC5-CBC, RC5-CBC- 185 Pad, and RC5-CTS Algorithms", RFC2040, October 1996 187 [Bradner97] Bradner, S., "Key words for use in RFCs to indicate 188 Requirement Levels", RFC2119, March 1997 190 [Kent97] Kent, S., Atkinson, R., "IP Encapsulating Security Payload 191 (ESP)", draft-ietf-ipsec-new-esp-01 193 8. Acknowledgments 195 This document is based on previous work by B. Howard of TimeStep 196 Corporation, suggestions from Stephen Kent, discussions from the 197 IPSec mailing list as well as the other IPSec drafts. 199 9. Editors' Addresses 201 Roy Pereira 202 203 TimeStep Corporation 204 (613) 599-3610 x 4808 206 Robert W. Baldwin 207 or 208 RSA Data Security, Inc. 209 (415) 210 595-8782 212 The IPSec working group can be contacted via the IPSec working 213 group's mailing list (ipsec@tis.com) or through its chairs: 215 Robert Moskowitz 216 rgm@chrysler.com 217 Chrysler Corporation 219 Theodore Y. Ts'o 220 tytso@MIT.EDU 221 Massachusetts Institute of Technology