rfc5176.txt

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

Network Working Group                                           M. Chiba
Request for Comments: 5176                                    G. Dommety
Obsoletes: 3576                                                M. Eklund
Category: Informational                              Cisco Systems, Inc.
                                                               D. Mitton
                                           RSA, Security Division of EMC
                                                                B. Aboba
                                                   Microsoft Corporation
                                                            January 2008


                  Dynamic Authorization Extensions to
          Remote Authentication Dial In User Service (RADIUS)

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Abstract

   This document describes a currently deployed extension to the Remote
   Authentication Dial In User Service (RADIUS) protocol, allowing
   dynamic changes to a user session, as implemented by network access
   server products.  This includes support for disconnecting users and
   changing authorizations applicable to a user session.
























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


Table of Contents

   1. Introduction ....................................................2
      1.1. Applicability ..............................................3
      1.2. Requirements Language ......................................4
      1.3. Terminology ................................................4
   2. Overview ........................................................4
      2.1. Disconnect Messages (DMs) ..................................5
      2.2. Change-of-Authorization (CoA) Messages .....................5
      2.3. Packet Format ..............................................6
   3. Attributes .....................................................10
      3.1. Proxy State ...............................................12
      3.2. Authorize Only ............................................13
      3.3. State .....................................................14
      3.4. Message-Authenticator .....................................15
      3.5. Error-Cause ...............................................16
      3.6. Table of Attributes .......................................20
   4. Diameter Considerations ........................................24
   5. IANA Considerations ............................................26
   6. Security Considerations ........................................26
      6.1. Authorization Issues ......................................26
      6.2. IPsec Usage Guidelines ....................................27
      6.3. Replay Protection .........................................28
   7. Example Traces .................................................28
   8. References .....................................................29
      8.1. Normative References ......................................29
      8.2. Informative References ....................................30
   9. Acknowledgments ................................................30
   Appendix A ........................................................31

1.  Introduction

   The RADIUS protocol, defined in [RFC2865], does not support
   unsolicited messages sent from the RADIUS server to the Network
   Access Server (NAS).

   However, there are many instances in which it is desirable for
   changes to be made to session characteristics, without requiring the
   NAS to initiate the exchange.  For example, it may be desirable for
   administrators to be able to terminate user session(s) in progress.
   Alternatively, if the user changes authorization level, this may
   require that authorization attributes be added/deleted from user
   session(s).

   To overcome these limitations, several vendors have implemented
   additional RADIUS commands in order to enable unsolicited messages to
   be sent to the NAS.  These extended commands provide support for
   Disconnect and Change-of-Authorization (CoA) packets.  Disconnect



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


   packets cause user session(s) to be terminated immediately, whereas
   CoA packets modify session authorization attributes such as data
   filters.

1.1.  Applicability

   This protocol is being recommended for publication as an
   Informational RFC rather than as a standards-track RFC because of
   problems that cannot be fixed without creating incompatibilities with
   deployed implementations.  This includes security vulnerabilities, as
   well as semantic ambiguities resulting from the design of the
   Change-of-Authorization (CoA) commands.  While fixes are recommended,
   they cannot be made mandatory since this would be incompatible with
   existing implementations.

   Existing implementations of this protocol do not support
   authorization checks, so that an ISP sharing a NAS with another ISP
   could disconnect or change authorizations for another ISP's users.
   In order to remedy this problem, a "Reverse Path Forwarding" check is
   described; see Section 6.1 for details.

   Existing implementations utilize per-packet authentication and
   integrity protection algorithms with known weaknesses [MD5Attack].
   To provide stronger per-packet authentication and integrity
   protection, the use of IPsec is recommended.  See Section 6.2 for
   details.

   Existing implementations lack replay protection.  In order to support
   replay detection, it is recommended that an Event-Timestamp Attribute
   be added to all packets in situations where IPsec replay protection
   is not employed.  See Section 6.3 for details.

   The approach taken with CoA commands in existing implementations
   results in a semantic ambiguity.  Existing implementations of the
   CoA-Request identify the affected session, as well as supply the
   authorization changes.  Since RADIUS Attributes included within
   existing implementations of the CoA-Request can be used for session
   identification or authorization change, it may not be clear which
   function a given attribute is serving.

   The problem does not exist within the Diameter protocol [RFC3588], in
   which server-initiated authorization change is initiated using a
   Re-Auth-Request (RAR) command identifying the session via User-Name
   and Session-Id Attribute Value Pairs (AVPs) and containing a
   Re-Auth-Request-Type AVP with value "AUTHORIZE_ONLY".  This results
   in initiation of a standard Request/Response sequence where
   authorization changes are supplied.  As a result, in no command can
   Diameter AVPs have multiple potential meanings.



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


