RADIUS EXTensions
charter-ietf-radext-07-01

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.

Proposed milestones:

• Deprecating Insecure Practices in RADIUS to IESG ñ April 2026

• Review of RADIUS Security and Privacy to IESG - April 2026

• RADIUS Status-Realm and Loop Prevention to IESG - December 2026

• RADIUS Connect-Info attribute to IESG ñ August 2026

• RADIUS attributes for National Security and Emergency Preparedness to IESG ñ August 2026

• Carrying location objects with uncertainty in RADIUS to IESG ñ August 2026

• RADIUS Proxy Load Balancing to IESG - August 2026

• RADIUS Congestion Control to IESG - August 2026