From cdr Fri Mar 22 22:08:21 1996
Received: (from cdr@localhost) by server.livingston.com (8.7.1/8.6.9) id WAA09917; Fri, 22 Mar 1996 22:08:21 -0800 (PST)
Date: Fri, 22 Mar 1996 22:08:21 -0800 (PST)
From: Carl Rigney <cdr>
Message-Id: <199603230608.WAA09917@server.livingston.com>
To: ietf-radius
Subject: RADIUS WG Minutes from 35th IETF
Status: R

Four hours of meeting is roughly 240 pages of written text and the IETF
Proceedings ask that minutes take no more than 6 pages, so my apologies
in advance to anyone whose words or thoughts are hereby squeezed.  The
suggestions for draft clarifications will appear in Draft 3 coming out
shortly, and assorted matters addressed in brief in the limited time
available at the working group will be treated in greater length on the
mailing list in the forthcoming month.  I would like to heartily thank
Dave Nelson for the use of his notes in preparing these minutes; any
mistakes, errors or mangled syntax here-in should be laid only at my
doorstep.




Minutes of the RADIUS IETF Working Group Session #1 held
Monday March 4, 1996 at the 35th IETF in Los Angeles, CA.

Reported by Dave Nelson (d_nelson@irocz.lkg.dec.com) and Carl Rigney
(cdr@livingston.com).

First session dealt with draft-ietf-radius-radius-02.txt and
draft-ietf-radius-accounting-02.txt, possible extensions dealt with in
the second session.  Attendance at one session or both was 95 (plus 45
via MBONE in the first session).


Recent Interoperability Experience from 3/2-3 was summarized.  16
implementors participated with 9 servers (half based on Livingston's
1.16 reference implementation, half independent implementations) and 14
clients testing several forms of interoperation in a 9x14 matrix.
Thanks were expressed to Glenn Zorn of Microsoft and Dave Nelson of
Digital for their efforts in organizing and creating a test plan.
Things went well, with no major problems discovered.  It may be useful
to hold another, bigger, interoperability test in six months or so, since
some implementors weren't ready to test yet or weren't able to make it
to this one given the short notice.  Merit has volunteered to host the
next one in Michigan if that is convenient.

The Keyed MD5 algorithm for hiding User-Passwords was discussed.  The
Security Area is reported as liking the scheme in Draft 02 much better
than the method used in Draft 00, and will examine it in more depth.
The issue of interoperability with the old method was raised but only
one vendor reported deploying code based on the old method so there's
no plan to support the obsolete method in the draft.  Servers that want
to be backwards compatible can try both methods, but that won't work
with Proxies.

A show of hands was asked for to identify implementors working on
adding the Appletalk and LAT attributes; they had no problems to
report.

Various people had requests to clarify Draft 02 in a handful of
places.  The Document Editor will make the necessary updates and send
Draft 03 of both RADIUS and RADIUS Accounting out for a two week
Working Group last Call by the end of March and incorporate any changes
from that, then RADIUS Draft 04 will be sent to the IESG to do a
two-week IETF Last Call and to issue it as a Proposed Standard.  RADIUS
Accounting Draft 04 will be sent to the RFC editor in April to be
issued as an informational RFC.

There was a suggestion to use 0xFFFFFFFE instead of 0x0 in
Login-TCP-Host to mean the NAS should assign a host for the user, but
it was felt that there was no point in breaking existing
implementations just to be tidy.

It was pointed out that the RADIUS Accounting Draft has a conflict in
what attributes are allowed in which types of packets.  The Document
Editor will add clarifying language pointing at The Table of Attributes
as the definitive word.

Is the RADIUS 02 Draft ready for submittal as proposed standard?  The
only outstanding issue besides clarification was how a RADIUS server
should identify the client.  Existing implementations use the source IP
address of the access-request UDP datagram, which makes proxy very easy
to do.  There was discussion over whether the RADIUS server should use
the NAS-IP-Address or NAS-Identifier attributes instead of the source
address, but then proxies have to spoof being a NAS and that's
undesirable.  One possibility would be to add a Client-Identifier which
if present could be used in place of the source UDP address, which
allows interoperability with existing implementations a future path to
avoiding using IP addresses for identification purposes.  A key point
was established that the UDP IP source address is NOT used for
authentication of the client, but only as an identifier telling the
RADIUS server which shared secret it should look up to establish the
client's identity.  That'll be useful in the future if network address
translation gateways become more common.

