idnits 2.17.1 draft-ietf-pppext-des-encrypt-v2-02.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. 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 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. 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 (March 1, 1998) is 9550 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: '0' is mentioned on line 377, but not defined -- 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: 10 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPP Working Group K. Sklower 3 INTERNET-DRAFT University of California, Berkeley 4 Obsoletes: RFC-1969 G. Meyer 5 Category: Standards Track Shiva 6 Date: March 1, 1998 8 The PPP DES Encryption Protocol, Version 2 (DESE-bis) 9 draft-ietf-pppext-des-encrypt-v2-02.txt 11 Status of This Memo 13 This document is a submission to the Point-to-Point Protocol Working 14 Group of the Internet Engineering Task Force (IETF). Comments should 15 be submitted to the ietf-ppp@merit.edu mailing list. 17 Distribution of this memo is unlimited. 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as ``work in progress.'' 29 To learn the current status of any Internet-Draft, please check the 30 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 31 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 32 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 33 ftp.isi.edu (US West Coast). 35 Abstract 37 The Point-to-Point Protocol (PPP) [1] provides a standard method for 38 transporting multi-protocol datagrams over point-to-point links. 40 The PPP Encryption Control Protocol (ECP) [2] provides a method to 41 negotiate and utilize encryption protocols over PPP encapsulated 42 links. 44 This document provides specific details for the use of the DES 45 standard [5, 6] for encrypting PPP encapsulated packets. 47 Acknowledgements 49 The authors extend hearty thanks to Fred Baker of Cisco, Philip 50 Rakity of Flowpoint, and William Simpson of Daydreamer for helpful 51 improvements to the clarity and correctness of the document. 53 Table of Contents 55 1. Introduction ................................................ 2 56 1.1. Motivation ................................................ 2 57 1.2. Conventions ............................................... 3 58 2. General Overview ............................................ 3 59 3. Structure of This Specification ............................. 4 60 4. DESE Configuration Option for ECP ........................... 4 61 5. Packet Format for DESE ...................................... 5 62 6. Encryption .................................................. 6 63 6.1. Padding Considerations .................................... 7 64 6.2. Generation of the Ciphertext .............................. 8 65 6.3. Retrieval of the Plaintext ................................ 8 66 6.4. Recovery after Packet Loss ................................ 9 67 7. MRU Considerations .......................................... 9 68 8. Differences from RFC 1969 ................................... 9 69 8.1. When to Pad ............................................... 9 70 8.2. Assigned Numbers .......................................... 10 71 8.3. Minor Editorial Changes ................................... 10 72 9. Security Considerations ..................................... 10 73 10. References ................................................. 10 74 11. Authors' Addresses ......................................... 11 75 12. Expiration Date of this Draft .............................. 11 77 1. Introduction 79 1.1. Motivation 81 The purpose of this draft is two-fold: to show how one specifies the 82 necessary details of a "data" or "bearer" protocol given the context 83 of the generic PPP Encryption Control Protocol, and also to provide 84 at least one commonly-understood means of secure data transmission 85 between PPP implementations. 87 The DES encryption algorithm is a well studied, understood and widely 88 implemented encryption algorithm. The DES cipher was designed for 89 efficient implementation in hardware, and consequently may be 90 relatively expensive to implement in software. However, its 91 pervasiveness makes it seem like a reasonable choice for a "model" 92 encryption protocol. 94 Source code implementing DES in the "Electronic Code Book Mode" can 95 be found in [7]. US export laws forbid the inclusion of compilation- 96 ready source code in this document. 98 1.2. Conventions 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119[8]. 104 2. General Overview 106 The purpose of encrypting packets exchanged between two PPP 107 implementations is to attempt to insure the privacy of communication 108 conducted via the two implementations. The encryption process 109 depends on the specification of an encryption algorithm and a shared 110 secret (usually involving at least a key) between the sender and 111 receiver. 113 Generally, the encryptor will take a PPP packet including the 114 protocol field, apply the chosen encryption algorithm, place the 115 resulting cipher text (and in this specification, an explicit 116 sequence number) in the information field of another PPP packet. The 117 decryptor will apply the inverse algorithm and interpret the 118 resulting plain text as if it were a PPP packet which had arrived 119 directly on the interface. 121 The means by which the secret becomes known to both communicating 122 elements is beyond the scope of this document; usually some form of 123 manual configuration is involved. Implementations might make use of 124 PPP authentication, or the EndPoint Identifier Option described in 125 PPP Multilink [3], as factors in selecting the shared secret. If the 126 secret can be deduced by analysis of the communication between the 127 two parties, then no privacy is guaranteed. 129 While the US Data Encryption Standard (DES) algorithm [5, 6] provides 130 multiple modes of use, this specification selects the use of only one 131 mode in conjunction with the PPP Encryption Control Protocol (ECP): 132 the Cipher Block Chaining (CBC) mode. In addition to the US 133 Government publications cited above, the CBC mode is also discussed 134 in [7], although no C source code is provided for it per se. 136 The initialization vector for this mode is deduced from an explicit 137 64-bit nonce, which is exchanged in the clear during the negotiation 138 phase. The 56-bit key required by all DES modes is established as a 139 shared secret between the implementations. 141 One reason for choosing the chaining mode is that it is generally 142 thought to require more computation resources to deduce a 64 bit key 143 used for DES encryption by analysis of the encrypted communication 144 stream when chaining mode is used, compared with the situation where 145 each block is encrypted separately with no chaining. Certainly, 146 identical sequences of plaintext will produce different ciphers when 147 chaining mode is in effect, thus complicating analysis. 149 However, if chaining is to extend beyond packet boundaries, both the 150 sender and receiver must agree on the order the packets were 151 encrypted. Thus, this specification provides for an explicit 16 bit 152 sequence number to sequence decryption of the packets. This mode of 153 operation even allows recovery from occasional packet loss; details 154 are also given below. 156 3. Structure of This Specification 158 The PPP Encryption Control Protocol (ECP), provides a framework for 159 negotiating parameters associated with encryption, such as choosing 160 the algorithm. It specifies the assigned numbers to be used as PPP 161 protocol numbers for the "data packets" to be carried as the 162 associated "data protocol", and describes the state machine. 164 Thus, a specification for use in that matrix need only describe any 165 additional configuration options required to specify a particular 166 algorithm, and the process by which one encrypts/decrypts the 167 information once the Opened state has been achieved. 169 4. DESE Configuration Option for ECP 171 Description 173 The ECP DESE Configuration Option indicates that the issuing 174 implementation is offering to employ this specification for 175 decrypting communications on the link, and may be thought of as 176 a request for its peer to encrypt packets in this manner. 178 The ECP DESE Configuration Option has the following fields, 179 which are transmitted from left to right: 181 Figure 1: ECP DESE Configuration Option 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Type = 3 | Length | Initial Nonce ... 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 Type 191 Type = 3, to indicate the DESE-bis protocol. The former 192 value 1 indicating the previous DESE specification is 193 deprecated, i.e. systems implementing this specification 194 MUST NOT offer the former value 1 in a configure-request 195 and MUST configure-reject the former value on receipt of a 196 configure-request containing it. 198 Length 200 10 202 Initial Nonce 204 This field is an 8 byte quantity which is used by the peer 205 implementation to encrypt the first packet transmitted 206 after the sender reaches the opened state. 208 To guard against replay attacks, the implementation SHOULD 209 offer a different value during each ECP negotiation. An 210 example might be to use the number of seconds since Jan 211 1st, 1970 (GMT/UT) in the upper 32 bits, and the current 212 number of nanoseconds relative to the last second mark in 213 the lower 32 bits. 215 Its formulaic role is described in the Encryption section 216 below. 218 5. Packet Format for DESE 220 Description 222 The DESE packets themselves have the following fields: 224 Figure 2: DES Encryption Protocol Packet Format 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Address | Control | 0000 | Protocol ID | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Seq. No. High | Seq. No. Low | Ciphertext ... 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Address and Control 236 These fields MUST be present unless the PPP Address and 237 Control Field Compression option (ACFC) has been 238 negotiated. 240 Protocol ID 242 The value of this field is 0x53 or 0x55; the latter 243 indicates that ciphertext includes headers for the 244 Multilink Protocol, and REQUIRES that the Individual Link 245 Encryption Control Protocol has reached the opened state. 246 The leading zero MAY be absent if the PPP Protocol Field 247 Compression option (PFC) has been negotiated. 249 Sequence Number 251 These 16-bit numbers are assigned by the encryptor 252 sequentially starting with 0 (for the first packet 253 transmitted once ECP has reached the opened state. 255 Ciphertext 257 The generation of this data is described in the next 258 section. 260 6. Encryption 262 Once the ECP has reached the Opened state, the sender MUST NOT apply 263 the encryption procedure to LCP packets nor ECP packets. 265 If the async control character map option has been negotiated on the 266 link, the sender applies mapping after the encryption algorithm has 267 been run. 269 The encryption algorithm is generally to pad the Protocol and 270 Information fields of a PPP packet to some multiple of 8 bytes, and 271 apply DES in Chaining Block Cipher mode with a 56-bit key K. 273 There are a lot of details concerning what constitutes the Protocol 274 and Information fields, in the presence or non-presence of Multilink, 275 and whether the ACFC and PFC options have been negotiated, and the 276 sort of padding chosen. 278 Regardless of whether ACFC has been negotiated on the link, the 279 sender applies the encryption procedure to only that portion of the 280 packet excluding the address and control field. 282 If the Multilink Protocol has been negotiated and encryption is to be 283 construed as being applied to each link separately, then the 284 encryption procedure is to be applied to the (possibly extended) 285 protocol and information fields of the packet in the Multilink 286 Protocol. 288 If the Multilink Protocol has been negotiated and encryption is to be 289 construed as being applied to the bundle, then the multilink 290 procedure is to be applied to the resulting DESE packets. 292 6.1. Padding Considerations 294 Since the DES algorithm operates on blocks of 8 octets, plain text 295 packets which are of length not a multiple of 8 octets must be 296 padded. This can be injurious to the interpretation of some 297 protocols which do not contain an explicit length field in their 298 protocol headers. 300 Since there is no standard directory of protocols which are 301 susceptible to corruption through padding, this can lead to confusion 302 over which protocols should be protected against padding-induced 303 corruption. Consequently, this specification requires that the 304 unambiguous technique described below MUST be applied to ALL plain 305 text packets. 307 The method of padding is based on that described for the LCP Self- 308 Describing-Padding (SDP) option (as defined in RFC 1570[4]), but 309 differs in two respects: first, maximum-pad value is fixed to be 8, 310 and second, the method is to be applied to ALL packets, not just 311 "specifically identified protocols". 313 Plain text which is not a multiple of 8 octets long MUST be padded 314 prior to encrypting the plain text with sufficient octets in the 315 sequence of octets 1, 2, 3 ... 7 to make the plain text a multiple of 316 8 octets. 318 Plain text which is already a multiple of 8 octets may require 319 padding with a further 8 octets (1, 2, 3 ... 8). These additional 320 octets MUST be appended prior to encrypting the plain text if the 321 last octet of the plain text has a value of 1 through 8, inclusive. 323 After the peer has decrypted the cipher text, it strips off the Self- 324 Describing-Padding octets, to recreate the original plain text. 326 Note that after decrypting, only the content of the last octet need 327 be examined to determine how many pad bytes should be removed. 328 However, the peer SHOULD discard the frame if all the octets forming 329 the padding do not match the scheme just described. 331 The padding operation described above is performed independently of 332 whether or not the LCP Self-Describing-Padding (SDP) option has been 333 negotiated. If it has, SDP would be applied to the packet as a whole 334 after it had been ciphered and after the Encryption Protocol 335 Identifiers had been prepended. 337 6.2. Generation of the Ciphertext 339 In this discussion, E[k] will denote the basic DES cipher determined 340 by a 56-bit key k acting on 64 bit blocks. and D[k] will denote the 341 corresponding decryption mechanism. The padded plaintext described 342 in the previous section then becomes a sequence of 64 bit blocks P[i] 343 (where i ranges from 1 to n). The circumflex character (^) 344 represents the bit-wise exclusive-or operation applied to 64-bit 345 blocks. 347 When encrypting the first packet to be transmitted in the opened 348 state let C[0] be the result of applying E[k] to the Initial Nonce 349 received in the peer's ECP DESE option; otherwise let C[0] be the 350 final block of the previously transmitted packet. 352 The ciphertext for the packet is generated by the iterative process 354 C[i] = E[k](P[i] ^ C[i-1]) 356 for i running between 1 and n. 358 6.3. Retrieval of the Plaintext 360 When decrypting the first packet received in the opened state, let 361 C[0] be the result of applying E[k] to the Initial Nonce transmitted 362 in the ECP DESE option. The first packet will have sequence number 363 zero. For subsequent packets, let C[0] be the final block of the 364 previous packet in sequence space. Decryption is then accomplished 365 by 366 P[i] = C[i-1] ^ D[k](C[i]), 368 for i running between 1 and n. 370 6.4. Recovery after Packet Loss 372 Packet loss is detected when there is a discontinuity in the sequence 373 numbers of consecutive packets. Suppose packet number N - 1 has an 374 unrecoverable error or is otherwise lost, but packets N and N + 1 are 375 received correctly. 377 Since the algorithm in the previous section requires C[0] for packet 378 N to be C[last] for packet N - 1, it will be impossible to decode 379 packet N. However, all packets N + 1 and following can be decoded in 380 the usual way, since all that is required is the last block of 381 ciphertext of the previous packet (in this case packet N, which WAS 382 received). 384 7. MRU Considerations 386 Because padding can occur, and because there is an additional 387 protocol field in effect, implementations should take into account 388 the growth of the packets. As an example, if PFC had been 389 negotiated, and if the MRU before had been exactly a multiple of 8, 390 then the plaintext resulting combining a full sized data packets with 391 a one byte protocol field would require an additional 7 bytes of 392 padding, and the sequence number would be an additional 2 bytes so 393 that the information field in the DESE protocol is now 10 bytes 394 larger than that in the original packet. Because the convention is 395 that PPP options are independent of each other, negotiation of DESE 396 does not, by itself, automatically increase the MRU value. 398 8. Differences from RFC 1969 400 8.1. When to Pad 402 In RFC 1969, the method of Self-Describing Padding was not applied to 403 all packets transmitted using DESE. Following the method of the SDP 404 option itself, only "specifically identified protocols", were to be 405 padded. Protocols with an explicit length identifier were exempt. 406 (Examples included non-VJ-compressed IP, XNS, CLNP). 408 In this speficiation, the method is applied to ALL packets. 410 Secondly, this specification is clarified as being completely 411 independent of the Self-Describing-Padding option for PPP, and fixes 412 the maximum number of padding octets as 8. 414 8.2. Assigned Numbers 416 Since this specification could theoretically cause misinterpretation 417 of a packet transmitted according to the previous specification, a 418 new type field number has been assigned for the DESE-bis protocol 420 8.3. Minor Editorial Changes 422 This specification has been designated a standards track document. 423 Some other language has been changed for greater clarity. 425 9. Security Considerations 427 Security issues are the primary subject of this draft. This proposal 428 relies on exterior and unspecified methods for authentication and 429 retrieval of shared secrets. 431 It proposes no new technology for privacy, but merely describes a 432 convention for the application of the DES cipher to data transmission 433 between PPP implementation. 435 Any methodology for the protection and retrieval of shared secrets, 436 and any limitations of the DES cipher are relevant to the use 437 described here. 439 10. References 441 [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, 442 RFC 1661, Daydreamer, July 1994. 444 [2] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, Spider 445 Systems. June 1996 447 [3] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, 448 "The PPP Multilink Protocol (MP)", RFC 1990, UC Berkeley, August, 449 1996. 451 [4] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, Daydreamer, 452 January 1994. 454 [5] National Bureau of Standards, "Data Encryption Standard", FIPS 455 PUB 46 (January 1977). 457 [6] National Bureau of Standards, "DES Modes of Operation", FIPS PUB 458 81 (December 1980). 460 [7] Schneier, B., "Applied Cryptography - Protocols Algorithms, and 461 source code in C", John Wiley & Sons, Inc. 1994. There is an 462 errata associated with the book, and people can get a copy by 463 sending e-mail to schneier@counterpane.com. 465 [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement 466 Levels", RFC 2119, Harvard University, March 1997. 468 11. Authors' Addresses 470 Keith Sklower 471 Computer Science Department 472 339 Soda Hall, Mail Stop 1776 473 University of California 474 Berkeley, CA 94720-1776 476 Phone: (510) 642-9587 477 EMail: sklower@CS.Berkeley.EDU 479 Gerry M. Meyer 480 Shiva Europe Ltd. 481 Stanwell Street 482 Edinburgh EH6 5NG 483 Scotland, UK 485 Phone: (UK) 131 561 4223 486 Fax: (UK) 131 561 4083 487 Email: gerry@europe.shiva.com 489 12. Expiration Date of this Draft 491 September 1st, 1998