2.4.15 RADIUS EXTensions (radext)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-10-15


David Nelson <dnelson@enterasys.com>
Bernard Aboba <aboba@internaut.com>

Operations and Management Area Director(s):

Bert Wijnen <bwijnen@lucent.com>
David Kessens <david.kessens@nokia.com>

Operations and Management Area Advisor:

David Kessens <david.kessens@nokia.com>

Technical Advisor(s):

Paul Congdon <paulcongon@hp.com>

Mailing Lists:

General Discussion: radiusext@ops.ietf.org
To Subscribe: radiusext-request@ops.ietf.org
In Body: In Body: subscribe
Archive: http://ops.ietf.org/lists/radiusext

Description of Working Group:

The RADIUS Extensions Working Group will focus on extensions to the
RADIUS protocol required to enable its use in applications such as IP
telephony and Local Area Network authentication, authorization and

The IETF has recently completed work on the Diameter Base protocol. In
order to support the deployment of Diameter, and enable interoperation
of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items
MUST contain a Diameter compatibility section, outlining how
interoperability with Diameter will be maintained.

Furthermore, to ensure backward compatibility with existing RADIUS
implementations, as well as compatibility between RADIUS and Diameter,
the following restrictions are imposed on extensions considered by the

- All RADIUS work MUST be backward compatible with existing RADIUS RFCs,
including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, and 3580.
- All RADIUS work MUST be compatible with equivalent facilities in
Diameter. Where possible, new attributes should be defined so that
the same attribute can be used in both RADIUS and Diameter without
translation. In other cases a translation considerations
section should be included in the specification.
- No new RADIUS transports (e.g. TCP, SCTP) will be defined.
- No new security mechanisms will be defined for protecting RADIUS.
- No new commands will be defined.

Work Items

The immediate goals of the RADEXT working group are to address the
following issues:

- RADIUS design guidelines. This document will provide guidelines for
design of RADIUS attributes. It will specifically consider how
complex data types may be introduced in a robust manner, maintaining
backwards compatibility with existing RADIUS RFCs, across all the
classes of attributes: Standard, Vendor-Specific and SDO-Specific.
In addition, it will review RADIUS data types and associated
backwards compatibility issues.

- RADIUS implementation issues and fixes. This document will address
common RADIUS implementation issues and describe proposed solutions.

- Revised NAI specification. This document, known as "RFC 2486bis"
will revise the NAI specification to correct known errors,
add support for privacy and internationalization, and provide
more details on routing.

- Pre-paid support. Prepaid services are contemplated in a number
of potential applications, including wireless LAN access and IP
telephony. In order to enable support of pre-paid services in
an interoperable way, the WG will provide definitions of the
attributes required to support operator service models for
pre-paid, as documented in liaison communications. This
document will include within it a specification for interoperation
with Diameter Credit Control.

- SIP support. RADIUS is currently used for SIP authentication,
authorization and accounting. Standardization of these attributes
will enable improved interoperability.

This document will be upwards compatible with the Diameter SIP
application, and conform to existing IETF RFCs on HTTP Digest,
including RFC 2617, 3261, and 3310.

- LAN attributes. New attributes have been proposed to enable use of
authentication, authorization and accounting in wired and
wireless LANs. Standardization of these attributes will enable
improved interoperability.

- RADIUS MIB update. RFC 2618-2621 lack IPv6 compatibility, and modest
changes are required to address this issue. MIBs for RFC 3576 are
also needed.

Goals and Milestones:

