Internet DRAFT - draft-ietf-nasreq-ext-radpract
draft-ietf-nasreq-ext-radpract
Network Access Servers Requirements D. Mitton
Internet Draft Nortel Networks
Expires December 1999 June 1999
Network Access Servers Requirements:
Extended RADIUS Practices
draft-ietf-nasreq-ext-radiuspract-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This document is a product of the Network-Access-Server Requirements
Next Generation (NASREQNG) Working Group of the Internet Engineering
Task Force (IETF). Comments should be submitted to the mailing list
nasreq@tdmx.rutgers.edu.
Abstract
This document describes current practices implemented in NAS products
that go beyond the scope of the RADIUS RFCs (2138, 2139). 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
D. Mitton Expires: 25 Dec 99 [Page 1]
Internet Draft Extended RADIUS Practices June 1999
hindered.
These practices are documented here to show functions that are obviously
desired in developing future AAA protocols for NAS deployment.
This document is a draft submission of the Network Access Server
Requirements Next Generation (NASREQNG) Working Group of the Internet
Engineering Task Force (IETF). Comments should be submitted to the
mailing list nasreq@tdmx.rutgers.edu.
D. Mitton Expires: 25 Dec 99 [Page 2]
Internet Draft Extended RADIUS Practices June 1999
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Attribute Usage . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Attribute Conflicts . . . . . . . . . . . . . . . . . . . . . 5
2.2. Attribute Value Conflicts . . . . . . . . . . . . . . . . . . 5
2.2.1 Vendor Specific Enumerations Proposal . . . . . . . . . . . . 6
2.3 Vendor Specific Attribute Usage . . . . . . . . . . . . . . . 6
2.3.1 VSAs in use by clients: . . . . . . . . . . . . . . . . . . . 6
3. Attribute Data Types . . . . . . . . . . . . . . . . . . . . . 7
4. New Messages . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Additional Functions . . . . . . . . . . . . . . . . . . . . . 8
5.1 Password Change . . . . . . . . . . . . . . . . . . . . . . . 8
5.2 Authentication Modes . . . . . . . . . . . . . . . . . . . . . 9
5.3 Menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.4 Pseudo Users . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Resource Management . . . . . . . . . . . . . . . . . . . . . . 10
6.1 Managed Resources . . . . . . . . . . . . . . . . . . . . . . . 10
6.2 Resource Management Messages . . . . . . . . . . . . . . . . . 10
6.3 Concurrent Logins . . . . . . . . . . . . . . . . . . . . . . . 11
6.4 Authorization Changes . . . . . . . . . . . . . . . . . . . . . 11
7. Accounting Extentions . . . . . . . . . . . . . . . . . . . . . 12
7.1 Auditing/Activity . . . . . . . . . . . . . . . . . . . . . . . 12
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Implementation Documents . . . . . . . . . . . . . . . . . . . . 13
9.1. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.2. Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
11. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
D. Mitton Expires: 25 Dec 99 [Page 3]
Internet Draft Extended RADIUS Practices June 1999
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 contin-
ues 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 proto-
col. These features use the RADIUS protocol struture 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 interoper-
able product.
1.1. Disclaimers
The data and numbers in this document have been gleened from public
sources and vendor documents along the way.
This document is a snapshot of practices at the time of writing. It is
not intended to standardize these practices here, or keep this document
current.
The author has not transcribed copyrighted material, and is not aware of
whether any of these practices have of intellectual property restric-
tions.
Any numeric assignments are subject to change by vendors without notice
to me. 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
D. Mitton Expires: 25 Dec 99 [Page 4]
Internet Draft Extended RADIUS Practices June 1999
- Attribute Data Types
- Message Codes
- New Operations
2. Attribute Usage
The RADIUS RFCs define attribute type ranges and specific attribute
definititions.
- 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.
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 Ascend clients. And Shiva
NASes 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.
The MERIT RADIUS server has a vendors file to describe the mapping to an
internal format in detail. The Bay SecureAccess Control server uses
multiple dictionaries, each tied NAS definition list.
2.2. Attribute Value Conflicts
Adding additional attributes may be more trouble than necessary for some
features. Often existing RADIUS attributes could be extended with addi-
tional values (particularly attributes that are enumerated choices).
But in doing such there is no way to guarantee lack of conflict with
other vendor's extentions.
D. Mitton Expires: 25 Dec 99 [Page 5]
Internet Draft Extended RADIUS Practices June 1999
2.2.1. Vendor Specific Enumerations proposal
One proposal, Vendor Specific Enumerations (VSEs), implemented by Bay
Networks, is to imbed the vendor's management ID in the numeric value
(ala VSAs) to divide up the space. This technique has not seen any
acceptance by other vendors, however, Bay did accomplish the goal of not
conflicting with standard or other vendor values.
Example dictionary of Bay VSE values:
#
# Define Bay Networks Vendor Specific Enumeration (VSE) values
#
VALUE Service-Type Annex-Authorize-Only 0x06300001
VALUE Acct-Status-Type Annex-User-Reject 0x06300001
VALUE Acct-Status-Type Annex-Call-Reject 0x06300002
VALUE Acct-Status-Type Annex-IPCP-Start 0x06300003
VALUE Acct-Status-Type Annex-IPXCP-Start 0x06300004
VALUE Acct-Status-Type Annex-ATCP-Start 0x06300005
VALUE Acct-Status-Type Annex-Accounting-Restart 0x06300006
VALUE Acct-Status-Type Annex-Accounting-Shutoff 0x06300007
VALUE Acct-Status-Type Annex-Tunnel-Start 0x06300008
VALUE Acct-Status-Type Annex-Tunnel-Stop 0x06300009
VALUE Acct-Status-Type Annex-Tunnel-Reject 0x0630000a
VALUE Acct-Status-Type Annex-Tunnel-Link-Start 0x0630000b
VALUE Acct-Status-Type Annex-Tunnel-Link-Stop 0x0630000c
VALUE Acct-Status-Type Annex-MP-Start 0x0630000d
VALUE Acct-Status-Type Annex-MP-Stop 0x0630000e
VALUE Acct-Status-Type Annex-Line-Seizure 0x0630000f
VALUE Acct-Status-Type Annex-Rlogin-Start 0x06300010
VALUE Acct-Status-Type Annex-Rlogin-Stop 0x06300011
2.3. Vendor Specific Attribute Usage
Because attribute 26 Vendor Specific Attributes (VSAs) came late in the
RADIUS WG development, there are some implementations that do not sup-
port them. However, there are several leading implementations of
clients that make extensive use of them.
2.3.1. VSAs in use by clients:
- Microsoft: several for MS-CHAP [10]
- ACC: 42 [13]
D. Mitton Expires: 25 Dec 99 [Page 6]
Internet Draft Extended RADIUS Practices June 1999
- Bay: about 60 VSAs and 16 VSEs
- 3Com (nee USR): about 130
USR VSAs are different than RFC suggested format. They have a 4
byte type field and have no internal length.
- Ascend: While they did not use VSAs initially, the latest version
(TAOS 7.0) contains the option to use VSAs instead of non-standard
regular attribute numbers.
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 implementation drafts add optional compound tag bytes for
tunnel attributes. These are a single byte prepended to the data field
in order for sets of attributes to be returned. The byte value must be
in the range 01-3F hex or it is considered to be data.
Ascend created two special attribute types within their server. 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. Ascend also created a
"phonestring" parsing server data type.
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 proto-
col to implement new functions.
D. Mitton Expires: 25 Dec 99 [Page 7]
Internet Draft Extended RADIUS Practices June 1999
6 Accounting Status
(now Interim Accounting in draft-radius-ext-04.txt)
7 Password Request - Livingston
8 Password Ack
9 Password Reject
10 Accounting Message
21 Resource Free Request -USR
22 Resource Free Response
23 Resource Query Request
24 Resource Query Response
25 Alternate Resource Reclaim Request
26 NAS Reb Request
27 NAS Reb Response
29 Next Passcode -Ascend
30 New Pin
31 Terminate Session
32 Password Expired
33 Ascend Event Request
34 Ascend Event Response
40 Ascend Disconnect Request
41 Ascend Disconnect Ack
42 Ascend Disconnect Nak
43 Ascend Change Filters Request
44 Ascend Change Filters Ack
45 Ascend Change Filters Nak
50 Ascend RADIPA Allocate
51 Ascend RADIPA Release
5. Additional Functions
These are operations performed using RADIUS extentions and additional
messages types.
5.1. Password Change
Remotely requested password change operations were proposed by Livings-
ton, but rejected by the working group. None the less, the feature is
still deployed in the Livingston product and some other servers.
Message types:
- Password Request
- Password Ack or Reject
D. Mitton Expires: 25 Dec 99 [Page 8]
Internet Draft Extended RADIUS Practices June 1999
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.
The Livingston 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 car-
riage returns and line-feeds. The new Echo attribute should also con-
trol echo behavior on the menu response. Use of the State attribute to
keep track of a Challenge sequence is also standard behavior.
The Ascend implementation uses two vendor attributes (Ascend-Menu-Item,
and Ascend-Menu-Selector as well as Ascend-Third-Prompt) to convey this
information. This implementation is vendor specific.
5.4. Pseudo Users
The Ascend 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 Message of the Day.
Bay Networks 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 Authorization-Only(Bay VSE). The
D. Mitton Expires: 25 Dec 99 [Page 9]
Internet Draft Extended RADIUS Practices June 1999
response must also be of the same Service-Type, or the response will be
ignored. The responding profile should contain the Annex-IP-Filter VSA
attributes that will define the desired filter.
It should be noticed that pseudo-user profiles could be a security prob-
lem 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 preform their services. The most typical is IP
addresses. The allocation may want to be delayed until needed or coori-
dinated on a scale independent of the RADIUS server. Additional mes-
sages may be used to allocate and free these resources. The RADIUS
server may proxy these requests to another server.
Examples: Ascend servers can allocate addresses local to the NAS or use
an outboard address server (RADIPAD) The BSAC server has an internal
address pool capability, which will fill in the Framed-IP-Address attri-
bute 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.
There are several different types of implementation techniques:
- USR - Explicit request/free requests
- Merit - Monitor usage with deamons
- Ascend - Explicit messages to a state deamon
- Bay - Monitor Accounting messages
6.2. Resource Management Messages
Messages used for resource management
- IP Address Allocate
- IP Address Release
- Resource Request
- Resource Response
- Resource Free Request
D. Mitton Expires: 25 Dec 99 [Page 10]
Internet Draft Extended RADIUS Practices June 1999
- Resource Free Response
- Resource Reclaim Request
- NAS Reboot Request/Reponse
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 enviroment. 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.
- Livingston, Aptis; SNMP commands
- Merit - Telnet monitor deamon
- Bay/SBR - 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
D. Mitton Expires: 25 Dec 99 [Page 11]
Internet Draft Extended RADIUS Practices June 1999
- Disconnect Request
- Disconnect Response
Filters are used to limit the access the user has to the network by res-
tricting the systems and protocols he can send packets to. Upon fulfil-
ling some registration with an authorization server, the service pro-
vider may wish to remove those restrictions, or disconnect the user.
7. Accounting Extentions
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.
7.1. Auditing/Activity
- 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 suprising that more implemen-
tations have not been made in this area.
8. Conclusions
In real life RADIUS Servers are becoming rather complex software imple-
mentations. 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.
D. Mitton Expires: 25 Dec 99 [Page 12]
Internet Draft Extended RADIUS Practices June 1999
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. Without standardiza-
tion 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 draft is not a complete survey by any means. If anything I apolo-
gize for it's current brevity. I would appreciate any input from ven-
dors or users on practices and details known, and particularly any
reference material you can pass me.
9. Implementation documents
Information about the following implementations can be obtained from the
respective owners. Most listed are availible from the manufacturer's
web site.
9.1. Clients:
- 3Com(USR) Total Control Hub
- Ericsson (ACC) Datacom Access
draft-ilgun-radius-accvsa-01.txt, Dec 1998
- Ascend MAX TNT software version 7.0.0
- Nortel (Bay Networks) Versalar 5399/8000 Remote Access Controller
- Livingston Portmaster
- Nortel (Aptis) CVX 1800
9.2. Servers:
- Ascend Access Control
- Ascend NavisAccess
- Ascend Modified Livingston
- BaySecure Access Control (Nortel)
- Funk Steel-Belted RADIUS
- Livingston V2.01
- Livingston ABM
- Lucent Port Authority
- MERIT AAA Server
D. Mitton Expires: 25 Dec 99 [Page 13]
Internet Draft Extended RADIUS Practices June 1999
10. References
[1] C. Rigney, et.al. "Remote Authentication Dial In User Service
(RADIUS)", RFC 2138, April 1977.
[2] C. Rigney, et.al. "RADIUS Accounting", RFC 2139, April 1977.
[3] C. Rigney, et.al. "Remote Authentication Dial In User Service
(RADIUS)", draft-ietf-radius-radius-v2-01.txt, May 1999
[4] C. Rigney, et.al. "RADIUS Accounting", draft-ietf-radius-
accounting-v2-01.txt, May 1999.
[5] C. Rigney, W. Willats, P Calhoun, "RADIUS Extensions", draft-ietf-
radius-ext-04.txt, May 1999
[6] G. Zorn, D. Leifer, A. Rubens, J. Shriver, "RADIUS Attributes for
Tunnel Protocol Support", draft-ietf-radius-tunnel-auth-06.txt, Sep-
tember 1998
[7] G. Zorn, D. Mitton, "RADIUS Accounting Modifications for Tunnel Pro-
tocol Support",draft-ietf-radius-tunnel-acct-02.txt, September 1999
[8] Aboba, Zorn, "Implementation of PPTP/L2TP Compulsory Tunneling via
RADIUS", draft-ietf-radius-tunnel-imp-03.txt, July 1997.
[9] G. Zorn, S. Cobb, "Microsoft PPP CHAP Extensions", draft-ietf-
pppext- mschap-00.txt, March 1998.
[10] G. Zorn, "RADIUS Attributes for MS-CHAP Support", draft-ietf-
radius-mschap-attr-01.txt, November 1997
[11] L. Blunk, J. Vollbrecht. "PPP Extensible Authentication Protocol
(EAP)." RFC 2284, March 1998.
[12] Calhoun, et.al. "Extensible Authentication Protocol Support in
RADIUS", draft-ietf-radius-eap-05.txt, May 1998.
[13] K. Ilgun, "RADIUS Vendor Specific Attributes for ACC/Ericsson
Datacom Access", draft-ilgun-radius-accvsa-01.txt, December 1998
[14] B. Aboba, M. Beadles, "The Network Access Identifier" RFC 2486, Jan
1999.
[15] D. Mitton, M. Beadles, "NASREQNG NAS Operational Model", draft-
ietf-nasreq-nasmodel-00.txt, June 1999
[16] G. Zorn, "Yet Another Authentication Protocol (YAAP)", draft-zorn-
D. Mitton Expires: 25 Dec 99 [Page 14]
Internet Draft Extended RADIUS Practices June 1999
yaap-01.txt, 30 June 1996
[17] N. Greene, "Best Current Practice for Modem Outsourcing", draft-
greene-nasreq-00.txt, March 1998
11. Author's Address
David Mitton
Nortel Networks
8 Federal St BL8-05
Billerica, MA 01821
978-288-4570
dmitton@nortelnetworks.com
12. Full Copyright Statement
Copyright (C) The Internet Society (May 1999). All Rights Reserved.
This document and translations of it may be copied and furnished to oth-
ers, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and dis-
tributed, 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 Stan-
dards 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 FIT-
NESS FOR A PARTICULAR PURPOSE."
D. Mitton Expires: 25 Dec 99 [Page 15]
