rfc3576.txt

radius协议的经典实现

   0-1       0        0    85   Acct-Interim-Interval [Note 3]
   0-1       0        0    87   NAS-Port-Id [Note 1]
   0-1       0        0    88   Framed-Pool [Note 3]
   0+        0        0    90   Tunnel-Client-Auth-ID [Note 5]
   0+        0        0    91   Tunnel-Server-Auth-ID [Note 5]
   0-1       0        0    94   Originating-Line-Info [Note 1]
   0-1       0        0    95   NAS-IPv6-Address [Note 1]
   0-1       0        0    96   Framed-Interface-Id [Note 1]
   0+        0        0    97   Framed-IPv6-Prefix [Note 1]
   0+        0        0    98   Login-IPv6-Host [Note 3]
   0+        0        0    99   Framed-IPv6-Route [Note 3]
   0-1       0        0   100   Framed-IPv6-Pool [Note 3]
   0         0        0+  101   Error-Cause
   Request   ACK      NAK   #   Attribute

   Disconnect Messages

   Request   ACK      NAK   #   Attribute
   0-1       0        0     1   User-Name [Note 1]
   0-1       0        0     4   NAS-IP-Address [Note 1]
   0-1       0        0     5   NAS-Port [Note 1]
   0-1       0        0-1   6   Service-Type [Note 6]
   0-1       0        0     8   Framed-IP-Address [Note 1]
   0+        0        0    18   Reply-Message [Note 2]
   0-1       0-1      0-1  24   State [Note 7]
   0+        0        0    25   Class [Note 4]
   0+        0        0    26   Vendor-Specific
   0-1       0        0    30   Called-Station-Id [Note 1]
   0-1       0        0    31   Calling-Station-Id [Note 1]
   0-1       0        0    32   NAS-Identifier [Note 1]
   0+        0+       0+   33   Proxy-State
   Request   ACK      NAK   #   Attribute



Chiba, et al.                Informational                     [Page 17]

RFC 3576       Dynamic Authorization Extensions to RADIUS      July 2003


   Request   ACK      NAK   #   Attribute
   0-1       0        0    44   Acct-Session-Id [Note 1]
   0-1       0-1      0    49   Acct-Terminate-Cause
   0-1       0        0    50   Acct-Multi-Session-Id [Note 1]
   0-1       0-1      0-1  55   Event-Timestamp
   0-1       0        0    61   NAS-Port-Type [Note 1]
   0+        0-1      0    79   EAP-Message [Note 2]
   0-1       0-1      0-1  80   Message-Authenticator
   0-1       0        0    87   NAS-Port-Id [Note 1]
   0-1       0        0    94   Originating-Line-Info [Note 1]
   0-1       0        0    95   NAS-IPv6-Address [Note 1]
   0-1       0        0    96   Framed-Interface-Id [Note 1]
   0+        0        0    97   Framed-IPv6-Prefix [Note 1]
   0         0+       0+  101   Error-Cause
   Request   ACK      NAK   #   Attribute

   [Note 1] Where NAS or session identification attributes are included
   in Disconnect-Request or CoA-Request messages, they are used for
   identification purposes only.  These attributes MUST NOT be used for
   purposes other than identification (e.g. within CoA-Request messages
   to request authorization changes).

   [Note 2] The Reply-Message Attribute is used to present a displayable
   message to the user.  The message is only displayed as a result of a
   successful Disconnect-Request or CoA-Request (where a Disconnect-ACK
   or CoA-ACK is subsequently sent).  Where EAP is used for
   authentication, an EAP-Message/Notification-Request Attribute is sent
   instead, and Disconnect-ACK or CoA-ACK messages contain an EAP-
   Message/Notification-Response Attribute.

   [Note 3] When included within a CoA-Request, these attributes
   represent an authorization change request.  When one of these
   attributes is omitted from a CoA-Request, the NAS assumes that the
   attribute value is to remain unchanged.  Attributes included in a
   CoA-Request replace all existing value(s) of the same attribute(s).

   [Note 4] When included within a successful Disconnect-Request (where
   a Disconnect-ACK is subsequently sent), the Class Attribute SHOULD be
   sent unmodified by the client to the accounting server in the
   Accounting Stop packet.  If the Disconnect-Request is unsuccessful,
   then the Class Attribute is not processed.

   [Note 5] When included within a CoA-Request, these attributes
   represent an authorization change request.  Where tunnel attribute(s)
   are sent within a successful CoA-Request, all existing tunnel
   attributes are removed and replaced by the new attribute(s).





