Skip to main content

RADIUS EXTensions
charter-ietf-radext-06-01

The information below is for an older proposed charter
Document Proposed charter RADIUS EXTensions WG (radext) Snapshot
Title RADIUS EXTensions
Last updated 2023-02-03
State Start Chartering/Rechartering (Internal Steering Group/IAB Review) Rechartering
WG State Proposed
IESG Responsible AD Paul Wouters
Charter edit AD Paul Wouters
Send notices to (None)

charter-ietf-radext-06-01

The RADIUS Extensions Working Group will focus on extensions to the
RADIUS protocol pending approval of the new work from the Area Director
and clarify its usage and definition.

Furthermore, to ensure backward compatibility with existing RADIUS
implementations, as well as compatibility between RADIUS and Diameter,
the following restriction is imposed on extensions considered by the
RADEXT WG:

All documents produced must specify means of interoperation with legacy
RADIUS and, if possible, be backward compatible with existing RADIUS
RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675,
5080, 5090, 5176 and 6158. Transport profiles should, if possible, be
compatible with RFC 3539.

The WG will review its existing RFCs' document track categories and
where necessary or useful change document tracks, with minor changes in
the documents if needed. Any changes to document tracks require approval
by the responsible Area Director.

Work Items

The immediate goals of the RADEXT working group are to address the
following issues:

  • Deprecating the use of insecure transports outside of secure
    networks. This work updates RFC 6421 where possible.

  • Bring RFC 6614 (RADIUS/TLS), and RFC 7360 (RADIUS/DTLS) to
    Standards track.

  • Define best practices for using TLS-PSK with TLS-based transport.

  • Define best practices for RADIUS roaming, and roaming consortia
    based on experience with RADIUS/TLS.

  • Improve operations for multi-hop RADIUS networks: e.g. loop detection
    and prevention, a multi-hop Status-Server equivalent with ability to
    Trace the proxy steps a RADIUS message will follow.

  • Extend the 8-bit RADIUS ID space to allow more than 256 "in flight"
    packets across one connection.

  • Allow for CoA / Disconnect packets to be sent in "reverse" down a
    RADIUS/TLS or RADIUS/DTLS connection. This functionality assists with
    transit of NATs.

  • Defining Application-Layer Protocol Negotiation (ALPN) extensions for RADIUS/TLS and RADIUS/TLS
    which allow the use of those transports in a FIPS-140 compliant environment.

Timeline:

Much of this work should be completed by 2024 in order to be part of
the WiFi 8 release, with products in 2026.