rfc1334.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 899 行 · 第 1/3 页

         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