With Open Source software, the temptation for vendors is to say “we have the source, we can change it”, and then make many changes to create a custom version of FreeRADIUS. This process does not always work. Vendors can make their lives easier by following our best practices for customization, which we outline here.

Our guiding principle for FreeRADIUS customization is to keep things simple and modular, by leveraging its API and its plugin architecture. This practice makes upgrade paths much simpler, and the embedded product much easier to maintain. It can also have positive legal implications!

Best practice #1: Don’t make changes to the core code

It can be tempting to build customizations directly into the core code of FreeRADIUS. However, there are some serious drawbacks to this approach.

It makes upgrades difficult. Whenever a new version of FreeRADIUS is released, any local changes will have to be integrated into the new version. These local changes may conflict with changes made in the upstream distribution, and can require significant work to merge. In addition, there will be additional work on testing and QA in order to ensure quality and stability. All of this effort takes time and expertise.

Any new FreeRADIUS features will need to be re-implemented. If a new release of FreeRADIUS has some functionality that a vendor would like to use, it is often difficult to integrate those features into a heavily modified implementation. Typically, the vendor ends up having to re-implement the new features themselves into their own customized version. Which is another waste of time and resources.

It requires maintaining RADIUS expertise in house. One of the key benefits of embedding FreeRADIUS as an OEM product is that you do not need to have any particular RADIUS expertise in-house to use it. FreeRADIUS handles the RADIUS portion of the work, and your team can focus on the part which integrates it with the rest of your product. In addition, your team can rely on Network RADIUS for any RADIUS or FreeRADIUS questions.

Once you start making customizations to the core code, you lose the benefit of using an upstream release. A local version which is heavily modified will require significant experience in RADIUS and FreeRADIUS, In order to maintain the product over multiple releases and over multiple years. If anyone on the local team moves elsewhere, the company will be left with software which is critical for a product line, but which has no one internally to support or even understand it.

In our experience working with OEM vendors of FreeRADIUS, we’ve seen cases where upgrades are avoided altogether because the system is so heavily patched that it is essentially a custom RADIUS server. This approach is costly, and is not recommended.

Best practice #2: Leverage the API and plugin modules

In most cases, customizations to FreeRADIUS can be handled through its powerful plugin architecture.

Plugin modules communicate with FreeRADIUS via an internal API which has been unchanged for many years. If a vendor has a proprietary system which needs to exchange information with FreeRADIUS, it is possible to create a separate plugin module which accesses the external system. Similarly, a vendor needing new functionality can create a custom module which implements that functionality. This module will have full access to the FreeRADIUS internals, and can do just about anything.

Because the FreeRADIUS software is publicly available, we have seen some vendors put their customizations directly into the core APIs of FreeRADIUS. This approach gives them the worst of both the open source world, and the proprietary software world.

Because they are altering an open source product, they must release their customizations under a GPL license as well. This of course might reveal more than they want to about their proprietary products. Conversely, because their customizations are embedded in various places throughout the source code, there are usually only a handful of people on the vendor side that understand and are able to maintain it.

Aside from just being a better programming practice in general, the use of plugin module makes a clear separation between the Open Source code, and any external APIs used by the vendor. The result is that a vendor can have a standard RADIUS server, accommodate highly customized behavior, and protect their intellectual property all at the same time.

Best practice #3: Keep data external to FreeRADIUS where possible

Vendors sometimes maintain user account information and configurations within the FreeRADIUS server, in custom configuration. This practice is not recommended. Any bulk data should be stored in a database. Database APIs are standardized, well understood, and can be easily accessed by external systems. In contrast, configuration files are bespoke, and it is difficult to share the information the contain via a simple API.

A common use-case is to have many users, but only a few different types of user profile. For example, user profiles could be “super-user”, “admin”, “read-only”, or “normal”. These profiles could be assigned to many thousands of users.

Even worse, the use of devices from multiple network equipment vendors means that the RADIUS response required to set the “admin” profile may be different from vendor to vendor!

For this scenario, any RADIUS-specific profiles need to be kept in the FreeRADIUS configuration. However, these profiles are few in number, the contents of the profile are small (only a few if / then / else conditions and setting of attributes), and the profiles rarely change.

In contrast, there are many thousands of users, where those users are added, deleted, and modified regularly. That user information belongs in a database, which can contain the profile name along with any additional per-user data such as names, passwords, etc..

The bottom line

FreeRADIUS provides many mechanisms for allowing customizations to be implemented without touching the core code at all. This modularity is very much by design, making FreeRADIUS extremely flexible and able to integrate with external systems, without requiring deep expertise of the underlying technology.

In general, OEM vendors should make use tools like configuration files, external databases, plugin modules, and the internal APIs in order to achieve the customization they need.

