From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: radext@ietf.org
Reply-To: iesg@ietf.org
Subject: WG Review: RADIUS EXTensions (radext)
The RADIUS EXTensions (radext) WG in the Security Area of the IETF is
undergoing rechartering. The IESG has not made any determination yet. The
following draft charter was submitted, and is provided for informational
purposes only. Please send your comments to the IESG mailing list
(iesg@ietf.org) by 2026-04-14.
RADIUS EXTensions (radext)
-----------------------------------------------------------------------
Current status: Active WG
Chairs:
Margaret Cullen <mrcullen42@gmail.com>
Valery Smyslov <valery@smyslov.net>
Assigned Area Director:
Christopher Inacio <stndrds-inacio@andrew.cmu.edu>
Security Area Directors:
Deb Cooley <debcooley1@gmail.com>
Christopher Inacio <stndrds-inacio@andrew.cmu.edu>
Mailing list:
Address: radext@ietf.org
To subscribe: https://www.ietf.org/mailman/listinfo/radext
Archive: https://mailarchive.ietf.org/arch/browse/radext/
Group page: https://datatracker.ietf.org/group/radext/
Charter: https://datatracker.ietf.org/doc/charter-ietf-radext/
The RADIUS Extensions (radext) Working Group is responsible for maintaining
the RADIUS protocol, including defining extensions or making modifications
to the RADIUS protocol and related specifications, as needed. The WG is also
responsible for publishing best practices or other guidance, as needed,
to encourage the security, privacy, stability and reliability of RADIUS
deployments.
The radext WG will coordinate with other working groups, standards bodies
(such as the WBA), eduroam, and other organizations that define
RADIUS-related standards or operate RADIUS services. The radext WG will
publish minor RADIUS extensions, best-practices documents and clarifications,
as needed to support the work of those organizations.
To ensure backward compatibility with existing RADIUS implementations,
as well as compatibility between RADIUS and Diameter, all documents produced
must specify means of interoperation with legacy RADIUS. Any non-backwards
compatibility changes with existing RADIUS RFCs, including RFCs 2865-2869,
3162, 3575, 3579, 3580, 4668-4673, 4675, 5080, 5090, 5176, 6158, 6929, 8044
and the RadSec RFC (when published) must be justified. Transport profiles
should be compatible with RFC 3539, with any non-backwards compatibility
changes justified.
Work Items
The immediate goals of the RADEXT working group are to:
* Define and publish minor extensions to RADIUS, such as new attribute
definitions,
needed by external organizations or other IETF WGs.
* Define best practices for RADIUS roaming, and roaming consortia.
* Improve operations for multi-hop RADIUS networks, including:
** loop detection and prevention.
** a multi-hop Status-Server equivalent with ability to Trace the proxy
steps
a RADIUS message will follow.
** improve client-server signaling, and replace non-security requirements to
"silently discard" of packets with explicit signaling that a packet
(or a set of packets) cannot be processed.
** improve signaling of reasons for Access-Reject, including the ability to
signal
explicit refusal of certain authentications. Information from operators
shows that anywhere from 20% to 90% of authentications are for accounts
which are always rejected.
Milestones:
WG action announcement
WG Action Announcement
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: The IESG <iesg@ietf.org>,
radext-chairs@ietf.org,
radext@ietf.org
Subject: WG Action: Rechartered RADIUS EXTensions (radext)
The RADIUS EXTensions (radext) WG in the Security Area of the IETF has been
rechartered. For additional information, please contact the Area Directors or
the WG Chairs.
RADIUS EXTensions (radext)
-----------------------------------------------------------------------
Current status: Active WG
Chairs:
Margaret Cullen <mrcullen42@gmail.com>
Valery Smyslov <valery@smyslov.net>
Assigned Area Director:
Christopher Inacio <stndrds-inacio@andrew.cmu.edu>
Security Area Directors:
Deb Cooley <debcooley1@gmail.com>
Christopher Inacio <stndrds-inacio@andrew.cmu.edu>
Mailing list:
Address: radext@ietf.org
To subscribe: https://www.ietf.org/mailman/listinfo/radext
Archive: https://mailarchive.ietf.org/arch/browse/radext/
Group page: https://datatracker.ietf.org/group/radext/
Charter: https://datatracker.ietf.org/doc/charter-ietf-radext/
The RADIUS Extensions (radext) Working Group is responsible for maintaining
the RADIUS protocol, including defining extensions or making modifications
to the RADIUS protocol and related specifications, as needed. The WG is also
responsible for publishing best practices or other guidance, as needed,
to encourage the security, privacy, stability and reliability of RADIUS
deployments.
The radext WG will coordinate with other working groups, standards bodies
(such as the WBA), eduroam, and other organizations that define
RADIUS-related standards or operate RADIUS services. The radext WG will
publish minor RADIUS extensions, best-practices documents and clarifications,
as needed to support the work of those organizations.
To ensure backward compatibility with existing RADIUS implementations,
as well as compatibility between RADIUS and Diameter, all documents produced
must specify means of interoperation with legacy RADIUS. Any non-backwards
compatibility changes with existing RADIUS RFCs, including RFCs 2865-2869,
3162, 3575, 3579, 3580, 4668-4673, 4675, 5080, 5090, 5176, 6158, 6929, 8044
and the RadSec RFC (when published) must be justified. Transport profiles
should be compatible with RFC 3539, with any non-backwards compatibility
changes justified.
Work Items
The immediate goals of the RADEXT working group are to:
* Define and publish minor extensions to RADIUS, such as new attribute
definitions,
needed by external organizations or other IETF WGs.
* Define best practices for RADIUS roaming, and roaming consortia.
* Improve operations for multi-hop RADIUS networks, including:
** loop detection and prevention.
** a multi-hop Status-Server equivalent with ability to Trace the proxy
steps
a RADIUS message will follow.
** improve client-server signaling, and replace non-security requirements to
"silently discard" of packets with explicit signaling that a packet
(or a set of packets) cannot be processed.
** improve signaling of reasons for Access-Reject, including the ability to
signal
explicit refusal of certain authentications. Information from operators
shows that anywhere from 20% to 90% of authentications are for accounts
which are always rejected.
Milestones: