rfc2882.txt

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

   done to support a superset of competing vendor's extensions, as well
   as it's own, and include an extensions from a sister product.

3.  Attribute Data Types

   The base RFCs define only has 4 basic data types:

   -    integer, 32 bit unsigned

   -    string, 1-253 bytes, counted.

   -    ipaddr, 32 bit IPv4

   -    date, 32 bit Unix format.

   Since then, various variations have been added:

   The tunnel authentication document [6] adds an optional compound
   "tag" byte to tunnel attributes.  These are a single byte prepended
   to the data field in order to support sets of attributes to be
   returned.  The byte value must be in the range 01-3F hex or it is
   considered to be data.

   Note that there is no native support for IPv6 addresses. In fact IPv6
   support is missing in some fixed message components too.

   There have been special attribute types created within servers.  For
   packet filters, the format called "abinary" was created.  The user
   enters an ASCII string filter description in the user profile, but
   the server parses it into a binary string before passing it to the
   NAS.  This lowers the complexity of the NAS parser.  Also a
   "phonestring" server data type allows additional data type checking
   at the entry application.




Mitton                       Informational                      [Page 6]

RFC 2882               Extended RADIUS Practices               July 2000


4.  New Messages

   A number of new message types have been introduced by various parties
   over time. The base specification has 6, vendors have added 26.

   These fall into a number of categories which are described in the
   next section below. Some of these messages are actually used between
   the RADIUS server and some other resource server, using a RADIUS-like
   protocol to implement new functions.

         6 Accounting Status
                  (now Interim Accounting [5])
         7 Password Request
         8 Password Ack
         9 Password Reject
         10 Accounting Message

         21 Resource Free Request
         22 Resource Free Response
         23 Resource Query Request
         24 Resource Query Response
         25 Alternate Resource Reclaim Request
         26 NAS Reboot Request
         27 NAS Reboot Response

         29 Next Passcode
         30 New Pin
         31 Terminate Session
         32 Password Expired
         33 Event Request
         34 Event Response
         40 Disconnect Request
         41 Disconnect Ack
         42 Disconnect Nak
         43 Change Filters Request
         44 Change Filters Ack
         45 Change Filters Nak
         50 IP Address Allocate
         51 IP Address Release

5.  Additional Functions

   These are operations performed using RADIUS extensions and additional
   messages types.







Mitton                       Informational                      [Page 7]

RFC 2882               Extended RADIUS Practices               July 2000


5.1.  Password Change

   Remotely requested password change operations were described and
   proposed, but rejected by the working group.  None the less, the
   feature is still deployed in a number of products.

   Message types:

    - Password Request
    - Password Ack or Reject

5.2.  Authentication Modes

   Additional message types have been added to negotiate passcode
   changes for token card servers.

    - Next Passcode
    - New PIN
    - Password Expired

   They allow the NAS or RADIUS server negotiate passcode changes with
   an external security server.

5.3.  Menus

   At least two vendors have built menuing interaction systems for use
   with terminal dial-ins.

   One implementation uses the Reply-Message string as the menu text to
   be displayed, and the State attribute to keep track of the place in
   the menu.  The menu is displayed using the Access-Challenge message.
   The response is encoded in the User-Password field like an ordinary
   challenge sequence would.

   Some RADIUS clients have problems with this because they cannot
   handle long or multiple Reply-Message attributes that may have
   embedded carriage returns and line-feeds.  The new Echo attribute
   should also control echo behavior on the menu response.   Use of the
   State attribute to keep track of a Challenge sequence is also
   standard behavior.

   Another implementation uses two vendor attributes (VSA-Menu-Item, and
   VSA-Menu-Selector as well as VSA-Third-Prompt) to convey this
   information.  This implementation is vendor specific.







Mitton                       Informational                      [Page 8]

RFC 2882               Extended RADIUS Practices               July 2000


