CURRENT MEETING REPORT
Reported by Dave Nelson, Digital Equipment
Corporation, and Carl Rigney, Livingston Enterprises, Inc.
Minutes of the Remote Authentication
Dial-In User Services Working Group (radius)
First Session
The first session dealt with draft-ietf-radius-radius-02.txt
and draft-ietf-radius-accounting-02.txt, with possible extensions
being 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. Sixteen implementors participated with nine
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 were not ready to test yet or were not 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 the 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.
Second Session
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
96/4/21
96/5/6
96/6
96/7
96/11
97/4