Name: RADIUS Extensions (RADEXT)

Description

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 (Security Area)
• BOF proponents: Alan DeKok <aland@deployingradius.com>
• BOF chairs: TBD
• Number of people expected to attend: 20
• Length of session (1 or 2 hours): 2 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:
  Minor updates to existing RADIUS TLS / DLTS deployments. Increased security by banning RADIUS/UDP over the wider Internet.
  Updates to implementations to remove MD4 and MD5 for SRADIUS.

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

Agenda

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

Links to the mailing list, draft charter if any, relevant Internet-Drafts, etc.

• Mailing List: https://www.ietf.org/mailman/listinfo/radext
• Draft charter: Added below
• Relevant drafts:
  • Use Cases:
  • Solutions
    • https://datatracker.ietf.org/doc/draft-dekok-radext-request-authenticator/

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
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, 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
  permitted.

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