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:
[email protected]
Request address:
[email protected]
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
