Network Working Group G. Meyer
`Request for Comments: 1968 Spider Systems
`Category: Standards Track June 1996
`
` The PPP Encryption Control Protocol (ECP)
`Status of this Memo
` This document specifies an Internet standards track protocol for the
` Internet community, and requests discussion and suggestions for
` improvements. Please refer to the current edition of the "Internet
` Official Protocol Standards" (STD 1) for the standardization state
` and status of this protocol. Distribution of this memo is unlimited.
`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.
` 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.
`
`Meyer Standards Track [Page 1]
`RFC 1968 PPP Encryption June 1996
`
`Table of Contents
` 1. Introduction ........................................... 2
` 2. Encryption Control Protocol (ECP) ...................... 2
` 2.1 Sending Encrypted Datagrams ....................... 3
` 3. Additional Packets ..................................... 4
` 3.1 Reset-Request and Reset-Ack ....................... 5
` 4. ECP Configuration Options .............................. 6
` 4.1 Proprietary Encryption OUI ........................ 7
` 4.2 Publicly Available Encryption Types ............... 8
` 4.3 Negotiating an Encryption Algorithm ............... 9
` 5. Security Considerations ................................ 10
`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
` established, optional facilities may be negotiated as needed.
`
`http://www.ietf.org/rfc/rfc1968[7/8/2011 8:26:23 PM]
`
`Petitioner RPX Corporation - Ex. 1034, p. 1
`
`

`

` 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.
`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
` Protocol (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 LCP [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.
`
`Meyer Standards Track [Page 2]
`RFC 1968 PPP Encryption June 1996
`
` 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 (decimal) codes 1 through 7 (Configure-Request,
` Configure-Ack, Configure-Nak, Configure-Reject, Terminate-
` Request, Terminate-Ack and Code-Reject); And may also use 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
` Determination to finish before timing out waiting for a
` Configure-Ack or other response.
` An implementation MUST NOT transmit data until ECP negotiation
` has completed successfully. If ECP negotiation is not
` successful the link SHOULD 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).
`
`http://www.ietf.org/rfc/rfc1968[7/8/2011 8:26:23 PM]
`
`Petitioner RPX Corporation - Ex. 1034, p. 2
`
`

`

` When using multiple PPP links to a single destination [2], there are
` two methods of employing data encryption:
`
`Meyer Standards Track [Page 3]
`RFC 1968 PPP Encryption June 1996
`
` o The first method is to encrypt the data prior to sending it out
` through the multiple links.
` The PPP Protocol field MUST indicate type hex 0053.
` o The second is to treat each link as a separate connection, that
` may or may not have encryption enabled.
` On links which have negotiated encryption, the PPP Protocol field
` MUST be type hex 0055 (Individual link encrypted datagram).
` Only one encryption 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
` passing data reliably, or it must require the use of a reliable
` transport such as LAPB [3].
` Compression may also be negotiated using the Compression Control
` Protocol [5]. To ensure interoperability, plain text MUST be:
` o First compressed.
` o Then encrypted.
` This order has been chosen since it should result in smaller output
` and more secure encryption.
`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:
`
`Meyer Standards Track [Page 4]
`RFC 1968 PPP Encryption June 1996
`
` 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
` direction. Some encryption algorithms may not require this
` mechanism.
` Individual algorithms need to specify a mechanism for determining
`
`http://www.ietf.org/rfc/rfc1968[7/8/2011 8:26:23 PM]
`
`Petitioner RPX Corporation - Ex. 1034, p. 3
`
`

`

` how to detect a decryption failure. On initial detection of a
` decryption failure, an ECP implementation 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
` undesirable 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.
` 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.
`
`Meyer Standards Track [Page 5]
`RFC 1968 PPP Encryption June 1996
`
` 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 SHOULD 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
`
`http://www.ietf.org/rfc/rfc1968[7/8/2011 8:26:23 PM]
`
`Petitioner RPX Corporation - Ex. 1034, p. 4
`
`

`

` receiver is willing or able to use to decrypt data sent by the
` sender. Systems may offer to accept several algorithms, and
` negotiate a single one that will be used.
` 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:
`
`Meyer Standards Track [Page 6]
`RFC 1968 PPP Encryption June 1996
`
` ECP Option Encryption type
` 0 OUI
` 1 DESE
`
` All compliant ECP implementations SHOULD implement ECP option 1 - the
` PPP DES Encryption Protocol (DESE) [6].
` Vendors who want to use proprietary encryption MAY use the OUI
` mechanism to negotiate these without recourse to requesting an
` assigned option number from the Internet Assigned Numbers Authority.
` All other encryption options are registered by IANA. At the time of
` writing only DESE (option 1) is registered. Other registered options
` may be found by referring to future versions of the Assigned Numbers
` RFC.
`4.1 Proprietary Encryption OUI
` Description
` This Configuration Option provides a way to negotiate the use of a
` proprietary encryption protocol.
` Vendor's encryption protocols are distinguished from each other by
` means of an Organisationally Unique Identifier (OUI), namely the
` first three octets of a Vendor's Ethernet address assigned by IEEE
` 802.
` Since the first matching encryption will be used, it is
` recommended 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 OUI identifies a proprietary algorithm that the implementation
` can decrypt, and that any vendor 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.
`
`Meyer Standards Track [Page 7]
`RFC 1968 PPP Encryption June 1996
`
` 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...
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
`
`http://www.ietf.org/rfc/rfc1968[7/8/2011 8:26:23 PM]
`
`Petitioner RPX Corporation - Ex. 1034, p. 5
`
`

`