We’re here to help!

FreeRADIUS is used by all of the cloud-based RADIUS providers, as well as nearly all the networking companies (Aruba, Extreme, etc.) and token card companies (RSA, etc.). We’ve helped those customers build and maintain their OEM versions of FreeRADIUS. In cases where we’ve been involved from the start, maintenance is straightforward. We check configuration files and their REST API and the vendor is off to the races. In other cases where the source code has been heavily modified before we’re called in, we need to spend a lot of time untangling the changes that have been made before we can even start moving forward.

If you need help with an OEM implementation of FreeRADIUS, reach out to us by visiting our quote page.

Information is sent “in the clear”

The most obvious shortcoming of RADIUS is that, other than a few attributes such as User-Password, all information is sent “in the clear”. This means that things like users’ location data and device MAC addresses, among others, are sent in clear text across the network. This has obvious privacy and security implications when UDP is used across the Internet.

What to do about it right now

The first step is to stop using insecure transports such as UDP and TCP for RADIUS traffic. Instead, we strongly recommend using TLS. An issue that affected RADIUS/TLS in version 3 of FreeRADIUS was resolved earlier this year, so the transition from UDP to TLS should be straightforward. If using certificates is too hard, we recommend using TLS-PSK. Administrator overhead for TLS-PSK is not substantially higher than for shared secrets, and TLS-PSK offers significantly increased security and privacy.

Looking ahead

Another way of increasing privacy with RADIUS is to minimize the amount of PII (Personal Identifying Information) which is sent in packets. Where possible, identities should be anonymized using the Chargeable-User-Identifier. Other information such as device identity, user location, and visited networks should be omitted, anonymized, or replaced. A more detailed discussion of these issues can be found in our IETF Draft

MD5 has been broken

The security of RADIUS relies on an MD5 signing of the packet using the shared secret. Unfortunately, MD5 has been broken for over a decade. GPUs have gotten faster, which means that administrators should assume that when RADIUS/UDP packets are sent over the Internet:

• any shared secret of 8 characters or less has been immediately compromised.
• any shared secret of 10 characters or less has been compromised by an attacker with significant resources.
• any private information (such as User-Password) which depends on a cracked secret has also been compromised.

What to do about it right now

First, don’t send RADIUS/UDP traffic across the Internet. It was a terrible idea ten years ago. It is incredibly irresponsible to do that in 2023.

For internal use in management networks, RADIUS/UDP can be acceptable. But the RADIUS traffic should be isolated from all other network traffic, ideally via a VLAN or an IPSec connection. If you must use RADIUS/UDP in any context, we recommend using strong shared secrets. Use at least 32 characters, and take the shared secret from a cryptographically strong pseudo-random number generator.

Looking ahead

One of the biggest barriers to sending RADIUS traffic using TLS instead of UDP is that many NAS hardware devices do not support this functionality. As seen in our document, the IETF is mandating that TLS-based transport layers be used for RADIUS traffic outside of secure networks. This document will become an IETF standard in the near future. We hope that these new requirements will push NAS vendors to make RADIUS/TLS available in their products.

Short shared secrets have been compromised

Because of the ease of cracking MD5, administrators should assume that all short shared secrets have been compromised by anyone who can see RADIUS/UDP traffic.

What to do about it now

You should immediately change all short shared secrets to ones that have at least 32 characters (we recommend 64). It is very easy to create long shared secrets. One way of doing this is the following script:

#!/usr/bin/env perl
use MIME::Base32;
use Crypt::URandom();
print lc encode_base32(Crypt::URandom::urandom(24)), "\n";

Given the simplicity of creating strong secrets, there is no excuse for using weak shared secrets with RADIUS.

Additionally, we repeat that you should send RADIUS traffic over TLS, rather than UDP.

Looking ahead

This cannot be fixed as it is a fundamental design flaw in the RADIUS protocol. We can only “paper over” the issue by using RADIUS/TLS.

Secure storage of passwords

The authentication protocol used for RADIUS has knock-on effects for the related systems that use it. Specifically, we recommend that the PAP protocol be used because it allows passwords to be stored in the database in salted/encrypted form. They are in clear-text only temporarily in the memory of the RADIUS server which receives and then verifies the password

By contrast, using CHAP or MS-CHAP instead of PAP means that the passwords must be stored in clear text in the database, all of the time. Any compromise of the application means that the entire database can be immediately read and exfiltrated as a whole. The attacker then has complete access to all user identities, and all associated clear-text passwords.

Given that the vast, vast, majority of breaches consist of database attacks, the risk of password compromise is much less with PAP than with CHAP or MS-CHAP.

What to do about it now

If possible, make sure that you are using the PAP authentication protocol. Store passwords securely in a database.

Looking ahead

We cannot mandate which authentication protocols are used, but we will continue to strongly recommend using PAP for the foreseeable future.

MS-CHAP is broken

In addition to the vulnerability described above regarding the storage of passwords, MS-CHAP is also deeply flawed and should be considered an insecure protocol.

Recent developments have demonstrated that it is possible to crack MS-CHAP exchanges with consumer hardware within milliseconds. This means that for all intents and purposes, any MS-CHAP exchanges that are sent using UDP or TCP transports should be considered compromised.

What to do about it now

Our first recommendation is always to use PAP instead of MS-CHAP. However, if this is not possible, MS-CHAP should always be used within TTLS, PEAP, or RADIUS/TLS.

Looking ahead

In our proposed IETF standard, we are deprecating insecure transport protocols for RADIUS and will be mandating that MS-CHAP authentication data carried in RADIUS must not be sent over UDP or TCP

To summarize

The key take-aways from this summary are as follows:

• Stop using insecure transports such as UDP and TCP. (mandated in upcoming new standard)
• Use long shared secrets, at least 32 characters (mandated in upcoming new standard). 64 characters are preferred (recommended)
• Use PAP instead of CHAP or MS-CHAP as the authentication protocol (recommended)
• If MS-CHAP must be used, it must be sent across a secure transport such as TLS (mandated in upcoming new standard)

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.

Conclusion? MS-CHAP is insecure. MS-CHAPv2 is insecure. MS-CHAP is dead.

This attack means that if you have sent MS-CHAP over the wider Internet in the past 10 years, you should assume that the underlying user passwords have been compromised.

While some people still claim that MS-CHAP is secure, the truth is that MS-CHAP is dead. No one should use MS-CHAP outside of a secure transport protocol such as PEAP or TTLS.

MS-CHAP depends on cracked DES encryption

The MS-CHAP authentication method was first created in 1998. At the time, it used the industry standard encryption method at the time, which was DES (Data Encryption Standard). The DES standard had been used across the U.S. government since the 1970’s as a secure way of exchanging confidential data.

Around the same time of the MS-CHAP standard however, critics of DES estimated that the key size was too short and efforts were afoot to crack it through brute force attacks. The Electronic Frontier Foundation created custom microchips and other hardware to successfully decrypt DES in 1998. Over the next two years, they were able to progressively decrease the cracking time from 56 hours, to less than a day.

The successful attacks on DES cryptography led to it being replaced by AES (Advanced Encryption Standard) as the U.S. federal standard in 2002.

MS-CHAP implementation of DES is flawed

Even if DES was completely secure, there is a key flaw in the design of MS-CHAP that makes it highly vulnerable to attacks. To understand the flaw in MS CHAP we need to look more closely at how DES is integrated with the protocol.

As part of the handshake protocol, MS-CHAP exchanges a 16 character NT hash of the password. These keys are mapped to DES keys, which uses 56 bit (7 characters) for keys for its encryption. The mismatch means that in order to use the NT hash with DES, there are 3 separate DES operations as seen below.

Each byte of the NT hash maps to a DES key, but that leaves five (5) bytes left over. So the last DES key only uses the first two characters for the NT hash, and the rest of the key is filled with padding, which is all zeroes.

This is the key flaw in the MS-CHAP implementation. Instead of filling out the last five characters of the final DES key with secure data (for example, by wrapping around to the beginning of the hash and re-using “Hash 1”, “Hash 2” etc), it is simply padded out with zeros. This means that the final DES key has only 16 bits of actual key data, and the rest of the key bits are known.

The problem space is now only 2¹⁶, instead of 2⁵⁶. In other words, for DES key 3, there are only slightly over 65,000 possible values instead of over 72 Quintillion. On modern hardware, it is possible to “brute force” search all possible values for DES key 3, and find those 16 bits. While this attack is brute-force, 2¹⁶ is not a large number, and doing 2¹⁶ DES operations is trivial for any modern computer.

All that remains then is to crack the remaining 14 bytes of the NT hash. Admittedly, this is still a lot of key space to search: 2^(56+56) or 2¹¹² which is a huge number. However in 2012, a key insight showed that you could leverage the design of MS-CHAPv2 to instead search only 2⁵⁶ possible keys, which could be cracked using a brute force attack in less than a day.

This time can be further reduced by noting that most passwords are generated by users, and in computer security terms, do not have large entropy. In human terms, that means that the passwords are likely to be re-used, and therefore guessable.

We can make many guesses by using freely available lists of most frequently used passwords, and creating pre-build “dictionaries” which precompute the NT hash values for those passwords. These dictionaries can also be created for any additional information about targeted individuals such as birthdays, pet names, children names, company names / projects, etc. A simple program can generate hundreds of millions or billions of such guesses, and store them in a simple database on commodity hardware. This database would take at most a few tens of gigabytes of space, which is less than many high-end games.

