rfc5176.txt

使用最广泛的radius的linux的源码

   or Acct-Multi-Session-Id Attribute within an Access-Request.  Where
   an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not included
   within an Access-Request, the Dynamic Authorization Client will not
   know the Acct-Session-Id or Acct-Multi-Session-Id of the session it
   is attempting to target, unless it also has access to the accounting
   data for that session.

   Where an Acct-Session-Id or Acct-Multi-Session-Id Attribute is not
   present in a CoA-Request or Disconnect-Request, it is possible that
   the User-Name or Chargeable-User-Identity attributes will not be
   sufficient to uniquely identify a single session (e.g., if the same
   user has multiple sessions on the NAS, or if the privacy NAI is
   used).  In this case, if it is desired to identify a single session,
   session identification MAY be performed by using one or more of the
   Framed-IP-Address, Framed-IPv6-Prefix/Framed-Interface-Id, Called-
   Station-Id, Calling-Station-Id, NAS-Port, and NAS-Port-Id attributes.



Chiba, et al.                Informational                     [Page 11]

RFC 5176       Dynamic Authorization Extensions to RADIUS   January 2008


   To assist RADIUS proxies in routing Request packets to their
   destination, one or more of the NAS-IP-Address or NAS-IPv6-Address
   attributes SHOULD be present in CoA-Request and Disconnect-Request
   packets; the NAS-Identifier Attribute MAY be present.  Impersonation
   issues with NAS Identification attributes are discussed in [RFC3579],
   Section 4.3.7.

   A Disconnect-Request MUST contain only NAS and session identification
   attributes.  If other attributes are included in a Disconnect-
   Request, implementations MUST send a Disconnect-NAK; an Error-Cause
   Attribute with value "Unsupported Attribute" MAY be included.

   The DAC may require access to data from RADIUS authentication or
   accounting packets.  It uses this data to compose compliant CoA-
   Request or Disconnect-Request packets.  For example, as described in
   Section 3.3, a CoA-Request packet containing a Service-Type Attribute
   with a value of "Authorize Only" is required to contain a State
   Attribute.  The NAS will subsequently transmit this attribute to the
   RADIUS server in an Access-Request.  In order for the DAC to include
   a State Attribute that the RADIUS server will subsequently accept,
   some coordination between the two parties may be required.

   This coordination can be achieved in multiple ways.  The DAC may be
   co-located with a RADIUS server, in which case it is presumed to have
   access to the necessary data.  The RADIUS server may also store that
   information in a common database.  The DAC can then be separated from
   the RADIUS server, so long as it has access to that common database.

   Where the DAC is not co-located with a RADIUS server, and does not
   have access to a common database, the DAC SHOULD send CoA-Request or
   Disconnect-Request packets to a RADIUS server acting as a proxy,
   rather than sending them directly to the NAS.

   A RADIUS server receiving a CoA-Request or Disconnect-Request packet
   from the DAC MAY then add or update attributes (such as adding NAS or
   session identification attributes or appending a State Attribute),
   prior to forwarding the packet.  Having CoA/Disconnect-Requests
   forwarded by a RADIUS server can also enable upstream RADIUS proxies
   to perform a Reverse Path Forwarding (RPF) check (see Section 6.1).

3.1.  Proxy State

   If there are any Proxy-State attributes in a Disconnect-Request or
   CoA-Request received from the Dynamic Authorization Client, the
   Dynamic Authorization Server MUST include those Proxy-State
   attributes in its response to the Dynamic Authorization Client.





Chiba, et al.                Informational                     [Page 12]

