idnits 2.17.1 draft-ietf-pppext-des-encrypt-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-04-24) 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], [5,6], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 97: '... o MUST, SHALL or MANDATORY -- th...' RFC 2119 keyword, line 100: '... o SHOULD or RECOMMENDED -- the i...' RFC 2119 keyword, line 103: '... o MAY or OPTIONAL -- the item is...' RFC 2119 keyword, line 205: '...lay attacks, the implementation SHOULD...' RFC 2119 keyword, line 233: '... These fields MUST be present unles...' (2 more instances...) 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: '0' is mentioned on line 371, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 1717 (ref. '3') (Obsoleted by RFC 1990) -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Sklower 2 INTERNET-DRAFT University of California, Berkeley 3 Expires: February 15th, 1996 4 G. Meyer 5 Spider Systems 7 The PPP DES Encryption Protocol (DESE) 8 draft-ietf-pppext-des-encrypt-01.txt 10 Status of This Memo 12 This document is a submission to the Point-to-Point Protocol Working 13 Group of the Internet Engineering Task Force (IETF). Comments should 14 be submitted to the ietf-ppp@merit.edu mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as ``work in progress.'' 28 To learn the current status of any Internet-Draft, please check the 29 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 30 Shadow 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 Abstract 36 The Point-to-Point Protocol (PPP) [1] provides a standard method for 37 transporting multi-protocol datagrams over point-to-point links. 39 The PPP Encryption Control Protocol (ECP) [2] provides a method to 40 negotiate and utilize encryption protocols over PPP encapsulated 41 links. 43 This document provides specific details for the use of the DES 44 standard [5, 6] for encrypting PPP encapsulated packets. 46 Acknowledgements 48 The authors extend hearty thanks to Fred Baker of Cisco for helpful 49 improvements to the clarity of the document. 51 Table of Contents 53 1. Introduction ................................................ 2 54 1.1. Motivation ................................................ 2 55 1.2. Conventions ............................................... 3 56 2. General Overview ............................................ 3 57 3. Structure of This Specification ............................. 4 58 4. DESE Configuration Option for ECP ........................... 4 59 5. Packet Format for DESE ...................................... 5 60 6. Encryption .................................................. 6 61 6.1. Padding Considerations .................................... 7 62 6.2. Generation of the Ciphertext .............................. 8 63 6.3. Retrieval of the Plaintext ................................ 8 64 6.4. Recovery after Packet Loss ................................ 9 65 7. MRU Considerations .......................................... 9 66 8. Security Considerations ..................................... 9 67 9. References .................................................. 9 68 10. Authors' Addresses ......................................... 10 69 11. Expiration Date of this Draft .............................. 10 71 1. Introduction 73 1.1. Motivation 75 The purpose of this draft is two-fold: to show how one specifies the 76 necessary details of a "data" or "bearer" protocol given the context 77 of the generic PPP Encryption Control Protocol, and also to provide 78 at least one commonly-understood means of secure data transmission 79 between PPP implementations. 81 The DES encryption algorithm is a well studied, understood and widely 82 implemented encryption algorithm. The DES cipher was designed for 83 efficient implementation in hardware, and consequently may be 84 relatively expensive to implement in software. However, its 85 pervasiveness makes it seem like a reasonable choice for a "model" 86 encryption protocol. 88 Source code implementing DES in the "Electronic Code Book Mode" can 89 be found in [7]. US export laws forbid the inclusion of compilation- 90 ready source code in this document. 92 1.2. Conventions 94 The following language conventions are used in the items of 95 specification in this document: 97 o MUST, SHALL or MANDATORY -- the item is an absolute requirement 98 of the specification. 100 o SHOULD or RECOMMENDED -- the item should generally be followed 101 for all but exceptional circumstances. 103 o MAY or OPTIONAL -- the item is truly optional and may be 104 followed or ignored according to the needs of the implementor. 106 2. General Overview 108 The purpose of encrypting packets exchanged between two PPP 109 implementations is to attempt to insure the privacy of communication 110 conducted via the two implementations. The encryption process 111 depends on the specification of an encryption algorithm and a shared 112 secret (usually involving at least a key) between the sender and 113 receiver. 115 Generally, the encryptor will take a PPP packet including the 116 protocol field, apply the chosen encryption algorithm, place the 117 resulting cipher text (and in this specification, an explicit 118 sequence number) in the information field of another PPP packet. The 119 decryptor will apply the inverse algorithm and interpret the 120 resulting plain text as if it were a PPP packet which had arrived 121 directly on the interface. 123 The means by which the secret becomes known to both communicating 124 elements is beyond the scope of this document; usually some form of 125 manual configuration is involved. Implementations might make use of 126 PPP authentication, or the EndPoint Identifier Option described in 127 PPP Multilink [3], as factors in selecting the shared secret. If the 128 secret can be deduced by analysis of the communication between the 129 two parties, then no privacy is guaranteed. 131 While the US Data Encryption Standard (DES) algorithm [5, 6] provides 132 multiple modes of use, this specification selects the use of only one 133 mode in conjunction with the PPP Encryption Control Protol (ECP): the 134 Cipher Block Chaining (CBC) mode. In addition to the US Government 135 publications cited above, the CBC mode is also discussed in [7], 136 although no C source code is provided for it per se. 138 The initialization vector for this mode is deduced from an explicit 139 64-bit nonce, which is exchanged in the clear during the negotiation 140 phase. The 56-bit key required by all DES modes is established as a 141 shared secret between the implementations. 143 One reason for choosing the chaining mode is that it is generally 144 thought to require more computation resources to deduce a 64 bit key 145 used for DES encryption by analysis of the encrypted communication 146 stream when chaining mode is used, compared with the situation where 147 each block is encrypted separately with no chaining. Further, if 148 chaining is not used, even if the key is never deduced, the 149 communication may be subject to replay attacks. 151 However, if chaining is to extend beyond packet boundaries, both the 152 sender and receiver must agree on the order the packets were 153 encrypted. Thus, this specification provides for an explicit 16 bit 154 sequence number to sequence decryption of the packets. This mode of 155 operation even allows recovery from occasional packet loss; details 156 are also given below. 158 3. Structure of This Specification 160 The PPP Encryption Control Protocol (ECP), provides a framework for 161 negotiating parameters associated with encryption, such as choosing 162 the algorithm. It specifies the assigned numbers to be used as PPP 163 protocol numbers for the "data packets" to be carried as the 164 associated "data protocol", and describes the state machine. 166 Thus, a specification for use in that matrix need only describe any 167 additional configuration options required to specify a particular 168 algorithm, and the process by which one encrypts/decrypts the 169 information once the Opened state has been achieved. 171 4. DESE Configuration Option for ECP 173 Description 175 The ECP DESE Configuration Option indicates that the issuing 176 implementation is offering to employ this specification for 177 decrypting communications on the link, and may be thought of as 178 a request for its peer to encrypt packets in this manner. 180 The ECP DESE Configuration Option has the following fields, 181 which are transmitted from left to right: 183 Figure 1: ECP DESE Configuration Option 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 | Type | Length | Initial Nonce ... 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 Type 193 1, to indicate the DESE protocol. 195 Length 197 10 199 Initial Nonce 201 This field is an 8 byte quantity which is used by the peer 202 implementation to encrypt the first packet transmitted 203 after the sender reaches the opened state. 205 To guard against replay attacks, the implementation SHOULD 206 offer a different value during each ECP negotiation. An 207 example might be to use the number of seconds since Jan 208 1st, 1970 (GMT/UT) in the upper 32 bits, and the current 209 number of nanoseconds relative to the last second mark in 210 the lower 32 bits. 212 Its formulaic role is described in the Encryption section 213 below. 215 5. Packet Format for DESE 217 Description 219 The DESE packets themselves have the following fields: 221 Figure 2: DES Encryption Protocol Packet Format 223 0 1 2 3 224 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 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Address | Control | 0000 | Protocol ID | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Seq. No. High | Seq. No. Low | Ciphertext ... 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 Address and Control 233 These fields MUST be present unless the PPP Address and 234 Control Field Compression option (ACFC) has been 235 negotiated. 237 Protocol ID 239 The value of this field is 0x53 or 0x55; the latter 240 indicates that ciphertext includes headers for the 241 Multilink Protocol, and REQUIRES that the Individual Link 242 Encryption Control Protocol has reached the opened state. 243 The leading zero MAY be absent if the PPP Protocol Field 244 Compression option (PFC) has been negotiated. 246 Sequence Number 248 These 16-bit numbers are assigned by the encryptor 249 sequentially starting with 0 (for the first packet 250 transmitted once ECP has reached the opened state. 252 Ciphertext 254 The generation of this data is described in the next 255 section. 257 6. Encryption 259 Once the ECP has reached the Opened state, the sender MUST NOT apply 260 the encryption procedure to LCP packets nor ECP packets. 262 If the async control character map option has been negotiated on the 263 link, the sender applies mapping after the encryption algorithm has 264 been run. 266 The encryption algorithm is generally to pad the Protocol and 267 Information fields of a PPP packet to some multiple of 8 bytes, and 268 apply DES in Chaining Block Cipher mode with a 56-bit key K. 270 There are a lot of details concerning what constitutes the Protocol 271 and Information fields, in the presence or non-presence of Multilink, 272 and whether the ACFC and PFC options have been negotiated, and the 273 sort of padding chosen. 275 Regardless of whether ACFC has been negotiated on the link, the 276 sender applies the encryption procedure to only that portion of the 277 packet excluding the address and control field. 279 If the Multilink Protocol has been negotiated and encryption is to be 280 construed as being applied to each link separately, then the 281 encryption procedure is to be applied to the (possibly extended) 282 protocol and information fields of the packet in the Multilink 283 Protocol. 285 If the Multilink Protocol has been negotiated and encryption is to be 286 construed as being applied to the bundle, then the multilink 287 procedure is to be applied to the resulting DESE packets. 289 6.1. Padding Considerations 291 Since the DES algorithm operates on blocks of 8 octets, packets which 292 are of length not a multiple of 8 octets must be padded. This can be 293 injurious to the interpretation of some protocols which do not 294 contain an explicit length field in their protocol headers. 295 (Additional padding of the ciphered packet for the purposes of 296 transmission by HDLC hardware which requires an even number of bytes 297 should not be necessary since the information field will now be of 298 length a multiple of 8, and whether or not the packet is of even 299 length can be forced by use or absence of a leading zero in the 300 protocol field). 302 For protocols which do have an explicit length field, such as IP, 303 IPX, XNS, and CLNP, then padding may be accomplished by adding random 304 trailing garbage. Even when performing the Multilink protocol, if it 305 is only being applied to packets with explicit length fields, and if 306 care is taken so that all non-terminating fragments (i.e., those not 307 bearing the (E)nd bit) are of lengths divisible by 8; then no ill 308 effects will happen if garbage padding is applied only to terminating 309 fragments. 311 For certain cases, such as the PPP bridging protocol when the 312 trailing CRC is forwarded or when any bridging is being applied to 313 protocols not having explicit length fields, adding garbage changes 314 the interpretation of the packet. The self-describing padding option 315 [4] permits unambiguous removal of padded bytes; although it should 316 only be used when absolutely necessary as it may inadvertently 317 require adding as many as 8 octets to packets that could otherwise be 318 left unaltered. 320 Consider a packet, which by unlucky circumstance is already a 321 multiple of 8 octets, but terminates in the sequence 0x1, 0x2. 322 Self-describing padding would otherwise remove the trailing two 323 bytes. For purposes of coexistence with archaic HDLC chips 324 where it is necessary to transmit packets of even length, one 325 would normally only have to add an additional two octets (0x1, 326 0x2), which could then be removed. However, since the packet 327 was initially a multiple of 8 bytes, an additional 8 bytes would 328 need to be added. 330 6.2. Generation of the Ciphertext 332 In this discussion, E[k] will denote the basic DES cipher determined 333 by a 56-bit key k acting on 64 bit blocks. and D[k] will denote the 334 corresponding decryption mechanism. The padded plaintext described 335 in the previous section then becomes a sequence of 64 bit blocks P[i] 336 (where i ranges from 1 to n). The circumflex character (^) 337 represents the bit-wise exclusive-or operation applied to 64-bit 338 blocks. 340 When encrypting the first packet to be transmitted in the opened 341 state let C[0] be the result of applying E[k] to the Initial Nonce 342 received in the peer's ECP DESE option; otherwise let C[0] be the 343 final block of the previously transmitted packet. 345 The ciphertext for the packet is generated by the iterative process 347 C[i] = E[k](P[i] ^ C[i-1]) 349 for i running between 1 and n. 351 6.3. Retrieval of the Plaintext 353 When decrypting the first packet received in the opened state, let 354 C[0] be the result of applying E[k] to the Initial Nonce transmitted 355 in the ECP DESE option. The first packet will have sequence number 356 zero. For subsequent packets, let C[0] be the final block of the 357 previous packet in sequence space. Decryption is then accomplished 358 by 360 P[i] = C[i-1] ^ D[k](C[i]), 362 for i running between 1 and n. 364 6.4. Recovery after Packet Loss 366 Packet loss is detected when there is a discontinuity in the sequence 367 numbers of consecutive packets. Suppose packet number N - 1 has an 368 unrecoverable error or is otherwise lost, but packets N and N + 1 are 369 received correctly. 371 Since the algorithm in the previous section requires C[0] for packet 372 N to be C[last] for packet N - 1, it will be impossible to decode 373 packet N. However, all packets N + 1 and following can be decoded in 374 the usual way, since all that is required is the last block of 375 ciphertext of the previous packet (in this case packet N, which WAS 376 received). 378 7. MRU Considerations 380 Because padding can occur, and because there is an additional 381 protocol field in effect, implementations should take into account 382 the growth of the packets. As an example, if PFC had been 383 negotiated, and if the MRU before had been exactly a multiple of 8, 384 then the plaintext resulting combining a full sized data packets with 385 a one byte protocol field would require an additional 7 bytes of 386 padding, and the sequence number would be an additional 2 bytes so 387 that the information field in the DESE protocol is now 10 bytes 388 larger than that in the original packet. Because the convention is 389 that PPP options are independent of each other, negotiation of DESE 390 does not, by itself, automatically increase the MRU value. 392 8. Security Considerations 394 Security issues are the primary subject of this draft. This proposal 395 relies on exterior and unspecified methods for authentication and 396 retrieval of shared secrets. 398 It proposes no new technology for privacy, but merely describes a 399 convention for the application of the DES cipher to data transmission 400 between PPP implementation. 402 Any methodology for the protection and retrieval of shared secrets, 403 and any limitations of the DES cipher are relevant to the use 404 described here. 406 9. References 408 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, 409 RFC 1661, Daydreamer, July 1994. 411 [2] Meyer, G., "The PPP Encryption Protocol", work-in-progress, 412 Spider Systems. 414 [3] Sklower, K., Lloyd, B., McGregor, G., and D. Carr, "The PPP 415 Multilink Protocol (MP)", RFC 1717, UC Berkeley, November, 1994. 417 [4] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, Daydreamer, 418 January 1994. 420 [5] National Bureau of Standards, "Data Encryption Standard", FIPS 421 PUB 46 (January 1977). 423 [6] National Bureau of Standards, "DES Modes of Operation", FIPS PUB 424 81 (December 1980). 426 [7] Schneier, B., "Applied Cryptography - Protocols Algorithms, and 427 source code in C", John Wiley & Sons, Inc. 1994. There is an 428 errata associated with the book, and people can get a copy by 429 sending e-mail to schneier@counterpane.com. 431 10. Authors' Addresses 433 Keith Sklower 434 Computer Science Department 435 384 Soda Hall, Mail Stop 1776 436 University of California 437 Berkeley, CA 94720-1776 439 Phone: (510) 642-9587 440 EMail: sklower@CS.Berkeley.EDU 442 Gerry M. Meyer 443 Spider Systems 444 Stanwell Street 445 Edinburgh EH6 5NG 446 Scotland, UK 448 Phone: (UK) 131 554 9424 449 Fax: (UK) 131 554 0649 450 Email: gerry@spider.co.uk 452 11. Expiration Date of this Draft 454 February 15th, 1996