` Type
` 0
` Length
` >= 6
` IEEE OUI
` The IEEE OUI 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.
`4.2 Publicly Available Encryption Types
` Description
` These Configuration Options provide a way to negotiate the use of
` a publicly defined encryption algorithm.
` These protocols should be made available to interested parties,
` but may have certain licencing or export restrictions associated
` with them. For additional information, refer to the encryption
` protocol documents that define each of the encryption types.
`
`Meyer Standards Track [Page 8]
`RFC 1968 PPP Encryption June 1996
`
` 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, indicating the encryption protocol option
` being negotiated. DESE [6] is option type 1. Refer to the
` latest Assigned Numbers RFC for other encryption protocols.
` Length
` >= 2
` Values
` This field is zero or more octets, and contains additional data as
` determined by the encryption protocol.
`4.3 Negotiating an Encryption Algorithm
` ECP uses LCP option negotiation techniques to negotiate encryption
` algorithms. In contrast with most other LCP or NCP negotiation of
` multiple options, ECP negotiation is expected to converge on a single
` mutually agreeable option (encryption algorithm) - or none.
` Encryption SHOULD be negotiated in both directions, but the
` algorithms MAY be different.
`
`http://www.ietf.org/rfc/rfc1968[7/8/2011 8:26:23 PM]
`
`Petitioner RPX Corporation - Ex. 1034, p. 6
`
`

`

` An implementation willing to decrypt using a particular encryption
` algorithm (or one of a set of algorithms) offers the algorithm(s) as
` an option (or options) in an ECP Configure-Request - call this end
` the Decrypter; call the peer the Encrypter.
` A Decrypter supporting more than one encryption algorithm may send a
` Configure-Request containing either:
` o an ordered list of options, with the most-preferred encryption
` algorithm coming first.
` o Or may just offer its preferred (not already Rejected) option.
`
`Meyer Standards Track [Page 9]
`RFC 1968 PPP Encryption June 1996
`
` An Encrypter wishing to accept the first option (of several) MAY
` Configure-Ack ALL Options to indicate complete acceptance of the
` first-listed, preferred, algorithm.
` Otherwise, if the Encrypter does not recognise - or is unwilling to
` support - an option it MUST send a Configure-Reject for that option.
` Where more than one option is offered, the Encrypter SHOULD
` Configure-Reject all but a single preferred option.
` If the Encrypter Configure-Rejects all offered ECP options - and the
` Decrypter has no further (non-rejected) options it can offer in a
` Configure-Request - the Encrypter SHOULD take the link down.
` If the Encrypter recognises an option, but it is not acceptable due
` to values in the request (or optional parameters not in the request),
` it MUST send a Configure-Nak with the option modified appropriately.
` The Configure-Nak MUST contain only those options that will be
` acceptable. The Decrypter SHOULD send a new Configure-Request with
` only the single preferred option, adjusted as specified in the
` Configure-Nak.
`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 'secret' 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.
`References
` [1] Simpson, W., Editor; "The Point-to-Point Protocol (PPP)", STD
` 51, RFC 1661, Daydreamer, July 1994.
` [2] Sklower, K., Lloyd, B., McGregor, G. and and D. Carr, "The PPP
` Multilink 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", STD 2,
` RFC 1700, USC/Information Sciences Institute, October 1994.
` [5] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
` 1962, Novell, June 1996.
`
`Meyer Standards Track [Page 10]
`RFC 1968 PPP Encryption June 1996
`
` [6] Sklower, K., and G. Meyer, "The PPP DES Encryption Protocol
` (DESE)", RFC 1969, University of California, Berkeley, June
`
`http://www.ietf.org/rfc/rfc1968[7/8/2011 8:26:23 PM]
`
`Petitioner RPX Corporation - Ex. 1034, p. 7
`
`

`

` 1996.
`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:
` Karl Fox
` Ascend Communications
` 3518 Riverside Drive, Suite 101
` Columbus, Ohio 43221
` EMail: karl@ascend.com
`Author's Address
` Gerry Meyer
` Spider Systems
` Stanwell Street
` Edinburgh EH6 5NG
` Scotland, UK
` Phone: (UK) 131 554 9424
` Fax: (UK) 131 554 0649
` EMail: gerry@spider.co.uk
`
`Meyer Standards Track [Page 11]
`
`http://www.ietf.org/rfc/rfc1968[7/8/2011 8:26:23 PM]
`
`Petitioner RPX Corporation - Ex. 1034, p. 8
`
`