The final nail in the coffin

In 2021, the final nail in the coffin of MS-CHAP security was demonstrated by leveraging a novel strategy of:

1. Brute force cracking the third DES key to get the last 16 bits of the NT-hash,
2. Storing a database of billions of guessed passwords and their NT hash, indexed by the final 16 bits of the hash
3. Using the found DES key to get a list of guessed passwords (index lookups are fast), which reduces the search space by 2¹⁶

The result was that it with a little bit of work and disk space, it is now possible to obtain the underlying MS-CHAP password very quickly, with much less than 2⁵⁶ possible work.

That is, if the database stores a table of 4 billion passwords, then dividing that search space by 2¹⁶ means that the system only has to brute-force check about 65,000 passwords. The result of this algorithm attack means that MS-CHAP can be cracked by checking 64K DES keys, and then using large tables to get another 64K NT hashes to check. The combined cost of these two operations is very, very, small. A laptop with a few gigabytes of memory and a large SSD can crack MS-CHAP in only a few milliseconds.

In other words, if your organization sent MS-CHAP over the internet with user generated passwords, you can assume that those passwords are now in the hands of malicious actors, or the NSA, or both.

Some notable exceptions

There are some caveats to this doomsday proclamation, however.

The flaws of MS-CHAP can be mitigated by running it inside of TTLS or PEAP. This is the approach used by the eduroam community and it works well since those EAP methods protect MS-CHAP by wrapping it in a secure layer of TLS. Since TLS has not been broken, no one can see the MS-CHAP data, and the attack is stopped in its tracks.

Another factor that can make this attack somewhat less effective is by encouraging users to use computer generated passwords (for ex: the passwords suggested by web browsers or common password managers.) These randomly generated passwords will not appear on any of the pre generated password tables, and therefore will still require brute force effort to crack

This is small comfort however, as the brute force attack requires only 2⁵⁶ operations, and that was shown to be possible over 25 years ago!

Even if none of the above attacks worked, there is still a major security problem with MS-CHAP: it requires you to store clear-text passwords in the database. (Or NT-hashes, which are “clear-text equivalent.”) Any compromise of the database means that all user identities and passwords can be trivially copied by an attacker.

Our recommendation, then, is do not use MS-CHAP. Adding a PEAP or TTLS wrapper to simple MS-CHAP helps a little bit against some attackers, but it is still not secure.

What to use instead of MS-CHAP

We always maintain that the most secure protocol for authenticating users is PAP. Using PAP means that passwords can be stored in the database in a salted/hashed form. Given that the vast majority of data breaches have succeeded by targeting password databases, storing passwords in an encrypted form is definitively the most secure approach for any authentication system.

Still need 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.

What does this mean for RADIUS, especially since RFC 7542 allows using email addresses as identifiers? Speaking as the author of RFC 7542, I think I can help you.

The short answer is that an email address at my organization is not a valid identifier at your organization. For the simple reason that my organization controls the mapping between the person (or people!) and the email address (or addresses!) that they use, and you don’t. Since you don’t control this mapping, you have no idea who is behind an email address.

As such, email addresses are best used for contacting users. But user identies at your site must be controlled by you. Any email address(es) or physical addresses for a user should be additional fields associated with the user identity. Other fields could be ones like login credentials, telephine number, billing information, rate plan, etc. That separation allows the user identity to remain constant while other information about the user changes.

Relationship to RFC 7542 Network Access Identifier (NAI)

If I agree that email addresses are not user identifiers, then why does RFC 7542 allow them to be used as identifiers?

The answer is that the NAI is defined for routing inside of an AAA system. That is, when a user logs into your site (e.g. a visited network as with eduroam), that identifier is used to route your login request to the home network. That home network knows who you are, and knows the association between the email address and the person. The home network then authenticates you (or not), and returns success / fail to the visited network.

This routing means that the user identity at my organization is never validated by your organization. Instead, the two organizations trust each other (via RADIUS proxying). My organization can vouch for my user at your organization, and the same goes in reverse. There is no need for your organization to know anything about the person behind the email address. The address is just used as a routing label, not a personal identifier!

GPDR and Privacy

Is it a good idea, then to use an email address for network access, such as with eduroam?

No.

The network access identifier should contain domain routing information, such as @example.com. There is no need for it to contain user identifiers, such as bob@example.com. When the NAI contains identifying information for a particular user, then there are major impacys on user privacy, including General Data Protection Regulation (GPDR) issues.

That is, there is no need for the visited network (or any proxy) to identify a particular user. Even worse, when proxying is done via RADIUS/UDP, then pretty much anyone can see who is accessing the network, which networks they are accessing, what devices they are using to access the network, etc. We have written extensively on RADIUS insecurity, and we are working at the IETF to formally deprecate RADIUS/UDP.

