Network Working Group B. Lloyd
Request for Comments: Draft Telebit
W A Simpson
CSCS
October 1991
The PPP Authentication Protocols
Status of this Memo
This proposal is the product of the Point-to-Point Protocol Working
Group of the Internet Engineering Task Force (IETF). Comments on
this memo should be submitted to the IETF Working Group at ietf-
ppp@ucdavis.edu.
Distribution of this memo is unlimited.
Abstract
The Point-to-Point Protocol (PPP) [1] provides a standard method of
encapsulating Network Layer protocol information over point-to-point
links. PPP also defines an extensible Link Control Protocol, and
provides for Authentication before allowing Network Layer protocols
to transmit over the link.
This document defines two protocols for Authentication: the simple
Password Authentication Protocol, and the Challenge Handshake
Authentication Protocol.
Lloyd & Simpson FORMFEED[Page i]
RFC DRAFT PPP Authentication October 1991
1. Introduction
PPP has three main components:
1. A method for encapsulating datagrams over serial links. PPP
uses HDLC as a basis for encapsulating datagrams over point-
to-point links. At this time, PPP specifies the use of
asynchronous or synchronous duplex circuits, either dedicated
or circuit switched.
2. A Link Control Protocol (LCP) for establishing, configuring,
and testing the data-link connection.
3. A family of Network Control Protocols (NCPs) for establishing
and configuring different network-layer protocols. PPP is
designed to allow the simultaneous use of multiple network-
layer protocols.
In order to establish communications over a point-to-point link, the
originating PPP would first send LCP packets to configure and test
the data link. After the link has been established, PPP provides for
an optional Authentication phase before proceeding to the Network-
Layer Protocol phase.
If an implementation requires that the peer authenticate with some
specific authentication protocol, then it must negotiate the use of
that authentication protocol during Link Establishment phase.
These authentication protocols are intended for use primarily by
hosts and routers that connect via switched circuits or dial-up lines
to a PPP network server. The server can then use the identification
of the connecting host or router in the selection of options for
network layer negotiations. When failing authentication, the server
should terminate the connection.
1.1. Requirements
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized.
MUST
This word, or the adjective "required", means that the definition
is an absolute requirement of the specification.
MUST NOT
This phrase means that the definition is an absolute prohibition
Lloyd & Simpson FORMFEED[Page 1]
RFC DRAFT PPP Authentication October 1991
of the specification.
SHOULD
This word, or the adjective "recommended", means that there may
exist valid reasons in particular circumstances to ignore this
item, but the full implications should be understood and carefully
weighed before choosing a different course.
MAY
This word, or the adjective "optional", means that this item is
one of an allowed set of alternatives. An implementation which
does not include this option must none-the-less be prepared to
interoperate with another implementation which does include the
option.
1.2. Terminology
This document frequently uses the following terms:
authenticator
The end of the link requiring the authentication.
peer
The other end of the point-to-point link.
silently discard
This means the implementation MUST discard the packet without
further processing. However, for diagnosis of problems, the
implementation SHOULD provide the capability of logging the error,
including the contents of the silently discarded packet, and
SHOULD record the event in a statistics counter.
2. Management of Keys
Distribution and management of Passwords and other Key values ....
EDITOR'S NOTE: We need some text for this section.
Lloyd & Simpson FORMFEED[Page 2]
RFC DRAFT PPP Authentication October 1991
3. Password Authentication Protocol
The Password Authentication Protocol (PAP) may be used to verify the
identity of the other end of the link. After the Link Establishment
phase is complete, an Id/Password pair is repeatedly sent by the peer
to the authenticator until authentication is acknowledged or the
connection is terminated.
Note that PAP is not a strong authentication method. Passwords are
passed over the circuit in the clear and there is no protection from
playback or repeated trial and error attacks. It is strongly
recommended that any implementations which negotiate an
Authentication-Protocol Configuration Option offer another
authentication method prior to PAP.
EDITOR'S NOTE: Some would change "strongly recommended" to
REQUIRED.
This authentication method is most likely used where the plaintext
password must be available to simulate a login at a remote host. In
such use, the method is no less secure than the normal user login at
the remote host.
Lloyd & Simpson FORMFEED[Page 3]
RFC DRAFT PPP Authentication October 1991
3.1. Configuration Option Format
A summary of the Authentication-Protocol Configuration Option format
to negotiate the Password Authentication Protocol 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 | Authentication-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
3
Length
4
Authentication-Protocol
c023 (hex) for Password Authentication Protocol.
Data
There is no Data field.
Lloyd & Simpson FORMFEED[Page 4]
RFC DRAFT PPP Authentication October 1991
3.2. Packet Format
Exactly one Password Authentication Protocol packet is encapsulated
in the Information field of PPP Data Link Layer frames where the
protocol field indicates type hex c023 (Password Authentication
Protocol). A summary of the PAP packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
Code
The Code field is one octet and identifies the type of PAP packet.
PAP Codes are assigned as follows:
1 Authenticate-Req
2 Authenticate-Ack
3 Authenticate-Nak
Identifier
The Identifier field is one octet and aids in matching requests
and replies.
Length
The Length field is two octets and indicates the length of the PAP
packet including the Code, Identifier, Length and Data fields.
Octets outside the range of the Length field should be treated as
Data Link Layer padding and should be ignored on reception.
Data
The Data field is zero or more octets. The format of the Data
field is determined by the Code field.
Lloyd & Simpson FORMFEED[Page 5]
RFC DRAFT PPP Authentication October 1991
3.3. Authenticate-Req
Description
The Authenticate-Req packet is used to begin the Password
Authentication Protocol. An implementation having sent a LCP
Configure-Ack packet with an Authentication-Protocol Configuration
Option specifying the Password Authentication Protocol must send
an Authenticate-Req packet during the Authentication phase. The
Authenticate-Req packet must be repeated until a valid reply
packet is received, or an optional counter expires.
An implementation receiving a Configure-Ack with said
Configuration Option should expect the peer to send an
Authenticate-Req packet. Upon reception of an Authenticate-Req
packet, some type of Authenticate reply (described below) MUST be
returned.
Note: Because the reply might be lost, the protocol MUST allow
repeated Authenticate-Req packets after completing the
Authentication phase. To prevent discovery of alternative
Identities and Passwords, any Authenticate-Req packets received
during the Network-Layer Protocol phase MUST return the same
reply returned when the Authentication phase completed. Any
Authenticate-Req packets received during any other phase MUST
be silently discarded.
A summary of the Authenticate-Req packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer-ID Length| Peer-Id ...
+-+-+-+-+-+-+-+-+-+-+-+-+
| Passwd-Length | Password ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
1 for Authenticate-Req.
Identifier
The Identifier field is one octet and aids in matching requests
and replies. The Identifier field SHOULD be changed each time an
Lloyd & Simpson FORMFEED[Page 6]
RFC DRAFT PPP Authentication October 1991
Authenticate-Req packet is transmitted.
Peer-ID-Length
The Peer-ID-Length field is one octet and indicates the length of
the Peer-ID field
Peer-ID
The Peer-ID field is zero or more octets and indicates the name of
the peer to be authenticated.
Passwd-Length
The Passwd-Length field is one octet and indicates the length of
the Password field.
Password
The Password field is zero or more octets and indicates the
password to be used for authentication.
Lloyd & Simpson FORMFEED[Page 7]
RFC DRAFT PPP Authentication October 1991
3.4. Authenticate-Ack and Authenticate-Nak
Description
If the Peer-ID/Password pair received in an Authenticate-Req is
both recognizable and acceptable, then the authenticator MUST
transmit a PAP packet with the Code field set to 2 (Authenticate-
Ack), the Identifier field copied from the received Authenticate-
Req packet, and the Message field optionally filled with an ASCII
message.
If the Peer-ID/Password pair received in a Authenticate-Req is not
recognizable or acceptable, then the authenticator MUST transmit a
PAP packet with the Code field set to 3 (Authenticate-Nak), the
Identifier field copied from the received Authenticate-Req packet,
and the Message field optionally filled with an ASCII message.
A summary of the Authenticate-Ack and Authenticate-Nak packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg-Length | Message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
2 for Authenticate-Ack;
3 for Authenticate-Nak.
Identifier
The Identifier field is one octet and aids in matching requests
and replies. The Identifier field MUST be copied from the
Identifier field of the Authenticate-Req which caused this reply.
Msg-Length
The Msg-Length field is one octet and indicates the length of the
Message field.
Message
The Message field is zero or more octets and indicates an ASCII
Lloyd & Simpson FORMFEED[Page 8]
RFC DRAFT PPP Authentication October 1991
message.
Lloyd & Simpson FORMFEED[Page 9]
RFC DRAFT PPP Authentication October 1991
4. Challenge Handshake Authentication Protocol
The Challenge Handshake Authentication Protocol (CHAP) may be used to
verify the identity of the other end of the link. After the Link
Establishment phase is complete, an Id is sent by the peer to the
authenticator, which returns a randomly generated "challenge" value.
The peer responds with a challenge checksum of the challenge value
paired with a local secret. The authenticator then checks the
"response" value against the checksum value of its challenge combined
with its copy of the secret.
The CHAP authentication method provides protection against playback
attack, and substitutions in circuit-switched connections after the
initial link establishment.
This authentication method is most likely used where the same secret
is easily maintained at both ends of the link.
Lloyd & Simpson FORMFEED[Page 10]
RFC DRAFT PPP Authentication October 1991
4.1. Configuration Option Format
A summary of the Authentication-Protocol Configuration Option format
to negotiate the Challenge Handshake Authentication Protocol 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 | Authentication-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Digest | Callback |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
3
Length
5
Authentication-Protocol
c223 (hex) for Challenge Handshake Authentication Protocol.
Digest
The Digest field is one octet and indicates the challenge method
to be used. The most up-to-date values of the CHAP Digest field
are specified in the most recent "Assigned Numbers" RFC [2].
Current values are assigned as follows:
0-4 unused (reserved)
5 MD5 [3]
Callback
The Callback field is one octet containing a flag which indicates
that the authenticator will hang up and call back after successful
authentication. Current values are assigned as follows:
0 no callback
1 callback
Lloyd & Simpson FORMFEED[Page 11]
RFC DRAFT PPP Authentication October 1991
4.2. Packet Format
Exactly one Challenge Handshake Authentication Protocol packet is
encapsulated in the Information field of PPP Data Link Layer frames
where the protocol field indicates type hex c223 (Challenge Handshake
Authentication Protocol). A summary of the CHAP packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
Code
The Code field is one octet and identifies the type of CHAP
packet. CHAP Codes are assigned as follows:
1 Challenge
2 Response
3 Success
4 Failure
Identifier
The Identifier field is one octet and aids in matching requests
and replies.
Length
The Length field is two octets and indicates the length of the
CHAP packet including the Code, Identifier, Length and Data
fields. Octets outside the range of the Length field should be
treated as Data Link Layer padding and should be ignored on
reception.
Data
The Data field is zero or more octets. The format of the Data
field is determined by the Code field.
Lloyd & Simpson FORMFEED[Page 12]
RFC DRAFT PPP Authentication October 1991
4.3. Challenge and Response
Description
The Challenge packet is used to begin the Challenge Handshake
Authentication Protocol. An implementation having sent a LCP
Configure-Ack packet with an Authentication-Protocol Configuration
Option specifying the Challenge Handshake Authentication Protocol
must expect a Challenge packet during the Authentication phase.
An implementation receiving a Configure-Ack with said
Configuration Option should transmit a CHAP packet with the Code
field set to 1 (Challenge), the Identifier field set, the Value
field filled with a randomly generated value, and the Name field
filled with the identification of the authenticator.
A Challenge packet MAY also be transmitted at any time during the
Network-Layer Protocol phase to ensure that the connection has not
been altered. The random value MUST be different each time a
challenge is issued.
Whenever a Challenge packet is received, the implementation MUST
transmit a CHAP packet with the Code field set to 2 (Response),
the Identifier field copied from the received Challenge packet,
and the Value field filled with the challenge checksum of the
Challenge Value followed by the local copy of the secret which
corresponds to the Name transmitted in the initial Identity
packet.
Whenever a Response packet is received, the implementation
calculates the challenge checksum of its Challenge Value followed
by its copy of the secret which corresponds to the Name received
in the initial Identity packet, and compares this checksum with
the Response Value. Based on this comparison, the authenticator
sends a Success or Failure packet (described below).
A summary of the Challenge and Response packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value size | Value ... (up to 255 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Name ... (remainder of Length)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Lloyd & Simpson FORMFEED[Page 13]
RFC DRAFT PPP Authentication October 1991
Code
1 for Challenge;
2 for Response.
Identifier
The Identifier field is one octet and aids in matching requests
and replies. The Identifier field MUST be copied from the
Identifier field of the packet which caused this reply.
Value
The Value field is two or more octets, depending on the digest
method negotiated. It contains the values used in the challenge
handshake. The most significant octet is transmitted first.
Name
The Name field is one or more octets representing the
identification of the system transmitting the packet. There are no
limitations on the content of this field. However, the use of
standard ASCII character strings are encouraged.
Since CHAP may be used to authenticate many different systems the
content of the name field may be used as a key to locate the
proper secret in a database of secrets. This also makes it
possible to support more than one name/secret pair per system.
Lloyd & Simpson FORMFEED[Page 14]
RFC DRAFT PPP Authentication October 1991
4.4. Success and Failure
Description
If the Value received in a Response is acceptable, then the
implementation MUST transmit a CHAP packet with the Code field
set to 3 (Success), the Identifier field copied from the
received Response packet, and the Message field optionally
filled with an ASCII message.
If the Value received in a Response is not acceptable, then the
implementation MAY transmit a CHAP packet with the Code field
set to 4 (Failure), the Identifier field copied from the
received Response packet, and the Message field optionally
filled with an ASCII message.
A summary of the Success and Failure packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
4 for Success;
5 for Failure.
Identifier
The Identifier field is one octet and aids in matching requests
and replies. The Identifier field MUST be copied from the
Identifier field of the Response which caused this reply.
Message
The Message field is zero or more octets and indicates an ASCII
message.
Lloyd & Simpson FORMFEED[Page 15]
RFC DRAFT PPP Authentication October 1991
References
[1] Perkins, D., "The Point-to-Point Protocol for the
Transmission of Multi-Protocol of Datagrams Over Point-to-
Point Links", RFC 1171, July, 1990.
[2] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,
USC/Information Sciences Institute, March 1990.
[3] Rivest, R., and S. Dusse, "The MD5 Message-Digest
Algorithm", RFC in publication
Security Considerations
Security issues are the primary topic of this RFC.
Acknowledgments
Some of the text in this document is taken from previous documents
produced by the Point-to-Point Protocol Working Group of the Internet
Engineering Task Force (IETF), formerly chaired by Drew Perkins of
Carnegie Mellon University, by Russ Hobby of the University of
California at Davis, and by Steve Knowles of FTP Software.
Chair's Address
The working group can be contacted via the current chair:
Brian Lloyd
Lloyd & Associates
3420 Sudbury Road
Cameron Park, California 95682
Phone: (916) 676-1147
EMail: brian@ray.lloyd.com
Author's Address
Questions about this memo can also be directed to:
William Allen Simpson
Computer Systems Consulting Services
Lloyd & Simpson FORMFEED[Page 16]
RFC DRAFT PPP Authentication October 1991
P O Box 6205
East Lansing, MI 48826-6025
EMail: Bill_Simpson@um.cc.umich.edu
Lloyd & Simpson FORMFEED[Page 17]
RFC DRAFT PPP Authentication October 1991
TTaabbllee ooff CCoonntteennttss
1. Introduction .......................................... 1
1.1 Requirements .................................... 1
1.2 Terminology ..................................... 2
2. Management of Keys .................................... 2
3. Password Authentication Protocol ...................... 3
3.1 Configuration Option Format ..................... 4
3.2 Packet Format ................................... 5
3.3 Authenticate-Req ................................ 6
3.4 Authenticate-Ack and Authenticate-Nak ........... 8
4. Challenge Handshake Authentication Protocol ........... 10
4.1 Configuration Option Format ..................... 11
4.2 Packet Format ................................... 12
4.3 Challenge and Response .......................... 13
4.4 Success and Failure .......................... 15
REFERENCES ................................................ 16
SECURITY CONSIDERATIONS ...................................... 16
ACKNOWLEDGEMENTS ............................................. 16
CHAIR'S ADDRESS .............................................. 16
AUTHOR'S ADDRESS ............................................. 16
Lloyd & Simpson FORMFEED[Page ii]