idnits 2.17.1 draft-ietf-pppext-3des-encrypt-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-23) 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** There are 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([2], [6], [1]), 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 (July 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) ** Obsolete normative reference: RFC 1969 (ref. '4') (Obsoleted by RFC 2419) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Kummert 3 Internet-draft Nentec GmbH 4 Expires: January 1998 July 1997 6 The PPP Triple-DES Encryption Protocol (3DESE) 7 draft-ietf-pppext-3des-encrypt-00.txt 9 Status of this Memo 11 This document is a submission to the Point-to-Point Protocol Working 12 Group of the Internet Engineering Task Force (IETF). Comments should 13 be submitted to the ietf-ppp@merit.edu mailing list. 15 Distribution of this memo is unlimited. 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 are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 29 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 30 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 31 ftp.isi.edu (US West Coast). 33 Abstract 35 The Point-to-Point Protocol (PPP) [1] provides a standard method for 36 transporting multi-protocol datagrams over point-to-point links. 38 The PPP Encryption Control Protocol (ECP) [2] provides a method to 39 negotiate and utilize encryption protocols over PPP encapsulated 40 links. 42 This document provides specific details for the use of the Triple-DES 43 standard (3DES) [6] for encrypting PPP encapsulated packets. 45 Table of contents 47 1. Introduction .............................................. 2 48 1.1 Algorithm ................................................. 3 49 1.2 Keys ...................................................... 3 50 2. 3DESE Configuration Option for ECP ........................ 4 51 3. Packet format for 3DESE ................................... 4 52 4. Encryption ................................................ 5 53 4.1 Padding ................................................... 6 54 4.2 Recovery after packet loss ................................ 6 55 5. Security considerations ................................... 7 56 6. References ................................................ 7 57 7. Acknowledgements .......................................... 7 58 8. Author's address .......................................... 8 59 9. Expiration date of this draft ............................. 8 61 1. Introduction 63 The purpose of encrypting packets exchanged between two PPP implemen- 64 tations is to attempt to insure the privacy of communication con- 65 ducted via the two implementations. There exists a large variety of 66 encryption algorithms, where one is the DES algorithm. The DES 67 encryption algorithm is a well studied, understood and widely imple- 68 mented encryption algorithm. Triple-DES means that this algorithm is 69 applied three times on the data to be encrypted before it is sent 70 over the line. The variant used is the DES-EDE3-CBC, which is 71 described in more detail in the text. It was also chosen to be 72 applied in the security section of IP [5]. 74 This document shows how to send via the Triple-DES algorithm 75 encrypted packets over a point-to-point-link. It lies in the context 76 of the generic PPP Encryption Control Protocol [2]. 78 Because of the use of the CBC-mode a sequence number is provided to 79 ensure the right order of transmitted packets. So lost packets can be 80 detected. 82 The padding section reflects the result of the discussion on this 83 topic on the ppp mailing list. 85 In this document, the key words "MUST", "SHOULD", and "recommended" 86 are to be interpreted as described in [3]. 88 1.1 Algorithm 90 The DES-EDE3-CBC algorithm is a simple variant of the DES-CBC algo- 91 rithm. In DES-EDE3-CBC, an Initialization Vector (IV) is XOR'd with 92 the first 64-bit (8 octet) plaintext block (P1). The keyed DES func- 93 tion is iterated three times, an encryption (E) followed by a decryp- 94 tion (D) followed by an encryption (E), and generates the ciphertext 95 (C1) for the block. Each iteration uses an independent key: k1, k2 96 and k3. 98 For successive blocks, the previous ciphertext block is XOR'd with 99 the current 8-octet plaintext block (Pi). The keyed DES-EDE3 encryp- 100 tion function generates the ciphertext (Ci) for that block. 102 P1 P2 Pi 103 | | | 104 IV--->(X) +------>(X) +-------->(X) 105 v | v | v 106 +-----+ | +-----+ | +-----+ 107 k1->| E | | k1->| E | : k1->| E | 108 +-----+ | +-----+ : +-----+ 109 | | | : | 110 v | v : v 111 +-----+ ^ +-----+ ^ +-----+ 112 k2->| D | | k2->| D | | k2->| D | 113 +-----+ | +-----+ | +-----+ 114 | | | | | 115 v | v | v 116 +-----+ | +-----+ | +-----+ 117 k3->| E | | k3->| E | | k3->| E | 118 +-----+ | +-----+ | +-----+ 119 | | | | | 120 +---->+ +------>+ +----> 121 | | | 122 C1 C2 Ci 124 To decrypt, the order of the functions is reversed: decrypt with k3, 125 encrypt with k2, decrypt with k1, and XOR with the previous cipher- 126 text block. 128 When all three keys (k1, k2 and k3) are the same, DES-EDE3-CBC is 129 equivalent to DES-CBC. 131 1.2 Keys 133 The secret DES-EDE3 key shared between the communicating parties is 134 effectively 168-bits long. This key consists of three independent 135 56-bit quantities used by the DES algorithm. Each of the three 56- 136 bit subkeys is stored as a 64-bit (8 octet) quantity, with the least 137 significant bit of each octet used as a parity bit. 139 When configuring keys for 3DESE those with incorrect parity or so- 140 called weak keys [6] SHOULD be rejected. 142 2. 3DESE Configuration Option for ECP 144 Description 146 The ECP 3DESE Configuration Option indicates that the issuing 147 implementation is offering to employ this specification for 148 decrypting communications on the link, and may be thought of as 149 a request for its peer to encrypt packets in this manner. The 150 ECP 3DESE Configuration Option has the following fields, which 151 are transmitted from left to right: 153 Figure 1: ECP 3DESE Configuration Option 155 0 1 2 3 156 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Type | Length | Initial Nonce ... 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Type 163 tbd, to indicate the 3DESE protocol. 165 Length 167 10 169 Initial Nonce 171 This field is an 8 byte quantity which is used by the peer 172 implementation to encrypt the first packet transmitted 173 after the sender reaches the opened state. To guard against 174 replay attacks, the implementation SHOULD offer a different 175 value during each ECP negotiation. 177 3. Packet format for 3DESE 179 Description 180 The 3DESE packets that contain the encrypted payload have the 181 following fields: 183 Figure 2: 3DESE Encryption Protocol Packet Format 185 0 1 2 3 186 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Address | Control | 0000 | Protocol ID | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Seq. No. High | Seq. No. Low | Ciphertext ... 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 Address and Control 195 These fields MUST be present unless the PPP Address and 196 Control Field Compression option (ACFC) has been nego- 197 tiated. 199 Protocol ID 201 The value of this field is 0x53 or 0x55; the latter indi- 202 cates the use of the Individual Link Encryption Control 203 Protocol and that the ciphertext contains a Multilink frag- 204 ment. Protocol Field Compression MAY be applied to the 205 leading zero if negotiated. 207 Sequence Number 209 These 16-bit numbers are assigned by the encryptor sequen- 210 tially starting with 0 (for the first packet transmitted 211 once ECP has reached the opened state). 213 Ciphertext 215 The generation of this data is described in the next sec- 216 tion. 218 4. Encryption 220 Once the ECP has reached the Opened state, the sender MUST NOT apply 221 the encryption procedure to LCP packets nor ECP packets. 223 If the async control character map option has been negotiated on the 224 link, the sender applies mapping after the encryption algorithm has 225 been run. 227 The encryption algorithm is generally to pad the Protocol and Infor- 228 mation fields of a PPP packet to some multiple of 8 bytes, and apply 229 3DES as described in section 1.1 with the three 56-bit keys k1, k2 230 and k3. 232 The encryption procedure is only applied to that portion of the 233 packet excluding the address and control field. 235 When encrypting the first packet after ECP stepped into opened state 236 the Initial Nonce is encrypted via 3DES-algorithm before its use. 238 4.1 Padding 240 Since the 3DES algorithm operates on blocks of 8 octets, plain text 241 packets which are of length not a multiple of 8 octets must be padded 242 prior to encrypting. If this padding is not removed after decryption 243 this can be injurious to the interpretation of some protocols which 244 do not contain an explicit length field in their protocol headers. 246 Therefore all packets not already a multiple of eight bytes in length 247 MUST be padded prior to encrypting using the unambiguous technique of 248 Self Describing Padding with a Maximum Pad Value (MPV) of 8. This 249 means that the plain text is padded with the sequence of octets 1, 2, 250 3, .. 7 since its length is a multiple of 8 octets. Negotiation of 251 SDP is not needed. Negotiation of the LCP Self Describing Option may 252 be negotiated independently to solve an orthogonal problem. 254 Plain text which length is already a multiple of 8 octets may require 255 padding with a further 8 octets (1, 2, 3 ... 8). These additional 256 octets MUST only be appended, if the last octet of the plain text had 257 a value of 8 or less. 259 When using Multilink and encrypting on individual links it is recom- 260 mended that all non-terminating fragments have a length divisible by 261 8. So no additional padding is needed on those fragments. 263 After the peer has decrypted the ciphertext, it strips off the Self 264 Describing Padding octets to recreate the original plain text. The 265 peer SHOULD discard the frame if the octets forming the padding do 266 not match the Self Describing Padding scheme just described. 268 Note that after decrypting, only the content of the last byte needs 269 to be examined to determine the presence or absence of a Self 270 Described Pad. 272 4.2 Recovery after packet loss 274 Packet loss is detected when there is a discontinuity in the sequence 275 numbers of consecutive packets. Suppose packet number N - 1 has an 276 unrecoverable error or is otherwise lost, but packets N and N + 1 are 277 received correctly. 279 Since the previously described algorithm requires the last Ci of 280 packet N - 1 to decrypt C1 of packet N, it will be impossible to 281 decrypt packet N. However, all packets N + 1 and following can be 282 decrypted in the usual way, since all that is required is the last 283 block of ciphertext of the previous packet (in this case packet N, 284 which WAS received). 286 5. Security considerations 288 Security issues are the primary subject of this draft. This proposal 289 relies on exterior and unspecified methods for retrieval of shared 290 secrets. It proposes no new technology for privacy, but merely 291 describes a convention for the application of the 3DES cipher to data 292 transmission between PPP implementations. Any methodology for the 293 protection and retrieval of shared secrets, and any limitations of 294 the 3DES cipher are relevant to the use described here. 296 6. References 298 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 299 51, RFC 1661, Daydreamer, July 1994. 301 [2] Meyer, G., "The PPP Encryption Protocol", RFC 1968, Spider Sys- 302 tems, June 1996. 304 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 305 Levels", RFC 2119, BCP 14, Harvard University, March 1997. 307 [4] Meyer, G., Sklower, K. "The PPP DES Encryption Protocol (DESE)", 308 RFC 1969, Spider Systems, June 1996. 310 [5] Doraswamy, N., Metzger, P., Simpson, W., "The ESP Triple DES 311 Transform", Work in progress, June 1997 313 [6] Schneier, B., "Applied Cryptography Second Edition", John Wiley 314 & Sons, New York, NY, 1995. ISBN 0-471-12845-7. 316 7. Acknowledgements 318 Much portions of this document was taken from [4] and [5]. Bill Simp- 319 son gave useful hints on the initial revision. 321 8. Author's Address: 323 Holger Kummert 324 Nentec Gesellschaft fuer Netzwerktechnologie 325 76227 Karlsruhe, Killisfeldstr. 64, Germany 327 Phone: +49 721 9495 0 328 E-mail: kummert@nentec.de 330 9. Expiration date of this draft 332 January 23, 1998