Recently, Radiator Software has been heavily involved in Internet Engineering Task Force (IETF) working groups. We see IETF as an important forum to discuss important developments that benefit our customers as well. Last month, IETF meeting 116 was organised in Japan, and Radiator Software participated in the meeting.
Now the IETF 116 has concluded and the newly rechartered RADIUS EXTensions (radext) working group is now organising its work items. The first drafts called for radext WG adoption are:
- RFC 6614 RadSec update: Transport Layer Security (TLS) Encryption for RADIUS
- RADIUS encryption and FIPS compliance enhancements, efficiency updates: RADIUS Version 1.1
- Guidance for using pre-shared keys as an alternative for certificates with (D)TLS: RADIUS and TLS-PSK
The RadSec update moves RadSec from experimental to standards track and updates TLS and encryption recommendations to cover TLSv1.3 and the current best practices.
FIPS compliance is achieved by removing the use of MD5 with RADIUS hop-by-hop attribute value obfuscation and message integrity signing. This frees the authenticator field in the RADIUS messages header and allows its re-use as a long identifier field. The current short identifier field is a major cause of problems with RADIUS, especially when used with connection oriented protocols, such as RadSec that runs over TCP. When identifiers run out, a new connection and TLS session is needed. This causes significant overhead on busy RADIUS systems.
Where RADIUS traffic is secured with TLS, many organisations can benefit from the possibility of using pre-shared keys (PSKs) instead of having to set up certificates. The use of PSKs with (D)TLS is mentioned in the current RFCs, but specific guidance of their use is now getting updated and expanded.
What does the above mean for Radiator users?
We will start implementing the new drafts and do testing, including interoperability testing, with other vendors. We will also participate in the radext working group activities to help advancing the drafts to RFCs. When the drafts stabilise, we’ll make our implementation available as part of Radiator. If you are interested in early testing, please let us know.
The work is just starting and the final number of drafts, their names and content, and resulting RFCs, are subject to change.
EAP Method Update (emu) working group has a number of drafts that are getting near to being published as RFCs.
One of the EMU drafts defines updates for using TLSv1.3 with PEAP, EAP-TTLS and some other TLS-based EAP methods. TLSv1.3 for PEAP and EAP-TTLS is already implemented in Radiator 4.27.
Another EMU working group draft defines updates and clarifications for TEAP, for which our customers have also shown a lot of interest. Radiator implementation for TEAP aims directly for the revised version and it is under development and interoperability testing.
Would you like to know more?
If you are interested more about these and other developments with Radiator, you can always contact us at info(a)radiatorsoftware.com. We are always delighted to hear about different use cases of our customers, and to provide assistance when needed.
