Wednesday, November 16, 2022

Radiator team take part in RADIUS extensions working group reboot

With the Remote Authentication Dial-In User Service (RADIUS) standard in its early 30s, it continues to be the go-to protocol for network authentication use cases. With the IETF drafting RADIUS protocol’s standard RFC 2058 in the year 1997, RADIUS has seen continuous development even though Diameter (RFC 6733) was developed to be its intended successor. Since then, RADIUS has held a strong ground in networking authentication and Diameter has become de facto standard in the TELCO field.

RADIUS is still alive and the way to keep it current with the latest security requirements such as TLS 1.3 is by cooperation of many players in the field in joint standardisation of the protocol. Last week our technical team took part in the reboot of the RADIUS extensions working group at IETF 115 meeting in London.

Some highlights from the proposed future agenda for standardisation are updating RFC 6614 RADIUS over TLS (RadSec) and developing RADIUS protocol and extensions further towards current security requirements: for example SRadius draft, Extended ID and Reverse Change of Authorisation over RadSec.

What is SRadius?

SRadius is essentially a RADIUS packet transport profile, which would mandate TLS transport and remove the previous reliance on MD5 attribute obfuscation and packet signing. This is an important change as MD5 has been proven insecure (RFC 6151) and should no longer be used. SRadius implementation would then be FIPS-140 compliant while old RADIUS is not.

Why RADIUS should be secured with TLS?

Even with the use of current EAP authentication methods, RADIUS accounting messages can and are still sent in plain text format. This accounting information can include sensitive information such as user location attributes, which are open to eavesdropping by man-in-the-middle attacks without any encryption in-between. RADIUS over TLS protocol (RadSec, RFC 6614) tunnels this information with TLS. Both RadSec and SRadius secure the transport with TLS.

The working group reboot received interest and positive feedback from many stakeholders in the field working on both commercial and non-commercial RADIUS projects. There is unanimous support across the field that rebooting the RADIUS extensions working group is necessary for the future development of RADIUS. We are looking forward to working on RADIUS drafts and standards and implementing them in Radiator.

Want to know more?

Friday, November 4, 2022

Radiator Service Provider Pack 1.8 released!

We are happy to announce that Radiator Service Provider Pack (formerly known as Radiator Carrier Pack) has been released!

The main new development is a new Diameter relay functionality. With Diameter relay, incoming Diametet traffic load can be distributed to multiple instances. The workers can be optionally made visible only as a single Diameter node to the rest of the Diameter nodes. This enhances Diameter performance when Radiator is used as 3GPP AAA server or in other use cases. For the relay functionality, we have also provided configuration examples, for Radiator SIM Pack, Radiator 3GPP AAA Server and Radiator Policy and Charging Pack.

At the same time, new release contains performance enhancements for Diameter protocol and enhanced logging for Diameter request and answers messages. More info can be found out from Radiator Service Provider Pack revision history.

Would you like to know more?

If you would like to know more about Radiator Service Provider Pack and how it could be used in your use case, please contact our team at info(a)radiatorsoftware.com