Chiba, et al.                Informational                     [Page 18]

RFC 3576       Dynamic Authorization Extensions to RADIUS      July 2003


   [Note 6] When included within a Disconnect-Request or CoA-Request, a
   Service-Type Attribute with value "Authorize Only" indicates that the
   Request only contains NAS and session identification attributes, and
   that the NAS should attempt reauthorization by sending an Access-
   Request with a Service-Type Attribute with value "Authorize Only".
   This enables a usage model akin to that supported in Diameter, thus
   easing translation between the two protocols.  Support for the
   Service-Type Attribute is optional within CoA-Request and
   Disconnect-Request messages; where it is not included, the Request
   message may contain both identification and authorization attributes.
   A NAS that does not support the Service-Type Attribute with the value
   "Authorize Only" within a Disconnect-Request MUST respond with a
   Disconnect-NAK including no Service-Type Attribute; an Error-Cause
   Attribute with value "Unsupported Service" MAY be included.  A NAS
   that does not support the Service-Type Attribute with the value
   "Authorize Only" within a CoA-Request MUST respond with a CoA-NAK
   including no Service-Type Attribute; an Error-Cause Attribute with
   value "Unsupported Service" MAY be included.

   A NAS supporting the "Authorize Only" Service-Type value within
   Disconnect-Request or CoA-Request messages MUST respond with a
   Disconnect-NAK or CoA-NAK respectively, containing a Service-Type
   Attribute with value "Authorize Only", and an Error-Cause Attribute
   with value "Request Initiated".  The NAS then sends an Access-Request
   to the RADIUS server with a Service-Type Attribute with value
   "Authorize Only".  This Access-Request SHOULD contain the NAS
   attributes from the Disconnect or CoA-Request, as well as the session
   attributes from the Request legal for inclusion in an Access-Request
   as specified in [RFC2865], [RFC2868], [RFC2869] and [RFC3162].  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 should send back an Access-Accept to (re-)authorize
   the session or an Access-Reject to refuse to (re-)authorize it.

   [Note 7] The State Attribute is available to be sent by the RADIUS
   server to the NAS in a Disconnect-Request or CoA-Request message and
   MUST be sent unmodified from the NAS to the RADIUS server in a
   subsequent ACK or NAK message.  If a Service-Type Attribute with
   value "Authorize Only" is included in a Disconnect-Request or CoA-
   Request along with a State Attribute, then the State Attribute MUST
   be sent unmodified from the NAS to the RADIUS server in the resulting
   Access-Request sent to the RADIUS server, if any.  The State
   Attribute is also available to be sent by the RADIUS server to the
   NAS in a CoA-Request that also includes a Termination-Action
   Attribute with the value of RADIUS-Request.  If the client performs
   the Termination-Action by sending a new Access-Request upon
   termination of the current session, it MUST include the State



Chiba, et al.                Informational                     [Page 19]

RFC 3576       Dynamic Authorization Extensions to RADIUS      July 2003


   Attribute unchanged in that Access-Request.  In either usage, the
   client MUST NOT interpret the Attribute locally.  A Disconnect-
   Request or CoA-Request packet must have only zero or one State
   Attribute.  Usage of the State Attribute is implementation dependent.
   If the RADIUS server does not recognize the State Attribute in the
   Access-Request, then it MUST send an Access-Reject.

   The following table defines the meaning of the above table entries.

   0   This attribute MUST NOT be present in packet.
   0+  Zero or more instances of this attribute MAY be present in
       packet.
   0-1 Zero or one instance of this attribute MAY be present in packet.
   1   Exactly one instance of this attribute MUST be present in packet.

4.  IANA Considerations

   This document uses the RADIUS [RFC2865] namespace, see
   <http://www.iana.org/assignments/radius-types>.  There are six
   updates for the section: RADIUS Packet Type Codes.  These Packet
   Types are allocated in [RADIANA]:

   40 - Disconnect-Request
   41 - Disconnect-ACK
   42 - Disconnect-NAK
   43 - CoA-Request
   44 - CoA-ACK
   45 - CoA-NAK

   Allocation of a new Service-Type value for "Authorize Only" is
   requested.  This document also uses the UDP [RFC768] namespace, see
   <http://www.iana.org/assignments/port-numbers>.  The authors request
   a port assignment from the Registered ports range.  Finally, this
   specification allocates the Error-Cause Attribute (101) with the
   following decimal values:

    #     Value
   ---    -----
   201    Residual Session Context Removed
   202    Invalid EAP Packet (Ignored)
   401    Unsupported Attribute
   402    Missing Attribute
   403    NAS Identification Mismatch
   404    Invalid Request
   405    Unsupported Service
   406    Unsupported Extension
   501    Administratively Prohibited
   502    Request Not Routable (Proxy)



