NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 18-Mar-98
Chair(s):
Carl Rigney <cdr@livingston.com>
Operations and Management Area Director(s):
John Curran <jcurran@bbn.com>
Michael O'Dell <mo@uu.net>
Operations and Management Area Advisor:
John Curran <jcurran@bbn.com>
Mailing Lists:
General Discussion:ietf-radius@livingston.com
To Subscribe: ietf-radius-request@livingston.com
In Body: subscribe ietf-radius
Archive: ftp://ftp.livingston.com/pub/radius/archive
Description of Working Group:
Background:
The original specification for and implementation of RADIUS was written by Steve Willens of Livingston Enterprises in response to a need outlined by the earlier NASREQ working group, and has been deployed by multiple vendors over the past 3 years.
No other working group appears to be addressing the topic of communicating authentication and authorization information between a Network Access Server and a central authentication & authorization server, and general consensus is that standardization of such a protocol would be extremely useful.
This working group will produce four documents:
1) By early '96, an informational RFC documenting the RADIUS protocol already deployed for use by a Network Access Server (NAS) to communicate with a remote Authentication & Authorization database server, with minor amendments reflecting field experience of several implementations over several years at hundreds of sites.
2) By February '96, an informational RFC describing RADIUS Accounting.
3) By early '97, a full standard RFC documenting the RADIUS protocol, addressing any operational or security issues raised concerning the informational RFC. This document will obsolete goal 1. (If the Internet-Draft for goal 1 is deemed suitable by the IESG for release as a Proposed Standard instead of informational, then goals 1 and 3 will be merged.)
4) Starting in February '96 and concluding in '97, a RADIUS Extensions RFC documenting extensions for additional functionality within the RADIUS framework, which will be interoperable with the base RADIUS defined in the document for goal 3.
The intent in goals 1 through 3 are to document the protocol as it exists and is used currently, in such a way as to allow interoperable implementations to be written from the RFC. Minor modifications to enhance interoperability or operation based on field experience are suitable, major overhauls are outside the scope of this working group's charter. Goal 4 is to provide a mechanism for additional features deemed widely useful to be added to the existing framework, for example to provide better support for EAP.
Clearly outside the scope of the charter are the following:
1) NAS Standardization is outside the scope. We're defining standard RADIUS, not a standard encompassing everything about network access servers. This effort does not require NASes to implement RADIUS; it just defines how the RADIUS Protocol works on NASes that do implement RADIUS.
2) RADIUS is not intended as a NAS management protocol; SNMP already exists for that.
3) Management of the Authentication/Authorization database itself is outside the scope.
4) Alternative transport protocols such as IPX or IPv6 appear straightforward, but will not be addressed in this effort.
5) The flexibility and generality of RADIUS have led to its use for other applications, but this Working Group is addressing only those uses involving user dial-in to Network Access Servers.
Goals and Milestones:
Done |
|
Meet at Dallas IETF. |
Done |
|
Submit revised Radius Accounting Internet-Draft. |
Done |
|
Submit revised Radius Internet-Draft. |
Jan 96 |
|
Submit Radius Accounting Internet-Draft to IESG for consideration as an Informational RFC. |
Jan 96 |
|
Submit Radius Internet-Draft to IESG for consideration as an Informational RFC. |
Feb 96 |
|
Submit Internet-Draft on Radius Extensions. |
Mar 96 |
|
Meet at LA IETF to deal with any pending issues on Radius or Radius Accounting Internet-Drafts. |
Apr 96 |
|
Submit Radius protocol Internet-Draft to IESG for consideration as a Proposed Standard. |
May 96 |
|
Submit revised Radius Extensions document as Internet-Draft. |
Nov 96 |
|
Submit Radius Protocol to IESG to be considered for elevation to Draft Standard. |
Internet-Drafts:
· Implementation of PPTP/L2TP Compulsory Tunneling via RADIUS
· RADIUS Attributes for Tunnel Protocol Support
· Extensible Authentication Protocol Support in RADIUS
· RADIUS Extensions
· RADIUS Accounting Interim Accounting Record Extension
· RADIUS Accounting Client MIB
· RADIUS Accounting Server MIB
· RADIUS Authentication Client MIB
· RADIUS Authentication Server MIB
· RADIUS Attributes for MS-CHAP Support
· RADIUS Attributes for MS-CHAP Support
· RADIUS IP Security Extensions
· RADIUS Accounting Modifications for Tunnel Protocol Support
· Salt-Encryption of RADIUS Attributes
· RADIUS Attributes for Multilink PPP Bandwidth Allocation Control
· RADIUS Attributes for Multilink PPP Bandwidth Allocation Control
Request For Comments:
RFC |
Status |
Title |
RFC2139 |
RADIUS Accounting | |
RFC2138 |
PS |
Remote Authentication Dial In User Service (RADIUS) |
Minutes of the Remote Authentication Dial-In User Service (radius) Working Group
The Working Group met Tuesday March 31st, 1997 15:45-18:00 at the 41st IETF Meeting in Los Angeles, with 73 attending.
This was the last RADIUS Working Group session, as the group's work is nearly complete and the remaining matters can be dealt with on the mailing list, ietf-radius@livingston.com.
Consensus was to allow zero or more instances of Connect-Info in an Accounting-Request packet (instead of zero or one), to accommodate expected efforts by ITU to have modems report more connection information in a standard format that might exceed 252 octets. The requirement that the connect speed be at the start of the string will be changed to suggest (but not require) that the first instance of Connect-Info in a packet start with the connection speed.
There was discussion on whether an attribute for Vendor ID might be a good idea, but no consensus was reached, with discussion to be taken to the mailing list.
Status and disposition of existing WG drafts was settled:
RFC 2138 will have language clarified and be submitted to last call for advancement to Draft Standard. RFC 2139 will likewise be cleaned up a bit and submitted as an updated informational RFC.
draft-ietf-radius-ext-01.txt will be updated to incorporate
draft-ietf-radius-acct-interim-01.txt and draft-ietf-radius-eap-04.txt and submitted to the working group, and after feedback to clean up the draft will be submitted to working group last call and then IETF last call as a proposed standard.
draft-ietf-radius-tunnel-auth-04.txt and draft-ietf-radius-tunnel-imp-03.txt will be submitted for last call for advancement to proposed standard.
draft-ietf-radius-tunnel-acct-02.txt will be submitted for last call for informational.
The 4 RFCs on MIBs for RADIUS servers and clients will be submitted as informational RFCs to go along with the advancement of RFC 2138 on the standards track:
draft-ietf-radius-acc-clientmib-01.txt
draft-ietf-radius-acc-servmib-01.txt
draft-ietf-radius-auth-clientmib-01.txt
draft-ietf-radius-auth-servmib-01.txt
There was discussion on what mechanism to use for post-WG attribute allocation, and general consensus was that allocation should be done through formal working groups, with existing Working Groups in other areas able to request an attribute for their use if related to RADIUS. Language will be added as part of the update to Draft Standard describing attribute allocation (or perhaps as a separate memo).
There was consensus that experimental attributes 192-254 be "cleared out" by adding disapproving language towards implementations that are still using those attributes rather than the Vendor-Specific Attribute.
The Mobile IP working group may request a RADIUS attribute for their efforts, and will send the appropriate information to the mailing list.
There was discussion on whether proxy forwarding servers should flood Accounting-Start packets with an Acct-Status-Type of Accounting-On to all their remote servers. It was agreed to mention this in considerations for RADIUS proxy implementers, but not require it.
More details on RADIUS Proxy are desirable, and that section of RFC 2138 and 2139 will be extended and clarified to point out areas that need careful attention, and to discuss security considerations in more depth. In particular, the use of shared secrets means that the NAS and remote server are vulnerable to man-in-the-middle attacks on the forwarding server.
The Working Group Chair would like to thank the working group members who put so much effort into making RADIUS a success; it was a privilege to work with you all.
None Received