We understand that some RADIUS servers (or one in particular) do not permit anonymous NAIs. We understand why people use that server, it’s simple, cheap, and it mostly works. But we cannot in all good conscience recommend this practice.

Email addresses are not identifiers

In conclusion, email addresses are not primary user identifiers, and should never be used as such.

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.

The IETF is meeting in San Francisco for IETF 117. We are working on a number of standards in different groups.

RADIUS Extensions (RADEXT)

The bulk of our work is in the RADIUS extensions (RADEXT) working group. The documents we are working on are:

• RADIUS v1.1. Updating RADIUS for 2023 technology! This topic is covered in more detail in our other article, Introducing RADIUS 1.1

• TLS-PSK The original RADIUS/TLS specifications did not describe how to use TLS-PSK with RADIUS. This document corrects that mistake. In many cases, it can be simpler to use pre-shared keys with RADIUS, than configuring clients with certificates.

• Deprecating insecure transports. This document suggests that it’s a bad idea to use “bare” UDP or TCP transports across the Internet. We have more discussion on this topic in our RADIUS Insecurity article.

• Reverse CoA. When a NAS connects to a RADIUS server via TLS, it can be difficult (or impossible) to send CoA-Request or Disconnect-Request packets to the NAS. This document describes how to send CoA packets in “reverse” down that RADIUS/TLS connection. While it is not yet a working group document, we believe that it will be published shortly. It is most likely to be useful in OpenRoaming.

EAP Updates

We are working with the EAP Method Update (EMU) working group to update the TEAP RFC.

There is a strong demand for TEAP, in part because of its ability to do provisioning inside of the TLS tunnel. We have implemented TEAP in FreeRADIUS 3.2.3, and are working on updates and documentation.

We are also monitoring EAP-FIDO, which is a new proposed specification that uses Passkeys for 802.1X. The hope is that EAP configuration will become little more than “Use EAP-FIDO for network access”. It looks like this will not only work, but that it will not be too complicated to do.

If EAP-FIDO reaches its potential, then many Mobile Device Management (MDM) problems simply go away. That is a good thing for enterprises and universities.

DHC