5.4.  Pseudo Users

   One client implementation takes advantage of your vanilla RADIUS
   server's ability to be used as a remote database server.  By using
   some well-known, implementation specific, strings for Username and
   Password attributes, the NAS can request information from the server,
   such as:  Static IP routes, Static IPX routes, or the Message of the
   Day.

   These are called pseudo-user requests, because they use a user entry
   with this manufactured name, for purposes other than authentication.

   Another client also uses a pseudo-user technique for resolving
   unknown Filter-ID(11) values.  An Access-Request message is sent to
   the RADIUS server with the Filter-ID as the Username value, the
   password is a known string, and the Service-Type is VSE-
   Authorization-Only.  The response must also be of the same Service-
   Type, or the response will be ignored.  The responding profile should
   contain the IP-Filter VSA attributes that will define the desired
   filter.

   It should be noticed that pseudo-user profiles could be a security
   problem if a specific or operationally invalid Service-Type is not
   attached to the profile. The client should test for this returned
   value, to prevent normal dial-in users from gaining access via this
   profile.

6.  Resource Management

   Authorized sessions may need to be allocated additional dynamic
   resources in order to perform their services.  The most typical is IP
   addresses.  The allocation may want to be delayed until needed or
   coordinated on a scale independent of the RADIUS server.  Additional
   messages may be used to allocate and free these resources.  The
   RADIUS server may proxy these requests to another server.

   Examples: Certain servers can allocate addresses local to the NAS or
   use an outboard address server.  Other servers have an internal
   address pool capability, which will fill in the Framed-IP-Address
   attribute with an assigned value based on pool selected.

6.1.  Managed Resources:

   Resources managed include: IP Addresses, Concurrent Logins, Dial-in
   Port allocation policies, Tunnel limits and load distribution.






Mitton                       Informational                      [Page 9]

RFC 2882               Extended RADIUS Practices               July 2000


   There are several different types of implementation techniques:

    - Explicit request/free resource requests
    - Monitor usage with deamons watching the state
    - Explicit messages to a state deamon
    - Monitor Accounting messages for state changes

6.2.  Resource Management Messages

   Messages used for resource management

    - IP Address Allocate
    - IP Address Release

    - Resource Request
    - Resource Response
    - Resource Free Request
    - Resource Free Response
    - Resource Reclaim Request
    - NAS Reboot Request/Response

   These messages are used to allocate and free resources for a NAS from
   a centralized server.  These mechanisms allows the service provider
   better administrative control than some automated LAN services, which
   don't have policy inputs or controls.

6.3.  Concurrent Logins

   The RADIUS protocol was designed to allow stateless servers.  That
   is, servers that don't know the status of the active sessions.
   However, it is very important for many service providers to keep
   track of how many sessions a given user may have open, and
   accordingly disallow access.

   There are several different techniques used to implement login limits
   on a RADIUS environment.  Some vendors have build NAS monitoring
   tools either into their RADIUS servers, either directly or as
   auxiliary deamons, that can check the session status of the
   controlled NASes by SNMP or proprietary methods.

   Other vendors monitor the RADIUS accesses and accounting messages and
   derive state information from the requests.  This monitoring is not
   as reliable as directly auditing the NAS, but it is also less vendor
   specific, and can work with any RADIUS NAS, provided it sends both
   streams to the same server.

   Some of the approaches used:




Mitton                       Informational                     [Page 10]

RFC 2882               Extended RADIUS Practices               July 2000


    - SNMP commands
    - Telnet monitor deamon
    - Accounting monitor

6.4.  Authorization Changes:

   To implement an active changes to a running session, such as filter
   changes or timeout and disconnect, at least one vendor has added a
   RADIUS "server" to his NAS. This server accepts messages sent from an
   application in the network, and upon matching some session
   information, will perform such operations.

   Messages sent from Server to NAS

    - Change Filter Request
    - Change Filter Ack / Nak
    - Disconnect Request
    - Disconnect Response

   Filters are used to limit the access the user has to the network by
   restricting the systems and protocols he can send packets to.  Upon
   fulfilling some registration with an authorization server, the
   service provider may wish to remove those restrictions, or disconnect
   the user.

7.  Policy Services

   Some vendors have implemented policy servers using RADIUS as the
   control protocol.  Two prominent Policy Managers act as RADIUS proxy
   filters and use RADIUS messages to deny access to new sessions that
   exceed active policy limits.

   One implementation behaves like a RADIUS proxy server, but with a
   policy process governing it's forward decisions. Typically a pre-