1.2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.3.  Terminology

   This document frequently uses the following terms:

   Dynamic Authorization Client (DAC)
        The entity originating Change of Authorization (CoA) Requests or
        Disconnect-Requests.  While it is possible that the DAC is
        co-resident with a RADIUS authentication or accounting server,
        this need not necessarily be the case.

   Dynamic Authorization Server (DAS)
        The entity receiving CoA-Request or Disconnect-Request packets.
        The DAS may be a NAS or a RADIUS proxy.

   Network Access Server (NAS)
        The device providing access to the network.

   service
        The NAS provides a service to the user, such as IEEE 802 or
        Point-to-Point Protocol (PPP).

   session
        Each service provided by the NAS to a user constitutes a
        session, with the beginning of the session defined as the point
        where service is first provided and the end of the session
        defined as the point where service is ended.  A user may have
        multiple sessions in parallel or series if the NAS supports
        that.

   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.  Overview

   This section describes the most commonly implemented features of
   Disconnect and Change-of-Authorization (CoA) packets.





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


2.1.  Disconnect Messages (DMs)

   A Disconnect-Request packet is sent by the Dynamic Authorization
   Client in order to terminate user session(s) on a NAS and discard all
   associated session context.  The Disconnect-Request packet is sent to
   UDP port 3799, and identifies the NAS as well as the user session(s)
   to be terminated by inclusion of the identification attributes
   described in Section 3.

   +----------+                          +----------+
   |          |   Disconnect-Request     |          |
   |          |   <--------------------  |          |
   |    NAS   |                          |    DAC   |
   |          |   Disconnect-ACK/NAK     |          |
   |          |   ---------------------> |          |
   +----------+                          +----------+

   The NAS responds to a Disconnect-Request packet sent by a Dynamic
   Authorization Client with a Disconnect-ACK if all associated session
   context is discarded and the user session(s) are no longer connected,
   or a Disconnect-NAK, if the NAS was unable to disconnect one or more
   sessions and discard all associated session context.  A Disconnect-
   ACK MAY contain the Acct-Terminate-Cause (49) Attribute [RFC2866]
   with the value set to 6 for Admin-Reset.

2.2.  Change-of-Authorization (CoA) Messages

   CoA-Request packets contain information for dynamically changing
   session authorizations.  Typically, this is used to change data
   filters.  The data filters can be of either the ingress or egress
   kind, and are sent in addition to the identification attributes as
   described in Section 3.  The port used and packet format (described
   in Section 2.3) are the same as those for Disconnect-Request packets.

   The following attributes MAY be sent in a CoA-Request:

   Filter-ID (11) -        Indicates the name of a data filter list
                           to be applied for the session(s) that the
                           identification attributes map to.

   NAS-Filter-Rule (92) -  Provides a filter list to be applied for
                           the session(s) that the identification
                           attributes map to [RFC4849].








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


   +----------+                          +----------+
   |          |      CoA-Request         |          |
   |          |  <--------------------   |          |
   |   NAS    |                          |    DAC   |
   |          |     CoA-ACK/NAK          |          |
   |          |   ---------------------> |          |
   +----------+                          +----------+

   The NAS responds to a CoA-Request sent by a Dynamic Authorization
   Client with a CoA-ACK if the NAS is able to successfully change the
   authorizations for the user session(s), or a CoA-NAK if the CoA-
   Request is unsuccessful.  A NAS MUST respond to a CoA-Request
   including a Service-Type Attribute with an unsupported value with a