rfc2882.txt

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

Network Working Group                                           D. Mitton
Request for Comments: 2882                                Nortel Networks
Category: Informational                                         July 2000


                  Network Access Servers Requirements:
                       Extended RADIUS Practices

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 (2000).  All Rights Reserved.

Abstract

   This document describes current practices implemented in NAS products
   that go beyond the scope of the RADIUS RFCs 2138, 2139 [1,2]. The
   purpose of this effort is to give examples that show the need for
   addressing and standardizing these types of ad-hoc functions.  Since
   many of these features require a matching server support component,
   the ability to deploy and manage interoperable NAS and AAA server
   products is severely hindered.

   These practices are documented here to show functions that are
   obviously desired in developing future AAA protocols for NAS
   deployment.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . .  2
   1.1.  Disclaimers . . . . . . . . . . . . . . . . . . . . . . .  3
   1.2.  Presentation  . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Attribute Usage . . . . . . . . . . . . . . . . . . . . . .  3
   2.1. Attribute Conflicts  . . . . . . . . . . . . . . . . . . .  4
   2.2. Attribute Value Conflicts  . . . . . . . . . . . . . . . .  4
   2.2.1 Vendor Specific Enumerations Proposal . . . . . . . . . .  4
   2.3   Vendor Specific Attribute Usage . . . . . . . . . . . . .  5
   2.3.1 VSAs in use by clients: . . . . . . . . . . . . . . . . .  5
   2.3.2 Clients that support multiple Vendors:  . . . . . . . . .  5
   3.  Attribute Data Types  . . . . . . . . . . . . . . . . . . .  6
   4.  New Messages  . . . . . . . . . . . . . . . . . . . . . . .  7
   5.  Additional Functions  . . . . . . . . . . . . . . . . . . .  7
   5.1 Password Change   . . . . . . . . . . . . . . . . . . . . .  8



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


   5.2 Authentication Modes  . . . . . . . . . . . . . . . . . . .  8
   5.3 Menus . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.4 Pseudo Users  . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Resource Management . . . . . . . . . . . . . . . . . . . .  9
   6.1 Managed Resources . . . . . . . . . . . . . . . . . . . . .  9
   6.2 Resource Management Messages  . . . . . . . . . . . . . . . 10
   6.3 Concurrent Logins . . . . . . . . . . . . . . . . . . . . . 10
   6.4 Authorization Changes . . . . . . . . . . . . . . . . . . . 11
   7. Policy Services  . . . . . . . . . . . . . . . . . . . . . . 11
   8. Accounting Extensions  . . . . . . . . . . . . . . . . . . . 12
   8.1 Auditing/Activity . . . . . . . . . . . . . . . . . . . . . 12
   9. Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . 12
   10. Security Considerations . . . . . . . . . . . . . . . . . . 13
   11. Implementation Documents  . . . . . . . . . . . . . . . . . 13
   11.1. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 13
   11.2. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 14
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . 14
   13. Author's Address  . . . . . . . . . . . . . . . . . . . . . 15
   14. Full Copyright Statement  . . . . . . . . . . . . . . . . . 16

1.  Introduction

   The RADIUS Working Group was formed in 1995 to document the protocol
   of the same name, and was chartered to stay within a set of bounds
   for dial-in terminal servers.  Unfortunately the real world of
   Network Access Servers (NASes) hasn't stayed that small and simple,
   and continues to evolve at an amazing rate.

   This document shows some of the current implementations on the market
   have already outstripped the capabilities of the RADIUS protocol.  A
   quite a few features have been developed completely outside the
   protocol.  These features use the RADIUS protocol structure and
   format, but employ operations and semantics well beyond the RFC
   documents.

   I learn of the details of these functions from reading industry
   manuals and often have to respond to them in competive bid
   specifications.  As they become deployed in the field, they gather
   the force of de-facto standards.

   Because they have been done outside scope of the RFCs, they are
   vendor specific, and introduce significant problems in offering an
   interoperable product.








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


1.1.  Disclaimers

   The data and numbers in this document have been gleaned from public
   sources and vendor documents along the way.  Actual implementation of
   many these features and variation from the documentation has not been
   confirmed.

   This document is a snapshot of known practices at the time of
   writing.  It is not intended to standardize these practices here, or
   keep this document current, beyond initial publication. While some
   detailed information is given, it is not the purpose of this document
   to directly or sufficiently describe the functions mentioned to the
   level of a complete functional specification.

   The author has not transcribed copyrighted material, and is not aware
   of whether any of these practices have of intellectual property
   restrictions.

   Any numeric assignments or functional operations are subject to
   change by vendors without notice.  I would appreciate any direct
   input, preferably first hand, from implementors.

1.2.  Presentation

   Without any easy organization for the material, information is
   arranged in a simple taxonomy from bottom-up complexity:

   -    Attribute Usage

   -    Attribute Data Types

   -    Message Codes

   -    New Operations

