rfc2865.txt

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


RFC 2865                         RADIUS                        June 2000


   A summary of the Access-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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                     Request Authenticator                     |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attributes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

   Code

      1 for Access-Request.

   Identifier

      The Identifier field MUST be changed whenever the content of the
      Attributes field changes, and whenever a valid reply has been
      received for a previous request.  For retransmissions, the
      Identifier MUST remain unchanged.

   Request Authenticator

      The Request Authenticator value MUST be changed each time a new
      Identifier is used.

   Attributes

      The Attribute field is variable in length, and contains the list
      of Attributes that are required for the type of service, as well
      as any desired optional Attributes.

4.2.  Access-Accept

   Description

      Access-Accept packets are sent by the RADIUS server, and provide
      specific configuration information necessary to begin delivery of
      service to the user.  If all Attribute values received in an
      Access-Request are acceptable then the RADIUS implementation MUST
      transmit a packet with the Code field set to 2 (Access-Accept).




Rigney, et al.              Standards Track                    [Page 18]

RFC 2865                         RADIUS                        June 2000


      On reception of an Access-Accept, the Identifier field is matched
      with a pending Access-Request.  The Response Authenticator field
      MUST contain the correct response for the pending Access-Request.
      Invalid packets are silently discarded.

   A summary of the Access-Accept 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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                     Response Authenticator                    |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attributes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

   Code

      2 for Access-Accept.

   Identifier

      The Identifier field is a copy of the Identifier field of the
      Access-Request which caused this Access-Accept.

   Response Authenticator

      The Response Authenticator value is calculated from the Access-
      Request value, as described earlier.

   Attributes

      The Attribute field is variable in length, and contains a list of
      zero or more Attributes.












Rigney, et al.              Standards Track                    [Page 19]

RFC 2865                         RADIUS                        June 2000


4.3.  Access-Reject

   Description

      If any value of the received Attributes is not acceptable, then
      the RADIUS server MUST transmit a packet with the Code field set
      to 3 (Access-Reject).  It MAY include one or more Reply-Message
      Attributes with a text message which the NAS MAY display to the
      user.

   A summary of the Access-Reject 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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                     Response Authenticator                    |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attributes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

   Code

      3 for Access-Reject.

   Identifier

      The Identifier field is a copy of the Identifier field of the
      Access-Request which caused this Access-Reject.

   Response Authenticator

      The Response Authenticator value is calculated from the Access-
      Request value, as described earlier.

   Attributes

      The Attribute field is variable in length, and contains a list of
      zero or more Attributes.







Rigney, et al.              Standards Track                    [Page 20]

RFC 2865                         RADIUS                        June 2000


4.4.  Access-Challenge

   Description

      If the RADIUS server desires to send the user a challenge
      requiring a response, then the RADIUS server MUST respond to the
      Access-Request by transmitting a packet with the Code field set to
      11 (Access-Challenge).

      The Attributes field MAY have one or more Reply-Message
      Attributes, and MAY have a single State Attribute, or none.
      Vendor-Specific, Idle-Timeout, Session-Timeout and Proxy-State
      attributes MAY also be included.  No other Attributes defined in
      this document are permitted in an Access-Challenge.

      On receipt of an Access-Challenge, the Identifier field is matched
      with a pending Access-Request.  Additionally, the Response
      Authenticator field MUST contain the correct response for the
      pending Access-Request.  Invalid packets are silently discarded.

      If the NAS does not support challenge/response, it MUST treat an
      Access-Challenge as though it had received an Access-Reject
      instead.

      If the NAS supports challenge/response, receipt of a valid
      Access-Challenge indicates that a new Access-Request SHOULD be
      sent.  The NAS MAY display the text message, if any, to the user,
      and then prompt the user for a response.  It then sends its
      original Access-Request with a new request ID and Request
      Authenticator, with the User-Password Attribute replaced by the
      user's response (encrypted), and including the State Attribute
      from the Access-Challenge, if any.  Only 0 or 1 instances of the
      State Attribute can be present in an Access-Request.

      A NAS which supports PAP MAY forward the Reply-Message to the
      dialing client and accept a PAP response which it can use as
      though the user had entered the response.  If the NAS cannot do
      so, it MUST treat the Access-Challenge as though it had received
      an Access-Reject instead.












Rigney, et al.              Standards Track                    [Page 21]

RFC 2865                         RADIUS                        June 2000


   A summary of the Access-Challenge 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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                     Response Authenticator                    |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attributes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

   Code

      11 for Access-Challenge.

   Identifier

      The Identifier field is a copy of the Identifier field of the
      Access-Request which caused this Access-Challenge.

   Response Authenticator

      The Response Authenticator value is calculated from the Access-
      Request value, as described earlier.

   Attributes

      The Attributes field is variable in length, and contains a list of
      zero or more Attributes.

5.  Attributes

   RADIUS Attributes carry the specific authentication, authorization,
   information and configuration details for the request and reply.

   The end of the list of Attributes is indicated by the Length of the
   RADIUS packet.

   Some Attributes MAY be included more than once.  The effect of this
   is Attribute specific, and is specified in each Attribute
   description.  A summary table is provided at the end of the
   "Attributes" section.




Rigney, et al.              Standards Track                    [Page 22]

RFC 2865                         RADIUS                        June 2000


   If multiple Attributes with the same Type are present, the order of
   Attributes with the same Type MUST be preserved by any proxies.  The
   order of Attributes of different Types is not required to be
   preserved.  A RADIUS server or client MUST NOT have any dependencies
   on the order of attributes of different types.  A RADIUS server or
   client MUST NOT require attributes of the same type to be contiguous.

   Where an Attribute's description limits which kinds of packet it can
   be contained in, this applies only to the packet types defined in
   this document, namely Access-Request, Access-Accept, Access-Reject
   and Access-Challenge (Codes 1, 2, 3, and 11).  Other documents
   defining other packet types may also use Attributes described here.
   To determine which Attributes are allowed in Accounting-Request and
   Accounting-Response packets (Codes 4 and 5) refer to the RADIUS
   Accounting document [5].

   Likewise where packet types defined here state that only certain
   Attributes are permissible in them, future memos defining new
   Attributes should indicate which packet types the new Attributes may
   be present in.

   A summary of the Attribute format is shown below.  The fields are
   transmitted from left to right.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |     Type      |    Length     |  Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Type

      The Type field is one octet.  Up-to-date values of the RADIUS Type
      field are specified in the most recent "Assigned Numbers" RFC [6].