idnits 2.17.1 draft-simpson-cbc-01.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 an Authors' Addresses Section. ** 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 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 1998) is 9388 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: 'DayDreamer' is mentioned on line 2, but not defined == Unused Reference: 'Bellovin95' is defined on line 275, but no explicit reference was found in the text == Unused Reference: 'Bellovin96' is defined on line 281, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Bellovin95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bellovin96' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-8732' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-81' -- Possible downref: Non-RFC (?) normative reference: ref. 'Knudsen94' -- Possible downref: Non-RFC (?) normative reference: ref. 'Maurer91' -- Possible downref: Non-RFC (?) normative reference: ref. 'MOV97' ** Obsolete normative reference: RFC 1827 (Obsoleted by RFC 2406) -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier95' -- Possible downref: Non-RFC (?) normative reference: ref. 'VK83' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W A Simpson [DayDreamer] 3 Internet Draft 4 expires in six months July 1998 6 ESP with Cipher Block Chaining (CBC) 7 draft-simpson-cbc-01.txt 9 Status of this Memo 11 This document is an Internet-Draft. Internet Drafts are working doc- 12 uments of the Internet Engineering Task Force (IETF), its Areas, and 13 its Working Groups. Note that other groups may also distribute work- 14 ing documents as Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months, and may be updated, replaced, or obsoleted by other documents 18 at any time. It is not appropriate to use Internet Drafts as refer- 19 ence material, or to cite them other than as a ``working draft'' or 20 ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 24 Directories on: 26 ftp.is.co.za (Africa) 27 nic.nordu.net (Northern Europe) 28 ftp.nis.garr.it (Southern Europe) 29 ftp.ietf.org (Eastern USA) 30 ftp.isi.edu (Western USA) 31 munnari.oz.au (Pacific Rim) 33 Distribution of this memo is unlimited. 35 Copyright Notice 37 Copyright (C) William Allen Simpson (1997-1998). All Rights 38 Reserved. 40 Abstract 42 This document describes the Cipher Block Chaining (CBC) mode, used by 43 a number of IP Encapsulating Security Payload (ESP) transforms. 45 1. Introduction 47 The Encapsulating Security Payload (ESP) [RFC-1827x] provides confi- 48 dentiality for IP datagrams by encrypting the payload data to be pro- 49 tected. This specification describes the ESP use of the Cipher Block 50 Chaining (CBC) mode. 52 CBC is used to mask patterns of identical blocks within the same 53 datagram. Together with an Initialization Vector (IV) that is dif- 54 ferent for every datagram, identical plaintext payloads will each 55 encrypt to different ciphertext payloads. As an added benefit, when 56 the cipher output is effectively random in appearance (a characteris- 57 tic of a good cipher), masking the plaintext with previous ciphertext 58 will strengthen the entropy of the next input to the cipher. 60 CBC was first defined for DES in [FIPS-81], and generalized by 61 [ISO-8732] and [ISO/IEC-10116]. For a technical exposition on CBC, 62 see [MOV97]. For more explanation and implementation information for 63 CBC, and a useful comparison with other modes of operation, see 64 [Schneier95]. 66 2. Description 67 2.1. Single Algorithm 69 P1 P2 Pi 70 | | | 71 IV->->(X) +>->->->(X) +>->->->(X) 72 v ^ v ^ v 73 +-----+ ^ +-----+ ^ +-----+ 74 k->| E | ^ k->| E | ^ k->| E | 75 +-----+ ^ +-----+ ^ +-----+ 76 | ^ | ^ | 77 +>->->+ +>->->+ +>->-> 78 | | | 79 C1 C2 Ci 81 For each datagram, an Initialization Vector (IV) is XOR'd with the 82 first plaintext block (P1). The keyed encryption function (Ek) gen- 83 erates the ciphertext (C1) for the block. 85 For successive blocks, the previous ciphertext block is XOR'd with 86 the current plaintext (Pi). The keyed encryption function (Ek) gen- 87 erates the ciphertext (Ci) for that block. 89 C1 C2 Ci 90 | | | 91 +>->->+ +>->->+ +>->-> 92 v v v v v 93 +-----+ v +-----+ v +-----+ 94 k->| D | v k->| D | v k->| D | 95 +-----+ v +-----+ v +-----+ 96 | v | v | 97 IV->->(X) +>->->->(X) +>->->->(X) 98 | | | 99 P1 P2 Pi 101 To decrypt, the order of the manipulations is reversed (as shown). 103 2.2. Multiple Algorithms 105 P1 P2 Pi 106 | | | 107 IV->->(X) +>->->->(X) +>->->->(X) 108 v ^ v ^ v 109 +-----+ ^ +-----+ ^ +-----+ 110 k1->| A1 | ^ k1->| A1 | ^ k1->| A1 | 111 +-----+ ^ +-----+ ^ +-----+ 112 | ^ | ^ | 113 v ^ v ^ v 114 +-----+ ^ +-----+ ^ +-----+ 115 k2->| A2 | ^ k2->| A2 | ^ k2->| A2 | 116 +-----+ ^ +-----+ ^ +-----+ 117 | ^ | ^ | 118 v ^ v ^ v 119 +-----+ ^ +-----+ ^ +-----+ 120 k3->| A3 | ^ k3->| A3 | ^ k3->| A3 | 121 +-----+ ^ +-----+ ^ +-----+ 122 | ^ | ^ | 123 +>->->+ +>->->+ +>->-> 124 | | | 125 C1 C2 Ci 127 When using multiple algorithms, the "outer" chaining technique is 128 used. 130 For each datagram, an Initialization Vector (IV) is XOR'd with the 131 first plaintext block (P1). The series of keyed algorithm functions 132 (Ankn) generate the ciphertext (C1) for the block. Each algorithm 133 uses an independant key. 135 For successive blocks, the previous ciphertext block is XOR'd with 136 the current plaintext (Pi). The series of keyed algorithm functions 137 (Ankn) generate the ciphertext (Ci) for that block. 139 To decrypt, the order of the manipulations and keys is reversed (as 140 shown earlier). 142 3. Initialization Vector 144 CBC requires an Initialization Vector (IV). The IV conceals initial 145 blocks that repeat in multiple datagrams. 147 For ESP, each datagram generates its IV from material carried in the 148 datagram. This ensures that decryption of the received datagram can 149 be performed, even when some datagrams are lost, duplicated, or re- 150 ordered in transit. 152 Security Notes: 154 Each IV is intended to be unique over the lifetime of the ESP 155 cipher session-key(s). A counter is most commonly used to gener- 156 ate the IV, providing an easy method to prevent repetition. 158 However, cryptanalysis might be aided by the rare serendipitous 159 occurrence when the counter repeatedly changes in exactly the same 160 fashion as corresponding bit positions in the first block. Design 161 of specific IV generation techniques must take this into account. 163 Ideally, the IV would be based on explicit fields carried in each 164 datagram, but generated pseudo-randomly and protected from disclo- 165 sure [VK83]. This completely protects the first block from unde- 166 tectable modification. One such method could use the same cipher 167 and key(s) in Electronic CodeBook (ECB) mode, enciphering the ESP 168 Security Parameters Index (SPI) concatenated with the ESP Sequence 169 Number (SN), to generate a keyed hash for an IV. 171 Incorporating the anti-replay ESP Sequence Number (SN) can provide 172 both uniqueness and mutual protection between the first block and 173 the ESP header. Modification of the SN to avoid anti-replay mea- 174 sures will also prevent correct decryption of the first block, 175 which is most likely to contain datagram headers required for 176 delivery. Attempts to modify the IV to deliberately redirect 177 transport headers will also likely be detected by the transport 178 checksums. 180 Alternatively, a pseudo-random number generator can be used to 181 generate the IV. Care should be taken that the periodicity of the 182 number generator is long enough to prevent repetition during the 183 lifetime of the session-key(s). 185 Historically, another pseudo-random number source has been the 186 final ciphertext block of a previous datagram, extending CBC to an 187 entire stream of data. This is a common link-level configuration, 188 but does not meet the IP requirement to function reliably with 189 lost, duplicated, and re-ordered datagrams. Also, this could be 190 vulnerable to a datagram insertion attack similar to the splicing 191 attack described later. 193 4. Integrity 195 CBC does not provide integrity for the datagram. A single ciphertext 196 bit change will affect the current block, and a single corresponding 197 bit of the following block. The remaining blocks will be unaffected, 198 without any subsequent indication of the alteration. 200 Blocks can be easily appended to the datagram. When a different ses- 201 sion-key was used to encrypt the appended blocks, the trailing blocks 202 will be uninterpretable. When the same session-key was applied, even 203 though that session-key is unknown, only the first two appended 204 blocks will be garbage, and the remainder will decrypt correctly. 205 Either case could be detrimental to the intended operations. 207 Therefore, depending upon the threat environment, when the ESP data 208 is not otherwise verified (externally using AH or internally by the 209 plaintext payload itself), it is recommended (but not required) that 210 an Authenticator be provided. 212 Security Notes: 214 Historically, Cipher Block Chaining was designed for uni- 215 directional streams of data. When a block is damaged in transmis- 216 sion, on decryption both it and the following block will be gar- 217 bled, but all subsequent blocks will automatically be re- 218 synchronized. 220 The cut and paste splicing attack described by [Bellovin95, 221 Bellovin96] exploits the self-synchronization of CBC. If multiple 222 users of a service have legitimate access to the same key, this 223 feature can be used to insert or replay previously encrypted data 224 of the other users, revealing their original plaintext. The usual 225 (ICMP, TCP, UDP) transport checksum can detect this attack, but on 226 its own is not considered cryptographically strong. In this situ- 227 ation, user or connection oriented integrity checking is needed. 229 5. Collisions 231 The "birthday paradox" probability of identical ciphertexts is 232 squareroot(pi/2) * 2**(blocksize/2). Additional 2**(blocksize/2+n) 233 ciphertexts yield 2**(2**n) collisions. 235 Each such collision reveals a linear relation between two (random) 236 unknown plaintexts and two (random) known ciphertexts. So, an 237 observer learns that Pi = Pj + K for some i, j, and a known constant 238 [Maurer91, Knudsen94]. 240 A datagram generally consists of several ciphertext blocks. The num- 241 ber of datagrams that can be safely exchanged under a single session- 242 key is a function of the total size of the datagrams. Ciphers using 243 CBC need to refresh keys more frequently than might otherwise be 244 expected. 246 Security Notes: 248 For a 64-bit block cipher, the basic collision rate is on the 249 order of 48 GigaBytes. While at first glance that might seem like 250 a lot of data, a telephone conversation generates about 7,200 251 bytes per second, or 26 GigaBytes per hour, not including neces- 252 sary transport headers. Thus, for this application, the key would 253 require refreshment about once per hour to avoid linear cryptanal- 254 ysis. 256 Security Considerations 258 Specific security limitations are described as notes in the relevant 259 sections. 261 Acknowledgements 263 Most of the text of this specification was derived from earlier work 264 by William Allen Simpson and Perry Metzger in multiple Request for 265 Comments. 267 The mathematical explanation of the collision rate was provided by 268 Bart Preneel, based on "folklore" from the late 1980s and analysis in 269 the early 1990s. 271 The telephone analogy was provided by Bob Baldwin. 273 References 275 [Bellovin95] 276 Bellovin, S., "An Issue With DES-CBC When Used Without 277 Strong Integrity", Presentation at the 32nd Internet 278 Engineering Task Force, Danvers Massachusetts, April 279 1995. 281 [Bellovin96] 282 Bellovin, S., "Problem Areas for the IP Security Proto- 283 cols", Proceedings of the Sixth Usenix Security Sympo- 284 sium, July 1996. 286 [ISO-8732] "Banking -- Key management (wholesale)", International 287 Organization for Standardization, 1988. 289 [ISO/IEC-10116] 290 "Information Processing -- Modes of Operation for an n- 291 bit block cipher algorithm", International Organization 292 for Standardization, 1991. 294 [FIPS-81] US National Bureau of Standards, "DES Modes of Opera- 295 tion", Federal Information Processing Standard Publica- 296 tion 81, December 1980. 298 [Knudsen94] Knudsen, L., PhD thesis, 1994. 300 [Maurer91] Maurer, U., "Self-Synchronizing Stream Ciphers", Euro- 301 Crypt'91. 303 [MOV97] Menezes, A.J., van Oorschot, P., and Vanstone, S., "Hand- 304 book of Applied Cryptography", CRC Press, 1997. 306 [RFC-1827x] Atkinson, R., "IP Encapsulating Security Protocol (ESP)", 307 Naval Research Laboratory, July 1995. 309 [Schneier95] 310 Schneier, B., "Applied Cryptography Second Edition", John 311 Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7. 313 [VK83] Voydock, V.L., and Kent, S.T., "Security Mechanisms in 314 High-level Networks", ACM Computing Surveys, Vol. 15, No. 315 2, June 1983. 317 Contacts 319 Comments about this document should be discussed on the ipsec@tis.com 320 mailing list. 322 Questions about this document can also be directed to: 324 William Allen Simpson 325 DayDreamer 326 Computer Systems Consulting Services 327 1384 Fontaine 328 Madison Heights, Michigan 48071 330 wsimpson@UMich.edu 331 wsimpson@GreenDragon.com (preferred) 333 Full Copyright Statement 335 Copyright (C) William Allen Simpson (1997-1998). All Rights 336 Reserved. 338 This document and translations of it may be copied and furnished to 339 others, and derivative works that comment on or otherwise explain it 340 or assist in its implementation may be prepared, copied, published 341 and distributed, in whole or in part, without restriction of any 342 kind, provided that the above copyright notice and this paragraph are 343 included on all such copies and derivative works. However, this doc- 344 ument itself may not be modified in any way, except as required to 345 translate it into languages other than English. 347 This document and the information contained herein is provided on an 348 "AS IS" basis and the author(s) DISCLAIM ALL WARRANTIES, EXPRESS OR 349 IMPLIED, INCLUDING (BUT NOT LIMITED TO) ANY WARRANTY THAT THE USE OF 350 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 351 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.