RADIUS has a problem. The name of the problem is MD5. The MD5 hash algorithm was defined in 1991, and was used in RADIUS in 1993. However, MD5 is no longer secure. It is a bit of a miracle that RADIUS is still safe to use, even though it is using 30 year-old cryptographic primitives!
It’s time for us to fix RADIUS.
We had originally proposed SRADIUS earlier this year to solve the problem of using MD5. We received a lot of useful feedback from the community about the name, and the technical content of the proposal. We have integrated those comments into a new and improved standard which has been accepted as a Working Group Document by the IETF. This new standard is called RADIUS 1.1, and replaces the earlier SRADIUS proposal.
What is RADIUS 1.1?
In short, RADIUS 1.1 fixes a few major issues dating back to 1993. The two major changes are:
1) Remove dependency on old cryptography
The original RADIUS protocol relies on MD5 encryption, which is decades old and is no longer secure. Worse, the FIPS (Federal Information Processing Standards) specifications do permit systems to use MD5, which makes it difficult to use RADIUS in a FIPS compatible environment.
2) Remove the 8-bit limit on the number of packets per connection
The original RADIUS protocol tracked requests and responses via an 8-bit “Identifier” field. This meant that only 256 packets could be sent from client to server (without getting a response), before the client had to open a new connection! As a result, it was difficult to use RADIUS in environments with high packet rates.
RADIUS 1.1 uses a 32-bit Token field to track requests and responses. Which means that a client can now send four billion packets to a server (without getting a response), before the client needs to open a new connection. High packet rates are now much easier to achieve.
What else has changed from RADIUS to RADIUS 1.1?
Not much. All of the attributes are the same. The RADIUS packet types are the same. The RADIUS packet header is mostly the same. The RADIUS state machine is the same. The attribute encoding, contents, format, meaning, etc. are all the same.
If you are implementing a RADIUS client or server, we suggest reading the specification for full details.
If you are running a RADIUS client or server, just know that “RADIUS 1.1” is little more than a configuration flag that products will implement. The flag can be enabled or disabled by the administrator, and that is it. When the flag is disabled, RADIUS is used. When the flag is enabled, RADIUS 1.1 is used.
The use of RADIUS 1.1 is negotiated for each connection, and it is therefore fully compatible with existing RADIUS implementations. It will “fall back” to using normal RADIUS if one end of a connection does not use RADIUS 1.1. So it is completely safe for an administrator to enable it everywhere.
The only practical difference for an administrator is that enabling RADIUS 1.1 means that the RADIUS server is now fully FIPS compatible.
What are the limitations of RADIUS 1.1?
RADIUS 1.1 can only be used over TLS connections, either as TLS (over TCP), or DTLS (over UDP). It uses the same port (2083) as existing RADIUS/TLS connections.
What is the current status of RADIUS 1.1?
The RADIUS 1.1 specification has been accepted by the IETFs RADEXT (RADIUS Extenations) working group. It is likely to be accepted as an IETF standard in mid 2023, and published towards the end of 2023.
Where can I get RADIUS 1.1?
You can download RADIUS 1.1 right now from GitHub. It is available in FreeRADIUS version 3.2.3 via a compile-time option. Using a compile-time option means that the existing behavior of FreeRADIUS is not changed. However, as the source code is available, it allows implementers to test their software against FreeRADIUS.
Once other vendors have implemented RADIUS 1.1 as well, we will make it part of the official release.
Need more help?
InkBridge Networks has been at the forefront of network security for over two decades, tackling complex challenges across various protocols and infrastructures. Our team of seasoned experts has encountered and solved nearly every conceivable network security issue. If you're looking for insights from the architects behind some of the internet's most foundational authentication systems, you can request a quote for network security solutions here.
Related Articles
Making RADIUS more secure
We are currently working in the IETF (Internet Engineering Task Force) to close those gaps and improve security for everyone. This article outlines some of the current shortcomings of RADIUS, best practices for mitigating against them, and a roadmap for how these vulnerabilities will be addressed within the RADIUS standard.
Announcing SRADIUS
We just released an Internet-Draft which defines “Secure RADIUS”, or “SRADIUS”. We also have preliminary code available. It’s only a small change from RADIUS, but (we hope) a big leap forward in RADIUS security.
This document builds on the Deprecating RADIUS document which we have recently published.