As per Relevance of the word identifier, we have this rfc below:
Network Working Group B.
Request for Comments: 1334 L&
W.
October 1992
PPP Authentication
Status of this
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
The Point-to-Point Protocol (PPP) [1] provides a standard method
encapsulating Network Layer protocol information over point-to-
links. PPP also defines an extensible Link Control Protocol,
allows negotiation of an Authentication Protocol for
its peer before allowing Network Layer protocols to transmit over
link
This document defines two protocols for Authentication: the
Authentication Protocol and the Challenge-Handshake
Protocol. This memo is the product of the Point-to-Point
Working Group of the Internet Engineering Task Force (IETF).
Comments on this memo should be submitted to the ietf-ppp@ucdavis.
mailing list
Table of
1. Introduction ............................................... 2
1.1 Specification Requirements ................................. 2
1.2 Terminology ................................................ 3
2. Password Authentication Protocol ............................ 3
2.1 Configuration Option Format ................................ 4
2.2 Packet Format .............................................. 5
2.2.1 Authenticate-Request ..................................... 5
2.2.2 Authenticate-Ack and Authenticate-Nak .................... 7
3. Challenge-Handshake Authentication Protocol.................. 8
3.1 Configuration Option Format ................................ 9
3.2 Packet Format .............................................. 10
3.2.1 Challenge and Response ................................... 11
3.2.2 Success and Failure ...................................... 13
Lloyd & Simpson [Page 1]
RFC 1334 PPP Authentication October 1992
SECURITY CONSIDERATIONS ........................................ 14
REFERENCES ..................................................... 15
ACKNOWLEDGEMENTS ............................................... 16
CHAIR'S ADDRESS ................................................ 16
AUTHOR'S ADDRESS ............................................... 16
1.
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
and configuring different network-layer protocols
In order to establish communications over a point-to-point link,
end of the PPP link must first send LCP packets to configure the
link during Link Establishment phase. After the link has
established, PPP provides for an optional Authentication phase
proceeding to the Network-Layer Protocol phase
By default, authentication is not mandatory. If authentication
the link is desired, an implementation MUST specify
Authentication-Protocol Configuration Option during
Establishment phase
These authentication protocols are intended for use primarily
hosts and routers that connect to a PPP network server via
circuits or dial-up lines, but might be applied to dedicated links
well. The server can use the identification of the connecting
or router in the selection of options for network layer negotiations
This document defines the PPP authentication protocols. The
Establishment and Authentication phases, and the Authentication
Protocol Configuration Option, are defined in The Point-to-
Protocol (PPP) [1].
1.1. Specification
In this document, several words are used to signify the
of the specification. These words are often capitalized
This word, or the adjective "required", means that the
is an absolute requirement of the specification
Lloyd & Simpson [Page 2]
RFC 1334 PPP Authentication October 1992
MUST
This phrase means that the definition is an absolute
of the specification
This word, or the adjective "recommended", means that there
exist valid reasons in particular circumstances to ignore
item, but the full implications should be understood and
weighed before choosing a different course
This word, or the adjective "optional", means that this item
one of an allowed set of alternatives. An implementation
does not include this option MUST be prepared to interoperate
another implementation which does include the option
1.2.
This document frequently uses the following terms
The end of the link requiring the authentication.
authenticator specifies the authentication protocol to be used
the Configure-Request during Link Establishment phase
The other end of the point-to-point link; the end which is
authenticated by the authenticator
silently
This means the implementation discards the packet without
processing. The implementation SHOULD provide the capability
logging the error, including the contents of the
discarded packet, and SHOULD record the event in a
counter
2. Password Authentication
The Password Authentication Protocol (PAP) provides a simple
for the peer to establish its identity using a 2-way handshake.
is done only upon initial link establishment
After the Link Establishment phase is complete, an Id/Password
is repeatedly sent by the peer to the authenticator
authentication is acknowledged or the connection is terminated
PAP is not a strong authentication method. Passwords are sent
the circuit "in the clear", and there is no protection from
Lloyd & Simpson [Page 3]
RFC 1334 PPP Authentication October 1992
or repeated trial and error attacks. The peer is in control of
frequency and timing of the attempts
Any implementations which include a stronger authentication
(such as CHAP, described below) MUST offer to negotiate that
prior to PAP
This authentication method is most appropriately used where
plaintext password must be available to simulate a login at a
host. In such use, this method provides a similar level of
to the usual user login at the remote host
Implementation Note: It is possible to limit the exposure of
plaintext password to transmission over the PPP link, and
sending the plaintext password over the entire network. When
remote host password is kept as a one-way transformed value,
the algorithm for the transform function is implemented in
local server, the plaintext password SHOULD be locally
before comparison with the transformed password from the
host
2.1. Configuration Option
A summary of the Authentication-Protocol Configuration Option
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3
4
Authentication-
c023 (hex) for Password Authentication Protocol
There is no Data field
Lloyd & Simpson [Page 4]
RFC 1334 PPP Authentication October 1992
2.2. Packet
Exactly one Password Authentication Protocol packet is
in the Information field of a PPP Data Link Layer frame where
protocol field indicates type hex c023 (Password
Protocol). A summary of the PAP packet format is shown below.
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 ...
+-+-+-+-+
The Code field is one octet and identifies the type of PAP packet
PAP Codes are assigned as follows
1 Authenticate-
2 Authenticate-
3 Authenticate-
The Identifier field is one octet and aids in matching
and replies
The Length field is two octets and indicates the length of the
packet including the Code, Identifier, Length and Data fields
Octets outside the range of the Length field should be treated
Data Link Layer padding and should be ignored on reception
The Data field is zero or more octets. The format of the
field is determined by the Code field
2.2.1. Authenticate-
The Authenticate-Request packet is used to begin the
Authentication Protocol. The link peer MUST transmit a PAP
Lloyd & Simpson [Page 5]
RFC 1334 PPP Authentication October 1992
with the Code field set to 1 (Authenticate-Request) during
Authentication phase. The Authenticate-Request packet MUST
repeated until a valid reply packet is received, or an
retry counter expires
The authenticator SHOULD expect the peer to send an Authenticate
Request packet. Upon reception of an Authenticate-Request packet
some type of Authenticate reply (described below) MUST
returned
Implementation Note: Because the Authenticate-Ack might
lost, the authenticator MUST allow repeated Authenticate
Request packets after completing the Authentication phase
Protocol phase MUST return the same reply Code returned
the Authentication phase completed (the message portion MAY
different). Any Authenticate-Request packets received
any other phase MUST be silently discarded
When the Authenticate-Nak is lost, and the
terminates the link, the LCP Terminate-Request and Terminate
Ack provide an alternative indication that
failed
A summary of the Authenticate-Request 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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 for Authenticate-Request
The Identifier field is one octet and aids in matching
and replies. The Identifier field MUST be changed each time
Authenticate-Request packet is issued
Lloyd & Simpson [Page 6]
RFC 1334 PPP Authentication October 1992
Peer-ID-
The Peer-ID-Length field is one octet and indicates the length
the Peer-ID field
Peer-
The Peer-ID field is zero or more octets and indicates the name
the peer to be authenticated
Passwd-
The Passwd-Length field is one octet and indicates the length
the Password field
The Password field is zero or more octets and indicates
password to be used for authentication
2.2.2. Authenticate-Ack and Authenticate-
If the Peer-ID/Password pair received in an Authenticate-
is both recognizable and acceptable, then the authenticator
transmit a PAP packet with the Code field set to 2 (Authenticate
Ack).
If the Peer-ID/Password pair received in a Authenticate-Request
not recognizable or acceptable, then the authenticator
transmit a PAP packet with the Code field set to 3 (Authenticate
Nak), and SHOULD take action to terminate the link
A summary of the Authenticate-Ack and Authenticate-Nak packet
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
2 for Authenticate-Ack
Lloyd & Simpson [Page 7]
RFC 1334 PPP Authentication October 1992
3 for Authenticate-Nak
The Identifier field is one octet and aids in matching
and replies. The Identifier field MUST be copied from
Identifier field of the Authenticate-Request which caused
reply
Msg-
The Msg-Length field is one octet and indicates the length of
Message field
The Message field is zero or more octets, and its contents
implementation dependent. It is intended to be human readable
and MUST NOT affect operation of the protocol. It is
that the message contain displayable ASCII characters 32
126 decimal. Mechanisms for extension to other character sets
the topic of future research
3. Challenge-Handshake Authentication
The Challenge-Handshake Authentication Protocol (CHAP) is used
periodically verify the identity of the peer using a 3-way handshake
This is done upon initial link establishment, and MAY be
anytime after the link has been established
After the Link Establishment phase is complete, the
sends a "challenge" message to the peer. The peer responds with
value calculated using a "one-way hash" function. The
checks the response against its own calculation of the expected
value. If the values match, the authentication is acknowledged
otherwise the connection SHOULD be terminated
CHAP provides protection against playback attack through the use
an incrementally changing identifier and a variable challenge value
The use of repeated challenges is intended to limit the time
exposure to any single attack. The authenticator is in control
the frequency and timing of the challenges
This authentication method depends upon a "secret" known only to
authenticator and that peer. The secret is not sent over the link
This method is most likely used where the same secret is
accessed from both ends of the link
Lloyd & Simpson [Page 8]
RFC 1334 PPP Authentication October 1992
Implementation Note: CHAP requires that the secret be available
plaintext form. To avoid sending the secret over other links
the network, it is recommended that the challenge and
values be examined at a central server, rather than each
access server. Otherwise, the secret SHOULD be sent to
servers in a reversably encrypted form
The CHAP algorithm requires that the length of the secret MUST be
least 1 octet. The secret SHOULD be at least as large
unguessable as a well-chosen password. It is preferred that
secret be at least the length of the hash value for the
algorithm chosen (16 octets for MD5). This is to ensure
sufficiently large range for the secret to provide protection
exhaustive search attacks
The one-way hash algorithm is chosen such that it is
infeasible to determine the secret from the known challenge
response values
The challenge value SHOULD satisfy two criteria: uniqueness
unpredictability. Each challenge value SHOULD be unique,
repetition of a challenge value in conjunction with the same
would permit an attacker to reply with a previously
response. Since it is expected that the same secret MAY be used
authenticate with servers in disparate geographic regions,
challenge SHOULD exhibit global and temporal uniqueness.
challenge value SHOULD also be unpredictable, least an attacker
a peer into responding to a predicted future challenge, and then
the response to masquerade as that peer to an authenticator
Although protocols such as CHAP are incapable of protecting
realtime active wiretapping attacks, generation of
unpredictable challenges can protect against a wide range of
attacks
A discussion of sources of uniqueness and probability of
is included in the Magic-Number Configuration Option [1].
3.1. Configuration Option
A summary of the Authentication-Protocol Configuration Option
to negotiate the Challenge-Handshake Authentication Protocol is
below. The fields are transmitted from left to right
Lloyd & Simpson [Page 9]
RFC 1334 PPP Authentication October 1992
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm |
+-+-+-+-+-+-+-+-+
3
5
Authentication-
c223 (hex) for Challenge-Handshake Authentication Protocol
The Algorithm field is one octet and indicates the one-way
method to be used. The most up-to-date values of the
Algorithm field are specified in the most recent "
Numbers" RFC [2]. Current values are assigned as follows
0-4 unused (reserved
5 MD5 [3]
3.2. Packet
Exactly one Challenge-Handshake Authentication Protocol packet
encapsulated in the Information field of a PPP Data Link Layer
where the protocol field indicates type hex c223 (Challenge-
Authentication Protocol). A summary of the CHAP packet format
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 ...
+-+-+-+-+
Lloyd & Simpson [Page 10]
RFC 1334 PPP Authentication October 1992
The Code field is one octet and identifies the type of
packet. CHAP Codes are assigned as follows
1
2
3
4
The Identifier field is one octet and aids in matching challenges
responses and replies
The Length field is two octets and indicates the length of
CHAP packet including the Code, Identifier, Length and
fields. Octets outside the range of the Length field should
treated as Data Link Layer padding and should be ignored
reception
The Data field is zero or more octets. The format of the
field is determined by the Code field
3.2.1. Challenge and
The Challenge packet is used to begin the Challenge-
Authentication Protocol. The authenticator MUST transmit a
packet with the Code field set to 1 (Challenge).
Challenge packets MUST be sent until a valid Response packet
received, or an optional retry counter expires
A Challenge packet MAY also be transmitted at any time during
Network-Layer Protocol phase to ensure that the connection has
been altered
The peer SHOULD expect Challenge packets during the
phase and the Network-Layer Protocol phase. Whenever a
packet is received, the peer MUST transmit a CHAP packet with
Code field set to 2 (Response).
Whenever a Response packet is received, the authenticator
Lloyd & Simpson [Page 11]
RFC 1334 PPP Authentication October 1992
the Response Value with its own calculation of the expected value
Based on this comparison, the authenticator MUST send a Success
Failure packet (described below).
Implementation Note: Because the Success might be lost,
authenticator MUST allow repeated Response packets
completing the Authentication phase. To prevent discovery
alternative Names and Secrets, any Response packets
having the current Challenge Identifier MUST return the
reply Code returned when the Authentication phase
(the message portion MAY be different). Any Response
received during any other phase MUST be silently discarded
When the Failure is lost, and the authenticator terminates
link, the LCP Terminate-Request and Terminate-Ack provide
alternative indication that authentication failed
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 for Challenge
2 for Response
The Identifier field is one octet. The Identifier field MUST
changed each time a Challenge is sent
The Response Identifier MUST be copied from the Identifier
of the Challenge which caused the Response
Value-
This field is one octet and indicates the length of the
field
Lloyd & Simpson [Page 12]
RFC 1334 PPP Authentication October 1992
The Value field is one or more octets. The most significant
is transmitted first
The Challenge Value is a variable stream of octets.
importance of the uniqueness of the Challenge Value and
relationship to the secret is described above. The
Value MUST be changed each time a Challenge is sent. The
of the Challenge Value depends upon the method used to
the octets, and is independent of the hash algorithm used
The Response Value is the one-way hash calculated over a stream
octets consisting of the Identifier, followed by (
with) the "secret", followed by (concatenated with) the
Value. The length of the Response Value depends upon the
algorithm used (16 octets for MD5).
The Name field is one or more octets representing
identification of the system transmitting the packet. There
no limitations on the content of this field. For example, it
contain ASCII character strings or globally unique identifiers
ASN.1 syntax. The Name should not be NUL or CR/LF terminated
The size is determined from the Length field
Since CHAP may be used to authenticate many different systems,
content of the name field(s) may be used as a key to locate
proper secret in a database of secrets. This also makes
possible to support more than one name/secret pair per system
3.2.2. Success and
If the Value received in a Response is equal to the
value, then the implementation MUST transmit a CHAP packet
the Code field set to 3 (Success).
If the Value received in a Response is not equal to the
value, then the implementation MUST transmit a CHAP packet
the Code field set to 4 (Failure), and SHOULD take action
terminate the link
A summary of the Success and Failure packet format is shown below
The fields are transmitted from left to right
Lloyd & Simpson [Page 13]
RFC 1334 PPP Authentication October 1992
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
3 for Success
4 for Failure
The Identifier field is one octet and aids in matching
and replies. The Identifier field MUST be copied from
Identifier field of the Response which caused this reply
The Message field is zero or more octets, and its contents
implementation dependent. It is intended to be human readable
and MUST NOT affect operation of the protocol. It is
that the message contain displayable ASCII characters 32
126 decimal. Mechanisms for extension to other character sets
the topic of future research. The size is determined from
Length field
Security
Security issues are the primary topic of this RFC
The interaction of the authentication protocols within PPP
highly implementation dependent. This is indicated by the use
SHOULD throughout the document
For example, upon failure of authentication, some
do not terminate the link. Instead, the implementation limits
kind of traffic in the Network-Layer Protocols to a
subset, which in turn allows the user opportunity to
secrets or send mail to the network administrator indicating
problem
There is no provision for re-tries of failed authentication
However, the LCP state machine can renegotiate the
protocol at any time, thus allowing a new attempt. It
Lloyd & Simpson [Page 14]
RFC 1334 PPP Authentication October 1992
recommended that any counters used for authentication failure
be reset until after successful authentication, or
termination of the failed link
There is no requirement that authentication be full duplex or
the same protocol be used in both directions. It is
acceptable for different protocols to be used in each direction
This will, of course, depend on the specific protocols negotiated
In practice, within or associated with each PPP server, there is
database which associates "user" names with
information ("secrets"). It is not anticipated that a
named user would be authenticated by multiple methods. This
make the user vulnerable to attacks which negotiate the
secure method from among a set (such as PAP rather than CHAP).
Instead, for each named user there should be an indication
exactly one method used to authenticate that user name. If a
needs to make use of different authentication method
different circumstances, then distinct user names SHOULD
employed, each of which identifies exactly one
method
Passwords and other secrets should be stored at the
ends such that access to them is as limited as possible. Ideally
the secrets should only be accessible to the process
access in order to perform the authentication
The secrets should be distributed with a mechanism that limits
number of entities that handle (and thus gain knowledge of)
secret. Ideally, no unauthorized person should ever
knowledge of the secrets. It is possible to achieve this
SNMP Security Protocols [4], but such a mechanism is outside
scope of this specification
Other distribution methods are currently undergoing research
experimentation. The SNMP Security document also has an
overview of threats to network protocols
[1] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1331,
Daydreamer, May 1992.
[2] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1340,
USC/Information Sciences Institute, July 1992.
Lloyd & Simpson [Page 15]
RFC 1334 PPP Authentication October 1992
[3] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm",
Laboratory for Computer Science and RSA Data Security, Inc.
1321, April 1992.
[4] Galvin, J., McCloghrie, K., and J. Davin, "SNMP
Protocols", Trusted Information Systems, Inc., Hughes
Systems, Inc., MIT Laboratory for Computer Science, RFC 1352,
July 1992.
Some of the text in this document is taken from RFC 1172, by
Perkins of Carnegie Mellon University, and by Russ Hobby of
University of California at Davis
Special thanks to Dave Balenson, Steve Crocker, James Galvin,
Steve Kent, for their extensive explanations and suggestions. Now
if only we could get them to agree with each other
Chair's
The working group can be contacted via the current chair
Brian
Lloyd &
3420 Sudbury
Cameron Park, California 95682
Phone: (916) 676-1147
EMail: brian@lloyd.
Author's
Questions about this memo can also be directed to
William Allen
Computer Systems Consulting
P O Box 6205
East Lansing, MI 48826-6205
EMail: Bill.Simpson@um.cc.umich.
Lloyd & Simpson [Page 16]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