Chiba, et al.                Informational                     [Page 20]

RFC 3576       Dynamic Authorization Extensions to RADIUS      July 2003


   503    Session Context Not Found
   504    Session Context Not Removable
   505    Other Proxy Processing Error
   506    Resources Unavailable
   507    Request Initiated

5.  Security Considerations

5.1.  Authorization Issues

   Where a NAS is shared by multiple providers, it is undesirable for
   one provider to be able to send Disconnect-Request or CoA-Requests
   affecting the sessions of another provider.

   A NAS or RADIUS proxy MUST silently discard Disconnect-Request or
   CoA-Request messages from untrusted sources.  By default, a RADIUS
   proxy SHOULD perform a "reverse path forwarding" (RPF) check to
   verify that a Disconnect-Request or CoA-Request originates from an
   authorized RADIUS server.  In addition, it SHOULD be possible to
   explicitly authorize additional sources of Disconnect-Request or
   CoA-Request packets relating to certain classes of sessions.  For
   example, a particular source can be explicitly authorized to send
   CoA-Request messages relating to users within a set of realms.

   To perform the RPF check, the proxy uses the session identification
   attributes included in Disconnect-Request or CoA-Request messages, in
   order to determine the RADIUS server(s) to which an equivalent
   Access-Request could be routed.  If the source address of the
   Disconnect-Request or CoA-Request is within this set, then the
   Request is forwarded; otherwise it MUST be silently discarded.

   Typically the proxy will extract the realm from the Network Access
   Identifier [RFC2486] included within the User-Name Attribute, and
   determine the corresponding RADIUS servers in the proxy routing
   tables.  The RADIUS servers for that realm  are then compared against
   the source address of the packet.  Where no RADIUS proxy is present,
   the RPF check will need to be performed by the NAS itself.

   Since authorization to send a Disconnect-Request or CoA-Request is
   determined based on the source address and the corresponding shared
   secret, the NASes or proxies SHOULD configure a different shared
   secret for each RADIUS server.









Chiba, et al.                Informational                     [Page 21]

RFC 3576       Dynamic Authorization Extensions to RADIUS      July 2003


5.2.  Impersonation

   [RFC2865] Section 3 states:

      A RADIUS server MUST use the source IP address of the RADIUS UDP
      packet to decide which shared secret to use, so that RADIUS
      requests can be proxied.

   When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or
   NAS-IPv6-Address Attributes will typically not match the source
   address observed by the RADIUS server.  Since the NAS-Identifier
   Attribute need not contain an FQDN, this attribute may not be
   resolvable to the source address observed by the RADIUS server, even
   when no proxy is present.

   As a result, the authenticity check performed by a RADIUS server or
   proxy does not verify the correctness of NAS identification
   attributes.  This makes it possible for a rogue NAS to forge NAS-IP-
   Address, NAS-IPv6-Address or NAS-Identifier Attributes within a
   RADIUS Access-Request in order to impersonate another NAS.  It is
   also possible for a rogue NAS to forge session identification
   attributes such as the Called-Station-Id, Calling-Station-Id, or
   Originating-Line-Info [NASREQ].  This could fool the RADIUS server
   into sending Disconnect-Request or CoA-Request messages containing
   forged session identification attributes to a NAS targeted by an
   attacker.

   To address these vulnerabilities RADIUS proxies SHOULD check whether
   NAS identification attributes (see Section 3.) match the source
   address of packets originating from the NAS.  Where one or more
   attributes do not match, Disconnect-Request or CoA-Request messages
   SHOULD be silently discarded.

   Such a check may not always be possible.  Since the NAS-Identifier
   Attribute need not correspond to an FQDN, it may not be resolvable to
   an IP address to be matched against the source address.  Also, where
   a NAT exists between the RADIUS client and proxy, checking the NAS-
   IP-Address or NAS-IPv6-Address Attributes may not be feasible.

5.3.  IPsec Usage Guidelines

   In addition to security vulnerabilities unique to Disconnect or CoA