RFC 5176       Dynamic Authorization Extensions to RADIUS   January 2008


   A forwarding proxy or NAS MUST NOT modify existing Proxy-State,
   State, or Class attributes present in the packet.  The forwarding
   proxy or NAS MUST treat any Proxy-State attributes already in the
   packet as opaque data.  Its operation MUST NOT depend on the content
   of Proxy-State attributes added by previous proxies.  The forwarding
   proxy MUST NOT modify any other Proxy-State attributes that were in
   the packet; it may choose not to forward them, but it MUST NOT change
   their contents.  If the forwarding proxy omits the Proxy-State
   attributes in the request, it MUST attach them to the response before
   sending it.

   When the proxy forwards a Disconnect-Request or CoA-Request, it MAY
   add a Proxy-State Attribute, but it MUST NOT add more than one.  If a
   Proxy-State Attribute is added to a packet when forwarding the
   packet, the Proxy-State Attribute MUST be added after any existing
   Proxy-State attributes.  The forwarding proxy MUST NOT change the
   order of any attributes of the same type, including Proxy-State.
   Other attributes can be placed before, after, or even between the
   Proxy-State attributes.

   When the proxy receives a response to a CoA-Request or Disconnect-
   Request, it MUST remove its own Proxy-State Attribute (the last
   Proxy-State in the packet) before forwarding the response.  Since
   Disconnect and CoA responses are authenticated on the entire packet
   contents, the stripping of the Proxy-State Attribute invalidates the
   integrity check, so the proxy MUST recompute it.

3.2.  Authorize Only

   To simplify translation between RADIUS and Diameter, Dynamic
   Authorization Clients can include a Service-Type Attribute with value
   "Authorize Only" within a CoA-Request; see Section 4 for details on
   Diameter considerations.  Support for a CoA-Request including a
   Service-Type Attribute with value "Authorize Only" is OPTIONAL on the
   NAS and Dynamic Authorization Client.  A Service-Type Attribute MUST
   NOT be included within a Disconnect-Request.

   A NAS MUST respond to a CoA-Request including a Service-Type
   Attribute with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST
   NOT be sent.  If the NAS does not support a Service-Type value of
   "Authorize Only", then it MUST respond with a CoA-NAK; an Error-Cause
   Attribute with a value of 405 (Unsupported Service) SHOULD be
   included.

   A CoA-Request containing a Service-Type Attribute with value
   "Authorize Only" MUST in addition contain only NAS or session
   identification attributes, as well as a State Attribute.  If other




Chiba, et al.                Informational                     [Page 13]

RFC 5176       Dynamic Authorization Extensions to RADIUS   January 2008


   attributes are included in such a CoA-Request, a CoA-NAK MUST be
   sent; an Error-Cause Attribute with value 401 (Unsupported Attribute)
   SHOULD be included.

   If a CoA-Request packet including a Service-Type value of "Authorize
   Only" is successfully processed, the NAS MUST respond with a CoA-NAK
   containing a Service-Type Attribute with value "Authorize Only", and
   an Error-Cause Attribute with value 507 (Request Initiated).  The NAS
   then MUST send an Access-Request to the RADIUS server including a
   Service-Type Attribute with value "Authorize Only", along with a
   State Attribute.  This Access-Request SHOULD contain the NAS
   identification attributes from the CoA-Request, as well as the
   session identification attributes from the CoA-Request permitted in
   an Access-Request; it also MAY contain other attributes permitted in
   an Access-Request.

   As noted in [RFC2869], Section 5.19, a Message-Authenticator
   attribute SHOULD be included in an Access-Request that does not
   contain a User-Password, CHAP-Password, ARAP-Password, or EAP-Message
   Attribute.  The RADIUS server then will respond to the Access-Request
   with an Access-Accept to (re-)authorize the session or an Access-
   Reject to refuse to (re-)authorize it.

3.3.  State

   The State Attribute is available to be sent by the Dynamic
   Authorization Client to the NAS in a CoA-Request packet and MUST be
   sent unmodified from the NAS to the Dynamic Authorization Client in a
   subsequent ACK or NAK packet.

   [RFC2865], Section 5.44 states:

      An Access-Request MUST contain either a User-Password or a
      CHAP-Password or State.  An Access-Request MUST NOT contain both a
      User-Password and a CHAP-Password.  If future extensions allow
      other kinds of authentication information to be conveyed, the
      attribute for that can be used in an Access-Request instead of
      User-Password or CHAP-Password.

   In order to satisfy the requirements of [RFC2865], Section 5.44, an
   Access-Request with Service-Type Attribute with value "Authorize
   Only" MUST contain a State Attribute.

   In order to provide a State Attribute to the NAS, a Dynamic
   Authorization Client sending a CoA-Request with a Service-Type
   Attribute with a value of "Authorize Only" MUST include a State
   Attribute, and the NAS MUST send the State Attribute unmodified to
   the RADIUS server in the resulting Access-Request, if any.  A NAS



