RADIUS has used MD5 for security for almost thirty years. It is time to use a modern alternative: 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.
What is SRADIUS?
SRADIUS (pronounced “S” RADIUS) came out of a desire to remove thirty-year old cryptography from RADIUS. As RADIUS depends on MD5, is difficult to use RADIUS in a FIPS environment. The solution to this issue is simple remove MD5 from RADIUS.
There are a number of side effects and outcomes from this decision. In order to be secure, SRADIUS requires or uses the following technologies:
- TLS or DTLS transport,
- TLS-PSK, as pre-shared keys should replace shared secrets,
- TLS 1.3, as there is no reason to use any other version of TLS,
- no MD5! So no weird “encryption” of passwords, they’re protected by TLS, just like when you log into a modern web site,
- FIPS-140 compliant (so long as you don’t require CHAP authentication, MS-CHAP can still be fine)
- Allowing more than 256 packets on one connection.
- Supports all RADIUS packet formats and attributes: past, present, and future. Including CHAP and MS-CHAP.
You can think of SRADIUS as “RADIUS minus thirty year-old crypto, plus modern crypto”.
Why Use SRADIUS?
SRADIUS has a number of benefits over normal RADIUS. The first is that it can be used in a modern FIPS environment. The second is that it removes arbitrary limits on the number of packets per connection. This lets it be used in a “high load” environment, where there are large numbers of packets being sent.
How should it be used?
The goal is for NAS vendors to allow SRADIUS as a minor variant of RADIUS. The NAS administration interface should require no more than two pieces of information: NAS identity, and TLS-PSK. After that, SRADIUS should be simple.
We’ve had feedback from multiple customers that TLS is just too hard to configure. NAS equipment needs client certificates, which is a big administration change from a simple shared secret. Certificates expire and need renewal. These renewal processes can be complex, which means that by the time a certificate expires, no one knows how to renew it!
The solution is to mandate a simpler, more secure interface. From the point of view of the average administrator, not much will change. But the benefits will be increased security and stability for the RADIUS ecosystem.
Cloud Providers
Another benefit of SRADIUS is that it will be easier to use “RADIUS in the cloud”. Right now, almost all cloud providers use normal UDP, which is very insecure. When equipment is upgraded to support SRADIUS, it will be impossible to use an insecure configuration. Because SRADIUS must use good security from day one.
FreeRADIUS Implementation
There is code available for anyone wishing to do tests and interoperability. The changes are relatively small, and the source code diff from v3.2.x is about 2,000 lines including whitespace, comments, build flags, sample configuration, and documentation!
What happens next?
The SRADIUS specification has to work its way through the IETF. That takes time. But in the mean time, we will start shipping SRADIUS inside of the FreeRADIUS 3.2.x releases. We hope that NAS vendors and other RADIUS server vendors start enabling it.
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.
Introducing RADIUS 1.1
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.