Remote Authentication Dial-In User Service BOF (RADIUS) Reported by Carl Rigney/Livingston Enterprises The RADIUS BOF met on Tuesday, 4 April, at the 32nd IETF in Danvers, Massachusetts. There were 42 attendees. The chair, Carl Rigney, would like to thank Larry Brandt for forwarding his notes taken during the RADIUS BOF, which were very helpful in producing these minutes. Any omissions or errors should be ascribed to Carl. Mailing list information for the group: Mailing list: ietf-radius@livingston.com Request address: ietf-radius-request@livingston.com Request command: subscribe ietf-radius Archive: ftp://ftp.livingston.com/pub/radius/archive General Discussion Carl started the session by providing some historical background on RADIUS, noting that it has now been in production use at many sites for over two years. First question: Do we want a Working Group for RADIUS? There was strong consensus for yes. Carl agreed to provide a draft charter and timeline to the group mailing list by 17 April. Second Question: Should RADIUS be put on the standards track? There was strong consensus for yes. Clarification was requested on what ``standards track'' implied, and it was explained as meaning ``If you choose to support RADIUS here is how it will work, but there is no requirement that you must support RADIUS in your NAS (Network Access Server).'' There was a question regarding Cisco and Livingston's recent announcement regarding TACACS+ and RADIUS, but no one present had any further information regarding Cisco's plans in that regard. There was a question as to whether the next revision of the RADIUS draft should include a table summarizing which kinds of attributes were appropriate for which kinds of packet types. There was extremely strong consensus for yes. Carl described RADIUS Accounting briefly. It uses UDP/IP to send start- and end-of-service records, but is acknowledged, buffered, and includes an accounting session ID to make it easier to match up records. The end-of-service record includes an elapsed time attribute to make it easier to determine usage. It also includes other attributes detailing type of service, address used, NAS and Port used, etc. There was a question on whether RADIUS Accounting should be included with the rest of the RADIUS RFC or as a separate RFC, and if the latter, whether it should be standards-track or Experimental. General consensus was that RADIUS Accounting was much newer and more likely to change with further experience than the rest of RADIUS, and therefore should be issued as a separate, Experimental RFC for now. Charter Discussion Most of the remainder was taken up in a discussion of the proposed charter, with Carl agreeing to provide a draft of the consensus by 17 April. Elements generally considered desirable for the charter included: o Documenting RADIUS implementation as it exists today, and not attempting to create ``the perfect protocol.'' o The RADIUS protocol is the packet format and attributes used to communicate between the NAS and the server. Specifics of the server implementation (e.g., data dictionary or otherwise) should not be specified. o RADIUS was designed to be very simple, and avoids the clutter of every possible attribute. The burden on the NAS should be kept light. o Use of RADIUS to support third party security (Kerberos, SafeWord, SecurId, etc.) -- handling of challenge/response should be documented with perhaps some notes in an appendix on implementation factors to consider. o Protocol is not intended to be all things for all uses, the RFC is intended to cover RADIUS as a protocol for Network Access Servers to speak with an Authentication and Authorization server Mike O'Dell nicely phrased it as a ``service definition language for user access.'' o How the user is authenticated is outside of the protocol; the protocol addresses how the NAS passes that information to the RADIUS server and how it gets back the results. o The CAT framework could sit behind RADIUS, but that is outside the scope of our charter. o Interacts with DHCP but does not overlap. o Definite strong consensus to include notes on how to handle PPP CHAP with RADIUS. o Add attributes for Appletalk over PPP and LAT for those vendors who support those protocols, in addition to IP and IPX already present. o RADIUS is not a NAS management protocol, and does not take the place of SNMP. o RADIUS is not a protocol for managing the user service database, but only for communicating between the NAS and such a database. Therefore radpass is still deprecated. o RADIUS server-to-server calls (Proxy) need not be addressed in the RFC, but the protocol should keep in mind that many people may intend to use it that way and should make it easy to do so. In particular, server-to-server communications should look like NAS-to-server communications, to the server being called. o The charter is for standardized RADIUS not standardized NAS! o RADIUS for IPv6 appears straightforward, but is outside this charter. o RADIUS over alternate transport protocols like IPX appears straightforward but is outside this charter. Consensus was reached for the charter to be tightly focused on producing two documents: 1) RADIUS as it exists and 2) RADIUS Accounting, and not get lured down new alleys to solve every problem under the sun. For RADIUS Accounting, feedback is sought from developers of NAS user accounting. It was pointed out that new standards require a MIB, and suggested that the RADIUS Working Group should approach the Network Management Area concerning developing a small MIB for the RADIUS server. Clients do not require MIBs. There was general and widespread interest in holding a RADIUS bake-off in the September or October 1995 timeframe to get as many vendors as possible in a room to test their independent implementations for interoperability and vagueness in the specification. Two attendees expressed interest in possibly hosting such a bake-off and plans for such will be followed up via the RADIUS group mailing list. Discussion of a timeline suggested putting a Proposed Standard out in the next month or so, meet at the Dallas IETF in December 95 before advancing to Draft Standard, and work towards June 96 for Standard. Accounting should be issued as an Experimental RFC, offset approximately one IETF from the other document. Carl agreed to flesh out a proposed timeline and submit it to the group mailing list (also attached below, but bear in mind it may change based on reaction from the working group). General consensus was that the timeline was aggressive but feasible, particularly since implementations already existed and were operating in the field, and much of the work on the Internet-Draft has already been done. Action Items o 17 April 95 -- Carl Rigney to send out BOF minutes, draft timeline, and draft charter o 1 May 95 -- Carl Rigney to send RADIUS Draft 3 to the mailing list Timelines Proposed Timeline For RADIUS Standards-Track RFC: 17 April 95 BOF Minutes, draft proposal, draft timeline to the mailing list 1 May 95 Draft 3 to the mailing list 15 May 95 Comments on Draft due to the editor 29 May 95 Draft 4 submitted to the IESG as a Proposed Standard 5 June 95 Last Call issued 19 June 95 All comments on Last Call due 26 June 95 Issued as a Proposed Standard TBD Sept/Oct 95 RADIUS Bake-off to test interoperability 6 November 95 Necessary clarifications, resulting from the bake-off, to be integrated by the editor within one month 4-8 December 95 34th IETF, Dallas -- RADIUS Working Group meets to deal with any pending issues concerning advancement to Draft Standard 2 January 96 Submitted to the IESG as a Draft Standard 9 January 96 Last call issued 23 January 96 All comments on Last Call due 2 February 96 Issued as a Draft Standard TBD April 96 35th IETF -- RADIUS Working Group meets to deal with any pending issues concerning advancement to Standard; last meeting 27 May 96 Submitted to the IESG as a Standard 3 June 96 Last Call issued 1 July 96 All comments on Last Call complete Proposed Timeline for RADIUS Accounting Experimental RFC: 10 July 95 RADIUS Accounting first draft to the mailing list 31 July 95 Comments due 14 August 95 Second Draft to the mailing list 28 August 95 Comments due TBD Sept/Oct 95 RADIUS Bake-off 6 November 95 Necessary clarifications, resulting from the bake-off, to be integrated by the editor within one month 4-8 December 95 34th IETF Dallas -- RADIUS Working Group meets to deal with any pending issues concerning Accounting 18 December 95 Submitted to the IESG as an Experimental RFC 2 January 96 Last Call 16 January 96 Last Call comments due 30 January 96 Issued as an Experimental RFC