HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 06:37:30 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 24 Nov 1997 17:23:00 GMT ETag: "304d46-55ff-3479b7f4" Accept-Ranges: bytes Content-Length: 22015 Connection: close Content-Type: text/plain PPP Working Group K. Sklower INTERNET-DRAFT University of California, Berkeley Obsoletes: RFC-1969 G. Meyer Category: Informational Shiva Date: November 20, 1997 The PPP DES Encryption Protocol, Version 2 (DESE-bis) draft-ietf-pppext-des-encrypt-v2-01.txt Status of This Memo This document is a submission to the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The PPP Encryption Control Protocol (ECP) [2] provides a method to negotiate and utilize encryption protocols over PPP encapsulated links. This document provides specific details for the use of the DES standard [5, 6] for encrypting PPP encapsulated packets. Sklower & Meyer Expires May 20th, 1998 [Page 1] INTERNET-DRAFT PPP DES Encryption v2 November 1997 Acknowledgements The authors extend hearty thanks to Fred Baker of Cisco, Philip Rakity of Flowpoint, and William Simpson of Daydreamer for helpful improvements to the clarity and correctness of the document. Table of Contents 1. Introduction ................................................ 2 1.1. Motivation ................................................ 2 1.2. Conventions ............................................... 3 2. General Overview ............................................ 3 3. Structure of This Specification ............................. 4 4. DESE Configuration Option for ECP ........................... 4 5. Packet Format for DESE ...................................... 5 6. Encryption .................................................. 6 6.1. Padding Considerations .................................... 7 6.2. Generation of the Ciphertext .............................. 8 6.3. Retrieval of the Plaintext ................................ 8 6.4. Recovery after Packet Loss ................................ 9 7. MRU Considerations .......................................... 9 8. Security Considerations ..................................... 9 9. References .................................................. 10 10. Authors' Addresses ......................................... 10 11. Expiration Date of this Draft .............................. 11 1. Introduction 1.1. Motivation The purpose of this draft is two-fold: to show how one specifies the necessary details of a "data" or "bearer" protocol given the context of the generic PPP Encryption Control Protocol, and also to provide at least one commonly-understood means of secure data transmission between PPP implementations. The DES encryption algorithm is a well studied, understood and widely implemented encryption algorithm. The DES cipher was designed for efficient implementation in hardware, and consequently may be relatively expensive to implement in software. However, its pervasiveness makes it seem like a reasonable choice for a "model" encryption protocol. Source code implementing DES in the "Electronic Code Book Mode" can be found in [7]. US export laws forbid the inclusion of compilation- ready source code in this document. Sklower & Meyer Expires May 20th, 1998 [Page 2] INTERNET-DRAFT PPP DES Encryption v2 November 1997 1.2. Conventions The following language conventions are used in the items of specification in this document: o MUST, SHALL or MANDATORY -- the item is an absolute requirement of the specification. o SHOULD or RECOMMENDED -- the item should generally be followed for all but exceptional circumstances. o MAY or OPTIONAL -- the item is truly optional and may be followed or ignored according to the needs of the implementor. 2. General Overview The purpose of encrypting packets exchanged between two PPP implementations is to attempt to insure the privacy of communication conducted via the two implementations. The encryption process depends on the specification of an encryption algorithm and a shared secret (usually involving at least a key) between the sender and receiver. Generally, the encryptor will take a PPP packet including the protocol field, apply the chosen encryption algorithm, place the resulting cipher text (and in this specification, an explicit sequence number) in the information field of another PPP packet. The decryptor will apply the inverse algorithm and interpret the resulting plain text as if it were a PPP packet which had arrived directly on the interface. The means by which the secret becomes known to both communicating elements is beyond the scope of this document; usually some form of manual configuration is involved. Implementations might make use of PPP authentication, or the EndPoint Identifier Option described in PPP Multilink [3], as factors in selecting the shared secret. If the secret can be deduced by analysis of the communication between the two parties, then no privacy is guaranteed. While the US Data Encryption Standard (DES) algorithm [5, 6] provides multiple modes of use, this specification selects the use of only one mode in conjunction with the PPP Encryption Control Protocol (ECP): the Cipher Block Chaining (CBC) mode. In addition to the US Government publications cited above, the CBC mode is also discussed in [7], although no C source code is provided for it per se. The initialization vector for this mode is deduced from an explicit 64-bit nonce, which is exchanged in the clear during the negotiation Sklower & Meyer Expires May 20th, 1998 [Page 3] INTERNET-DRAFT PPP DES Encryption v2 November 1997 phase. The 56-bit key required by all DES modes is established as a shared secret between the implementations. One reason for choosing the chaining mode is that it is generally thought to require more computation resources to deduce a 64 bit key used for DES encryption by analysis of the encrypted communication stream when chaining mode is used, compared with the situation where each block is encrypted separately with no chaining. Certainly, identical sequences of plaintext will produce different ciphers when chaining mode is in effect, thus complicating analysis. However, if chaining is to extend beyond packet boundaries, both the sender and receiver must agree on the order the packets were encrypted. Thus, this specification provides for an explicit 16 bit sequence number to sequence decryption of the packets. This mode of operation even allows recovery from occasional packet loss; details are also given below. 3. Structure of This Specification The PPP Encryption Control Protocol (ECP), provides a framework for negotiating parameters associated with encryption, such as choosing the algorithm. It specifies the assigned numbers to be used as PPP protocol numbers for the "data packets" to be carried as the associated "data protocol", and describes the state machine. Thus, a specification for use in that matrix need only describe any additional configuration options required to specify a particular algorithm, and the process by which one encrypts/decrypts the information once the Opened state has been achieved. 4. DESE Configuration Option for ECP Description The ECP DESE Configuration Option indicates that the issuing implementation is offering to employ this specification for decrypting communications on the link, and may be thought of as a request for its peer to encrypt packets in this manner. The ECP DESE Configuration Option has the following fields, which are transmitted from left to right: Sklower & Meyer Expires May 20th, 1998 [Page 4] INTERNET-DRAFT PPP DES Encryption v2 November 1997 Figure 1: ECP DESE Configuration Option 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 3 | Length | Initial Nonce ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type Type = 3, to indicate the DESE-bis protocol. The former value 1 indicating the previous DESE specification is deprecated, i.e. systems implementing this specification MUST NOT offer the former value 1 in a configure-request and MUST configure-reject the former value on receipt of a configure-request containing it. Length 10 Initial Nonce This field is an 8 byte quantity which is used by the peer implementation to encrypt the first packet transmitted after the sender reaches the opened state. To guard against replay attacks, the implementation SHOULD offer a different value during each ECP negotiation. An example might be to use the number of seconds since Jan 1st, 1970 (GMT/UT) in the upper 32 bits, and the current number of nanoseconds relative to the last second mark in the lower 32 bits. Its formulaic role is described in the Encryption section below. 5. Packet Format for DESE Description The DESE packets themselves have the following fields: Sklower & Meyer Expires May 20th, 1998 [Page 5] INTERNET-DRAFT PPP DES Encryption v2 November 1997 Figure 2: DES Encryption Protocol Packet Format 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address | Control | 0000 | Protocol ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Seq. No. High | Seq. No. Low | Ciphertext ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address and Control These fields MUST be present unless the PPP Address and Control Field Compression option (ACFC) has been negotiated. Protocol ID The value of this field is 0x53 or 0x55; the latter indicates that ciphertext includes headers for the Multilink Protocol, and REQUIRES that the Individual Link Encryption Control Protocol has reached the opened state. The leading zero MAY be absent if the PPP Protocol Field Compression option (PFC) has been negotiated. Sequence Number These 16-bit numbers are assigned by the encryptor sequentially starting with 0 (for the first packet transmitted once ECP has reached the opened state. Ciphertext The generation of this data is described in the next section. 6. Encryption Once the ECP has reached the Opened state, the sender MUST NOT apply the encryption procedure to LCP packets nor ECP packets. If the async control character map option has been negotiated on the link, the sender applies mapping after the encryption algorithm has been run. Sklower & Meyer Expires May 20th, 1998 [Page 6] INTERNET-DRAFT PPP DES Encryption v2 November 1997 The encryption algorithm is generally to pad the Protocol and Information fields of a PPP packet to some multiple of 8 bytes, and apply DES in Chaining Block Cipher mode with a 56-bit key K. There are a lot of details concerning what constitutes the Protocol and Information fields, in the presence or non-presence of Multilink, and whether the ACFC and PFC options have been negotiated, and the sort of padding chosen. Regardless of whether ACFC has been negotiated on the link, the sender applies the encryption procedure to only that portion of the packet excluding the address and control field. If the Multilink Protocol has been negotiated and encryption is to be construed as being applied to each link separately, then the encryption procedure is to be applied to the (possibly extended) protocol and information fields of the packet in the Multilink Protocol. If the Multilink Protocol has been negotiated and encryption is to be construed as being applied to the bundle, then the multilink procedure is to be applied to the resulting DESE packets. 6.1. Padding Considerations Since the DES algorithm operates on blocks of 8 octets, plain text packets which are of length not a multiple of 8 octets must be padded. This can be injurious to the interpretation of some protocols which do not contain an explicit length field in their protocol headers. Since there is no standard directory of protocols which are susceptible to corruption through padding, this can lead to confusion over which protocols should be protected against padding-induced corruption. Consequently, this specification requires that the unambiguous technique described below MUST be applied to ALL plain text packets. The method of padding is based on that described for the LCP Self- Describing-Padding (SDP) option (as defined in RFC 1570[4]), but differs in two respects: first, maximum-pad value is fixed to be 8, and second, the method is to be applied to ALL packets, not just "specifically identified protocols". Plain text which is not a multiple of 8 octets long MUST be padded prior to encrypting the plain text with sufficient octets in the sequence of octets 1, 2, 3 ... 7 to make the plain text a multiple of 8 octets. Sklower & Meyer Expires May 20th, 1998 [Page 7] INTERNET-DRAFT PPP DES Encryption v2 November 1997 Plain text which is already a multiple of 8 octets may require padding with a further 8 octets (1, 2, 3 ... 8). These additional octets MUST be appended prior to encrypting the plain text if the last octet of the plain text has a value of 1 through 8, inclusive. After the peer has decrypted the cipher text, it strips off the Self- Describing-Padding octets, to recreate the original plain text. Note that after decrypting, only the content of the last octet need be examined to determine how many pad bytes should be removed. However, the peer SHOULD discard the frame if all the octets forming the padding do not match the scheme just described. The padding operation described above is performed independently of whether or not the LCP Self-Describing-Padding (SDP) option has been negotiated. If it has, SDP would be applied to the packet as a whole after it had been ciphered and after the Encryption Protocol Identifiers had been prepended. 6.2. Generation of the Ciphertext In this discussion, E[k] will denote the basic DES cipher determined by a 56-bit key k acting on 64 bit blocks. and D[k] will denote the corresponding decryption mechanism. The padded plaintext described in the previous section then becomes a sequence of 64 bit blocks P[i] (where i ranges from 1 to n). The circumflex character (^) represents the bit-wise exclusive-or operation applied to 64-bit blocks. When encrypting the first packet to be transmitted in the opened state let C[0] be the result of applying E[k] to the Initial Nonce received in the peer's ECP DESE option; otherwise let C[0] be the final block of the previously transmitted packet. The ciphertext for the packet is generated by the iterative process C[i] = E[k](P[i] ^ C[i-1]) for i running between 1 and n. 6.3. Retrieval of the Plaintext When decrypting the first packet received in the opened state, let C[0] be the result of applying E[k] to the Initial Nonce transmitted in the ECP DESE option. The first packet will have sequence number zero. For subsequent packets, let C[0] be the final block of the previous packet in sequence space. Decryption is then accomplished by Sklower & Meyer Expires May 20th, 1998 [Page 8] INTERNET-DRAFT PPP DES Encryption v2 November 1997 P[i] = C[i-1] ^ D[k](C[i]), for i running between 1 and n. 6.4. Recovery after Packet Loss Packet loss is detected when there is a discontinuity in the sequence numbers of consecutive packets. Suppose packet number N - 1 has an unrecoverable error or is otherwise lost, but packets N and N + 1 are received correctly. Since the algorithm in the previous section requires C[0] for packet N to be C[last] for packet N - 1, it will be impossible to decode packet N. However, all packets N + 1 and following can be decoded in the usual way, since all that is required is the last block of ciphertext of the previous packet (in this case packet N, which WAS received). 7. MRU Considerations Because padding can occur, and because there is an additional protocol field in effect, implementations should take into account the growth of the packets. As an example, if PFC had been negotiated, and if the MRU before had been exactly a multiple of 8, then the plaintext resulting combining a full sized data packets with a one byte protocol field would require an additional 7 bytes of padding, and the sequence number would be an additional 2 bytes so that the information field in the DESE protocol is now 10 bytes larger than that in the original packet. Because the convention is that PPP options are independent of each other, negotiation of DESE does not, by itself, automatically increase the MRU value. 8. Security Considerations Security issues are the primary subject of this draft. This proposal relies on exterior and unspecified methods for authentication and retrieval of shared secrets. It proposes no new technology for privacy, but merely describes a convention for the application of the DES cipher to data transmission between PPP implementation. Any methodology for the protection and retrieval of shared secrets, and any limitations of the DES cipher are relevant to the use described here. Sklower & Meyer Expires May 20th, 1998 [Page 9] INTERNET-DRAFT PPP DES Encryption v2 November 1997 9. References [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Daydreamer, July 1994. [2] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, Spider Systems. June 1996 [3] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, UC Berkeley, August, 1996. [4] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, Daydreamer, January 1994. [5] National Bureau of Standards, "Data Encryption Standard", FIPS PUB 46 (January 1977). [6] National Bureau of Standards, "DES Modes of Operation", FIPS PUB 81 (December 1980). [7] Schneier, B., "Applied Cryptography - Protocols Algorithms, and source code in C", John Wiley & Sons, Inc. 1994. There is an errata associated with the book, and people can get a copy by sending e-mail to schneier@counterpane.com. 10. Authors' Addresses Keith Sklower Computer Science Department 339 Soda Hall, Mail Stop 1776 University of California Berkeley, CA 94720-1776 Phone: (510) 642-9587 EMail: sklower@CS.Berkeley.EDU Gerry M. Meyer Shiva Europe Ltd. Stanwell Street Edinburgh EH6 5NG Scotland, UK Phone: (UK) 131 561 4223 Fax: (UK) 131 561 4083 Email: gerry@europe.shiva.com Sklower & Meyer Expires May 20th, 1998 [Page 10] INTERNET-DRAFT PPP DES Encryption v2 November 1997 11. Expiration Date of this Draft May 20th, 1998 Sklower & Meyer Expires May 20th, 1998 [Page 11]