Chiba, et al.                Informational                     [Page 14]

RFC 5176       Dynamic Authorization Extensions to RADIUS   January 2008


   receiving a CoA-Request containing a Service-Type Attribute with a
   value of "Authorize Only" but lacking a State Attribute MUST send a
   CoA-NAK and SHOULD include an Error-Cause Attribute with a value of
   402 (Missing Attribute).

   The State Attribute is also available to be sent by the Dynamic
   Authorization Client to the NAS in a CoA-Request that also includes a
   Termination-Action Attribute with the value of RADIUS-Request.  If
   the NAS performs the Termination-Action by sending a new Access-
   Request upon termination of the current session, it MUST include the
   State Attribute unchanged in that Access-Request.  In either usage,
   the Dynamic Authorization Server MUST NOT interpret the Attribute
   locally.  A CoA-Request packet MUST have only zero or one State
   Attribute.  Usage of the State Attribute is implementation dependent.

3.4.  Message-Authenticator

   The Message-Authenticator Attribute MAY be used to authenticate and
   integrity-protect CoA-Request, CoA-ACK, CoA-NAK, Disconnect-Request,
   Disconnect-ACK, and Disconnect-NAK packets in order to prevent
   spoofing.

   A Dynamic Authorization Server receiving a CoA-Request or
   Disconnect-Request with a Message-Authenticator Attribute present
   MUST calculate the correct value of the Message-Authenticator and
   silently discard the packet if it does not match the value sent.  A
   Dynamic Authorization Client receiving a CoA/Disconnect-ACK or
   CoA/Disconnect-NAK with a Message-Authenticator Attribute present
   MUST calculate the correct value of the Message-Authenticator and
   silently discard the packet if it does not match the value sent.

   When a Message-Authenticator Attribute is included within a CoA-
   Request or Disconnect-Request, it is calculated as follows:

      Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
      Request Authenticator, Attributes)

      When the HMAC-MD5 message integrity check is calculated the
      Request Authenticator field and Message-Authenticator Attribute
      MUST each be considered to be sixteen octets of zero.  The
      Message-Authenticator Attribute is calculated and inserted in the
      packet before the Request Authenticator is calculated.









Chiba, et al.                Informational                     [Page 15]

RFC 5176       Dynamic Authorization Extensions to RADIUS   January 2008


      When a Message-Authenticator Attribute is included within a CoA-
      ACK, CoA-NAK, Disconnect-ACK, or Disconnect-NAK, it is calculated
      as follows:

         Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
         Request Authenticator, Attributes)

      When the HMAC-MD5 message integrity check is calculated, the
      Message-Authenticator Attribute MUST be considered to be sixteen
      octets of zero.  The Request Authenticator is taken from the
      corresponding CoA/Disconnect-Request.  The Message-Authenticator
      is calculated and inserted in the packet before the Response
      Authenticator is calculated.

3.5.  Error-Cause

   Description

      It is possible that a Dynamic Authorization Server cannot honor
      Disconnect-Request or CoA-Request packets for some reason.  The
      Error-Cause Attribute provides more detail on the cause of the
      problem.  It MAY be included within CoA-NAK and Disconnect-NAK
      packets.

      A summary of the Error-Cause Attribute 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |             Value
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Value (cont)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      101 for Error-Cause

   Length

      6

   Value

      The Value field is four octets, containing an integer specifying
      the cause of the error.  Values 0-199 and 300-399 are reserved.
      Values 200-299 represent successful completion, so that these