There was extensive discussion of whether to define the format of the
Callback-Number attribute, which contains a number used for calling
back from a modem or ISDN.  It should exclude any modem initialization
commands.  Should we use or reference the phone number formats that PPP
specifies?  One suggestion is that this field is a Telephone System
Network Address.  Discussion continued in the second session, and
eventual conclusion was that for now it should be left as
undistinguished octets, since the RADIUS administrator is going to need
to configure it to be whatever number or value his NAS needs in order
to call back.

Access-Request hints were discussed.  The next draft will clarify their
usage and that it is OK for servers to ignore hints sent by the NAS.  A
proposal to allow multiple service types in the same access-accept was
rejected since it requires the NAS to make a decision, and the RADIUS
model has all the intelligence in the RADIUS server - the NAS just
follows orders.  A proposal was made that vendors who wish to specify a
set of permissions for the user should use either Access-Challenge or
the NAS-Prompt or the Authenticate-Only Service-Type to implement that,
with permission bit vectors, if needed, encoded within Vendor-Specific
attributes.  A suggestion was made that the implementors who support
NAS-Prompt features might want to work together to specify similar
mechanisms.

A question was uncovered in the Recent Interoperability Experience as
to what should happen if the NAS chooses one, and the RADIUS server has
been configured to want the other.  In particular, what if the NAS
negotiated PAP authentication with the user and sends that, but the
RADIUS server has been configured to use CHAP.  Should the user get
authenticated, or rejected?  The choice of authentication method is a
NAS configuration issue.  One view suggests that if a site wants only
to do CHAP then the RADIUS server should reject PAP even if the NAS
through misconfiguration accepted PAP.  Another view points out that
since the PAP password is encrypted between the NAS and the RADIUS
server that there's no additional exposure so the password should be
accepted rather than rejecting the user after the NAS already settled
on PAP authentication, resulting in a confused user having to call the
NAS administrator to be able to get in.  Another view suggests that
both views are right - this is a site security policy issue outside the
scope of the RADIUS protocol itself and server implementors should
implement hooks for whichever policy their customers prefer.  The
eventual deployment of EAP may make this a moot question, anyway.

A desire was expressed to have a NAS-Port type of "virtual" to handle
TCP connections into a NAS (such as Telnet) rather than serial
connections.  This seemed reasonable so an attribute value will be
allocated for it in the next draft.

There was discussion on the values for Account-Terminate-Cause, and as
to whether the current sixteen are too many, or if a few more are
needed.  A balance is desired between having enough to distinguish
between significantly different forms of session termination, but not
having so many that implementing it is burdensome.  Some vendors who
integrate modems into their NASes pointed out that they could have
scores of cause codes, but since they'll be vendor-specific anyway they
plan to use a Vendor-Specific attribute to specify the details.
Attendees seemed generally content with the sixteen existing so far.



Minutes of the RADIUS IETF Working Group Session #2 held 
Tuesday March 5, 1996 at the 35th IETF in Los Angeles, CA.

The second session was devoted to the RADIUS Extensions Draft-to-be,
and various presentations were made by assorted people and the list of
proposed experimental extensions was discussed.  The Document Editor
and others will send more detailed information to the mailing list in
the next two months so that the merits of various approaches can be
debated, and sample implementations done.  None of the proposals appear
at this time to require any changes in the existing RADIUS Draft; they
just add new Attributes and functionality in a manner similar to PPP
Extensions, without affecting existing functionality.

The session began with the chair illuminating the scope of possible
extensions.  RADIUS is not a NAS configuration or management protocol,
and it is not a replacement for SNMP or DHCP and should avoid overlap
with existing protocols.

Next came brief presentations from various people raising issues to be
possibly considered in the extensions.

Dennis Pinkas of Groupe Bull talked about GSS API from the CAT working
group.  GSS API tokens can authenticate a user.  They can be quite
large.  The 253 byte size limitation for a RADIUS attribute requires
breaking the GSS API token up into chunks, so he suggested thinking
about a new attribute type that would have a longer length field.
Various types of tokens exist, some of which have ASN.1 byte
definitions.  Dennis requested support for GSS API tokens, as defined
in the GSS API docs.  The CAT document covering GSS API is
draft-ietf-gssv2-05.txt in section 4.1.

Dan Mongrain of Gandalf talked about the use of RADIUS to authenticate
remote devices connected over a WAN network cloud to another NAS,
involving two layers of authentication are: the link from remote to the
NAS, and the actual remote user on the remote NAS.  This amounts to
authentication for firewall traversal.  There are problems of trust
between the owner of the local NAS and the owner of the remote NAS
since you can't trust user authentication at the remote NAS if its a
different organization.

