rfc3576.txt

radius协议的经典实现

Network Working Group                                           M. Chiba
Request for Comments: 3576                                    G. Dommety
Category: Informational                                        M. Eklund
                                                     Cisco Systems, Inc.
                                                               D. Mitton
                                                  Circular Logic, UnLtd.
                                                                B. Aboba
                                                   Microsoft Corporation
                                                               July 2003


              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.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

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 3576       Dynamic Authorization Extensions to RADIUS      July 2003


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
       1.1.  Applicability. . . . . . . . . . . . . . . . . . . . . .  3
       1.2.  Requirements Language  . . . . . . . . . . . . . . . . .  5
       1.3.  Terminology. . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
       2.1.  Disconnect Messages (DM) . . . . . . . . . . . . . . . .  5
       2.2.  Change-of-Authorization Messages (CoA) . . . . . . . . .  6
       2.3.  Packet Format. . . . . . . . . . . . . . . . . . . . . .  7
   3.  Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 11
       3.1.  Error-Cause. . . . . . . . . . . . . . . . . . . . . . . 13
       3.2.  Table of Attributes. . . . . . . . . . . . . . . . . . . 16
   4.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 20
   5.  Security Considerations. . . . . . . . . . . . . . . . . . . . 21
       5.1.  Authorization Issues . . . . . . . . . . . . . . . . . . 21
       5.2.  Impersonation. . . . . . . . . . . . . . . . . . . . . . 22
       5.3.  IPsec Usage Guidelines . . . . . . . . . . . . . . . . . 22
       5.4.  Replay Protection. . . . . . . . . . . . . . . . . . . . 25
   6.  Example Traces . . . . . . . . . . . . . . . . . . . . . . . . 26
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
       7.1.  Normative References . . . . . . . . . . . . . . . . . . 26
       7.2.  Informative References . . . . . . . . . . . . . . . . . 27
   8.  Intellectual Property Statement. . . . . . . . . . . . . . . . 28
   9.  Acknowledgements.  . . . . . . . . . . . . . . . . . . . . . . 28
   10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
   11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30
























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


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 a user session in progress.
   Alternatively, if the user changes authorization level, this may
   require that authorization attributes be added/deleted from a user
   session.

   To overcome these limitations, several vendors have implemented
   additional RADIUS commands in order to be able to support unsolicited
   messages sent from the RADIUS server to the NAS.  These extended
   commands provide support for Disconnect and Change-of-Authorization
   (CoA) messages.  Disconnect messages cause a user session to be
   terminated immediately, whereas CoA messages 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
   recommended.  See Section 5.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 5.3. for
   details.







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


   Existing implementations lack replay protection.  In order to support
   replay detection, it is recommended that the Event-Timestamp
   Attribute be added to all messages in situations where IPsec replay
   protection is not employed.  Implementations should be configurable
   to silently discard messages lacking the Event-Timestamp Attribute.
   See Section 5.4. 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 [Diameter], in which authorization
   change is requested by a command using Attribute Value Pairs (AVPs)
   solely for identification, resulting 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.

   Due to differences in handling change-of-authorization requests in
   RADIUS and Diameter, it may be difficult or impossible for a
   Diameter/RADIUS gateway to successfully translate existing
   implementations of this specification to equivalent messages in
   Diameter.  For example, a Diameter command changing any attribute
   used for identification within existing CoA-Request implementations
   cannot be translated, since such an authorization change is
   impossible to carry out in existing implementations.  Similarly,
   translation between existing implementations of Disconnect-Request or
   CoA-Request messages and Diameter is tricky because a Disconnect-
   Request or CoA-Request message will need to be translated to multiple
   Diameter commands.

   To simplify translation between RADIUS and Diameter, a Service-Type
   Attribute with value "Authorize Only" can (optionally) be included
   within a Disconnect-Request or CoA-Request.  Such a Request contains
   only identification attributes.  A NAS supporting the "Authorize
   Only" Service-Type within a Disconnect-Request or CoA-Request
   responds with a NAK containing a Service-Type Attribute with value
   "Authorize Only" and an Error-Cause Attribute with value "Request
   Initiated".  The NAS will then send an Access-Request containing a
   Service-Type Attribute with a value of "Authorize Only".  This usage
   sequence is akin to what occurs in Diameter and so is more easily
   translated by a Diameter/RADIUS gateway.





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


1.2.  Requirements Language

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.  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:

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

2.1.  Disconnect Messages (DM)

   A Disconnect-Request packet is sent by the RADIUS server in order to
   terminate a user session 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 to be terminated by
   inclusion of the identification attributes described in Section 3.



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


   +----------+   Disconnect-Request     +----------+
   |          |   <--------------------  |          |
   |    NAS   |                          |  RADIUS  |
   |          |   Disconnect-Response    |  Server  |
   |          |   ---------------------> |          |
   +----------+                          +----------+

   The NAS responds to a Disconnect-Request packet sent by a RADIUS
   server with a Disconnect-ACK if all associated session context is
   discarded and the user session is no longer connected, or a
   Disconnect-NAK, if the NAS was unable to disconnect the session and
   discard all associated session context.  A NAS MUST respond to a
   Disconnect-Request including a Service-Type Attribute with value
   "Authorize Only" with a Disconnect-NAK; a Disconnect-ACK MUST NOT be
   sent.  A NAS MUST respond to a Disconnect-Request including a
   Service-Type Attribute with an unsupported value with a Disconnect-
   NAK; an Error-Cause Attribute with value "Unsupported Service" MAY be
   included.  A Disconnect-ACK MAY contain the Attribute
   Acct-Terminate-Cause (49) [RFC2866] with the value set to 6 for
   Admin-Reset.