We are working with the [DHCP]((https://datatracker.ietf.org/wg/dhc/about/) working group to clarify implementation issues with DHCPv6.

Our customers have run into issues with DHCPv6. We are working on updates to clarify “best practices” around DHCPv6.

Madinas

MAC address randomization can make MAC authentication difficult. We are following the Madinas working group to ensure that new standards meet the markets needs, and are secure.

TACACS+

Now that the TACACS+ RFC has been published, the working group is updating the document for TACACS+ TLS. Many of our customers use TACACS+, and there is a strong need for a version of the protocol which uses modern cryptography.

How this affects people using FreeRADIUS

People using FreeRADIUS can rest assured that FreeRADIUS is compatible with all “up and coming” Internet standards. In fact, led by Alan DeKok, the team at Network RADIUS continues to lead the industry in defining and implementing these standards, as we have done for decases.

Your RADIUS systems will continue to get more secure, and more flexible.

We continue to follow these, and other standards. Our goal is to serve our customers, to improve the technology, and to make peoples lives easer.

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.

One of our key design principles for network configuration is to always design for the worst case scenario. It is a fact of life that at some point, a network component will fail. There are a variety of reasons for failure, and each of those reasons requires analysis. Designing for these failures is hard.

That is, it is easy to design a system which works when everything is fine. It is much harder to design a system which can gracefully adapt to failures. Designing for failure is just as important as designing for optimal performance, but it is a frequently overlooked aspect of network design.

In our work with clients, we often are asked to review network designs which will work just fine as long as nothing ever goes wrong, or if nothing ever changes. However, they are extremely fragile to any problems that occur (and they will occur). In this article, we look at network architectures which are intended to deal gracefully with the failure of a RADIUS server. Some designs work well, others less so.

Randomly assigned RADIUS servers

One solution for RADIUS server failure is to randomly assign clients to one of several RADIUS servers for authentication. This design does provide multiple servers for redundancy, but it is suboptimal. If one of the servers goes down, traffic is routed only to the available ones. It is also hard to know which of the clients were associated with the offline server and need to be reconnected. When something goes wrong. administrators have a random collection of clients which need to be fixed or checked.

This design adds some resiliency, but it greatly increases administrator load when the network has an issue, which is precisely the worst time to give administrators more work!

Geographically assigned RADIUS servers

An improvement to the above design RADIUS servers is to separate the servers by geographical area. In the US for example, it is common to have separate servers assigned to east, central, and west regions.

Depending on the IP address of the client, clients are configured to communicate with the RADIUS server (or servers) which are responsible for that specific geographical area. The client configuration can also specify a secondary server if the primary is not available.

Geographically assigning RADIUS servers to clients has a few advantages over the randomly assigned solution mentioned previously.

• If one of the RADIUS servers goes down, it is clear which clients have been affected and need to be reconnected
• Multiple RADIUS servers for each geographical area provides a certain degree of redundancy.

However, specifying the fail-over options in the client has a significant drawback.

The unfortunate truth is that fail-over implementations vary widely by client, and these implementations can often be unreliable. For example, some clients check server availability very infrequently (if at all), resulting in some clients never getting switched back to their original server once the problem has been resolved. Some other clients check for server availability too frequently, leading to clients getting moved from one server to another, impacting performance.

Geographically assigned RADIUS groups

An improvement to the geographically assigned RADIUS servers is to create a local management network or subnet for each geographic area. All of the geographical areas can use the same subnet and list of server IP addresses, as each area does not need to communicate with another area. The servers can share an IP address, using a system like High Availability (HA), or a load balancer.

Each area then can contain multiple RADIUS servers, but these details are hidden from clients. From the client point of view, there is only a single IP address for each geographic area.

Creating local networks for each area has several advantages:

Simplified client configuration and maintenance. RADIUS servers can be added and removed from each area without requiring any changes to the region specific client.

Improved stability of the overall ecosystem. Fail-over implementation in clients is notoriously unreliable. Putting the fail-over logic within the network itself makes the behavior more stable and predictable.

Greater control over fail-over behavior. It is simply a better choice to put network logic within the network itself, rather than in the client. By removing any dependencies on the client implementation, the system administrator can have much more fine-tuned control over what happens in the event of failures.

Creating networks to serve specific geographic areas, and configuring clients to point to the appropriate area still has one significant drawback however. It still requires the clients to maintain some logic about the network. Ideally, we want our clients to be as simple as possible, and put all the network logic within the network. We can improve on this design further.

Single RADIUS IP address

Our last solution completely abstracts the geographical designations of the RADIUS servers and presents only one single IP address to all of the clients. This practice is called “anycast”, and is done by using a routing protocol such as BGP or OSPF.

Putting all the RADIUS servers behind one IP address means that all the clients can be configured in exactly the same way. Unlike the geographically assigned RADIUS groups, the clients don’t even need to know what region they are in so that they can direct traffic accordingly. In this scenario, the clients are simple in the sense that they contain no network information at all, aside from the one RADIUS IP address.

The single RADIUS IP address solution has the following advantages

Standardized client configuration. Unlike any of the other solutions discussed above, this configuration allows all clients to be configured identically. When all clients have the same standard configuration, deploying and maintaining them becomes almost trivial.

Scaling the backend ecosystem doesn’t require any changes to the clients. The backend can be arbitrarily complex behind the IP address used by all the clients. For example, additional RADIUS servers can be added, a load balancer can be introduced to distribute traffic to a sharded configuration, or RADIUS servers can be split between live and historical data. These changes can be made behind the scenes without making any changes at all to the clients.

Improved fail-over capability. Because the routing logic is in the network and not in the clients, the overall system can be extremely resilient to even catastrophic events. For example, if there is a major power outage in the Eastern region, the traffic can simply be rerouted to the Western RADIUS servers without the clients ever noticing a difference. Or in extreme cases where multiple areas go down, new RADIUS servers can be spun up in minutes and all the traffic redirected to the new instances.

Design principles for resilient network design

Our discussion of different fail-over design configurations draws on some of our core network design principles.

• Always design for the worst case scenario. Bad things will happen, be prepared.
• Keep the clients as simple as possible. Keep network logic in the place most capable of handling it, in the network itself. You can control the network, you cannot control the client fail-over implementation.
• Look for ways to centralize configuration. If many different parts of your system require custom configuration, you’re probably making it more complex than it needs to be.
• Designing for failure not only makes your system more resilient, it also usually results in simplified overall configuration, maintenance, and ability to scale.

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.

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?

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.

Many cloud providers such as AWS offer database hosting services which seem reasonably priced at a first glance. They also typically offer additional benefits over a “self hosted” system such as security, tiered support, and scalability. This combination makes cloud hosted databases a sensible choice for many organizations.

That said, some of our clients have been blind-sided with high cloud costs for their hosted RADIUS databases. Why does this happen?

Most uses of cloud databases are for reads

A typical use-case for cloud databases is to store large amounts of data, and to do many queries. The data is updated occasionally, but not often. In many cases, reads outnumber writes one hundred to one.

Write operations are more expensive

The main issue with hosted databases is that the pricing models are based on the use-cases where database read operations strongly outnumber the database writes. In some cases, write operations can cost five times as much as read operations!

This model is fine if most of what you need to do is query a customer database or inventory system, and only occasionally do writes. However, the database usage pattern in a RADIUS ecosystem can be the exact opposite of this scenario, with the number of writes at least equal to the number of reads, and sometimes more.

For example, if you need to keep track of session data for accounting purposes, or if you keep your historical data separate from your live data, each RADIUS accounting packet results in one database read, and one database write. For an ISP with a million users, this can be a million read/write cycles, every ten minutes, 24 hours a day, seven days a week. The database write costs alone can quickly reach tens of thousands of dollars a month. This expense would be over and above the cost of storing hundreds of gigabytes of accounting data.

These numbers are enormous when you consider a comparison with a more conventional cloud storage scenario where reads outnumber writes by 100 times, a RADIUS server has closer to 1-1 read/write distribution. Which means that using RADIUS in the cloud can be hundreds of times more expensive than a non-RADIUS use-case!

The performance is artificially throttled

Some cloud hosting companies will also artificially throttle throughput at lower price tiers. This means that a smaller database will get slower performance, forcing the customer to pay for more storage than they need, in order to get the performance they want.

In RADIUS systems, it is common to expect performance of thousands of reads/second to authenticate users, even with relatively small databases. In the artificially throttled cloud model, you cannot get this level of throughput unless you pay for more storage capacity which then also permits higher throughput.

Coupling the pricing for performance with storage capacity means that customers have to choose the most expensive option to get the functionality they need from the cloud. The alleged “benefits of the cloud” turn out to have their costs, just like any other solution. In fact, we have seen several clients need to unnecessarily inflate the size of their databases simply to get better performance.

Shared resources are throttles resources

In many cases, it is possible to use a cloud virtual machine (VM), but not the cloud database. You can install your own database, and get a much better cost / performance ratio. There is still the downside that the cloud VM is using shared resources, and performance might just drop to near-zero for periods of time! If another VM on the same physical system is using large amounts of CPU time, disk IO, or network connectivity, then other VMs on the system can get “starved” of resources.

While such a cloud system may be “up” for purposes of monitoring, its performance will be minimal. So it might as well be “down”, as it cannot handle the load it normally needs to process.

What to do instead

If your organization is exploring cloud storage because you don’t want the overhead of managing your own database, and “cloud is cheaper”, there are other options.

We often recommend that our clients set up their own database and put it on their own hardware. They can then simply store their data server in a third party data center, which will provide physical security and temperature control. The data center will typically only charge for traffic, not storage because you are using your own hardware. This pricing model is often much truer to the promise of paying for “only what you need” than most cloud storage providers.

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.

It is important to remember that there is no “one size fits all” approach to database architecture for RADIUS. Rather, it is helpful to start with how you plan on using the database, and then design a system which supports those use-cases.

Here are some of the most common considerations:

• How many users are authenticating on your network?

• What kind of authentication protocols are they using?

• How are passwords stored in the DB? Encrypted? Cleartext?

• Do you need to keep track of accounting information?

• Are you billing users for their usage?

• Do you have multiple locations?

  • If so, how do you synchronize the database between the locations?

• Do you need to keep track of historical data for legal reasons?

• Do you need to detect and/or stop credential sharing?

• Do users tend to authenticate once during the day or do they authenticate multiple times throughout the day?

• Are you doing IP address assignment?

  • How many IP addresses need to be managed?

All of these factors should be considered when designing your RADIUS database ecosystem. Some of these might seem obvious, but others are less intuitively connected to database implications.

Number of users

This is probably the most intuitively understood factor for database design. Very large databases can be slower to respond than smaller ones, especially if the indexes are not carefully designed. One way to address these issues is to add more databases, either in a “cross bar” design, or as load-balanced shards. See our discussion on scaling RADIUS infrastructure .

Tracking accounting information

If your business needs to bill customers for their network usage, you should consider splitting the authentication and accounting functionality of your RADIUS system into separate databases.

Separating the two capabilities into independent databases means that users can still be authenticated if the accounting database is slow or unavailable. As RADIUS clients will retransmit accounting packets, these retransmits can work around an accounting database being down for a short period of time, and often no accounting information will be lost. On the other hand, if the authentication database is down, no user can get onto the network, and many users will call support.

For organizations which don’t need to track accounting information, such as typical enterprises or universities, this design is not necessary. However, for ISPs and telecoms, it is usually foundational to our RADIUS ecosystem design. See our article about separating Accounting from Authentication functionality.

It is also possible to split the accounting database into “live” and “historical” systems. The RADIUS server will write to the “live” system, and the “historical” system can be used for complex end of month billing queries. These queries may take significant resources on the database, which could negatively affect the RADIUS server if the queries were done on the “live” system.

Servicing multiple locations

Many large organizations have multiple locations. From universities with multiple campuses in the same general area, to ISPs with locations all over the country, to enterprises with locations that span the globe. To support multiple locations, we typically recommend cloning the primary RADIUS server and its related database(s). There are definitely nuances to this approach depending on the specific requirements of the organization. See our design blueprint for universities, and our design strategy for multi-site ISPs.

Retaining historical data

Many ISPs and telecoms are required to maintain historical data to comply with regulatory requirements. Keeping current session data in a separate database from historical session data is strongly recommended in this situation. The “live” accounting database is small and needs to be fast, whereas the “historical” database can be many terabytes in size and has fewer requirements for speed. See our article on separating historical data.

Preventing credential sharing

In some cases,credential sharing can be a major issue for ISPs, resulting in significant losses in revenue. To prevent credential sharing, the RADIUS infrastructure must check all new sessions against all current live sessions to ensure that there aren’t more than one session at a time for a given user. The database design needs to support more than just a simple authentication query for each new session. See our design strategy for multi-site ISPs for a detailed discussion.

Supporting authentication “peaks”

In most university settings, authentication requests tend to come in waves at the beginning of each class period. This places unique demands on the RADIUS infrastructure. See our design blueprint for universities for a detailed discussion.

The bottom line

Many organizations need to support more than one of these considerations. For example, a university might have multiple locations and authentication peaks. Or an ISP might have millions of users, and must track accounting information, and services multiple locations, and must retain historical information. The result is that RADIUS system design requires expertise, and a deep understanding of RADIUS and databases. It is just not possible to pick “a good design” and use it everywhere.

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.

Basic RADIUS configuration

The most simple and straightforward RADIUS system consists of a single RADIUS server and a single database.

This one-to-one configuration is appropriate for networks that need to support relatively small numbers of users. As a rule-of-thumb, a single RADIUS server and database is a reasonable implementation for up to 100,000 users.

However, this one-to-one setup doesn’t work very well for more than 100,000 users and is vulnerable to failure. If either the RADIUS system or the database are down, the entire system is down. Moreover, upgrading anything requires you to take the entire system offline, which is often not acceptable.

RADIUS crossbar configuration

For networks serving roughly between 100,000 and 1 million users, we usually recommend a “crossbar configuration” to improve performance and introduce redundancy into the system

In this architecture, RADIUS server 1 normally uses Database 1, and RADIUS server 2 normally uses Database 2. The two databases are synchronized with each other so that they contain the same information.

In the event that Database 1 fails or needs maintenance, RADIUS 1 can then easily switch over to using Database 2. Similarly, if Database 2 goes down, RADIUS 2 can seamlessly transition to using Database 1. If one of the RADIUS servers goes down or needs upgrading, the other RADIUS server takes over, and users experience no disruption in service.

The crossbar configuration is generally suitable for up to about 1 million users. Some more scalability can be gained by deploying multiples of the same configuration in multiple geographic locations.

Load balanced configuration

For networks that must support over 1 million users, we recommend a load balanced or “sharded” configuration.

In a sharded architecture, there are multiple pairs of RADIUS servers and databases, and a load balancer distributes the traffic between them. The number of shards can scale up depending on the number of users. The databases are synchronized so that they all contain the same information.

The benefit of a sharded configuration are that it can scale very easily. As the number of users grows, more RADIUS/Database pairs can be added. There is no need to change the client configuration, or create complex fail-over scenarios. Simply add more back-end systems, and the load accepted by the RADIUS servers will scale nearly without limit.

Sharded configurations also provide many levels of redundancy. If any component of any of the “shards” are compromised or is taken down for maintenance, the load balancer detects that situation, and stops sending packets to that particular shard temporarily. When the shard comes back online, the load balancer will automatically start using it again.

All of these configurations can be used in conjunction with any of the other RADIUS database architectures for specific characteristics. For example, it is possible to separate accounting from authentication functionality, or split historical data from “live data”. There is no need to use the same architecture for authentication and accounting. There is no need to use the same architecture in different locations.

For more details on RADIUS system architecture, see our article on RADIUS database architecture considerations.

The costs of implementing the wrong design

There are many costs to using the wrong design for your network. The simplest of course is increased expense, time, and effort for complex systems which are not needed. Similarly, a system which is too small will not be able to handle the traffic, which will result in users being unable to access the network.

It may be tempting to use cloud services which automatically scale, and are billed only for services used. However, using cloud services is not always recommended, as they have their own costs and benefits. We will cover those services in another article.

As with all summary articles, this one provides a high level summary of the technical issues. The numbers given above are only a guideline, and are not intended to be a “written in stone” set of recommendations. Your individual architecture may differ from the ones described here, depending on your local requirements.

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.