Pat Calhoun of U.S. Robotics proposed an alternate packet format and
requested that Packet Type 255 be reserved for some future alternate
format.  Features of his proposal include: longer ID field, longer
length field, digital signature field, flag field, version field,
provision for different encryption types.  It was pointed out that
different encryption types are already being handled by IPSEC and it
may not make sense to duplicate their effort.  It was agreed to reserve
Packet Type 255 for a future version of RADIUS packet format if that
turns out to be necessary someday.

Alan Rubens of Merit presented a summary of John Vollbrecht's recent
memo.  PPP EAP (Extended Authentication Protocol) can be supported
without major changes to RADIUS.  Merit would like a way to tell a NAS
to hold off on trying a backoff server, larger ID fields and larger
fields for nearly everything, more detailed session accounting, and
stronger hooks and stricter timing for use in resource management.
SNMP could be used for some of these except it's insecure.  Merit would
like to be able to decide whether to accept an incoming call before any
authentication information is presented (for example, from the ISDN
D-channel DNIS information).

Following the presentations there was a discussion of the use of
experimental attribute numbers.  If they get shipped in someone's code
do they ever get removed or reallocated?  Vendors will resist changing
their code to remove experimental numbers.  Should we just assign the
next available number for experimental use, assuming that it might
become permanent and standardized?  There seems to be no consensus on
this.  The PPP Extensions WG uses IANA to assign its numbers.

Some people are worried about running out of attribute space, but the
call for extensions only netted another 12 general attributes in
addition to the 50 that exist so far, so 255 still seems like plenty.
Six of the 12 were to add support for ARA, and in practice fewer may be
needed for actual implementation.

Various proposed extensions were then discussed, to evaluate whether
they should be placed in the RADIUS Extensions Experimental Draft for
possible implementation.

Considerable interest was expressed in Echo suppression to control NAS
behavior for Challenge-Response mechanisms.

There was interest in returning modem connect data such as speed, and
discussion on whether to return as a string or have the NAS parse it
into specific variables.  Rough consensus was to have it as
undistinguished ASCII octets unless some standard arises among modem
vendors, but connect speed should be at the start of the string.  It's
probably desireable to allow the string to be used in both
Access-Requests and Accounting-Requests?

A possible "Alert" attribute that would turn on debug flags or enable
intrusion detection sounded very vendor specific, and not much interest
was shown, so it won't be included for now.

Since ARA allows specification of the number of password retries, there
was some interest in extending the concept of Password-Retry generally,
so that number of password retries allowed could be configured on a
per-user basis.  A counter-argument was that this is a NAS
configuration issue outside the scope of RADIUS.  Someone may propose a
solution on the mailing list to suggest sample implementations.

Cyno has posted a proposal to extend RADIUS to work with ARA (Appletalk
Remote Access) in a manner similar to the EAP proposal.  Attending
vendors who support ARA in their NAS agreed to work together to
implement and test Cyno's proposal and report the results to the
working group.

Merit proposed a simple scheme to encapsulate EAP packets inside RADIUS
packets to allow NASes which implement RADIUS to deploy EAP by simply
updating their RADIUS server, instead of having to add code to the NAS
itself for each new flavor of authentication inside EAP.  One question
raised was how large are EAP Packets?  GSS API packets can be very
large (by RADIUS standards) but many EAP methods appear to fit nicely
in a UDP packet.  There may be LCP timing issues if the NAS is
forwarding EAP across the network to a RADIUS server which is
performing the EAP function for it.  A signature attribute on the
RADIUS access-request would be useful in conjunction with EAP, but
perhaps IPSEC's work can be used instead of re-inventing the wheel.
Many attendees expressed interest in incorporating EAP support within
RADIUS.

Currently the User-Password is used to authenticate the NAS sending the
Access-Request packet as well as the User.  We want to decouple bad
passwords from spoofing of NASes.  We could add a signature at the end
of the packet.  It must be based on the shared secret.  Should be the
signature be required?  Are we redoing work that IPSEC has already
done?  This proposal is easily retrofitted into existing RADIUS.

Configuration-Token was proposed for use in large distributed
authentication networks using proxy servers.  It gets passed from the
server to the proxy to support an abstract concept of user types, in
cases where the server and proxy are run by different organizations and
therefore the server doesn't know what kind of NAS has sent the request
and there's a need to send NAS-specific information back, for example
with Filters.   Domitru of Microsoft will post a proposal to the
mailing list.

