added RADIUS, RADIUS-EAP and EAP-MD5 (CHAP) RFCs
This commit is contained in:
parent
857ceac9d9
commit
354242c55a
|
@ -0,0 +1,732 @@
|
|||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group W. Simpson
|
||||
Request for Comments: 1994 DayDreamer
|
||||
Obsoletes: 1334 August 1996
|
||||
Category: Standards Track
|
||||
|
||||
|
||||
PPP Challenge Handshake Authentication Protocol (CHAP)
|
||||
|
||||
|
||||
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, which allows
|
||||
negotiation of an Authentication Protocol for authenticating its peer
|
||||
before allowing Network Layer protocols to transmit over the link.
|
||||
|
||||
This document defines a method for Authentication using PPP, which
|
||||
uses a random Challenge, with a cryptographically hashed Response
|
||||
which depends upon the Challenge and a secret key.
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction .......................................... 1
|
||||
1.1 Specification of Requirements ................... 1
|
||||
1.2 Terminology ..................................... 2
|
||||
2. Challenge-Handshake Authentication Protocol ........... 2
|
||||
2.1 Advantages ...................................... 3
|
||||
2.2 Disadvantages ................................... 3
|
||||
2.3 Design Requirements ............................. 4
|
||||
3. Configuration Option Format ........................... 5
|
||||
4. Packet Format ......................................... 6
|
||||
4.1 Challenge and Response .......................... 7
|
||||
4.2 Success and Failure ............................. 9
|
||||
SECURITY CONSIDERATIONS ...................................... 10
|
||||
ACKNOWLEDGEMENTS ............................................. 11
|
||||
REFERENCES ................................................... 12
|
||||
CONTACTS ..................................................... 12
|
||||
|
||||
|
||||
|
||||
|
||||
Simpson [Page i]
|
||||
|
||||
RFC 1994 PPP CHAP August 1996
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
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 Link Establishment phase. After the link has been
|
||||
established, PPP provides for an optional Authentication phase before
|
||||
proceeding to the Network-Layer Protocol phase.
|
||||
|
||||
By default, authentication is not mandatory. If authentication of
|
||||
the link is desired, an implementation MUST specify the
|
||||
Authentication-Protocol Configuration Option during Link
|
||||
Establishment phase.
|
||||
|
||||
These authentication protocols are intended for use primarily by
|
||||
hosts and routers that connect to a PPP network server via switched
|
||||
circuits or dial-up lines, but might be applied to dedicated links as
|
||||
well. The server can use the identification of the connecting host
|
||||
or router in the selection of options for network layer negotiations.
|
||||
|
||||
This document defines a PPP authentication protocol. The Link
|
||||
Establishment and Authentication phases, and the Authentication-
|
||||
Protocol Configuration Option, are defined in The Point-to-Point
|
||||
Protocol (PPP) [1].
|
||||
|
||||
|
||||
1.1. Specification of 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 exist valid reasons in particular circumstances to
|
||||
ignore this item, but the full implications must 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 be
|
||||
prepared to interoperate with another implementation which
|
||||
does include the option.
|
||||
|
||||
|
||||
|
||||
|
||||
Simpson [Page 1]
|
||||
|
||||
RFC 1994 PPP CHAP August 1996
|
||||
|
||||
|
||||
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 end which is
|
||||
being authenticated by the authenticator.
|
||||
|
||||
silently discard
|
||||
This means the implementation discards the packet without
|
||||
further processing. 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. Challenge-Handshake Authentication Protocol
|
||||
|
||||
The Challenge-Handshake Authentication Protocol (CHAP) is used to
|
||||
periodically verify the identity of the peer using a 3-way handshake.
|
||||
This is done upon initial link establishment, and MAY be repeated
|
||||
anytime after the link has been established.
|
||||
|
||||
1. After the Link Establishment phase is complete, the
|
||||
authenticator sends a "challenge" message to the peer.
|
||||
|
||||
2. The peer responds with a value calculated using a "one-way
|
||||
hash" function.
|
||||
|
||||
3. The authenticator checks the response against its own
|
||||
calculation of the expected hash value. If the values match,
|
||||
the authentication is acknowledged; otherwise the connection
|
||||
SHOULD be terminated.
|
||||
|
||||
4. At random intervals, the authenticator sends a new challenge to
|
||||
the peer, and repeats steps 1 to 3.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Simpson [Page 2]
|
||||
|
||||
RFC 1994 PPP CHAP August 1996
|
||||
|
||||
|
||||
2.1. Advantages
|
||||
|
||||
CHAP provides protection against playback attack by the peer through
|
||||
the use of an incrementally changing identifier and a variable
|
||||
challenge value. The use of repeated challenges is intended to limit
|
||||
the time of exposure to any single attack. The authenticator is in
|
||||
control of the frequency and timing of the challenges.
|
||||
|
||||
This authentication method depends upon a "secret" known only to the
|
||||
authenticator and that peer. The secret is not sent over the link.
|
||||
|
||||
Although the authentication is only one-way, by negotiating CHAP in
|
||||
both directions the same secret set may easily be used for mutual
|
||||
authentication.
|
||||
|
||||
Since CHAP may be used to authenticate many different systems, name
|
||||
fields may be used as an index to locate the proper secret in a large
|
||||
table of secrets. This also makes it possible to support more than
|
||||
one name/secret pair per system, and to change the secret in use at
|
||||
any time during the session.
|
||||
|
||||
|
||||
2.2. Disadvantages
|
||||
|
||||
CHAP requires that the secret be available in plaintext form.
|
||||
Irreversably encrypted password databases commonly available cannot
|
||||
be used.
|
||||
|
||||
It is not as useful for large installations, since every possible
|
||||
secret is maintained at both ends of the link.
|
||||
|
||||
Implementation Note: To avoid sending the secret over other links
|
||||
in the network, it is recommended that the challenge and response
|
||||
values be examined at a central server, rather than each network
|
||||
access server. Otherwise, the secret SHOULD be sent to such
|
||||
servers in a reversably encrypted form. Either case requires a
|
||||
trusted relationship, which is outside the scope of this
|
||||
specification.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Simpson [Page 3]
|
||||
|
||||
RFC 1994 PPP CHAP August 1996
|
||||
|
||||
|
||||
2.3. Design Requirements
|
||||
|
||||
The CHAP algorithm requires that the length of the secret MUST be at
|
||||
least 1 octet. The secret SHOULD be at least as large and
|
||||
unguessable as a well-chosen password. It is preferred that the
|
||||
secret be at least the length of the hash value for the hashing
|
||||
algorithm chosen (16 octets for MD5). This is to ensure a
|
||||
sufficiently large range for the secret to provide protection against
|
||||
exhaustive search attacks.
|
||||
|
||||
The one-way hash algorithm is chosen such that it is computationally
|
||||
infeasible to determine the secret from the known challenge and
|
||||
response values.
|
||||
|
||||
Each challenge value SHOULD be unique, since repetition of a
|
||||
challenge value in conjunction with the same secret would permit an
|
||||
attacker to reply with a previously intercepted response. Since it
|
||||
is expected that the same secret MAY be used to authenticate with
|
||||
servers in disparate geographic regions, the challenge SHOULD exhibit
|
||||
global and temporal uniqueness.
|
||||
|
||||
Each challenge value SHOULD also be unpredictable, least an attacker
|
||||
trick a peer into responding to a predicted future challenge, and
|
||||
then use the response to masquerade as that peer to an authenticator.
|
||||
|
||||
Although protocols such as CHAP are incapable of protecting against
|
||||
realtime active wiretapping attacks, generation of unique
|
||||
unpredictable challenges can protect against a wide range of active
|
||||
attacks.
|
||||
|
||||
A discussion of sources of uniqueness and probability of divergence
|
||||
is included in the Magic-Number Configuration Option [1].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Simpson [Page 4]
|
||||
|
||||
RFC 1994 PPP CHAP August 1996
|
||||
|
||||
|
||||
3. 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.
|
||||
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| Type | Length | Authentication-Protocol |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| Algorithm |
|
||||
+-+-+-+-+-+-+-+-+
|
||||
|
||||
Type
|
||||
|
||||
3
|
||||
|
||||
Length
|
||||
|
||||
5
|
||||
|
||||
Authentication-Protocol
|
||||
|
||||
c223 (hex) for Challenge-Handshake Authentication Protocol.
|
||||
|
||||
Algorithm
|
||||
|
||||
The Algorithm field is one octet and indicates the authentication
|
||||
method to be used. Up-to-date values are specified in the most
|
||||
recent "Assigned Numbers" [2]. One value is required to be
|
||||
implemented:
|
||||
|
||||
5 CHAP with MD5 [3]
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Simpson [Page 5]
|
||||
|
||||
RFC 1994 PPP CHAP August 1996
|
||||
|
||||
|
||||
4. Packet Format
|
||||
|
||||
Exactly one Challenge-Handshake Authentication Protocol packet is
|
||||
encapsulated in the Information field of a PPP Data Link Layer frame
|
||||
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.
|
||||
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| 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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Simpson [Page 6]
|
||||
|
||||
RFC 1994 PPP CHAP August 1996
|
||||
|
||||
|
||||
4.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). Additional
|
||||
Challenge packets MUST be sent 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 MUST send a Success or
|
||||
Failure packet (described below).
|
||||
|
||||
Implementation Notes: Because the Success might be lost, the
|
||||
authenticator MUST allow repeated Response packets during the
|
||||
Network-Layer Protocol phase after completing the
|
||||
Authentication phase. To prevent discovery of alternative
|
||||
Names and Secrets, any Response packets received having the
|
||||
current Challenge Identifier MUST return the same reply Code
|
||||
previously returned for that specific Challenge (the message
|
||||
portion MAY be different). Any Response packets received
|
||||
during any other phase MUST be silently discarded.
|
||||
|
||||
When the Failure is lost, and the authenticator terminates the
|
||||
link, the LCP Terminate-Request and Terminate-Ack provide an
|
||||
alternative indication that authentication failed.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Simpson [Page 7]
|
||||
|
||||
RFC 1994 PPP CHAP August 1996
|
||||
|
||||
|
||||
A summary of the Challenge and Response packet format is shown below.
|
||||
The fields are transmitted from left to right.
|
||||
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| 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 sent.
|
||||
|
||||
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 variable stream of octets. The
|
||||
importance of the uniqueness of the Challenge Value and its
|
||||
relationship to the secret is described above. The Challenge
|
||||
Value MUST be changed each time a Challenge is sent. The length
|
||||
of the Challenge Value depends upon the method used to generate
|
||||
the octets, and is independent of the hash algorithm used.
|
||||
|
||||
The Response Value is the one-way hash calculated over a stream of
|
||||
octets consisting of the Identifier, followed by (concatenated
|
||||
with) the "secret", followed by (concatenated with) the Challenge
|
||||
Value. The length of the Response Value depends upon the hash
|
||||
algorithm used (16 octets for MD5).
|
||||
|
||||
|
||||
|
||||
|
||||
Simpson [Page 8]
|
||||
|
||||
RFC 1994 PPP CHAP August 1996
|
||||
|
||||
|
||||
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. For example, it MAY
|
||||
contain ASCII character strings or globally unique identifiers in
|
||||
ASN.1 syntax. The Name should not be NUL or CR/LF terminated.
|
||||
The size is determined from the Length field.
|
||||
|
||||
|
||||
4.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 MUST transmit a CHAP packet with
|
||||
the Code field set to 4 (Failure), and SHOULD 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.
|
||||
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| 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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Simpson [Page 9]
|
||||
|
||||
RFC 1994 PPP CHAP August 1996
|
||||
|
||||
|
||||
Message
|
||||
|
||||
The Message field is zero or more octets, and its contents are
|
||||
implementation dependent. It is intended to be human readable,
|
||||
and MUST NOT affect operation of the protocol. It is recommended
|
||||
that the message contain displayable ASCII characters 32 through
|
||||
126 decimal. Mechanisms for extension to other character sets are
|
||||
the topic of future research. The size is determined from the
|
||||
Length field.
|
||||
|
||||
|
||||
|
||||
Security Considerations
|
||||
|
||||
Security issues are the primary topic of this RFC.
|
||||
|
||||
The interaction of the authentication protocols within PPP are highly
|
||||
implementation dependent. This is indicated by the use of SHOULD
|
||||
throughout the document.
|
||||
|
||||
For example, upon failure of authentication, some implementations do
|
||||
not terminate the link. Instead, the implementation limits the kind
|
||||
of traffic in the Network-Layer Protocols to a filtered subset, which
|
||||
in turn allows the user opportunity to update secrets or send mail to
|
||||
the network administrator indicating a problem.
|
||||
|
||||
There is no provision for re-tries of failed authentication.
|
||||
However, the LCP state machine can renegotiate the authentication
|
||||
protocol at any time, thus allowing a new attempt. It is recommended
|
||||
that any counters used for authentication failure not be reset until
|
||||
after successful authentication, or subsequent termination of the
|
||||
failed link.
|
||||
|
||||
There is no requirement that authentication be full duplex or that
|
||||
the same protocol be used in both directions. It is perfectly
|
||||
acceptable for different protocols to be used in each direction.
|
||||
This will, of course, depend on the specific protocols negotiated.
|
||||
|
||||
The secret SHOULD NOT be the same in both directions. This allows an
|
||||
attacker to replay the peer's challenge, accept the computed
|
||||
response, and use that response to authenticate.
|
||||
|
||||
In practice, within or associated with each PPP server, there is a
|
||||
database which associates "user" names with authentication
|
||||
information ("secrets"). It is not anticipated that a particular
|
||||
named user would be authenticated by multiple methods. This would
|
||||
make the user vulnerable to attacks which negotiate the least secure
|
||||
method from among a set (such as PAP rather than CHAP). If the same
|
||||
|
||||
|
||||
|
||||
Simpson [Page 10]
|
||||
|
||||
RFC 1994 PPP CHAP August 1996
|
||||
|
||||
|
||||
secret was used, PAP would reveal the secret to be used later with
|
||||
CHAP.
|
||||
|
||||
Instead, for each user name there should be an indication of exactly
|
||||
one method used to authenticate that user name. If a user needs to
|
||||
make use of different authentication methods under different
|
||||
circumstances, then distinct user names SHOULD be employed, each of
|
||||
which identifies exactly one authentication method.
|
||||
|
||||
Passwords and other secrets should be stored at the respective ends
|
||||
such that access to them is as limited as possible. Ideally, the
|
||||
secrets should only be accessible to the process requiring access in
|
||||
order to perform the authentication.
|
||||
|
||||
The secrets should be distributed with a mechanism that limits the
|
||||
number of entities that handle (and thus gain knowledge of) the
|
||||
secret. Ideally, no unauthorized person should ever gain knowledge
|
||||
of the secrets. Such a mechanism is outside the scope of this
|
||||
specification.
|
||||
|
||||
|
||||
Acknowledgements
|
||||
|
||||
David Kaufman, Frank Heinrich, and Karl Auerbach used a challenge
|
||||
handshake at SDC when designing one of the protocols for a "secure"
|
||||
network in the mid-1970s. Tom Bearson built a prototype Sytek
|
||||
product ("Poloneous"?) on the challenge-response notion in the 1982-
|
||||
83 timeframe. Another variant is documented in the various IBM SNA
|
||||
manuals. Yet another variant was implemented by Karl Auerbach in the
|
||||
Telebit NetBlazer circa 1991.
|
||||
|
||||
Kim Toms and Barney Wolff provided useful critiques of earlier
|
||||
versions of this document.
|
||||
|
||||
Special thanks to Dave Balenson, Steve Crocker, James Galvin, and
|
||||
Steve Kent, for their extensive explanations and suggestions. Now,
|
||||
if only we could get them to agree with each other.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Simpson [Page 11]
|
||||
|
||||
RFC 1994 PPP CHAP August 1996
|
||||
|
||||
|
||||
References
|
||||
|
||||
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
|
||||
51, RFC 1661, DayDreamer, July 1994.
|
||||
|
||||
[2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
|
||||
1700, USC/Information Sciences Institute, October 1994.
|
||||
|
||||
[3] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm",
|
||||
MIT Laboratory for Computer Science and RSA Data Security,
|
||||
Inc., RFC 1321, April 1992.
|
||||
|
||||
|
||||
|
||||
Contacts
|
||||
|
||||
Comments should be submitted to the ietf-ppp@merit.edu mailing list.
|
||||
|
||||
This document was reviewed by the Point-to-Point Protocol Working
|
||||
Group of the Internet Engineering Task Force (IETF). The working
|
||||
group can be contacted via the current chair:
|
||||
|
||||
Karl Fox
|
||||
Ascend Communications
|
||||
3518 Riverside Drive, Suite 101
|
||||
Columbus, Ohio 43221
|
||||
|
||||
karl@MorningStar.com
|
||||
karl@Ascend.com
|
||||
|
||||
|
||||
Questions about this memo can also be directed to:
|
||||
|
||||
William Allen Simpson
|
||||
DayDreamer
|
||||
Computer Systems Consulting Services
|
||||
1384 Fontaine
|
||||
Madison Heights, Michigan 48071
|
||||
|
||||
wsimpson@UMich.edu
|
||||
wsimpson@GreenDragon.com (preferred)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Simpson [Page 12]
|
||||
|
||||
|
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
Loading…
Reference in New Issue