project cleanup and prepare to release

1 files changed, 0 insertions, 732 deletions

diff --git a/doc/rfc1994.txt b/doc/rfc1994.txt
deleted file mode 100644
index e4a553e..0000000
--- a/doc/rfc1994.txt
+++ /dev/null
@@ -1,732 +0,0 @@
-
-
-
-
-
-
-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]
-
-