Network Working Group G.M. Meyer
Internet Draft Spider Systems
Expires May 7, 1995 Nov 1994
The PPP Encryption Control Protocol (ECP)
draft-ietf-pppext-encryption-00.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 Nov 1994
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. ECP Configuration Options .............................. 5
3.1 Proprietary Encryption OUI ........................ 6
3.2 Other Encryption Types ............................ 7
4. Security Considerations ................................ 7
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 Nov 1994
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 CCP packet is encapsulated in the PPP Information
field, where the PPP Protocol field indicates type hex <tbd>
(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 <tbd> (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). 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
has completed successfully. And if ECP negotiation is not
Meyer [Page 3]
Internet Draft PPP Encryption Nov 1994
successful 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 <tbd> (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 <tbd> (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 Nov 1994
3. 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
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:
CCP Option Encryption type
0 OUI
3.1 Proprietary Encryption OUI
Description
This Configuration Option provides a way to negotiate the use of a
proprietary encryption protocol.
Meyer [Page 5]
Internet Draft PPP Encryption Nov 1994
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
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
Meyer [Page 6]
Internet Draft PPP Encryption Nov 1994
determined by the vendor's encryption protocol.
3.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.
4. 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 7]
Internet Draft PPP Encryption Nov 1994
References
[1] Simpson, W., Editor; "The Point-to-Point Protocol (PPP)", RFC
1548, December 1993.
[2] Sklower, K., Lloyd, B., McGregor, G. and Carr, D., "The PPP Mul-
tilink Protocol (MP)", work in progress, University of Califor-
nia, Berkeley.
[3] Rand, D., "PPP Reliable Transmission", RFC 1663,
[4] Reynolds, J., and Postel, J.; "Assigned Numbers", STD 2, RFC
1340, USC/Information Sciences Institute, July 1992.
[5] Rand, D., "The PPP Compression Control Protocol (CCP)", work in
progress.
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 8]
