2.4.13 RADIUS EXTensions (radext)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional RADEXT Web Page

Last Modified: 2005-01-07


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
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-05.txt
  • draft-ietf-radext-digest-auth-01.txt
  • draft-ietf-radext-chargeable-user-id-03.txt

    No Request For Comments

    Current Meeting Report

    Minutes of the RADEXT WG session at IETF62
    Wednesday, March 9, 2005 1530 - 1730
    Hilton Minneapolis
    Rochester Room

    Notes taken by Paul Condgon and John Vollbrecht and edited by Dave Nelson.

    Agenda: http://www.drizzle.com/~aboba/IETF62/radext/ietf62_radext-agenda.ppt
    Slides: http://www.drizzle.com/~aboba/IETF62/radext/
    Issues Tracker: http://www.drizzle.com/~aboba/RADEXT

    1. Agenda Bashing: The published agenda was set for 2.5 hours but we were switched into a 2.0 hour session slot. Agenda will be reshuffled to fit in 2 hours because few wanted to cut short the dinner hour. Will start the capabilities discovery discussion at a fixed time.

    2. Document status was covered

    3. Milestones need to be updated on web site. Proposed revision is:

    - Done†† RFC 2486bis submitted as a Proposed Standard RFC
    - May 05††RADIUS digest auth draft submitted as a Proposed Standard RFC
    - Jun 05††Updates to RFC 2618-2621 RADIUS MIBs submitted for publication
    - Jul 05 RADIUS CUI draft submitted as a Proposed Standard RFC
    - Dec 05††RFC 3576 MIBs submitted as an Informational RFC
    - Dec 05††RADIUS design guidelines submitted as an Informational RFC
    - Jul 06†(W)LAN attributes draft submitted as a Proposed Standard RFC
    - Sep 06††RADIUS issues and fixes draft submitted as an Informational RFC
    - Dec 06††RADIUS Prepaid draft submitted as a Proposed Standard RFC

    4. Jari Arkko on 2486bis status Ė updated NAI.

    -- Document has been sent to IESG and has a single issue. Some minor modifications a have been made.

    -- Extended to use international characters, but UTF-8 is a problem. Needs to be made clear in the ABNF.

    -- Issue 18n includes a question about unassigned code points. Should they be prohibited or allowed? Approach is to prohibit them from a specification perspective.

    -- Related issue with ! syntax. Unclear what to do and we need the help of internationalization gurus. Username part may have different rules from IDN part of the NAI.

    -- Chairs will solicit consultation from an expert in internationalization issues.

    -- Conversation to be moved to list.

    5. Wolfgang Beck on auth digest draft

    -- There are several security design alternatives; encryption per RFC2868, wait for draft-zorn-radius-encattr or mandate IPSec if RADIUS client supports TLS. Concern about the draft-zorn... being "late" (now an individual submission). Wolfgang believes the IPSec solution is the only viable option.

    -- Concern about encrypted RADIUS attributes not providing the same level of protection as TLS (or IPSec). It was pointed out that most operators already protect their RADIUS traffic, but there is some debate about this.

    -- Other misc. changes in the works regarding alignment with diameter-sip-app, digest-Qop, multiple authorization, and document re-arranging.

    -- There is a comment that the parameters being included in the SIP-AOR are not properly discussed in the draft.

    6. Avi Lior on the CUI draft

    -- All issues in the tracker have been addressed to date. One issues raised recently, but not in the tracker yet. Resolution has been agreed on the list. Requesting that the document move to WG last call.

    7. Dave Nelson on the base MIBs Revision

    -- Asked to update the current set of four MIBs. There are now four drafts that update, but not obsolete the existing RFCs.

    -- Added support for IPv4/IPv6 textual conventions. Using the SMI AUGMENTS syntax to perform the update and non-obsolesce of the existing objects.

    -- To advance these, there will need to be updates to the boilerplates.

    -- Has been some informal MIB Doctor review and will be requesting formal review and recommend they become WG documents.

    -- Dan Romascanu doesnít believe that the boilerplate needs to be updated. Dave Harrington is the one who made this assertion, in his slides at IETF60/58. This is only related to the Standards Track MIBs. The AD wasnít clear what the procedure is.

    -- Glen Zorn would like to see the current Standard Track MIBs move to Draft Standard status. We need to understand what all is implied by taking this action.

    8. Greg Webber on the RFC3576 MIBs

    -- This adds support for the new extensions in 3675. Addresses IPv6/IPv6 textual conventions.

    -- Four issues are noted: 31, 44, 45, 48. Various changes to support the resolution of these issues.

    -- Proposed to make these a WG item. The WG seems to agree. Validate on the list.

    9. Mauricio Sanchez on the IEEE 802 Attributes

    -- Avi Lior and Farid Adrangi have contributed to this as well and should be noted as authors.

    -- Because of overlap, the draft-lior-redirection draft has been merged in and some changes to the format were made. The redirection draft was dropped.

    -- NAS-Filter-Rule supports L2 filters now and supports a flush action.

    -- 802.11i Key attributes were removed to avoid NIST issues. It was noted that all 802.11 attributes were pulled and they shouldnít have been.

    -- The dropping of the Key attributes is a concern by Glen Zorn. Since NIST has a bad track record of responding in a predictable timeframe, we donít want to create a dependency.

    -- Key attributes were copied for Key space so the code points already exist, so therefore some of these already exist.

    -- Several issues have been addressed: 37, 38, 39.

    -- Will bring back non-key related attributes for 802.11.

    -- The TNC of the TCG is interested in these attributes, so is 3GPP. John Vollbrecht will present on the TCG/TNC in the EAP WG tomorrow.

    -- Next steps involve incorporating the capabilities discovery direction of the group, more formatting of NAS-Filter-Rule and its syntax, improve document flow, considering a title change.

    -- Other SDOs depend on this, so rapid progress is necessary.

    -- Question about the extended attribute usage being removed. Glen Zorn is happy about this.

    -- Question about accounting records used on redirect. There is a stop and start used, but could there be a single record? Avi Lior believes it is possible to do this and an Interim should be used.

    10. Dave Nelson on Management Authorization Attributes

    -- Currently two attributes for management; CLI, privileged and non-privileged. The draft would like to extend this for SNMP and HTTP management. Would like the extend the privilege levels, support SSH, create a label for policy scope, leverage split horizon views of management, and do this on a per-command basis (parity with TACACS+)Ö a lot of improvements.

    -- The design is to add a Framed-Management service type and a Management-Access-ID (label), Management-Protocol, Non-Framed-Management-Command and operation, Management-Context for logging and human consumption.

    -- Today Enterasys uses VSA and believe that there is value in multi-vendor environment so would like to open them up. Would like to ask that this become a WG item. Poll of the room indicated about six to eight interested parties. Will validate on the list.

    -- Glen Zorn questions the wisdom of using RADIUS accounting for an audit log of command line changes because of the size of Radius logs Ė perhaps syslog would be better.

    -- Unclear how this works with SNMP. The idea is it would leverage the ISMS WG work. The ISMS group should certainly review this and an action was taken to put them in the loop.

    -- The ISMS scope, however, does not cover management access control.

    -- Dave Perkins asks if some of the other functionality is to provide parity with TACACS+. Yes, some of this is going to address that, but there is also the goal of addressing other management interfaces other than CLI. Dave Perkins points out that it is hard to do command-by-command authorization because you need to understand the level within the CLI you are operating at. Greg Weber indicated that the Management-Context attribute is defined to address this.

    11. Avi Lior on Prepaid Extensions

    -- Now at draft 7. During IETF60 they were at draft 5. A number of changes identified in the slides.

    -- Interesting complexities defined to transfer prepaid credit from the NAS to the device.

    -- The goal is to be similar to Diameter Credit Control, but integration will be hard to do. There are differences between Quotas in the two schemes; one is a delta the other is absolute. More thought needed here.

    -- Is the draft dependent on RFC3576? No, according to Avi Lior, but some disagreement on this. Any dependency can be taken out, but it would be good to have it in.

    12. Avi Lior on Bandwidth Parameters

    -- Draft has been thrashing about. The current draft strives towards simplicity with a simple set of attribute with reasonable tightness.

    -- There are ingress and egress bandwidth attributes, and a Bandwidth-ID for labels (similar to Filter-ID). Can use either of these, but not both at the same time.

    -- There is a capability to advertise, select and confirm bandwidth usage. Ability to update these dynamically as well. Mutual agreement among the parties?

    -- Reporting via start/stop or interim and the NAS decides which way it wants to do this.

    -- Bernard claims this draft has grown way out of scope. Need discussion on what is the appropriate set of functionality

    -- Question about the Bandwidth-Profile-ID and what are the scalability issues? Should it be part of the Filter-Rule attributes? Avi Lior believes it would be a bad idea to overload Filter-Rule with bandwidth as well.

    13. Dave Nelson on RADIUS Issues and Fixes

    -- Kicking off a discussion on problems and points of confusion in existing RADIUS RFCs. Not to be used for new functionality. Goal is an informational RFC.

    -- Glen Zorn questions how we fix problems if we canít add new functionality. Dave Nelson recommends that we document the issues and then consider fixes that might require a re-charter, i.e. a normative change to existing RADIUS RFCs, on a case-by-case basis.

    -- Slides presented list a large number of current issues and clarifications to be addressed.

    -- Next steps are to get discussion on the issues and begin a draft. Dave will kick off as editor but would like someone else to take over at some point soon.

    14. Greg Weber on RADIUS usage in L2PVN WG

    -- A current working group item in this group. How to provision customer equipment as it joins a provider network and determine the set of interconnected pseudo-wires.

    -- This is not a traditional use of RADIUS because it is authenticating equipment not users, but still using User-Name to identify the customer equipment.

    -- Accounting hasnít been addressed much yet. Looking into scalability concerns. There is a big question around how Ďzero-touchí can be supported? Would like to get customer equipment with credentials so it could do something like 802.1X. This is really how devices are being provisioned and authenticated into the network.

    -- Are there any dependencies? No objective to do this. Does RADEXT really need to look at this other than provide expertise review?

    -- There is some concern about using complex and formatted radius attributes with structure as this proposes. There is a general concern about how to represent complex attributes such as NAS-Filter-Rule in 802 extensions.

    15. Jari Arkko on Policy Decisions for Multiple Services

    -- Work from EAP lower layer efforts. A single subscription can have access to multiple services and providers may have to apply policies on how to allow access.

    -- This is only a problem in roaming environments. How to identify virtual services links such as PANA or IPSec. What is the NAS-Port-Type for these? It might be better for NAS-Port-Type to represent the physical port and use something else to represent the virtualized or higher-layer. Unclear that tunnel-type would be a good option either. Perhaps the combination of NAS-Port-Type and Tunnel-Type to describe this.

    -- Several issues with how to use tunnel attributes for these virtual services in the slide. Should there be a definition of something new or a clarification of how to use existing attributes? It was pointed out that this is somewhat like the management attributes being defined because of using Radius in new ways. This advocates creating new attributes for this.

    -- What happens if the NAS "lies"?

    -- Several people are interested in the problem, but no-one has a solution yet. Next steps are to put this document into the pre-working group item review list.

    16. Avi Lior on RADIUS Location Attributes (GEOPRIV WG)

    -- A number of GeoPriv issues were discussed from the slides

    -- One particular resolution is to add a capability attribute.

    -- Dave Nelson points out that this is another space where guidance on structured attributes would help

    -- Jari Arkko comments on Issue 70. He believes it is a requirement that a policy must be followed if the client demands it, but there is no link layer that advertises the clients demands. Somehow it would be good if the client could tell the NAS that it didnít want the information to be transferred.

    -- All the GeoPriv wants to do is be able to advertise location, but there are requirements to advertise additional objects that are location related. There is a proposal to have an additional type of location information beyond civic and geographical to allow this information to be advertised. This issue has been raised in the GeoPriv WG

    -- There is a question about which device has location information about what entities and what is advertised? There is location of NAS and of end-user which are separate. How would a NAS get location information of the user? Avi points out the goals are to get user location information, and if the user canít do this or there is no channel to communicate this, the NAS may use other information to represent the userís location with reduced capability.

    -- This discussion was taken offline to the list.

    17. Avi Lior on RADIUS Capability Exchange

    -- There has been a lot of discussion around NASes advertising their capabilities and this draft attempts to capture this and the requirements for capability advertisement.

    -- There are cases where the home AAA server needs to know what the NAS is capability of to properly provision services and policies (e.g. prepaid)

    -- There are cases where the NAS would like to tell the AAA server that it needs to see certain attributes.

    -- There are cases where the AAA server would like to get something specific from the NAS.

    -- There are issues with how to represent granularity of the capabilities.

    -- This mechanism is really necessary to implement mandatory attribute requirements.

    -- A question is if this implies that the server needs to be stateful, and now does the NAS need to advertise this in every access request? The goal would be to keep the server stateless. If the info is small it might not be a problem to include in each exchange.

    -- What are the scenarios for capability exchange seen in Diameter?

    -- Glen Zorn believes the exchange makes more sense when there is a persistent session between the NAS and server. The NAS support wonít change session to session, but if we donít want the Radius server to keep NAS state then how will it understand the capabilities? The concept of a permanent session between the NAS and the server is really about keeping state.

    -- Jari Arkko points out that we are really doing both policy and capability advertisement.



    RFC 2486bis a.k.a. Updated Network Access Identifier (NAI) Spec
    Chargeable User Identity
    RADEXT MIB Changes
    RADIUS Extended Attributes for Management Authorization
    RADIUS Prepaid Extensions
    RADIUS Bandwidth Capability
    RADEXT Issues and Fixes
    L2VPN RADIUS Auto-discovery and provisioning
    Capability Exchange Requirements
    Carrying Location Objects in RADIUS
    Policy Decisions for Users that Have Access to Multiple Services