2.4.12 RADIUS EXTensions (radext)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. 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-06-27


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 <paul.congdon@hp.com>

Mailing Lists:

General Discussion: radiusext@ops.ietf.org
To Subscribe: radiusext-request@ops.ietf.org
In Body: In Body: subscribe
Archive: https://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
Done  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-06.txt
  • draft-ietf-radext-digest-auth-03.txt
  • draft-ietf-radext-chargeable-user-id-05.txt
  • draft-ietf-radext-dynauth-server-mib-01.txt
  • draft-ietf-radext-dynauth-client-mib-01.txt
  • draft-ietf-radext-ieee802-00.txt

    No Request For Comments

    Current Meeting Report

    IETF-63 RADEXT WG Minutes

    Scribes: Paul Congdon, Greg Weber (Editor: Dave Nelson)
    No jabberer. (Later Hannes Tschofenig joined the jabber room.)
    Bluesheets started.
    No agenda changes requested.

    Presentations and agenda online at:

    RADEXT Issues Tracker location:

    Streaming audio archive location:
    http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf63/ietf63-ch5-wed.mp3.1 [start time index: 20:34]

    Brief status of WG work items:
    • 2684bis in AD follow-up
    • Dynauth MIBs completed WGLC, 9 issues
    • CUI in AD follow-up
    • Digest Auth completed WGLC, 5 issues
    • 802 Extensions in WGLC, 3 issues (so far)
    - RFC2684 bis presented by Jari Arkko.


    Problem with internationalization found in IESG review. Added clarifying text for ABNF vs. document text requirements and the use of UTF-8 vs. IDN-unware ASCII for the realm part. Revision back to IESG for approval -- very soon, e.g. about a week. Realm strings will be IDN unaware (no "!").

    - Chargeable User Identity presented by Avi Lior.


    All issues have been addressed in the current version of the document. Several SDOs are interested in this draft - WiMAX is one who will be submitting a liaison letter to IETF for this. Pasi Eronen clarifies that this document is in AD evaluation stage and not at the IESG. Bernard may need to update the web-site to indicate the appropriate document status. ID Tracker from IETF homepage is definitive on status.

    - Digest Authentication update by Wolfgang Beck.


    Diameter compatibility is the current main issue with the document. There is also an issue regarding client-side nonce generation when interoperating with Diameter - additional text will be added to address this. We could move forward two ways; one it get client side nonce generation added to diameter, or simply drop this. The 3GPP2 liaison would like to see client side nonce generation remain because they currently use it. Avi Lior recommends that we operate in both modes of operation and when working with Diameter, and get Diameter to update to support client side nonce generation. The 3GPP2 people are waiting for an RFC number on this document so they can publish their spec. The security considerations need to be updated to discuss what to do when realm check fails. There were also some typos that will be corrected. Desire to get -04 version out shortly after IETF-63.

    - Dynamic Authorization MIBs - Greg Weber speaking for authors who could not attend.



    These MIBs are companions to RFC 3576. They are expected to be completed by the end of the year. Issues 96/97 have been resolved and are simply editorial in nature. Issue 105 resolution relates to where the MIBs are to be located in the OID tree. It is believed that new MIBs should be rooted off of mib-2 and the authors are willing to make the change to support this. Issue 92 is the most controversial. A few new terms are defined by this document; DAC and DAS. It was suggested to match RFC 3576 and not introduce new terms in MIB, however the terms are embedded in all of the object names. It is still the belief of the WG that the terms should be consistent and it sounds as though the object names will be globally searched and replaced. Bernard Aboba: RFC 3576bis would be within WG charter, and we could address the terminology issues there. That would mean either delaying the MIBs or revising them later.

    - 802 Extensions draft presented by Paul Congdon.


    Discussed recent changes, but not current issue status. Changes include removal of controversial (Diameter-like) extended attribute types, no new data-types or M-bit, fleshed out the NAS-Filter-Rule, can now specify L2 encapsulations, removed IP-redirection rule type in favor of tunneling. Among the interested parties are TNC of TCG, 3GPP, WiMAX (hot-lining). Glen Zorn questioned the chairs on why this document was so quickly moved to last call. The chairs believe that the previous issues in the individual submissions were sufficiently resolved and there being a number of SDOs waiting on this document see the need to expedite the review and closure of this document. WG last call closes on Aug 10th. There was a question regarding when the wireless attributes would be documented. There is a -00 draft on WLAN attributes to be discussed on this later in the meeting.

    - RADIUS IPv6 MIBs discussed by Dave Nelson.





    New textual conventions for address objects have been included. Review comments from the MIB Doctors have been resolved in the -01 revisions. The drafts UPDATE their predecessor RFCs, deprecate old tables (not doing table augmenting anymore), added new tables to mirror old ones, added specific usage guidelines new IP address objects. The question of whether these should be WG work items was posed and no objections were heard. The RADEXT -00 drafts will be created and moved to WG last call.

    - Common Radius Implementation Issues and Fixes presented by Dave Nelson.


    The document was created based upon a long laundry list of issues that have been discussed on the mailing list. This document identifies many of the problems identified in the field and makes suggestions to resolve the problems. Areas discussed include:
    • Proper use of the state attribute
    • Request ID supplementation alternative
    • Re-transmit schemes
    • How to handle overload conditions
    • Clarification of accounting attribute updates
    • Clarification of using multiple Filter-ID attributes
    • Treating access-accept for unknown services as a reject
    • Avoiding sending VSAs to a NAS that doesn't understand them
    A question about this recommendation is how to reliably detect supported vs. unsupported VSAs. The capabilities attribute is a possible solution. Glen Zorn suggested the possibility of a version number. Since this is just -00, it was suggested to post issues against the document. It was noted that some issues were currently in the tracker but not yet included in the draft.
    • Corrections to RFC 2869, section 2.2 regarding miss-stated Access-Challenge.
    • Handling multiple services
    • Defining how to calculate Message-Authenticator for Disconnect, COA and others
    • Authorize only discussion
    There were some questions of how this document should progress. The document is useful, but perhaps an RFC 3576bis additionally needs to be created. Also, some of the issues are against earlier RFCs as well. These are standards track and may be more difficult to update. This document is intended to address existing and past issues. Another forward looking document discusses future issues. Other issues not addressed were NASes with multiple IP addresses and accounting interval updates. These should be included and consensus on a solution for these needs to be proposed.

    - RADIUS Attribute Design Guidelines presented by Greg Weber.


    This is a forwarding looking document addressing design recommendations for new attributes. This document describes what is considered a good attribute design and reviews the current RADIUS data types, as well as the divergence in the Standard and Vendor Specific data models. A few have reviewed this document so far. The current document does include some recommendations, but these are straw-man recommendations. The motivation for this document is to get better alignment with data models in vendor attributes, address attribute space exhaustion and align better with diameter. The scope of the document includes consideration for backward compatibility, existing VSAs, supporting the existing transport, non-AAA applications and Diameter compatibility. The document straw-man proposes a single standards base format for VSAs as a recommendation. The document also includes recommendations on when particular formats should be used and when to use existing VSA format verse the new one. Lots to do on this draft. Avi Lior agrees this document is a good starting point and is willing to work on the draft. There was a question whether SDOs should be differentiated from Vendors, but the group doesn't believe so. There was a question whether IANA considerations are included, but the authors believe this is already spelled out elsewhere. Glen Zorn asks if it was considered to extend the size of RADIUS attributes rather than dealing with fragmentation. Greg Weber did not consider this because he felt it would be beyond the scope of the charter.

    - WLAN Attributes presented by Jari Arkko.


    The list of attributes that were removed from the 802 Extensions draft was presented. There is some overlap that needs to be discussed. [Technical difficulties with slides caused us to move forward to the next topic.] Upon return, some relationships to the EAP keying draft were described. A list of key management attributes were described and the issues. Privacy can be addressed similar to NAI and by omitting Peer-ID and Server-ID attributes. Key-wrap options were described as three choices; AES key wrap, a Key Encryption Key (Zorn draft) or IPSec. The later is not used in industry. The key-wrap options may be difficult to resolve. The questions on this document are whether this should be a WG item and how to solve the privacy and key-wrap problems.

    - RADIUS attributes for Cryptographic Keys presented by Glen Zorn.


    The motivation for this draft was to allow RADIUS to be used in certain government environments. While RADIUS isn't a key provisioning protocol, there are keys that are passed around in RADIUS and perhaps aren't wrapped securely enough. Several editorial changes were made in the -07 revision, but also HMAC-MD5 was removed and other key transport attributes (e.g. MPPE-xxx) were outlawed if the same data is also transferred in the new attributes. Questions about how keys are transferred to the client - hop-by-hop or end-to-end? They are passed along the path in the way they are set-up - may be hop-by-hop. Glen plans to add AES-CMAC and some other technical changes in the -08 revision.

    - General WG discussion on key-wrap issues.

    Glen Zorn points out that the keying issue is not just an 802.11 or Wireless problem. Also, Glen believes that IPSec is inappropriate as a protection mechanism for an application level protocol. Glen believes that NIST is in agreement that IPSec is not appropriate for this use. Nancy Cam-Winget from Cisco summarized the NIST meeting that took place back at the end of June. She also agrees that it isn't just wireless that needs the keying solutions. They wanted to know if a new key-wrap attribute with a new algorithm would be sufficient or would IPSec work. Nancy believes that the latest draft of the Zorn document has all the changes included based upon the NIST discussion. Nancy believes that NIST's reaction to the use of IPSec to protect RADIUS key distribution was that it would require further review by NIST. Jari Arkko also believes the key work isn't just for wireless and would like to see it in a separate draft from other WLAN attributes. There was a question about the relationship to the Zorn document and the Aboba document? We do have keying attributes for WLAN as a charter item for this group, but can't introduce new security mechanisms. Bernard's document comes from the EAP key framework perspective. A question about a new message authenticator algorithm and attribute being described by Glen. It can be used in any RADIUS message because it is independent of the authenticator value in the RADIUS message. Message-Authenticator cannot be used in Accounting-Request or CoA messages. The new one is cryptographically stronger; the old one is not FIPS compliant (MD5). The new attribute can be used as a complete replacement of the old style message authenticator. Alternatively, the old message authenticator could still be used. Bernard's draft reuses the RADIUS shared secret, while Glen's draft assumes a cryptographically separate pre-shared key. Bill Burr cautions that NIST is not looking very closely at RADIUS usage and so there isn't a good view of what is being done here. He characterized the existing wireless key distribution mechanism (i.e. as used in 802.11i with RADIUS) as somewhat "Rube Goldberg". Bill described the process of obtaining a FIPS-140 certification and how painful it may be for vendors. Glen points out that there is a lot of interest in solving this problem and it has been solved, so why is there a new WLAN draft addressing the keying mechanisms? Dave Nelson (Chair) indicated that the keying problem seems to have a lot of interest. The WG might consider amending its charter (security mechanism restriction) to address this issue, if needed.

    [Ed. Note: Only the statements of Bill Burr should be considered as the position of NIST. Other statements are the opinion of the speaker.]

    - End-to-End capability exchange presented by Avi Lior.


    The proposal describes an end-to-end, per-session mechanism to negotiate capabilities. The attribute contains a string of octets where each capability is encoded in 2 bits that define, not-supported, supported and required. Avi points out other documents need this work; location in the GEOPRIV WG, VLAN, priority and filtering, CUI and prepaid could all use this. Should it be a WG document? No one objects to making this a WG item, but we will confirm this on the list. This document should be in alignment with Greg's work on Design Guidelines if we are defining a new data type.

    - RADIUS Prepaid attributes presented by Avi Lior.


    The document was re-organized for read-ability and updated. Flow based prepaid is becoming a requirement. Requested by 3GPP2 and WiMAX. The difference between RADIUS credit control (a.k.a. prepaid) and Diameter credit control was described. It is believed that some of the differences are regarding some features that may compromise the privacy of the client (e.g. balance check and cost inquiry). Other differences are not clear yet and need to be discussed. How can Diameter credit control and RADIUS prepaid be translated? The recommendation is that the server must do this itself. A recommendation from the audience was to have scenarios documented or analyzed - not necessarily included in the draft, but available. Different SDOs are using Diameter and RADIUS, and there will likely be some issues related to translation. Resolution of these issues may require assistance from 3GPP, 3GPP2 and WiMAX, as the RADEXT WG didn't anticipate supporting different "dialects" of the prepaid extensions. The authors believe the document is ready to become a WG item. Since the authors are not in complete alignment it was suggested that they hash out their problems before making it a WG document. The authors believe they have enough alignment, but being out of time, we will continue the discussion on the WG mailing list.

    - RADIUS Bandwidth attributes presented by Avi Lior.


    Issues from Bernard Aboba's extensive review have all been addressed, except one which is related to the length of the attribute size. Should this be a WG document? Discuss on the WG mailing list.

    - RADIUS QoS attributes presented by Hannes Tschofenig.


    Hannes describes a more general QoS environment. This work is related to the Diameter work. They are addressing a generic description described in NSIS QSPEC work. As compared to Avi Lior's bandwidth document, this is a more heavy weight description. Avi's document is viewed as a short term solution. There is the question of charter scope in RADEXT.

    - General WG Discussion about QoS and Bandwidth.

    Allison Mankin (Transport AD) points out that we shouldn't use RADIUS as a resource management protocol. She believes that RSVP and NSIS are the protocols to do resource allocation. There was an RSVP and Diameter document that is similar to proposed RADIUS document. John Loughney comments that the Diameter QoS document is an individual submission and not a current AAA WG document. John will post the link to the RADEXT WG mailing list for this document, so that we can review it. Allison mentions that we don't want to start extending the bandwidth draft to include a bunch of new things like latency and jitter, but they are happy with simple rates that are currently defined. Combining Avi's bandwidth draft and Hannes' QoS draft would certainly delay the simple bandwidth parameter attribute that has been requested by other SDOs. A comment from 3GPP is that they are depending upon the bandwidth draft to be complete for reference in their specification release 7, by mid-2006. The group doesn't believe they should be combined. Dave Nelson (Chair) asked what the overlap is between the documents. Avi points out that the QoS "blob" includes a bandwidth component and could be used, but John Loughney and the other authors believe there may be a solution on how cross reference the documents and avoid overlap. Dave (Chair) indicated he would work to facilitate the cross-WG and cross-Area coordination that will be required to move forward in this area.


    RADEXT WG IETF-63 Agenda
    RFC 2486bis a.k.a. Updated Network Access Identifier (NAI) Spec
    Chargeable User Identity
    RADEXT Dynauth MIBs
    RADIUS MIB Updates for IPv6
    RADIUS Issues & Fixes
    RADEXT WG RADIUS Attribute Guidelines
    Capability Exchange Requirements
    RADIUS Prepaid Extensions
    RADIUS Bandwidth Capability
    RADIUS Quality of Service Support