A Response-Pending packet type was proposed so that a server could ask
the NAS to suspend timeouts and avoid going to its secondary server, in
cases where the primary server is slow.  Probably this can be done more
simply with better retry algorithms, so a lot more discussion is needed
on the mailing list on retries and non-equivalent servers (that is,
some people have set up secondary servers that function differently
from their primary servers, which has a considerable impact on retry
mechanisms.)

Big Identifiers were proposed as a way to allow proxy servers to have
more than 255 outstanding requests, but it was pointed out that
Proxy-State can already perform this function quite well, so there's no
need to add an attribute for this.

Regarding signed Accounting Requests, a question was raised as to
whether the existing method of signing might risk exposure of the
single shared secret since there's lots of clear text in common.  Those
present familiar with MD5 said that MD5 is quite good at dealing with
small changes in the text to produce much different hashes, so this
appears not to be a problem.  Replays don't matter since the
Acct-Session-Id is used to reject duplicates and replays just look like
duplicates.

Responses already have signatures, but signed Access-Requests for CHAP
and EAP were proposed, to make it harder to attempt dictionary attacks
on the shared secret.  It was suggested that it should be in the packet
header and not an attribute, but that's a major change to RADIUS and
breaks existing implementations.  A Signature attribute that would be
allowed in all sorts of packets solves the problem without breaking
existing implementations.  Note however that the RADIUS Draft already
suggests that the shared secret be 16 octets or longer and dictionary
attacks on 128 bits have a lot of work cut out for them.

There was a question of the purpose of Accounting, and whether it
should log user rejects in order to aid detection of intrusion attempts
and keep authentication results "together in one place."  The issue
will be discussed on the mailing list.

An ISDN D Channel attribute was proposed to detect caller id
information BEFORE the call is accepted, generating a
pre-authentication phase based on caller-id.  This is desired by ISPs
who don't want their lines tied up at the Username prompt needlessly.

An Acct-Delay-Time for Access-Request packets was proposed, to let you
know how long the user has been waiting to authenticate.  Changing the
packet requires a new Id and authenticator and makes detecting
duplicates much harder, for very little perceived benefit, so the idea
was dropped.

A question was raised regarding NTP-based real-time stamps from
NTP-capable NASes? There was no interest expressed in such an
attribute, since servers are already quite capable of timestamping.

Client-Id vs Source Address is an issue for proxies.  The Livingston
reference server looks at the source IP address from the UDP socket to
look up the shared secret of the client.  Is this a potential problem?
After much discussion it was concluded that this behavior was
desirable since it made it easy to use separate shared secrets between
the NAS and a Proxy and the Proxy and a remote RADIUS server, a very
desireable feature.  Its important to note that the source UDP address
is NOT used for authentication of the client, it is only used to
identify the client for the purpose of looking up its shared secret,
and the shared secret is used to authenticate the client.  Still, it
may turn out to be desirable to have a Client-Identifier attribute
separate from the NAS-Identifier for use with proxies.   Don Dumitru of
Microsoft will post further thoughts on proxy requirements to the
mailing list.

Clarifying language will be added to the RADIUS draft that the source
IP address should be used to determine which shared secret to use, and
to weaken the required presence of either NAS-IP-Address or
NAS-Identifier from MUST to SHOULD, since some implementors interpreted
that language to mean that they should use those attributes to look up
the shared secret, breaking proxy service.

Resource Management was discussed with a suggestion made to allow
RADIUS servers to manage pools of addresses and allocate them to the
NASes.  Resource Management in a non-trivial environment (many NASes,
more than one server) is a non-trivial task and deserves its own
working group, instead of being shoehorned into an authentication
protocol like RADIUS.

The format of Callback-Number was discussed, continuing the discussion
from the first session.  It was concluded that callback prefixes are
complicated and complicated things should be done in the RADIUS server,
not the NAS.  Therefore Callback-Number should be left defined as it is
now, as undistinguished octets (like what might follow ATDT or CRN).

Acct-Terminate-Cause was discussed again briefly (in the final 17
seconds), with no further additions or deletions suggested.

Upcoming Milestones:

96/3/31	RADIUS Draft 03 and RADIUS Accounting Draft 03 go to working
	group last call for two weeks
96/4/21	RADIUS Draft 04 goes to IESG for two-week IETF last call for
	advancement to Proposed Standard
	RADIUS Accounting Draft 04 goes to RFC Editor as Informational
96/5/6	RADIUS Extensions Draft 00 goes to working group
96/6	RADIUS Extensions Draft 01 goes to working group
96/7	RADIUS Extensions Draft N goes to RFC Editor as Experimental
96/11	RADIUS submitted for advancement to Draft Standard
97/4	RADIUS submitted for advancement to Full standard