Dec 04  Updates to RFC 2618-2621 RADIUS MIBs submitted for publication
Dec 04  RADIUS design guidelines submitted as an Informational RFC
Dec 04  SIP RADIUS authentication draft submitted as a Proposed Standard RFC
Jan 05  LAN attributes draft submitted as a Proposed Standard RFC
Feb 05  RADIUS implementation issues and fixes submitted as an Informational RFC
Feb 05  WLAN attributes draft submitted as a Proposed Standard RFC
Feb 05  RFC 2486bis submitted as a Proposed Standard RFC
Dec 05  RADIUS Prepaid draft submitted as a Proposed Standard RFC
Dec 05  RFC 3576 MIBs submitted as an Informational RFC


  • draft-ietf-radext-rfc2486bis-01.txt

    No Request For Comments

    Current Meeting Report

    Minutes of RADEXT WG meeting at IETF61
    Monday November 8, 2004, 9:00AM-11:30AM
    Hilton Washington, Military Room

    Chairs: Preliminaries

    The Co-chairs presented the agenda. All slides are available from http://www.drizzle.com/~aboba/RADEXT/IETF61/

    Blue sheets were circulated.

    Document status:
    - Having completed WGLC
    - 2486bis
    - SIP authentication
    - Requiring review
    - GEOPRIV WG has requested us to review the RADIUS Extensions for GEOPRIV (and some people are doing that already). Preferably this should be stable by December due to 3GPP deadlines. Will go to GEOPRIV WGLC soon.
    - IPv6 MIB revisions will go to WGLC once we get the submissions
    - Two documents being evaluated as potential WG work items
    - Chargeable user identities
    - RFC 3576 MIBs

    - Some documents are pretty much ready, and some have been worked on for a long time -- we should move fast on those.
    - If something doesn't move, we interpret that as a lack of interest and drop it. So authors, please keep moving them.

    Jari Arkko: draft-ietf-radext-rfc2486bis-01.txt

    - Passed WGLC
    - All issues raised in WGLC have been resolved
    - Three new issues brought up since then
    - Better examples (#16)
    - Bernard's review and editorial nits (#15)
    - Josh's editorial nit (#17 part 1)
    - Suffix vs. prefix for the home realm (#17 part 2)
    - All have been addressed, except last one
    - It was discussed extensively in EAP WG early in this work
    - Prefix approach works better with unmodified AAA nodes

    Next steps:
    - Will submit -02 as soon as submission opens again
    - Jari thinks it's ready to go to IESG
    - This is one of the 3GPP R6 dependencies marked as "critical", so it should be stable (approved by IESG) by December
    - There is one reference to an internet-draft, but that's already in RFC editor queue, so it's not a problem

    Wolfgang Back: RADIUS Extensions for Digest Authentication

    This is now a WG item, but missed deadline for renaming it. Trying to align the draft with the Diameter application (ietf-aaa-diameter-sip).

    - Could not be calculated by RADIUS client alone, so we added a new attribute.
    - Comment: MD5 might not be acceptable anymore.
    - Response: This draft is not actually using MD5, just providing support for HTTP digest (which uses MD5).

    - This is a good thing to do, but RFC3579 is Informational
    - Added in -04 as "MAY"

    What's a "secure connection"?
    - Added some clarifications
    - Question: What exactly is a secure connection (IPsec, MPLS VPN, ...), and should we rely on the operator getting this right?
    - Comment: IPsec is used in RFC3579, so using it here should not be a problem.
    - Comment: It's important that the RADIUS client/server knows that IPsec was used.
    - Comment: The distinction is that this ID requires application to know that IPSec is being used. That requirement is not in RFC3579.
    - Comment: RADIUS includes other means to hide attributes besides IPSec. Other documents specify this.

    IANA allocation
    - IANA request has been submitted long ago, but received no decision yet.
    - Comment: It's probably been lost; resend it and CC the Chairs.

    - Chairs: We need people to check -04 and say that it's OK. Silence does not mean WG consensus.
    - Chairs: We may need a security review, too, considering the issues discussed today. The chairs will contact the Security ADs to solicit reviewers.

    Farid Adrangi: Carrying Location Objects in RADIUS

    Farid presented the history, motivation and overview of the draft (see the slides). The goal is to convey location information to the home AAA server while taking privacy into consideration. This will support location-based authorization, taxation, location-based services, a mid-session method for transfer. It is based on the CoA RFC and reuses existing GEOPRIV work as much as possible.

    - Question: What exactly does "not sharing the location information" mean, e.g., can RADIUS proxy forward it? Or how the home AAA server can use it?
    - Response: The policy rules are intended for the home AAA server, and the policy is mostly about passing the information beyond the AAA infrastructure.

    - Question: About retention: ISPs store accounting records for several years (because they're required to), so how the does the "retention-expires" work in this case?
    - Response: Most likely the entities are assumed to have business relationships and contracts that deal with some of these issues.

    - Question: Should the users be setting their own location privacy policies?
    - Response: This is mostly between operators and based on operators' policy (if an operator needs the location for authorization and accounting).

    - Question: So this is not about customers, it's about operators?
    - Response: Yes.

    - Comment: The location of the NAS often does not have anything to do with the location of the user. The document supports both, and in case of wireless, the radio range is limited.
    - Comment: Restricting this to only NAS location would simplify the draft and improve understandability.
    - Comment: The location of the user is important.

    - Question: Where does the NAS gets the location information?
    - Response: NAS or AAA proxies are configured with this information.

    There was discussion about alternative solutions. Since NASes don't in general move, why this could not be solved by some other approach? A table mapping NAS-Identifier to location at home AAA server does not scale in roaming situations (consider 100,000 APs and 10,000 home AAA networks). It's probably better to have this information in one place and send it to home AAA server where it's actually used.

    Chairs: We've had good discussion here, please continue it on the mailing list.

    Bernard Aboba (on behalf of Paul Congdon): 802.1 Support Attributes

    - Missed the ID update deadline
    - Not many changes to the previous version
    - Added VLAN-Name attribute
    - There as been interest from Trusted Computing Group (TCG) in referencing RADIUS attribute documents, most likely this one and the bandwidth draft.
    - Work has been slow, a new author should accelerate things
    - Some people are interested in new Layer 2 filter attributes
    - Is NIST ever going to speak up about key management attributes?
    - Paul Congdon would like to get a "design team" to work on this draft, please contact him to volunteer
    - Question: Does this document replace RFC3580?
    - Response: No, it adds attributes for 802 stuff that was not covered by 3580, but explicitly stating this might help.

    - Comment: Some have expressed an interest in working on a RFC3580-like document for IPsec VPNs, "RADIUS usage guidelines for IPsec/IKE/IKEv2 stuff". This would not necessarily define any new attributes, but at least clarify how existing ones should be used. Anyone interested should contact Pasi Eronen.

    Farid Adrangi: Chargeable User identity

    Farid went through current issues. Issues 13, 14 and 15 are addressed in the most recent draft. There are two open issues: (a) backward compatibility and (b) the lack of general capability negotiation mechanism in RADIUS. We could send a "hint" attribute in the Access-Request message as indication of CUI feature support.

    There was some discussion about why this draft is needed. The main reason seems to be that currently User-Name is overloaded for both routing and identification. The Class attribute works for two parties, but not so well for multiple parties (like roaming clearinghouses). It seems that the draft needs a better explanation of the problem being solved.

    Glen Zorn volunteered to send a paragraph clarifying the problem statement to the list.

    - Question: Clarification about the different identity type prefixes? It seems that the document defines a new number space, but does not say how numbers get added to that space.

    Chairs: We would like more than two people to read this, and say on the mailing list that they like it and would like it to be WG item.

    Farid Adrangi: RADIUS Redirection

    No activity.

    Chairs: Please review and comment upon the draft.

    Farid Adrangi: Bandwidth Capability

    In previous versions of the draft, there was some confusion about what exactly NAS should do with these attributes, e.g. what kind of algorithm it should apply to actually doing something about the traffic, or reserving something, or something.

    Farid presented the idea of having a general framework that would allow different types of actions.

    - Comment: A general framework without any concrete mechanisms is not useful.
    - Response: The draft would define one or two concrete mechanisms as well, but allow others to define more in the future.

    - Comment: This ID uses structured attributes, which are not very nice in RADIUS. Having separate attributes might be better from RADIUS point of view.
    - Response: We are running out of RADIUS Attribute ID space.
    - Comment: It's not clear that this is imminent, and when we do run out, there have been several proposals made on how do extend the ID space. We could pursue one of those proposals, as needed.

    - Comment: There's probably overlap with QoS-Filter-Rule attribute in the 802.1 LAN Attributes draft.

    - Question: What is the relationship to Diameter QoS application draft.

    - Comment: Having something very simple would probably be better than something complex and general.

    Jari Arkko (on behalf of David Mariblanca): EAP lower layer attributes

    Jari presented the approach (see slides).

    - Question: Do we want to just know the physical layer used to carry EAP, or tell the difference between what kind of service the user is using?
    - Response: The main goal was to tell the difference between 802.1X and IKEv2 cases, and allow policies like "this user can use 1X but not IKEv2".

    -Comment: Using Service-Type or some other attribute might be more appropriate.

    Chairs: It seems that several people are interested in NAS-Port-Type and/or Service-Type usages. It would be good if they can get together and review the alternatives. Volunteers: Glen Zorn, Pasi Eronen, Jari Arkko.

    Chairs: MIB work

    RADIUS and RADIUS Accounting MIBs. An IPv6 MIB update was intended for this meeting, but was delayed. The work is straightforward. MIB doctor review and input will be sought for the MIB updates, once the drafts are available.

    RFC3576 MIB. (draft-decnodder-radext-dynauth-server-mib-01.txt) Murtaza Chiba was not present. We should proceed with this work, as it is in the charter. Will seek volunteers to review the current draft, and seek MIB Doctor review, as well.

    The meeting ended about 11:00AM.



    RFC 2486bis
    Digest Authentication in RADIUS
    RADIUS Location attributes
    IEEE 802 attributes
    EAP lower layer attribues for AAA protocols
    Chargeable User Identity