RADIUS has used MD5 for security for almost thirty years. It is time to use a modern alternative: SRADIUS!

Secure RADIUS - 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?

Network RADIUS has been helping clients around the world design and deploy their RADIUS infrastructure for 20 years. We specialize in complex systems and have seen pretty much every variation and problem out there. If you want help from the people who wrote FreeRADIUS, visit our quote page to contact us for a consultation.