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.
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.
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.
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.
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.
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
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.
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 done to support a superset of competing vendor's extensions, as well as it's own, and include an extensions from a sister product.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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- authentication message (like the new RADIUS draft Service-Type = CallCheck) is emitted by the NAS upon call arrival. This message will contain only the Dialed-Number information in the Username field. The server receives the Access-Request messages and processes them against it's knowledge of the network state and the provisioned policies.
An Access-Accept will be returned to the system to accept the call, and many also contain dynamic policy information and Virtual POP specific default parameters. When the real PPP authentication is engaged, the proxy will forwards the Access-Request to a RADIUS server, if this session was approved at pre-auth. It can also process Access-Requests that were not preceded by a pre-auth exchange, and use the Username field for information about the
Mitton Informational [Page 11]
RFC 2882 Extended RADIUS Practices July 2000
desired realm, in it's policy evaluation.
The other implementation performs a similar operations. It uses VSAs in the Access-Request to distinguish pre-authentication message types.
Traditional Accounting only records session starts and stops which is pretty boring. Additional session information reporting can be added easily which gives a better picture of operation in use as they happen. Some event types are listed below.
- Call or Modem Starts, Stops - Tunnel Starts, Stops - Tunnel Link Starts & Stops - Admin changes
These events if monitored by a stateful server can be used to gather information about the usage of the network on a user/session basis. Information about when a particular user entered the network is more relevant to network service management than attempting track backwards from low level IP address flows. Useful information about port usage across a range of NASes allows service provider to quickly find problem areas or users.
Information about call failures, successes, and quality are also deemed important many service providers.
Extending RADIUS accounting is easy, it's surprising that more implementations have not been made in this area.
In real life RADIUS Servers are becoming rather complex software implementations. They are often brokering authentication and authorization to other authorities or repositories. Variants of RADIUS protocol is often used as glue protocol for these type of solutions.
Some of the solutions are kludges that could be cleaned up by better underlying services.
What this means to the implementor is that RADIUS as the RFCs describe it is becoming less relevant. Many additional features require matching client and server processing message processing.
Mitton Informational [Page 12]
RFC 2882 Extended RADIUS Practices July 2000
Without standardization of these functions we don't have much interoperability in the field and much effort is spent in reverse engineering and reaction to unknown areas.
This memo is not a complete survey by any means. It is a representative summary of practices that I am aware of at the time of writing. I still appreciate input from vendors or users on practices and details known, and particularly any reference material you can pass me.
This document documents known practices, and does not propose any particular new protocols. Extensions to RADIUS protocols create new security implications because of their functions go beyond those considered in the RFCs. Some of these include:
- The ability to change passwords via a RADIUS exchange was deliberately left out of the protocol by the working group, because of security concerns. - The Pseudo-User profiles and the Call-Check operation may allow unintended access if static and well-know account names and passwords are allowed to be used by regular interactive accounts. - Resource Management operations must be protected from denial of service attacks. - Client side authorization change exchanges need to be secured from attacks that could disconnect or restrict user services.
Information about the following implementations can be obtained from the respective owners. Most listed are available from the manufacturer's web site.
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.