2.  Attribute Usage

   The RADIUS RFCs define attribute type ranges and specific attribute
   definitions.


   -    There are about 70 defined RADIUS attributes:

   -    Values 192-223 are reserved for experimental use

   -    Values 224-240 are reserved for implementation-specific use

   -    Values 241-255 are reserved and should not be used.



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


   Attribute 26 was defined to be the Vendor Specific Attribute (VSA)
   with further internal structure to allow vendor expansion.

2.1.  Attribute conflicts

   In practice attributes 92-255 are in use by a vendor. And another
   vendor also use attributes in the 90-104 range and conflicts with
   this usage.

   To deal with these issues, server vendors have added vendor specific
   parameters to their client database files.  The administrator has to
   indicate the vendor type of NAS along with the client IP address and
   secret, so that the server can disambiguate the attribute usage.

   One server has a single large vendors file to describe the mapping
   all attributes to an internal format that retains the vendor id.
   Another server implementation uses multiple dictionaries, each
   indexed to a NAS and Vendor Model definition list.

2.2.  Attribute Value Conflicts

   Adding additional attributes may be more trouble than necessary for
   simple features.  Often existing RADIUS attributes could be extended
   with additional values (particularly attributes that are enumerated
   choices).  But in doing such there is no way to guarantee not
   conflicting with other vendor's extensions.

2.2.1.  Vendor Specific Enumerations proposal

   One proposed solution to this problem was Vendor Specific
   Enumerations (VSEs).  That is to imbed the vendor's management ID in
   the numeric value (ala VSAs) which would to divide up the attribute
   value space.  This technique has not seen any acceptance by the
   working group or other vendors, however, the vendor did accomplish
   the goal of not conflicting with working group additions or other
   vendor values.

   Example dictionary of VSE values:

   VALUE   Service-Type        VSE-Authorize-Only       0x06300001

   VALUE   Acct-Status-Type    VSE-User-Reject          0x06300001
   VALUE   Acct-Status-Type    VSE-Call-Reject          0x06300002
   VALUE   Acct-Status-Type    VSE-IPCP-Start           0x06300003
   VALUE   Acct-Status-Type    VSE-IPXCP-Start          0x06300004
   VALUE   Acct-Status-Type    VSE-ATCP-Start           0x06300005
   VALUE   Acct-Status-Type    VSE-Accounting-Restart   0x06300006
   VALUE   Acct-Status-Type    VSE-Accounting-Shutoff   0x06300007



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


   VALUE   Acct-Status-Type    VSE-Tunnel-Start         0x06300008
   VALUE   Acct-Status-Type    VSE-Tunnel-Stop          0x06300009
   VALUE   Acct-Status-Type    VSE-Tunnel-Reject        0x0630000a
   VALUE   Acct-Status-Type    VSE-Tunnel-Link-Start    0x0630000b
   VALUE   Acct-Status-Type    VSE-Tunnel-Link-Stop     0x0630000c
   VALUE   Acct-Status-Type    VSE-MP-Start             0x0630000d
   VALUE   Acct-Status-Type    VSE-MP-Stop              0x0630000e
   VALUE   Acct-Status-Type    VSE-Line-Seizure         0x0630000f
   VALUE   Acct-Status-Type    VSE-Rlogin-Start         0x06300010
   VALUE   Acct-Status-Type    VSE-Rlogin-Stop          0x06300011

2.3.  Vendor Specific Attribute Usage

   Because attribute 26 Vendor Specific Attributes (VSAs) came late in
   the RADIUS working group development,  there were some server
   implementations that were late to support them.  Today, there are
   several leading implementations of clients that make extensive use of
   VSAs.  What's unfortunate is that there is also several different
   formats of VSAs implemented.  This is because the RFC suggested
   format does not support more than 256 attributes.

2.3.1.  VSAs in use by some clients:

   At the time this document was written, the following had be observed:

   -    Microsoft: several for MS-CHAP authentication support [9]

   -    ACC: 42 [10]

   -    Nortel(Bay): about 60 VSAs and 16 VSEs

   -    Nortel(Aptis): about 60 VSA: 20 1-byte, ~130 4-byte header.
        Aptis VSAs have shifted from a regular format to a 4-byte header
        format, due to the large number of attributes implemented.

   -    3Com (USR): about 130
        USR VSAs are different than the format suggested in RFC 2138.
        They have a 4 byte type field and have no internal length.

   Some vendors that did not initially use VSAs, have shifted in later
   releases VSA usage as a configuration option.

2.3.2.  Clients that support Multiple Vendor Attributes

   Now that MS-CHAP RADIUS attributes have been published in RFC 2548
   [9] as Microsoft VSA attributes, it will become typical that for NAS
   clients that support MS-CHAP authentication to process several




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


   different vendor VSA types.  This has implications for RADIUS servers
   that filter or "prune" return attributes based on the vendor
   make/model of the NAS client.

   One NAS implementation can receive up to three different vendor
   specific attribute sets, but will only send attributes according to
   the "mode" that has been configured by the operator. This allows it
   to fit into environments where the customer has become dependent on a
   particular set of RADIUS attributes, and allows the NAS to "drop-in"
   without server attribute changes.

   There is another NAS that supports 3 vendor attributes sets
   concurrently.  That is, it will normally use a combination of
   different vendor VSAs in return profiles from the server.  This was