idnits 2.17.1 draft-ietf-ipsec-ciph-3des-expiv-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 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 17, 1997) is 9779 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 -- 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' == Outdated reference: A later version (-01) exists of draft-ietf-ipsec-doc-roadmap-00 ** Downref: Normative reference to an Informational draft: draft-ietf-ipsec-doc-roadmap (ref. 'Thayer97') -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-46' -- Possible downref: Non-RFC (?) normative reference: ref. 'Schneier95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Tuchman79' Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 7 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 R. Thayer 4 Expires in six months Sable Technology Corporation 5 July 17, 1997 7 The ESP 3DES-CBC Algorithm Using an Explicit IV 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 "Triple" DES-EDE3-CBC block cipher 39 algorithm used with the IP Encapsulating Security Payload (ESP). 40 Use of an explicit IV is described. 42 Table of Contents 44 1. Introduction...................................................2 45 1.1 Specification of Requirements...............................2 46 2. Cipher Algorithm...............................................2 47 2.1 Mode........................................................3 48 2.2 Performance.................................................4 49 3. Key Sizes......................................................4 50 3.1 Weak Keys...................................................4 51 4. ESP Payload....................................................4 52 4.1 Block Size and Padding......................................5 53 4.2 Interaction with Authentication Algorithms..................5 54 5. Keying Material................................................5 55 6. Security Considerations........................................5 56 7. References.....................................................6 57 8. Acknowledgments................................................6 58 9. Editors' Addresses.............................................7 60 1. Introduction 62 The Encapsulating Security Payload (ESP) [Kent97] provides 63 confidentiality for IP datagrams by encrypting the payload data to 64 be protected. This specification describes the ESP use of 3DES. 66 It is assumed that the reader is familiar with the terms and 67 concepts described in the "Security Architecture for the Internet 68 Protocol" [Atkinson95], "IP Security Document Roadmap" [Thayer97], 69 and "IP Encapsulating Security Payload (ESP)" [Kent97] documents. 71 Furthermore, this document is a companion to [Kent97] and MUST be 72 read in its context. 74 1.1 Specification of Requirements 76 The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD 77 NOT", and "MAY" that appear in this document are to be interpreted 78 as described in [Bradner97]. 80 2. Cipher Algorithm 82 This is a variant of the Cipher Block Chaining (CBC) mode of the US 83 Data Encryption Standard (DES) algorithm [FIPS-46]. 85 This variant, colloquially known as "Triple DES", processes each 86 block three times, each time with a different key. This technique 87 of using more than one DES operation was proposed in [Tuchman79]. 89 For more explanation and implementation information for Triple DES, 90 see [Schneier95]. 92 2.1 Mode 94 P1 P2 Pi 95 | | | 96 IV->->(X) +>->->->(X) +>->->->(X) 97 v ^ v ^ v 98 +-----+ ^ +-----+ ^ +-----+ 99 k1->| E | ^ k1->| E | ^ k1->| E | 100 +-----+ ^ +-----+ ^ +-----+ 101 | ^ | ^ | 102 v ^ v ^ v 103 +-----+ ^ +-----+ ^ +-----+ 104 k2->| D | ^ k2->| D | ^ k2->| D | 105 +-----+ ^ +-----+ ^ +-----+ 106 | ^ | ^ | 107 v ^ v ^ v 108 +-----+ ^ +-----+ ^ +-----+ 109 k3->| E | ^ k3->| E | ^ k3->| E | 110 +-----+ ^ +-----+ ^ +-----+ 111 | ^ | ^ | 112 +>->->+ +>->->+ +>->-> 113 | | | 114 C1 C2 Ci 116 The DES-EDE3-CBC algorithm is a simple variant of the DES-CBC 117 algorithm [RFC-1829x]. The "outer" chaining technique is used. 119 In DES-EDE3-CBC, an Initialization Vector (IV) is XOR'd with the 120 first 64-bit (8 byte) plaintext block (P1). The keyed DES function 121 is iterated three times, an encryption (Ek1) followed by a 122 decryption (Dk2) followed by an encryption (Ek3), and generates the 123 ciphertext (C1) for the block. Each iteration uses an independant 124 key: k1, k2 and k3. 126 For successive blocks, the previous ciphertext block is XOR'd with 127 the current plaintext (Pi). The keyed DES-EDE3 encryption function 128 generates the ciphertext (Ci) for that block. 130 To decrypt, the order of the functions is reversed: decrypt with 131 k3, encrypt with k2, decrypt with k1, and XOR the previous 132 ciphertext block. 134 Note that when all three keys (k1, k2 and k3) are the same, DES- 135 EDE3-CBC is equivalent to DES-CBC. This property allows the DES- 136 EDE3 hardware implementations to operate in DES mode without 137 modification. 139 2.2 Performance 141 Triple DES is approximately 2.5 times slower than "single" DES 142 (rather than 3 times), because inner permutations may be removed. 144 Phil Karn has tuned DES-EDE3-CBC software to achieve 6.22 Mbps with 145 a 133 MHz Pentium. Other DES speed estimates may be found at 146 [Schneier95, page 279]. 148 3. Key Sizes 150 The secret DES-EDE3 key shared between the communicating parties is 151 effectively 168-bits long. This key consists of three independent 152 56-bit quantities used by the DES algorithm. Each of the three 56- 153 bit sub-keys is stored as a 64-bit (8 byte) quantity, with the 154 least significant bit of each byte used as a parity bit. 156 Implementations of this transform SHOULD take into consideration 157 the parity bits when initially accepting a new set of keys. 159 3.1 Weak Keys 161 DES has 64 known weak keys, including so-called semi-weak keys and 162 possibly-weak keys [Schneier95, pp 280-282]. The likelihood of 163 picking one at random is negligible. 165 For DES-EDE3, there is no known need to reject weak or 166 complementation keys. Any weakness is obviated by the other keys. 168 However, if the first two independent 64-bit keys are equal (k1 == 169 k2), then the 3DES operation is simply the same as DES. 170 Implementers MUST reject keys that exhibit this property. 172 4. ESP Payload 174 DES-EDE3-CBC requires an explicit Initialization Vector (IV) of 8 175 octets (64 bits). Thus the payload is made up of the 8 octet IV 176 followed by raw cipher-text. The IV SHOULD be chosen at random. 177 Common practice is to use random data for the first IV and the last 178 8 octets of encrypted data from an encryption process as the IV for 179 the next encryption process. 181 The payload field, as defined in [Kent97], is broken down according 182 to the following diagram: 184 +---------------+---------------+---------------+---------------+ 185 | | 186 + Initialization Vector (IV) + 187 | | 188 +---------------+---------------+---------------+---------------+ 189 | | 190 ~ Encrypted Payload (variable length) ~ 191 | | 192 +---------------------------------------------------------------+ 193 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 195 4.1 Block Size and Padding 197 The ESP 3DES-CBC algorithm described in this document MUST use a 198 block size of 8 octets (64 bits). 200 When padding is required, it MUST be done according to the 201 conventions specified in [Kent97]. 203 4.2 Interaction with Authentication Algorithms 205 This ESP 3DES-CBC document has no limitations on what 206 authentication algorithm is used in ESP. 208 5. Keying Material 210 The number of bits sent from the key exchange protocol to this ESP 211 algorithm must be equal to the key size. 213 The key is taken from the first 192 bits of the keying material, 214 where the first 64 bits represent the first key, the next 64 bits 215 represent the second key and the last 64 bits represent the third 216 key. 218 6. Security Considerations 220 As with other ESP Transforms there are common security 221 considerations, which are not discussed here. The ESP document and 222 the IPsec architecture document should be consulted. Also, as with 223 any other encryption technology, one should examine the current 224 literature for any new attack strategies discovered after this 225 document was published. 227 A discussion of security considerations specific to DES is also 228 relevant to this cipher, see [RFC-1829x] for this discussion. 230 Since Triple DES uses three times as much keying material as DES, 231 it places a larger burden on automatic keying systems that use such 232 devices as random number generators and entropy pools. Use of 233 automatic keying should be carefully configured to be aware of this 234 impact. 236 7. References 238 [Atkinson95] Atkinson, R., "Security Architecture for the Internet 239 Protocol", draft-ietf-ipsec-arch-sec-01 241 [Bradner97] Bradner, S., "Key words for use in RFCs to indicate 242 Requirement Levels", RFC2119, March 1997 244 [Kent97] Kent, S., Atkinson, R., "IP Encapsulating Security Payload 245 (ESP)", draft-ietf-ipsec-new-esp-01 247 [Thayer97] R. Thayer, N. Doraswamy, R. Glenn, "IP Security Document 248 Roadmap", draft-ietf-ipsec-doc-roadmap-00.txt 250 [FIPS-46] US National Bureau of Standards, "Data Encryption 251 Standard", Federal Information Processing Standard (FIPS) 252 Publication 46, January 1977. 254 [RFC-1829x] Karn, P., Metzger, P., Simpson, W.A., "The ESP DES-CBC 255 Transform", work in progress. 257 [Schneier95] Schneier, B., "Applied Cryptography Second Edition", 258 John Wiley & Sons, New York, NY, 1995. ISBN 0-471-12845-7. 260 [Tuchman79] Tuchman, W, "Hellman Presents No Shortcut Solutions to 261 DES", IEEE Spectrum, v. 16 n. 7, July 1979, pp. 40-41. 263 8. Acknowledgments 265 This document is based on the IETF work described in with he only major differences being an 267 explicit IV instead of a derived one and that padding is done as 268 the default method states in ESP. 270 Our thanks to all of the editors of the previous ESP 3DES 271 documents; W. Simpson, N. Doraswamy, P. Metzger, and P. Karn. 273 9. Editors' Addresses 275 Roy Pereira 276 rpereira@timestep.com 277 TimeStep Corporation 278 (613) 599-3610 x 4808 280 Rodney Thayer 281 rodney@sabletech.com 282 Sable Technology Corporation 283 (617) 332-7292 285 The IPSec working group can be contacted via the IPSec working 286 group's mailing list (ipsec@tis.com) or through its chairs: 288 Robert Moskowitz 289 rgm@chrysler.com 290 Chrysler Corporation 292 Theodore Y. Ts'o 293 tytso@MIT.EDU 294 Massachusetts Institute of Technology