Skip to main content


The information below is for an older version of this BOF request.
Document Type Proposed BOF request Snapshot
Title bofreq-dekok-radius-extensions-and-security-00
Last updated 2022-09-06
State Proposed
Editor Alan DeKok
Responsible leadership
Send notices to (None)

Name: RADIUS Extensions (RADEXT)


There is increasing conflict between the security practices defined in RADIUS and modern cryptographic requirements. The move to RADIUS over TLS / DTLS has helped to secure the base protocol. However, the use of MD4 / MD5 is still "baked into" RADIUS. The use of these digest algorithms makes it impossible to use RADIUS in a FIPS-140 compliant system.

The WG will define a new SRADIUS which drops all use of MD4 / MD5, and will be suitable for use in a FIPS environment. This work is expected to require only minor changes to existing implementations.

As part of this effort, the IETF will formally deprecate the use of RADIUS over UDP. There are still many cloud providers sending bare RADIUS packets over the Internet. This practice is insecure, and should be forbidden.

RADIUS over TLS / DTLS are in wide-spread use. They should be updated to use TLS 1.3, to require Server Name Indication (which helps with sites hosting multiple authoritative servers), and to move the documents to standards track.

In order to address the 8-bit ID limitation, we also propose to allow for more than 256 packets "in flight" on one connection between client and server. This change will permit higher throughput connections. Some vendors have already implemented their own versions of this work, which has proven to be successful in practice. This behavior should be documented and standardized.

Required Details

  • Status: WG Forming
  • Responsible AD: Paul Wouters
  • BOF proponents: Alan DeKok <>
  • BOF chairs: TBD
  • Number of people expected to attend: 20
  • Length of session (1 or 2 hours): 1 hours
  • Conflicts (whole Areas and/or WGs)
  • Chair Conflicts: TBD
  • Technology Overlap: EMU
  • Key Participant Conflict: Alan DeKok, Bernard Aboba

Information for IAB/IESG

To allow evaluation of your proposal, please include the following items:

  • Any protocols or practices that already exist in this space:
    RADIUS, and various implementations of the WG items proposed here.

  • Which (if any) modifications to existing protocols or practices are required:
    Minimal changes to existing systems to implement the various proposals.

  • Which (if any) entirely new protocols or practices are required:

  • Open source projects (if any) implementing this work:
    FreeRADIUS, Radsecproxy


  • Charter bashing
  • deprecating RADIUS / UDP outside of secure management networks
  • updating RADIUS over TLS / DTLS
  • best practices for RADIUS roaming
  • extending the 8-bit ID space
  • CoA in "reverse" down a TLS / DTLS connection
  • SRADIUS (RADIUS without MD4 / MD5)

Proposed Charter

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
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, 6158, 6421, 6613, 6614, 6911, 6929, 7360, 7585, 8044, and 8669.
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 UDP as a transport for RADIUS outside of secure
    networks. This work updates RFC 6421.

  • Moving RFC 6613 (RADIUS/TCP), RFC 6614 (RADIUS/TLS), and RFC 7360
    (RADIUS/DTLS) to Standards track. Mandate the use of TLS 1.3.
    Adding TLS Server Name Indication to TLS-based transports.

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

  • extend the 8-bit RADIUS ID space to allow more than 256 "in flight"
    packets across one connection. No changes to packet format are

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

  • TBD - Add a 64-bit "date" type. The "date" type is a 32-bit
    unsigned value, so it has a Y2106 problem, not a Y2038 problem.

  • Defining a secure variant of RADIUS which does not use deprecated
    cryptographic methods such as MD4 and MD5. This variant will be
    suitable for use in a FIPS compliant system. The transport will be
    required to be TLS or DTLS. The packet format is unchanged from
    RADIUS. However, the packets no longer need to be signed. The
    attribute format is unchanged from RADIUS. However, attributes such
    as User-Password no longer need to be obfuscated, and can be sent
    as-is. Attributes which require MD4 or MD5 are forbidden. In
    short, "RADIUS without MD4 or MD5".