[radext] 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-08-01.

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 publish minor RADIUS extensions, best-practices documents
and clarifications.

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.

Work Items

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.

Proposed milestones:

* Deprecating Insecure Practices in RADIUS draft to IESG ñ April 2026

* Review of RADIUS Security and Privacy draft to IESG - April 2026

* RADIUS Status-Realm and Loop Prevention draft to IESG - December 2026

* RADIUS Connect-Info attribute draft to IESG ñ August 2026

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

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

* RADIUS Proxy Load Balancing draft to IESG - August 2026

* RADIUS Congestion Control draft to IESG - August 2026

Milestones:

  May 2026 - PS Deprecating Insecure Practices in RADIUS draft to IESG

  May 2026 - PS Review of RADIUS Security and Privacy draft to IESG

  Aug 2026 - PS RADIUS Connect-Info attribute draft to IESG

  Aug 2026 - PS RADIUS attributes for National Security and Emergency
  Preparedness draft to IESG

  Aug 2026 - INF Carrying location objects with uncertainty in RADIUS draft
  to IESG

  Aug 2026 - PS RADIUS Proxy Load Balancing draft to IESG

  Aug 2026 - PS RADIUS Congestion Control draft to IESG

  Dec 2026 - PS RADIUS Status-Realm and Loop Prevention draft to IESG