Skip to main content

RADIUS EXTensions (radext)

WG Name RADIUS EXTensions
Acronym radext
Area Security Area (sec)
State Active
Charter charter-ietf-radext-08 Approved
Document dependencies
Additional resources Github RADIUS repo
Issue tracker
Wiki
Wiki tracking problems with RADIUS
Personnel Chairs Margaret Cullen, Valery Smyslov
Area Director Christopher Inacio
Mailing list Address radext@ietf.org
To subscribe https://www.ietf.org/mailman/listinfo/radext
Archive https://mailarchive.ietf.org/arch/browse/radext/
Chat Room address https://zulip.ietf.org/#narrow/stream/radext

Charter for Working Group

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 publish:
* minor RADIUS extensions as proposed standard
* RADIUS roaming and interoperability guidance with regards to historical implementations as informational or best practices
* clarifications as informational

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 the RadSec RFC (when published) must be justified.
Transport profiles should be compatible with RFC 3539, with any non-backwards
compatibility changes justified.

The goals of the RADEXT working group are to:

  • Define and publish minor extensions to RADIUS, such as new attribute definitions.

  • 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.

Milestones

Date Milestone Associated documents
Dec 2026 PS RADIUS Status-Realm and Loop Prevention draft to IESG
Aug 2026 PS RADIUS Congestion Control draft to IESG
Aug 2026 PS RADIUS Proxy Load Balancing draft to IESG
Aug 2026 INF Carrying location objects with uncertainty in RADIUS draft to IESG
Aug 2026 PS RADIUS attributes for National Security and Emergency Preparedness draft to IESG
Aug 2026 PS RADIUS Connect-Info attribute draft to IESG
May 2026 PS Review of RADIUS Security and Privacy draft to IESG
May 2026 PS Deprecating Insecure Practices in RADIUS draft to IESG