From ietf-radius-request Mon Apr 17 23:45:59 1995 Date: Mon, 17 Apr 1995 23:45:42 -0700 From: Carl Rigney Message-Id: <199504180645.XAA04848@server.livingston.com> To: ietf-radius@livingston.com Subject: Minutes of RADIUS BOF at 32nd IETF Cc: minutes@cnri.reston.va.us, mo@uunet.uu.net, sob@harvard.edu These are the minutes of the Remote Authentication Dial-In User Service (RADIUS) BOF session held Tuesday 95/4/4 15:30-17:30 EST at the 32nd IETF in Danvers MA, under the Operational Requirements Directorate. There were 42 attendees; a list is attached below. I would like to thank Larry Brandt (Brandt_Lawrence_R/svoa0001@ssb.com) for forwarding to me his notes taken during the RADIUS BOF, which were very helpful in producing these minutes. Any omissions or errors should be ascribed to myself. Carl Rigney (cdr@livingston.com) chaired the BOF session, and started by providing some historical background on RADIUS, noting that it has now been in production use at many sites for 2+ years. First question: Do we want a Working Group for RADIUS? There was strong consensus for yes. Mr. Rigney agreed to provide a draft charter and timeline to the ietf-radius@livingston.com mailing list by 4/17. Second Question: Should RADIUS be put on a 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's how it will work, but there's no requirement that you must support RADIUS in your NAS (Network Access Server)." There was a question regarding Cisco & 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. Mr. Rigney 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 records includes an elapsed time attribute to make it easier to determine usage. 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. Most of the remainder was taken up in a discussion of the Proposed Charter, with Mr. Rigney agreeing to provide a draft of the consensus by 4/17. Elements generally considered desirable for the charter included: - documenting RADIUS implementation as it exists today, and not attempting to create "the perfect protocol." - 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. - RADIUS was designed to be very simple, and avoids the clutter of every possible attribute. The burden on the NAS should be kept light. - Use of RADIUS to support 3rd 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. - 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 & Authorization server Mike O'Dell nicely phrased it as a "service definition language for user access." - how 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 - CAT framework _could_ sit behind radius, but outside scope of our charter - interacts with DHCP but doesn't overlap - Definite strong consensus to include notes on how to handle PPP CHAP with RADIUS - Add attributes for Appletalk over PPP and LAT for those vendors who support those protocols, in addition to IP and IPX already present - RADIUS is not a NAS management protocol, and does not take place of SNMP - 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. - 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. - Charter is for standardized RADIUS not standardized NAS! - RADIUS for IPv6 appears straightforward, but is outside this charter - RADIUS over alternate transport protocols like IPX appears straightforward but is outside this charter Consensus was 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 Net Management group re 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 '95 timeframe to get as many vendors as possible in a room to test their independent implementations for interoperability and vagueness in the spec. Two attendees expressed interest in possibly hosting such a bake-off and plans for such will be followed up via the RADIUS mailing list, ietf-radius@livingston.com. Discussion of 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 other document. Mr. Rigney agreed to flesh out proposed timeline and submit it to ietf-radius@livingston.com mailing list (also attached below, but bear in mind it may change based on reaction from working group). General consensus was that the timeline was aggressive but feasible, particuarly 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: 4/17 Carl Rigney to send out BOF minutes, draft timeline, draft charter 5/01 Carl Rigney to send RADIUS Draft 3 to ietf-radius mailing list Proposed Timeline for RADIUS Standards-Track RFC 95/04/17 BOF Minutes, draft proposal, draft timeline to ietf-radius list 5/01 Draft 03 to list 5/15 Comments on Draft due in to Editor 5/29 Draft 4 submitted to IETF for Proposed Standard 6/05 Last Call issued 6/19 All comments on Last Call due 6/26 Issued as Proposed Standard 9-10/TBD RADIUS Bake-off to test interoperability 11/06 Clarifications need due to bake-off to be integrated by Editor within 1 month 12/04-08 34th IETF Dallas - RADIUS WG meets to deal with any pending issues re advancement to Draft Standard 96/01/02 Submitted to IETF for Draft Standard 1/09 Last call issued 1/23 All comments on last call due 2/02 Issued as Draft Standard 4/TBD 35th IETF - RADIUS WG meets to deal with any pending issues re advancement to Standard; last meeting 5/27 Submitted to IETF for Standard 6/03 Last Call Issued 7/01 All comments on Last Call complete Timeline for RADIUS Accounting Experimental RFC: 95/07/10 RADIUS Accounting 1st draft to list 7/31 Comments due 8/14 2nd Draft to list 8/28 Comments due 9-10/TBD RADIUS Bakeoff 11/06 Clarifications need due to bake-off to be integrated by Editor within 1 month 12/04-08 34th IETF Dallas - RADIUS WG meets to deal with any pending issues re Accounting 12/18 Submitted to IETF as an Experimental RFC 96/01/02 Last Call 1/16 Last Call comments due 1/30 Issued as Experimental RFC Attendee List 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 Carl Rigney cdr@livingston.com Mike O'Dell mo@uunet.uu.net John Shriver jas@shiva.com Sajit Bhaskaran sajit@dcsd.sj.nec.com Larry Brandt Brandt_Lawrence_R/svoa0001@ssb.com Jim Fenton fenton@combinet.com Jim Barnes barnes@xylogics.com Shane Davis shane@delphi.com Stephen Mattin stephin@delphi.com Diego Cassinera diego@delphi.com Ken Culbert ken@funk.com Brad Steinka bsteinka@microcom.com Richard Martin rmartin@sprint.net David Carrel carrel@cisco.com Dan VanBelleghem vanbelld@bah.com Scott Wasson sgwasson@eng.xyplex.com Glen Zorn gwz@cybersafe.com Tim Taylor ttaylor@csi.compuserve.com Rick Huber rvh@qsun.att.com Jan-Olof Jemnemo moon@intg.telia.se Gerry Meyer gerry@spider.co.uk Lowell Gilbert lowell@epilogue.com Jisoo Geiter geiter@mitre.org Jaha-Pekka Ahopelto jaha-pekka.ahopelto@ntc.udia.com Charles Young charles.e.young@att.com Allan Rubens acr@merit.edu Larry Blunk ljb@merit.edu Cynthia Martin martin@spica.disa.mil Mike Oehler mjo@tycho.ncsc.mil Jesse Walker walker@nacto.lkj.dec.com Dave Nelson d_nelson@took.enet.dec.com Todd Palgut todd@nei.com Derek Lichter ddl@clipper.ssb.com Carol Ladd carol@cayman.com Jeff Koniszewski jeffk@cayman.com Randy Roberts randy@acc.com Tony Ballardie a.ballardie@cs.ucl.ac.uk Ed Allen eallen@baynetworks.com Hascall Sharp hhs@teleoscom.com David Kaufman david@mmac.com Maria Gallagher mgallagh@atlas.arc.nasa.gov Kip Bryan kip@delphi.com