Status of RADIUS

[Randy Bush <randy@psg.com>]

bernard has given me permission to forward this.  it will provide
background to some future [non-]actions in the radius area.

randy


From: Bernard Aboba <aboba@internaut.com>
To: mankin@psg.com
cc: randy@psg.com
Subject: Status of RADIUS
Date: Wed, 29 Jan 2003 09:59:17 -0800 (PST)

I've been thinking a bit about your question on what the IETF should be
doing about RADIUS. Examination of the IETF archive shows that I-Ds
relating to RADIUS tend to fall in the following categories:

Improved security
draft-moskowitz-radius-client-kickstart-00.txt
draft-simon-radius-key-attr-01.txt
draft-kaushik-radius-sec-ext-07.txt

New applications of RADIUS
draft-heinanen-radius-pe-discovery-00.txt
draft-ietf-dhc-agentopt-radius-02.txt
draft-lonvick-sobgp-radius-02.txt
draft-nmcgill-l2tp-radius-ext-nas-port-00.txt
draft-schulzrinne-sipping-radius-accounting-01.txt

Dynamic disconnect
draft-chiba-radius-dynamic-authorization-06.txt

IEEE 802.1aa
draft-aboba-radius-rfc2869bis-07.txt
draft-congdon-radius-8021x-22.txt

Some thoughts on each category:

1. Improvements to security. RADIUS has several known security weaknesses,
including vulnerability to dictionary attack on the shared secret,
weaknesses in the RFC 2548 key wrap, replay and lack of confidentiality
in accounting messages and lack of e2e security. Most of
these weaknesses can be addressed by running RADIUS over IPsec, which is
specified in RFC 3162 and draft-chiba-radius-dynamic-authorization-06.txt.

The issue is that the industry has not felt motivated to ship RADIUS over
IPsec products, partly because implementation is optional. One thing the
IETF could do is decide that RADIUS SHOULD be run over IPsec, and write a
document analyzing the security of the protocol in order to justify that
decision.

There is not much we can or should do in e2e security for RADIUS until
Diameter CMS is done. The people required to finish Diameter CMS are busy
and are rare enough that trying to do both at once would be detrimental.

If we buy the argument that RADIUS over IPsec is the path to better
security, and that CMS would be the path to e2e security, then it would
not appear that any of the drafts in the "improved security" category need
to go forward to RFC publication.

2. New applications of RADIUS. There have been quite a few drafts
specifying new uses of RADIUS lately. However many of them fall into the
"bad idea" bucket, including use of RADIUS for SIP accounting (Henning's
draft), use of RADIUS for BGP, and linkage between DHCP and RADIUS. To
prevent AAA specifications from becoming a "bad idea magnet" we've long
had the policy to only generate new AAA applications based on requirements
docs from WGs with area expertise.

My recommendation in this area is to allow WGs to make requests for work in
this category, but not to originate any work without a WG request.  Absent
strong WG preferences for publication (which might be the case for SIPPING
and Henning's document), I do not see a reason to consider publishing
documents in this category.

3. Dynamic disconnect. This draft describes an existing practice, and so
it represents a documentation of what is in place, rather than a new
proposal. It is somewhat vague in places, and might benefit from more
discussion, so as to clearly delineate the limitations of the approach,
some of which are unique to RADIUS (e.g. UDP transport and resulting
packet loss). I don't know that it really deserves to be a Proposed
Standard (RADIUS Accounting, RFC 2866 isn't), but an IETF last call
probably couldn't hurt. Since this is a description of something that's
already deployed by multiple vendors, it is not the kind of thing that
would benefit much from WG discussion. It also contains a more detailed
specification of RADIUS over IPsec than RFC 3162.

4. IEEE 802.1aa dependencies. IEEE 802.1X references RFC 2869 and includes
a non-normative appendix describing how RADIUS attributes apply to IEEE
802.1X. Some issues were found in RFC 2869 and that is why we have RFC
2869bis, whose purpose is only to clarify RFC 2869, not add anything new.
The publication of the RADIUS appendix in IEEE 802.1X as an RFC is purely
a convenience to the IETF community, who otherwise would need to purchase
the IEEE standard at a significant cost. So it seems reasonable to allow
these drafts to go forward to IETF last call.

SUMMARY

Overall, it would not appear that there is a case for the IETF to charter
a WG to deal with RADIUS at this time. AAA in general continues to be a
"bad idea magnet" and if left alone, most of the "new ideas" relating to
RADIUS will disappear without a trace.

While Diameter Base and Transport are done, none of the application
documents have been completed, and at least a year of work is probably
required to finish NASREQ, MIPv4, CMS and EAP. Since the number of people
available to do that work is limited, forming another WG before the
current AAA WG milestones are completed would be detrimental to progress.

With some exceptions, there are few requests for additional RADIUS
functionality coming from the WGs. There is a need for clarifying some
existing documents (including a new IANA considerations section for RFC
2865, to close loopholes), and for improved visibility for better RADIUS
security practices, but it hardly seems worthwhile to charter a WG for
that purpose.

WHAT IS NEEDED

I do believe that there is a need to re-invigorate the AAARCH, which seems
to have gone inactive. There are a number of interesting ideas still at
the research stage that could use more work, including use of AAA for fast
handoff in IEEE 802.11 networks (Bill Arbaugh is working on this).

-30-