HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 06:38:27 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 13 Feb 1995 23:00:00 GMT ETag: "304d5e-4b2a-2f3fe470" Accept-Ranges: bytes Content-Length: 19242 Connection: close Content-Type: text/plain Network Working Group G.M. Meyer Internet Draft Spider Systems Expires Aug 10, 1995 Feb 1995 The PPP Encryption Control Protocol (ECP) draft-ietf-pppext-encryption-02.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 not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``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 ds.internic.net (US East Coast), nic.nordu.net Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP also defines an extensible Link Control Protocol. This document defines a method for negotiating data encryption over PPP links. Conventions The following language conventions are used in the items of specification in this document: o MUST -- the item is an absolute requirement of the specification. Meyer [Page 1] Internet Draft PPP Encryption Feb 1995 MUST is only used where it is actually required for interopera- tion, not to try to impose a particular method on implementors where not required for interoperability. o SHOULD -- the item should be followed for all but exceptional cir- cumstances. o MAY or optional -- the item is truly optional and may be followed or ignored according to the needs of the implementor. The words "should" and "may" are also used, in lower case, in their more ordinary senses. Table of Contents 1. Introduction ........................................... 2 2. Encryption Control Protocol (ECP) ...................... 3 2.1 Sending Encrypted Datagrams ....................... 4 3. Additional Packets ..................................... 5 3.1 Reset-Request and Reset-Ack ....................... 5 4. ECP Configuration Options .............................. 6 4.1 Proprietary Encryption OUI ........................ 7 4.2 Other Encryption Types ............................ 9 5. Security Considerations ................................ 9 1. Introduction In order to establish communications over a PPP link, each end of the link must first send LCP packets to configure and test the data link during Link Establishment phase. After the link has been esta- blished, optional facilities may be negotiated as needed. One such facility is data encryption. A wide variety of encryption methods may be negotiated, although typically only one method is used in each direction of the link. A different encryption algorithm may be negotiated in each direction, for speed, cost, memory or other considerations. Meyer [Page 2] Internet Draft PPP Encryption Feb 1995 2. Encryption Control Protocol (ECP) The Encryption Control Protocol (ECP) is responsible for configuring and enabling data encryption algorithms on both ends of the point- to-point link. ECP uses the same packet exchange mechanism as the Link Control Pro- tocol (LCP). ECP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. ECP packets received before this phase is reached should be silently discarded. The Encryption Control Protocol is exactly the same as the Link Con- trol Protocol [1] with the following exceptions: Frame Modifications The packet may utilise any modifications to the basic frame format which have been negotiated during the Link Establishment phase. Data Link Layer Protocol Field Exactly one ECP packet is encapsulated in the PPP Information field, where the PPP Protocol field indicates type hex 8053 (Encryption Control Protocol). When individual link data encryption is used in a multiple link connection to a single destination [2], the PPP Protocol field indicates type hex 8055 (Individual link Encryption Control Protocol). Code field ECP uses codes 1 through 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate- Ack and Code-Reject), code 14 (Reset-Request) and code 15 (Reset-Ack). Other Codes should be treated as unrecognised and should result in Code-Rejects. Negotiation ECP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. An implementation should be prepared to wait for Authentication and Link Quality Determina- tion to finish before timing out waiting for a Configure-Ack or other response. An implementation MUST NOT transmit data until ECP negotiation Meyer [Page 3] Internet Draft PPP Encryption Feb 1995 has completed successfully. And if ECP negotiation is not suc- cessful the link MUST be brought down. Configuration Option Types ECP has a distinct set of Configuration Options. 2.1 Sending Encrypted Datagrams Before any encrypted packets may be communicated, PPP must reach the Network-Layer Protocol phase, and the Encryption Control Protocol must reach the Opened state. An encrypted packet is encapsulated in the PPP Information field, where the PPP Protocol field indicates type hex 0053 (Encrypted datagram). When using multiple PPP links to a single destination [2], there are two methods of employing data encryption. The first method is to encrypt the data prior to sending it out through the multiple links. The second is to treat each link as a separate connection, that may or may not have encryption enabled. In the second case, the PPP Pro- tocol field MUST be type hex 0055 (Individual link encrypted datagram). Only one primary algorithm in each direction is in use at a time, and that is negotiated prior to sending the first encrypted frame. The PPP Protocol field of the encrypted datagram indicates that the frame is encrypted, but not the algorithm with which it was encrypted. The maximum length of an encrypted packet transmitted over a PPP link is the same as the maximum length of the Information field of a PPP encapsulated packet. If the encryption algorithm is likely to increase the size of the message beyond that, multilink should also be negotiated to allow fragmentation of the frames (even if only using a single link). If the encryption algorithm carries history between frames, the encryption algorithm must supply a way of determining if it is pass- ing data reliably, or it must require the use of a reliable transport such as LAPB [3]. If both compression and encryption have been negotiated, compression MUST be performed on the data prior to encryption. It is explicitly stated here to aid interoperability. Performing them in this order should maximise the effect of compression. Truly encrypted data is unlikely to be compressible. Meyer [Page 4] Internet Draft PPP Encryption Feb 1995 3. Additional Packets The Packet format and basic facilities are already defined for LCP [1]. Up-to-date values of the ECP Code field are specified in the most recent "Assigned Numbers" RFC [4]. This specification concerns the following values: 14 Reset-Request 15 Reset-Ack 3.1 Reset-Request and Reset-Ack Description ECP includes Reset-Request and Reset-Ack Codes in order to provide a mechanism for indicating a decryption failure in one direction of a decrypted link without affecting traffic in the other direc- tion. Individual algorithms need to specify a mechanism for determining how to detect a decryption failure. Some algorithms may not require this facility. On initial detection of a decryption failure, an ECP implementa- tion SHOULD transmit an ECP packet with the Code field set to 14 (Reset-Request). The Data field may be filled with any desired data. Once a Reset-Request has been sent, any encrypted packets received are discarded. Further Reset-Requests MAY be sent with the same Identifier, until a valid Reset-Ack is received. When the link is busy, one decryption error is usually followed by several more before the Reset-Ack can be received. It is undesir- able to transmit Reset-Requests more frequently than the round- trip-time of the link, since this will result in redundant Reset- Requests and Reset-Acks being transmitted and processed. The receiver MAY elect to limit transmission of Reset-Requests (to say one per second) while a Reset-Ack is outstanding. Upon reception of a Reset-Request, the transmitting encrypter is reset to an initial state. An ECP packet MUST be transmitted with the Code field set to 15 (Reset-Ack), the Identifier field copied from the Reset-Request packet, and the Data field filled with any desired data. Meyer [Page 5] Internet Draft PPP Encryption Feb 1995 On receipt of a Reset-Ack, the receiving decrypter is reset to an initial state. Since there may be several Reset-Acks in the pipe, the decrypter MUST be reset for each Reset-Ack which matches the currently expected identifier. A summary of the Reset-Request and Reset-Ack packet formats is shown below. The fields are transmitted from left to right. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+ Code 14 for Reset-Request; 15 for Reset-Ack. Identifier On transmission, the Identifier field MUST be changed whenever the content of the Data field changes, and whenever a valid reply has been received for a previous request. For retransmissions, the Identifier MAY remain unchanged. On reception, the Identifier field of the Reset-Request is copied into the Identifier field of the Reset-Ack packet. Data The Data field is zero or more octets and contains uninterpreted data for use by the sender. The data may consist of any binary value and may be of any length from zero to the peer's established MRU minus four. 4. ECP Configuration Options ECP Configuration Options allow negotiation of encryption algorithms and their parameters. ECP uses the same Configuration Option format defined for LCP [1], with a separate set of Options. Configuration Options, in this protocol, indicate algorithms that the Meyer [Page 6] Internet Draft PPP Encryption Feb 1995 receiver is willing or able to use to decrypt data sent by the sender. Systems may offer to accept several algorithms, and nego- tiate a single one that will be used. There is the possibility of not being able to agree on an encryption algorithm. In that case the link MUST be brought down. We expect that many vendors will want to use proprietary encryption algorithms, and have made a mechanism available to negotiate these without encumbering the Internet Assigned Number Authority with proprietary number requests. The LCP option negotiation techniques are used. If an option is unrecognised, a Configure-Reject MUST be sent. If all protocols the sender implements are Configure-Rejected by the receiver the link MUST be brought down. If an option is recognised, but not acceptable due to values in the request (or optional parameters not in the request), a Configure-Nak MUST be sent with the option modified appropriately. The Configure- Nak MUST contain only those options that will be acceptable. A new Configure-Request SHOULD be sent with only the single preferred option, adjusted as specified in the Configure-Nak. Up-to-date values of the ECP Option Type field are specified in the most recent "Assigned Numbers" RFC [4]. Current values are assigned as follows: ECP Option Encryption type 0 OUI 4.1 Proprietary Encryption OUI Description This Configuration Option provides a way to negotiate the use of a proprietary encryption protocol. Since the first matching encryption will be used, it is recom- mended that any known OUI encryption options be transmitted first, before the common options are used. Before accepting this option, the implementation must verify that the Organisation Unique Identifier identifies a proprietary algo- rithm that the implementation can decrypt, and that any vendor Meyer [Page 7] Internet Draft PPP Encryption Feb 1995 specific negotiation values are fully understood. A summary of the Proprietary Encryption OUI Configuration Option format is shown below. The fields are transmitted from left to right. 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 | Length | OUI ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OUI | Subtype | Values... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 0 Length >= 6 IEEE OUI The vendor's IEEE Organisation Unique Identifier (OUI), which is the most significant three octets of an Ethernet Physical Address, assigned to the vendor by IEEE 802. This identifies the option as being proprietary to the indicated vendor. The bits within the octet are in canonical order, and the most significant octet is transmitted first. Subtype This field is specific to each OUI, and indicates an encryption type for that OUI. There is no standardisation for this field. Each OUI implements its own values. Values This field is zero or more octets, and contains additional data as determined by the vendor's encryption protocol. Meyer [Page 8] Internet Draft PPP Encryption Feb 1995 4.2 Other Encryption Types Description These Configuration Options provide a way to negotiate the use of a publicly defined encryption algorithm. These protocols will be made available to all interested parties, but may have certain licencing restrictions associated with them. For additional information, refer to the encryption protocol docu- ments that define each of the encryption types. A summary of the Encryption Type Configuration Option format is shown below. The fields are transmitted from left to right. 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 | Length | Values... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 1 to 254 Length >= 2 Values This field is zero or more octets, and contains additional data as determined by the encryption protocol. 5. Security Considerations Negotiation of encryption using PPP is designed to provide protection against eavesdropping on that link. The strength of the protection is dependent on the encryption algorithm used and the care with which any 'secrets' used by the encryption algorithm is protected. It must be recognised that complete security can only be obtained through end-to-end security between hosts. Meyer [Page 9] Internet Draft PPP Encryption Feb 1995 References [1] Simpson, W., Editor; "The Point-to-Point Protocol (PPP)", RFC 1548, Computer Systems Consulting Services, December 1993. [2] Sklower, K., Lloyd, B., McGregor, G. and Carr, D., "The PPP Mul- tilink Protocol (MP)", RFC 1717, University of California, Berkeley, November 1994. [3] Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July 1994. [4] Reynolds, J., and Postel, J.; "ASSIGNED NUMBERS", RFC 1700, USC/Information Sciences Institute, October 1994. [5] Rand, D., "The PPP Compression Control Protocol (CCP)", work in progress, Novell. Acknowledgements The style and approach of this proposal owes much to the work on the Compression CP [5]. Chair's Address The working group can be contacted via the current chair: Fred Baker Cisco Systems 519 Lado Drive Santa Barbara California 93111 Email: fred@cicso.com Author's Address: Gerry Meyer Spider Systems Stanwell Street Edinburgh EH6 5NG Scotland, UK Phone: (UK) 31 554 9424 Fax: (UK) 31 554 0649 Email: gerry@spider.co.uk Meyer [Page 10]