Network Working Group B Lloyd
Request for Comments: Draft L&A
W A Simpson
Daydreamer
December 1991
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-ppp@ucdavis.edu mailing
list.
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, which
allows negotiation of an Authentication Protocol for authenticating
its peer 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 [Page i]
DRAFT PPP Authentication December 1991
1. Introduction
PPP has three main components:
1. A method for encapsulating datagrams over serial links.
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.
In order to establish communications over a point-to-point link, each
end of the PPP link must first send LCP packets to configure the data
link during the Establishment phase. 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 protocol using the Authentication-Protocol Configuration Option
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. Specification 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
of the specification.
SHOULD
This word, or the adjective "recommended", means that there may
Lloyd & Simpson [Page 1]
DRAFT PPP Authentication December 1991
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. The
authenticator specifies the authentication protocol to be used in
the Configure-Request during Link Establishment phase.
peer
The other end of the point-to-point link. The peer agrees to the
authentication protocol to be used in the Configure-Ack during
Link Establishment phase.
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.
Lloyd & Simpson [Page 2]
DRAFT PPP Authentication December 1991
2. Password Authentication Protocol
The Password Authentication Protocol (PAP) may be used by the peer to
verify its identity. 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.
PAP is not a strong authentication method. Passwords are sent over
the circuit "in the clear", and there is no protection from playback
or repeated trial and error attacks. The peer is in control of the
frequency and timing of the attempts.
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 usual user login at
the remote host.
Any implementations which include a stronger authentication method
(such as CHAP, described below) MUST offer to negotiate that method
prior to PAP.
Lloyd & Simpson [Page 3]
DRAFT PPP Authentication December 1991
2.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 [Page 4]
DRAFT PPP Authentication December 1991
2.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 [Page 5]
DRAFT PPP Authentication December 1991
2.2.1. Authenticate-Req
Description
The Authenticate-Req packet is used to begin the Password
Authentication Protocol. The link peer MUST transmit a PAP packet
with the Code field set to 1 (Authenticate-Req) during the
Authentication phase. The Authenticate-Req packet must be
repeated until a valid reply packet is received, or an optional
retry counter expires.
The authenticator 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 authenticator 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 MUST be changed each time an
Authenticate-Req packet is issued.
Lloyd & Simpson [Page 6]
DRAFT PPP Authentication December 1991
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 [Page 7]
DRAFT PPP Authentication December 1991
2.2.2. 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).
If the Peer-ID/Password pair received in a Authenticate-Req is not
recognizable or acceptable, then the authenticator SHOULD transmit
a PAP packet with the Code field set to 3 (Authenticate-Nak), and
take action to terminate the link.
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. The ASCII message
should not be NUL or CR/LF terminated.
Lloyd & Simpson [Page 8]
DRAFT PPP Authentication December 1991
3. Challenge Handshake Authentication Protocol
The Challenge Handshake Authentication Protocol (CHAP) may be used to
verify the identity of the peer. After the Link Establishment phase
is complete, the authenticator sends a challenge to the peer, which
includes a randomly generated "challenge" value. The peer responds
with a special calculated value called a "message digest". The
authenticator checks the response value against its own calculation
of the expected digest value.
This digest depends upon a "secret" known only to the authenticator
and that peer. The digest value is calculated over a stream of
octets consisting of the packet identifier, followed by (concatenated
with) the secret, followed by (concatenated with) the challenge
value. The message digest algorithm is chosen such that it is
computationally infeasable to determine the secret when the
identifier, the challenge and the digest are known.
CHAP provides protection against playback attack through the use of
an incrementally changing identifier and a randomly varying challenge
value. It is expected that the algorithm used to generate the
challenge value will have a periodicity which is not a multiple of
the identifier period.
This authentication method is most likely used where the same secret
is easily maintained at both ends of the link.
Lloyd & Simpson [Page 9]
DRAFT PPP Authentication December 1991
3.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 | Message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
3
Length
6
Authentication-Protocol
c223 (hex) for Challenge Handshake Authentication Protocol.
Digest
The Digest field is one octet and indicates the message digest
calculation 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
Message
The Message field is zero or more octets. The ASCII message
Lloyd & Simpson [Page 10]
DRAFT PPP Authentication December 1991
should not be NUL or CR/LF terminated. The field is terminated by
the Length field.
This optional field is implementation dependent. For example, it
MAY indicate the location for a callback, such as a phone number
or name.
Lloyd & Simpson [Page 11]
DRAFT PPP Authentication December 1991
3.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 challenges,
responses 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 [Page 12]
DRAFT PPP Authentication December 1991
3.2.1. Challenge and Response
Description
The Challenge packet is used to begin the Challenge Handshake
Authentication Protocol. The authenticator MUST transmit a CHAP
packet with the Code field set to 1 (Challenge). The Challenge
packet must be reissued until a valid Response packet is received,
or an optional retry counter expires.
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 peer SHOULD expect Challenge packets during the Authentication
phase and the Network-Layer Protocol phase. Whenever a Challenge
packet is received, the peer MUST transmit a CHAP packet with the
Code field set to 2 (Response).
Whenever a Response packet is received, the authenticator compares
the Response Value with its own calculation of the expected 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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
1 for Challenge;
2 for Response.
Identifier
The Identifier field is one octet. The Identifier field MUST be
changed each time a Challenge is issued.
Lloyd & Simpson [Page 13]
DRAFT PPP Authentication December 1991
The Response Identifier MUST be copied from the Identifier field
of the Challenge which caused the Response.
Value-Size
This field is one octet and indicates the length of the Value
field.
Value
The Value field is one or more octets. The most significant octet
is transmitted first.
The Challenge Value is a random stream of octets. The Challenge
Value MUST be changed each time a Challenge is issued. The length
of the Challenge Value depends upon the method used to generate
the octets, and SHOULD be independent of the digest method used.
The Response Value is the message digest value (described above).
The length of the Response Value depends upon the digest method
used.
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. The Name should
not be NUL or CR/LF terminated. The field is terminated by the
Length field.
Since CHAP may be used to authenticate many different systems, the
content of the name field(s) 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 [Page 14]
DRAFT PPP Authentication December 1991
3.2.2. Success and Failure
Description
If the Value received in a Response is equal to the expected
value, then the implementation MUST transmit a CHAP packet with
the Code field set to 3 (Success).
If the Value received in a Response is not equal to the expected
value, then the implementation SHOULD transmit a CHAP packet with
the Code field set to 4 (Failure), and take action to terminate
the link.
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
3 for Success;
4 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. The ASCII message
should not be NUL or CR/LF terminated. The field is terminated by
the Length field.
Lloyd & Simpson [Page 15]
DRAFT PPP Authentication December 1991
Security Considerations
Security issues are the primary topic of this RFC.
The LCP state machine may renegotiate the authentication protocol at
any time. It is recommended that any counters used for
authentication failure not be reset until after successful
authentication, or subsequent termination of the failed link.
Distribution and management of passwords and other secret values
should take place in a secure fashion. This topic is currently
undergoing research and experimentation. SNMP Security Protocols [4]
should be used where applicable. That document also has an excellent
overview of threats to network protocols.
References
[1] Simpson, W. A., "The Point-to-Point Protocol", RFC in progress.
[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 progress.
[4] Galvin, J., K. McCloghrie, and J. Davin, "SNMP Security
Protocols", RFC in progress.
Acknowledgments
Some of the text in this document is taken from RFC 1172, by Drew
Perkins of Carnegie Mellon University, and by Russ Hobby of the
University of California at Davis.
Special thanks to Dave Balenson, Steve Crocker, and James Galvin, for
their extensive explanations and suggestions.
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
Lloyd & Simpson [Page 16]
DRAFT PPP Authentication December 1991
EMail: brian@ray.lloyd.com
Author's Address
Questions about this memo can also be directed to:
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
P O Box 6205
East Lansing, MI 48826-6025
EMail: Bill_Simpson@um.cc.umich.edu
Lloyd & Simpson [Page 17]
DRAFT PPP Authentication December 1991
Table of Contents
1. Introduction .......................................... 1
1.1 Specification Requirements ...................... 1
1.2 Terminology ..................................... 2
2. Password Authentication Protocol ...................... 3
2.1 Configuration Option Format ..................... 4
2.2 Packet Format ................................... 5
2.2.1 Authenticate-Req ................................ 6
2.2.2 Authenticate-Ack and Authenticate-Nak ........... 8
3. Challenge Handshake Authentication Protocol ........... 9
3.1 Configuration Option Format ..................... 10
3.2 Packet Format ................................... 12
3.2.1 Challenge and Response .......................... 13
3.2.2 Success and Failure ............................. 15
SECURITY CONSIDERATIONS ...................................... 16
REFERENCES ................................................... 16
ACKNOWLEDGEMENTS .......................................... 16
CHAIR'S ADDRESS .............................................. 16
AUTHOR'S ADDRESS ............................................. 17