CURRENT MEETING REPORT


Reported by, Carl Rigney, Livingston Enterprises, Inc.

Minutes of the Remote Authentication Dial In UserService BOF
(RADIUS)


The second RADIUS BOF (Remote Authentication Dial In User
Service) was held 12/5/95 at the 34th IETF in Dallas Texas.


RADIUS

Draft draft-ietf-radius-radius-01.txt was reviewed.  A few places were
noted to be clarified or corrected in the next draft, to come out in
January.  The following changes to that draft were recommended:

For the Service-Type (6) attribute, Exec-User (value 7) is to be
renamed as Shell-User since that's the more common usage.  There
was a request to add a value for Callback Administrative User,
which will be 9.

There was discussion of the Framed-Route attribute and the language
in draft 01 that describes its format.  General consensus was happy
with that language.

There was a request to clarify that the Access-Request that replies to
an Access-Challenge may itself be replied to with another Access-
Challenge.

There was a request to make it clearer that "client" referred to a NAS
or to another server acting as a proxy.

There was consensus to delete the proposed NAS-Port-Id attribute
(61) and replace it with a NAS-Port-Type attribute that together
with the existing NAS-Port attribute (5) could be used by vendors
that number different kinds of ports from the same base number (e.g.
bri0 and async0).  NAS-Port-Type would be Attribute 61, encoded as a
32-bit integer with the following suggested values:

0       Async
1       Sync
2       ISDN Sync
3       ISDN Async V.120
4       ISDN Async V.110

The Keyed MD5 approach to protecting the User-Password (2)
Attribute when extending it from 16 characters to 128 was discussed.
The Security Area will be consulted as to whether this is a valid
approach.

There was a brief discussion of how to define an SNMP MIB for
RADIUS Servers; members of the working group familiar with useful
SNMP MIB definition are requested to make their presence known if
they have the time to help on that.

There was considerable interest in holding a RADIUS Bake-off in the
March timeframe, probably in the two days preceding the 35th IETF in
Los Angeles, in order to check interoperability of client and server
implementations.  Test plans should be drawn up in advance.


RADIUS ACCOUNTING

On the latest accounting draft draft-ietf-radius-radius-01.txt there
was consensus for Accounting-On and Accounting-Off with a request to
add more text explaining their usage.  Merit requested moving the
value of Accounting-On to 7 and Accounting-Off to 8, which was
accepted.

There was much discussion of Checkpointing, friend or foe, with it clear
that in some circumstances it wasn't useful, but there may be
circumstances in which it is.  Value 3 of Acct-Status-Type is
recommended for implementers who wish to experiment with
checkpointing and report their results back to the working group.

Values of Acct-Terminate-Cause were discussed, along with whether
any others were needed; people with ideas for other values are
requested to submit those to the working group mailing list or the
document editor by early January.

Adding a new packet type for Accounting-Reject (so an accounting server
could tell the NAS to go to its backup, instead of just not replying) was
discussed and rejected as complicating the protocol while not adding
sufficient benefit.


CHARTER

There was strong support to revise the charter in two ways: 1) to issue
the current draft, plus any minor changes for clarification, either as a
Proposed Draft by January or February, or if that wasn't possible to
issue it as an Informational RFC in that time frame and then continue
work on getting it onto a standards track.  2) To start a separate effort
within the working group to gather and document useful extensions
based on field experience with implementations, and issue that as a
later RFC along its own track.  The amended charter is included below.

The end purpose of this group is to produce four documents:

1) By early 1996, 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 in January, 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.

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.


CONTACT INFORMATION

A mailing List is available at [email protected].  To
join, send email to [email protected] with
"subscribe" in the body of the message.

Archives and working documents directory can be found at:

ftp://ftp.livingston.com/pub/radius/archive/
ftp://ftp.livingston.com/pub/radius/draft-ietf-radius-
radius-01.txt
ftp://ftp.livingston.com/pub/radius/draft-ietf-radius-
accounting-01.txt

The Document Editor is Carl Rigney of Livingston Enterprises, and can
be reached via email at [email protected].

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.