[802SEC] New IETF Working Group: RADIUS Extensions (radext)
The following announcement from the IETF may be of interest to certain
IEEE 802 working groups. IEEE 802 working group chairs should forward
this message to their group if they feel it is appropriate.
Paul Congdon
-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
On Behalf Of Bernard Aboba
Sent: Wednesday, July 14, 2004 12:17 PM
To: radiusext@ops.ietf.org
Subject: WG Action: RADIUS Extensions (radext)
A new IETF working group has been formed in the Operations and
Management Area.
For additional information, please contact the Area Directors or the WG
Chairs.
RADIUS Extensions (radext)
---------------------------
Current Status: Proposed Working Group
Chair(s):
Bernard Aboba <aboba@internaut.com>
David Nelson <dnelson@enterasys.com>
Operations and Management Area Director(s):
David Kessens <david.kessens@nokia.com>
Bert Wijnen <bwijnen@lucent.com>
Operations and Management Area Advisor:
David Kessens <david.kessens@nokia.com>
Technical Advisor(s):
aaa-doctors@ops.ietf.org
Paul Congdon <paul_congdon@hp.com>
Mailing Lists:
General Discussion: radiusext@ops.ietf.org To Subscribe:
radiusext-request@ops.ietf.org, 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
accounting.
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
RADEXT WG:
- 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.
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 LAN attributes draft 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.
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>
----------
This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.