project cleanup and prepare to release

1 files changed, 0 insertions, 899 deletions

diff --git a/doc/rfc1334.txt b/doc/rfc1334.txt
deleted file mode 100644
index 6051f480..00000000
--- a/doc/rfc1334.txt
+++ /dev/null
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           B. Lloyd
-Request for Comments: 1334                                           L&A
-                                                              W. Simpson
-                                                              Daydreamer
-                                                            October 1992
-
-
-                      PPP Authentication Protocols
-
-Status of this Memo
-
-   This RFC specifies an IAB standards track protocol for the Internet
-   community, and requests discussion and suggestions for improvements.
-   Please refer to the current edition of the "IAB Official Protocol
-   Standards" 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 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 Password
-   Authentication Protocol and the Challenge-Handshake Authentication
-   Protocol.  This memo 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.
-
-Table of Contents
-
-   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.  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 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 the PPP authentication protocols.  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 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.
-
-
-
-Lloyd & Simpson                                                 [Page 2]
-
-RFC 1334                   PPP Authentication               October 1992
-
-
-   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 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 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 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.  Password Authentication Protocol
-
-   The Password Authentication Protocol (PAP) provides a simple method
-   for the peer to establish its identity using a 2-way handshake.  This
-   is done only upon initial link establishment.
-
-   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
-
-
-
-Lloyd & Simpson                                                 [Page 3]
-
-RFC 1334                   PPP Authentication               October 1992
-
-
-   or repeated trial and error attacks.  The peer is in control of the
-   frequency and timing of the attempts.
-
-   Any implementations which include a stronger authentication method
-   (such as CHAP, described below) MUST offer to negotiate that method
-   prior to PAP.
-
-   This authentication method is most appropriately used where a
-   plaintext password must be available to simulate a login at a remote
-   host.  In such use, this method provides a similar level of security
-   to the usual user login at the remote host.
-
-      Implementation Note: It is possible to limit the exposure of the
-      plaintext password to transmission over the PPP link, and avoid
-      sending the plaintext password over the entire network.  When the
-      remote host password is kept as a one-way transformed value, and
-      the algorithm for the transform function is implemented in the
-      local server, the plaintext password SHOULD be locally transformed
-      before comparison with the transformed password from the remote
-      host.
-
-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]
-
-RFC 1334                   PPP Authentication               October 1992
-
-
-2.2.  Packet Format
-
-   Exactly one Password Authentication Protocol packet is encapsulated
-   in the Information field of a PPP Data Link Layer frame 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-Request
-         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.
-
-2.2.1.  Authenticate-Request
-
-   Description
-
-      The Authenticate-Request packet is used to begin the Password
-      Authentication Protocol.  The link peer MUST transmit a PAP packet
-
-
-
-Lloyd & Simpson                                                 [Page 5]
-
-RFC 1334                   PPP Authentication               October 1992
-
-
-      with the Code field set to 1 (Authenticate-Request) during the
-      Authentication phase.  The Authenticate-Request 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-
-      Request packet.  Upon reception of an Authenticate-Request packet,
-      some type of Authenticate reply (described below) MUST be
-      returned.
-
-         Implementation Note: Because the Authenticate-Ack might be
-         lost, the authenticator MUST allow repeated Authenticate-
-         Request packets after completing the Authentication phase.
-         Protocol phase MUST return the same reply Code returned when
-         the Authentication phase completed (the message portion MAY be
-         different).  Any Authenticate-Request packets received during
-         any other phase MUST be silently discarded.
-
-         When the Authenticate-Nak is lost, and the authenticator
-         terminates the link, the LCP Terminate-Request and Terminate-
-         Ack provide an alternative indication that authentication
-         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  ...
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   Code
-
-      1 for Authenticate-Request.
-
-   Identifier
-
-      The Identifier field is one octet and aids in matching requests
-      and replies.  The Identifier field MUST be changed each time an
-      Authenticate-Request packet is issued.
-
-
-
-
-
-
-Lloyd & Simpson                                                 [Page 6]
-
-RFC 1334                   PPP Authentication               October 1992
-
-
-   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.
-
-2.2.2.  Authenticate-Ack and Authenticate-Nak
-
-   Description
-
-      If the Peer-ID/Password pair received in an Authenticate-Request
-      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-Request is
-      not recognizable or acceptable, then the authenticator MUST
-      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 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;
-
-
-
-Lloyd & Simpson                                                 [Page 7]
-
-RFC 1334                   PPP Authentication               October 1992
-
-
-      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-Request 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 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.
-
-3.  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.
-
-   After the Link Establishment phase is complete, the authenticator
-   sends a "challenge" message to the peer.  The peer responds with a
-   value calculated using a "one-way hash" function.  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.
-
-   CHAP provides protection against playback attack 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.
-   This method is most likely used where the same secret is easily
-   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 in
-      plaintext form.  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.
-
-   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.
-
-   The challenge value SHOULD satisfy two criteria: uniqueness and
-   unpredictability.  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].
-
-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.
-
-
-
-
-
-
-
-
-
-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   |
-   +-+-+-+-+-+-+-+-+
-
-   Type
-
-      3
-
-   Length
-
-      5
-
-   Authentication-Protocol
-
-      c223 (hex) for Challenge-Handshake Authentication Protocol.
-
-   Algorithm
-
-      The Algorithm field is one octet and indicates the one-way hash
-      method to be used.  The most up-to-date values of the CHAP
-      Algorithm field are specified in the most recent "Assigned
-      Numbers" RFC [2].  Current values are assigned as follows:
-
-         0-4     unused (reserved)
-         5       MD5 [3]
-
-3.2.  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.
-
-    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
-
-
-   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.
-
-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).  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
-
-
-
-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 or
-      Failure packet (described below).
-
-         Implementation Note: Because the Success might be lost, the
-         authenticator MUST allow repeated Response packets 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 returned when the Authentication phase completed
-         (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.
-
-   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 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.
-
-
-
-Lloyd & Simpson                                                [Page 12]
-
-RFC 1334                   PPP Authentication               October 1992
-
-
-   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).
-
-   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.
-
-      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.
-
-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 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.
-
-
-
-
-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  ...
-   +-+-+-+-+-+-+-+-+-+-+-+-+-
-
-   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, 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
-
-
-
-Lloyd & Simpson                                                [Page 14]
-
-RFC 1334                   PPP Authentication               October 1992
-
-
-      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.
-
-      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).
-      Instead, for each named user 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 method 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.  It is possible to achieve this with
-      SNMP Security Protocols [4], but such a mechanism is outside the
-      scope of this specification.
-
-      Other distribution methods are currently undergoing research and
-      experimentation.  The SNMP Security document also has an excellent
-      overview of threats to network protocols.
-
-References
-
-   [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", MIT
-       Laboratory for Computer Science and RSA Data Security, Inc.  RFC
-       1321, April 1992.
-
-   [4] Galvin, J., McCloghrie, K., and J. Davin, "SNMP Security
-       Protocols", Trusted Information Systems, Inc., Hughes LAN
-       Systems, Inc., MIT Laboratory for Computer Science, RFC 1352,
-       July 1992.
-
-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, James Galvin, and
-   Steve Kent, for their extensive explanations and suggestions.  Now,
-   if only we could get them to agree with each other.
-
-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@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-6205
-
-      EMail: Bill.Simpson@um.cc.umich.edu
-
-
-
-
-
-
-
-
-Lloyd & Simpson                                                [Page 16]
-
\ No newline at end of file