A Review of RADIUS Security and Privacy

Introduction The RADIUS protocol was first standardized in 1997, though its roots go back much earlier to 1993. The protocol uses MD5 to authenticate some packets, and to obfuscate certain attributes such as User-Password. As originally designed, Access-Request packets were entirely unauthenticated, and could be trivially spoofed ( and ). As much of the protocol data is sent in clear-text, packets can leak information about use names, devices, and locations. This document provides a comprehensive review of RADIUS security and privacy. The discussion here motivates the changes to RADIUS security which are made in . In order to simplify the protocol changes for implementers, this historical review is a separate document from the protocol changes. While this document contains some operational recommendations, it does not change the RADIUS protocol.

History of RADIUS Security The insecurity of MD5 has been known for a long time. It was first noted in relation to RADIUS in 1996 on the IETF RADIUS working group mailing list , which also discussed using an HMAC construct to increase security. While it was common knowledge at the time, the earliest record of concerns about Access-Request packets spoofing was on the RADIUS working group mailing list in 1998. There was substantial further discussions about the lack of integrity checks on the list over the next few years. The outcome of that process was the definition of Message-Authenticator as an optional HMAC-based attribute in . Unfortunately, the use of Message-Authenticator was made optional. This lack of integrity checks for Access-Request packets was deemed acceptable for some situations in :

Access-Request packets with a User-Password establish the identity of both the user and the NAS sending the Access-Request, because of the way the shared secret between NAS and RADIUS server is used.

That conclusion now appears to be incorrect. The text continues with an acknowledgment that:

Access-Request packets with CHAP-Password or EAP-Message do not have a User-Password attribute, so the Message-Authenticator attribute should be used in access-request packets that do not have a User- Password, in order to establish the identity of the NAS sending the request.

This text was non-normative due to the lowercase 'should'. It appears that no implementation followed even this limited suggestion. The packet forgery issue was further discussed in 2004 in , and again in 2007 in . That document suggested that implementations require the use of Message-Authenticator in order to prevent forgery:

However, Access-Request packets not containing a Message- Authenticator attribute ... may be trivially forged. To avoid this issue, server implementations may be configured to require the presence of a Message-Authenticator attribute in Access-Request packets. Requests not containing a Message-Authenticator attribute MAY then be silently discarded.

It appears that only one RADIUS server implemented even this limited suggestion. At the time of publication of , there was no consensus to require the use of Message-Authenticator in all Access-Request packets. If this recommendation had instead been made mandatory, then the recent BlastRADIUS attack would largely have been prevented. The state of MD5 security was again discussed in , which states in Section 2:

MD5 is no longer acceptable where collision resistance is required such as digital signatures.

That statement led to RADIUS security being reviewed in . The outcome of that review was the text in the remainder of , which created crypto-agility requirements for RADIUS. The main outcome of those requirements was not any change to RADIUS, but instead the definition of RADIUS/TLS in , and RADIUS/DTLS in . Another outcome was the consensus that adding crypto-agility to RADIUS was likely not a good idea, and that standardizing RADIUS over TLS instead was a significantly better path forward. RadSec has now been standardized in . That document standardizes TLS and DTLS transporst for RADIUS, which gives implementors and operators a way to secure the RADIUS protocol. As for RADIUS/UDP and RADIUS/TCP, they still depend on MD5 for all security. The insecurity of MD5 was noted in , which is over a decade old as of the time of publication of this document. The recommendation to use Message-Authenticator in is almost two decades old. The knowledge that Access-Request packets lack integrity checks is almost three decades old. Over that entire span of time, there has been no mandate to increase the security of Access-Request packets. This document explains why that mandate is now being made in . It is no longer acceptable for RADIUS to rely on MD5 for security. It is no longer acceptable to send device or location information in clear text across the wider Internet. This document therefore explains why insecure uses of RADIUS need to be deprecated. mandates the use of secure practices in RADIUS, including the use of (D)TLS via .

RADIUS/UDP over the Internet is insecure Since the insecurity of MD5 has been well known for decades, RADIUS traffic over the Internet was historically secured with IPsec as described in :

To address the security vulnerabilities of RADIUS/EAP, implementations of this specification SHOULD support IPsec (RFC2401) along with IKE (RFC2409) for key management. IPsec ESP (RFC2406) with non-null transform SHOULD be supported, and IPsec ESP with a non-null encryption transform and authentication support SHOULD be used to provide per-packet confidentiality, authentication, integrity and replay protection. IKE SHOULD be used for key management.

The use of IPsec allowed RADIUS to be sent privately, and securely, across the Internet. However, experience showed that TLS was simpler than IPSec in many ways simpler for implementations and deployments. While IPsec required operating system support, TLS was an application-space library. This difference, coupled with the wide-spread adoption of TLS for HTTPS, ensures that it was often easier for applications such as RADIUS to use TLS than IPsec. RADIUS/TLS and RADIUS/DTLS were then defined in order to meet the crypto-agility requirements of . RADIUS/TLS has been in wide-spread use for about a decade, including in eduroam , and more recently in OpenRoaming and . RADIUS/DTLS has seen less use across the public Internet, but it still has multiple implementations. However, RADIUS/UDP is still widely used, even though it depends on MD5 and "ad hoc" constructions for security. The recent BlastRADIUS attack shows just how inadequate this dependency is. The details of the BlastRADIUS attack are discussed in more detail below, in .

RADIUS/UDP Has Security and Privacy Problems Even if we ignore the BlastRADIUS attack, problems with MD5 mean that a hobbyist attacker who can view RADIUS/UDP traffic can brute-force check all possible RADIUS shared secrets of eight characters in not much more than an hour. A more resourceful attacker (e.g. a nation-state) can check all much longer shared secrets with only modest expenditures. See below for a longer discussion of this topic. Determining the shared secret will also result in compromise of all passwords carried in the User-Password attribute. Even using CHAP-Password offers minimal protection, as the cost of cracking the underlying password is similar to the cost of cracking the shared secret. MS-CHAP ( and MS-CHAPv2 ) are significantly worse in security than PAP, as they can be completely broken with minimal resources. Attacks on MS-CHAP are described below in . The use of Message-Authenticator does not change the cost of attacking the shared secret. The Message-Authenticator attribute is a later addition to RADIUS, and does does not replace the original MD5-based packet signatures. While that attribute provides stronger protection for packets, it does not change the cost of attacking the shared secret. Moving to a stronger packet signatures (e.g. ) would still not fully address the issues with RADIUS, as the protocol still has privacy issues unrelated to the the security of the Authenticator field. Most attributes in RADIUS are sent in clear-text, with only a few attributes such as User-Password and Tunnel-Password have their contents hidden. The hidden attributes rely on "ad hoc" obfuscation methods using MD5, which have not been successfully attacked, but have not proven to be secure. Peoples locations can (and has) been accurately determined, and people have been tracked using location data sent insecurely across the Internet (). The implications for security and individual safety are large, and negative. These issues are only partly mitigated when the data carried within RADIUS use their own methods for increased security and privacy. For example, some authentication methods such EAP-TLS, EAP-TTLS, etc. allow for User-Name privacy and for more secure transport of passwords via the use of TLS. Some privacy can be gained through MAC address randomization, which can also limit device information identification to a particular manufacturer, instead of to a unique device. However, these methods are not always used, or are not always available. Even if these methods were used ubiquitously, they do not protect all of the information which is publicly available over RADIUS/UDP or RADIUS/TCP transports. And even when TLS-based EAP methods are used, implementations have historically often skipped certificate validation, leading to password compromise (). In many cases, users were not even aware that the server certificate was incorrect or spoofed, which meant that there was no way for the user to detect that anything was wrong. Their passwords were simply handed to a spoofed server, with little possibility for the user to take any action to stop it.

Simply using IPsec or TLS is not enough The use of a secure transport such as IPsec or TLS ensures complete privacy and security for all RADIUS traffic, but only for one client to server connection. An observer of encrypted traffic is limited to knowing rough activity levels of a client or server. That is, an observer can tell if there are a few users on a NAS, or many users on a NAS. All other information is hidden from all observers. Even with those limitations, it is not enough to say "use IPsec" and then move on to other issues. There are many issues which can only be addressed via an informed approach. For example, it is possible for an attacker to record the session traffic, and later crack the TLS session key or IPsec parameters. This attack could comprise all traffic sent over that connection, including EAP session keys. When the cryptographic methods provide forward secrecy (), then breaking one session provides no information about other sessions. The final attack possible in a AAA system is where one party in a AAA conversation is compromised or run by a malicious party. This attack is made more likely by the extensive use of RADIUS proxy forwarding chains. In that situation, every RADIUS proxy has full visibility into, and control over, the traffic it transports. The solution here is to minimize the number of proxies involved, such as by using Dynamic Peer Discovery, as defined in . There are many more security issues in addition to the need for a secure transport. The rest of this document discusses those issues in detail.

Overview of this document This document begins with a summary of issues with RADIUS, including showing just how trivial it is to crack RADIUS/UDP security. We then explain why mandating a secure transport is necessary, and describe what that requirement means in practice. We give recommendations on how current systems can be migrated to using TLS. We give suggestions for increasing the security of existing RADIUS transports, including a discussion of the authentication protocols carried within RADIUS. We conclude with security and privacy considerations. As IPsec has been discussed previously in the context of RADIUS, we do not discuss it more here, except to say it is an acceptable solution for securing RADIUS traffic. As the bulk of the current efforts are focused on TLS, this document likewise focuses on TLS. We note that all of the issues raised here about the RADIUS protocol also apply to IPsec transport. That is, when the application is not in charge of protocol security, the application is vulnerable to transport misconfigurations or attacks.

A Comment on Specifications While this document tries to be comprehensive, it is necessarily imperfect. There may be issues which should have been included here, but which were missed due to oversight or accident. Any reader should be aware that there are good practices which are perhaps not documented in a specification, and bad behaviors which are likewise not forbidden. For example, documents such as were written to both correct errors in earlier documents, and to address harmful behaviors which had been seen in practice. These harmful behaviors can have a large impact both on security and on interoperability, even if they are not expressly forbidden in a specification. There is a regrettable belief in some readers that a particular practice is "allowed" by a specification, simply because the practice is not forbidden. This belief is wrong. That is, a behavior which is not even mentioned in the specification cannot honestly be said to be "permitted" or "allowed" by that specification. The most charitable description would be that these behaviors are undefined, or perhaps not forbidden. By their very nature, documents include a small number of permitted, required, and/or forbidden behaviors. There are a much larger set of behaviors which are undefined. That is, behaviors which are neither permitted nor forbidden. Those behaviors are unconstrained by the specification, and therefore may be good or bad. Outside of published specifications, there is also a large set of common practices and behaviors which have grown organically over time, but which have not been formally written down. These practices have been found to be valuable by implementers and administrators. Deviations from these practices generally results in instabilities and incompatibilities between systems. As such, implementers should exercise caution when creating new behaviors which have not previously been seen in the industry. Such behaviors are likely to cause problems, where there would have been no problems if common practices had been followed instead. It is RECOMMENDED that implementations and administrators follow widely accepted practices which have been proven to work and to be secure, even if those practices are not written down in a public specification. Implementers SHOULD NOT create features which depend on undefined behavior; such features are very likely to be wrong.

Terminology

RADIUS

The Remote Authentication Dial-In User Service protocol, as defined in , , and among others.

RADIUS/UDP

RADIUS over the User Datagram Protocol as define above.

RADIUS/TCP

RADIUS over the Transport Control Protocol

RADIUS/TLS

RADIUS over the Transport Layer Security protocol

RADIUS/DTLS

RADIUS over the Datagram Transport Layer Security protocol

the Transport Layer Security protocol. Generally when we refer to TLS in this document, we are referring to RADIUS/TLS and/or RADIUS/DTLS.

Network Access Server, which is a RADIUS client.

In order to continue the terminology of , we describe the Request Authenticator, Response Authenticator, and Message-Authenticator as "signing" the packets. This terminology is not consistent with modern cryptographic terms, but using other terminology is inconsistent with historic RADIUS practices. The reader is assured that no modern cryptographic methods are used with RADIUS/UDP.

Security Issues with RADIUS There are a large number of issues with RADIUS. The most serious is the BlastRADIUS vulnerability, which means that subject to some limitations, attackers can leverage MD5 known-prefix collisions to cause any user to be authenticated, and then be given any authorization. Multi-factor Authentication (MFA) systems can be bypassed, and in many cases the RADIUS server will not even be aware that an unauthorized user is on the network. Another issue is that RADIUS sends most information (but not passwords) "in the clear", with obvious privacy implications. Publicly available data includes information such as names, MAC addresses, locations, etc. As for authenticating the packets themselves, even if Message-Authenticator is used for integrity checks, an average hobbyist who observes RADIUS traffic can perform brute-force attacks to crack even seemingly complex shared secrets. There is no way to fix the RADIUS protocol to address all of these issues. The short-term fix is in , which requires the use of Message-Authenticator to authenticate Access-Request packets, and responses to them. The long-term solution is in , which wraps the protocol in a secure transport. With the benefit of experience, errs on the side of security, while still allowing for backwards compatibility. It is not acceptable to permit insecure practices in the RADIUS protocol simply because a small number of implementations or organizations find it difficult to upgrade. Insecure implementations or practices have a concrete cost not only to the insecure organizations, but also to other organizations via secondary effects. When insecure organizations demand that others follow insecure practices continue due to perceived local costs, they are effectively offloading their costs onto everyone else. This practice both decreases security, and increases costs. We address these issues in more detail below.

The BlastRADIUS Vulnerability The BlastRADIUS vulnerability was first described in . This section gives a short summary of why RADIUS is vulnerable to this attack. , below, gives a longer explanation as to how the attack works, and why the mitigations defined in protect from the attack. The reader is referred to for a comprehensive description of the attack. The discussion below assumes that there exist plain texts "A", "B", "S". Following the practice of , we use "+" to denote concatenation. The vulnerability then relies on the following property of MD5:

If MD5(A) == MD5(B), then MD5(A + S) == MD5(B + S)

This construction menas that if an attacker is given text "A", and can find text "B" which has the same MD5 hash, then the attacker can perform a chosen prefix attack. The attack works even if the attacker does not know text "S". That is, given M5(A + S), then the attacker can trivially calculate MD5(B + S): it has the same value. In RADIUS, the Response Authenticator field is calculated via precisely this vulnerable construct:

Response Authenticator = MD5(packet + secret)

The attacker can generally observe or predict an Access-Reject packet, as they are generally empty. Each valid Access-Reject is signed with a shared secret unknown to the attacker. With sufficient work, the attacker can create an Access-Accept which has the same MD5 hash as the Access-Reject. The attacker then replaces the Access-Reject with this Access-Accept, using the Response Authenticator from the Access-Reject. The client will then receive the packet, calculate MD5(Access-Accept + secret), and verify that the Response Authenticator is correct. The client will then follow the attackers instructions: give the user access, along with some authorization. This chosen prefix attack is root cause behind the BlastRADIUS vulnerability. We note also that this attack does not expose the contents of the User-Password attribute. Instead, the attack simply bypasses all server-side authentication, and fools the client into accepting a forged response. While this attack requires that an attacker be "on path" and be able to intercept and modify packets, the meaning of "on path" is often "the entire Internet". As such, the existence of this attack alone is sufficient reason to deprecate all uses of RADIUS/UDP and RADIUS/TCP.

Failed Attempts to Improve RADIUS Security Independent of any cryptographic vulnerability, there are a number of factors which contributed to the ongoing failure to improve RADIUS security. A major factor is the continued use of MD5 for security, instead of mandating the use of an HMAC via Message-Authenticator. This change could have been made in in the year 2000. The stated reason there for not mandating Message-Authenticator was the issue of backwards compatibility. Unfortunately, experience shows that issues which are not fixed just grow larger over time. The issue of backwards compatibility is significantly worse now than it was in the year 2000. The issue of unauthenticated Access-Request packets was raised again in , and again was widely ignored. If vendors had implemented this recommendation in 2007, then the BlastRADIUS attack would have been impossible.

Failures of the Protocol State Machine Another contributing factor to the BlastRADIUS vulnerability is the principle of "be conservative in what you do, be liberal in what you accept from others", often known as Postel's law, after John Postel. This principle means that a client will accept packets that are well-formed, but which contain invalid signaling. Specifically, the Proxy-State attribute is intended for signalling between a proxy and a "next hop" server. It offers no value for RADIUS clients. A NAS which originates packets therefore does not send Proxy-State in an Access-Request, and should also not receive Proxy-State in any response packets. If a NAS does receive Proxy-State in a response, where the request did not contain Proxy-State, this is arguably a violation of the protocol state machine. It would be useful if such a packet would either trigger a warning message, or instead be rejected entirely. That is, when a NAS sees Proxy-State in an Access-Accept, that is a failure of signaling in the RADIUS protocol. It indicates either a serious failure of configuration, implementation, or as seen in this case, an active attack. If the specifications had instructed clients to discard responses which contained unexpected Proxy-State attributes, then this attack would have been prevented.

Most information is sent in Clear Text Even ignoring security issues, the RADIUS protocol has fundamental problems with privacy. With the exception of a few attributes such as User-Password, all RADIUS traffic is sent "in the clear" when using UDP or TCP transports. When using EAP, some EAP methods allow for user privacy, but the EAP Identitity and therefore User-Name are sent in the clear. For TLS-based EAP methods, any client certificate is sent in the clear when using TLS 1.2 or earlier. Even when RADIUS/TLS is used, all RADIUS traffic (including User-Password) is visible to proxies. The resulting data exposure has a large number of privacy issues. We refer to , and specifically to for detailed discussion, and to for recommendations on threat mitigations. When RADIUS/UDP or RADIUS/TCP is used across the public Internet, common configurations allow the location of individuals to be tracked in real-time (usually 10 minute intervals), to within a small physical location. The users devices can be identified, and also tracked. Even when the packets do not contain any location information for the user, the packets usually contain the MAC address of the Wi-Fi access point. The MAC address and physical location of the user device and often W-Fi access points are publicly available. There are multiple services selling databases of Wi-Fi access point location. More discussion of location privacy is given in , which defines an "Architecture for Location and Location Privacy in Internet Applications". However, that work was published too late to have any practical impact on the design of location information attributes, as had already been published. The effect of these design decisions is that any observer of non-TLS RADIUS traffic is able to obtain a substantial amount of personal identifiable information (PII) about users. The observer can tell who is logging in to the network, what devices they are using, where they are logging in from, and their approximate location (usually city). With location-based attributes as defined in , a user's location may be determined to within 15 or so meters outdoors, and with "meter-level accuracy indoors" . An observer can also use RADIUS accounting packets to determine how long a user is online, and to track a summary of their total traffic (upload and download totals). These issues are not theoretical. Recently, noted for the Diameter protocol that:

Overall, I think the above three examples are just the tip of the proverbial iceberg of SS7 and Diameter based location and monitoring exploits that have been used successfully against targeted people in the USA.

continues with a statement that there have been:

... numerous other exploits based on SS7 and Diameter that go beyond location tracking. Some of these involve issues like (1) the monitoring of voice and text messages, (2) the delivery of spyware to targeted devices, and (3) the influencing of U.S. voters by overseas countries using text messages.

While these comments mention only Diameter, the same location tracking and monitoring is also possible with RADIUS. There is every reason to believe that similar attacks on RADIUS have occurred, but are simply less publicized than similar attacks on Diameter.

MD5 has been broken Attacks on MD5 are summarized in part in . The BlastRADIUS work substantially improved the speed of finding MD5 collisions, and those improvements are publicly available at . While there have not been many other new attacks in the decade since was published, that does not mean that further attacks do not exist. It is more likely instead that no one is looking for new attacks.

Cracking RADIUS shared secrets can be cheap The cost of cracking a a shared secret can only go down over time as computation becomes cheaper. The issue is made worse because of the way MD5 is used to authenticate RADIUS packets. The attacker does not have to calculate the hash over the entire packet, as the hash prefix can be calculated once, and then cached. The attacker can then begin the attack with that hash prefix, and brute-force only the shared secret portion. At the time of writing this document, an "off the shelf" commodity computer can calculate at least 100M MD5 hashes per second. If we limit shared secrets to upper/lowercase letters, numbers, and a few "special" characters, we have 64 possible characters for shared secrets. Which means that for 8-character secrets, there are 2^48 possible combinations. The result is that using a consumer-grade machine, it can take about 32 days to brute-force the entire 8 octet / 64 character space for shared secrets. The problem is even worse when graphical processing units (GPUs) are used. A high-end GPU is capable of performing more than 64 billion hashes per second. At that rate, the entire 8 character space described above can be searched in approximately 90 minutes. This is an attack which is feasible today for a hobbyist. Increasing the size of the character set raises the cost of cracking, but not enough to be secure. Increasing the character set to 93 characters means that the hobbyist using a GPU could search the entire 8 character space in about a day. Increasing the length of the shared secret has a larger impact on the cost of cracking. For secrets ten characters long, the search space is approximately 2^60. One GPU can search a 64-character space in about six months. A 93 character space (2^65 complexity) would take approximately 24 years. This brute-force attack is trivially parallelizable. Nation-states have sufficient resources to deploy hundreds to thousands of systems dedicated to these attacks. That reality means that a "time to crack" of 24 years means "24 CPU years", and does not mean "wall clock" time. A thousand commodity CPUs are enough to reduce the crack time from 24 years to a little over a week. This attack is feasible for any organisation with a modest amount of resources. Whether the above numbers are precise or only approximate is immaterial. These attacks will only get better over time. The cost to crack shared secrets will only go down over time. If the shared secret is long, then "cracking" the secret is expensive, and different trade-offs occur. Rather than cracking the secret, it is cheaper to perform the BlastRADIUS attack at a cost of approximately 2^53 per packet, and less than $100 in purchased CPU time. While cracking the shared secret would break all RADIUS packets using that secret, forging one packet is likely enough to give the attacker administrator access to a NAS, where the shared secret is likely to be visible in the administration interface. The conclusion, then, is that increasing the security of the shared secret offers minimal protection when the Access-Request packets are unsigned. Even if the shared secrets were enough to secure all RADIUS packets, administrators do not always derive shared secrets from secure sources of random numbers. The "time to crack" numbers given above are the absolute best case, assuming administrators follow best practices for creating secure shared secrets. For shared secrets created manually by a person, the search space is orders of magnitude smaller than the best case outlined above. Rather than brute-forcing all possible shared secrets, an attacker can create a local dictionary which contains common or expected values for the shared secret. Where the shared secret used by an administrator is in the dictionary, the cost of the attack can drop by multiple orders of magnitude. Implementers and administrators should assume that a hobbyist attacker with modest resource can crack most shared secrets created by people in minutes, if not seconds. Despite the ease of attacking MD5, it is still a common practice for some "cloud" and other RADIUS providers to send RADIUS/UDP packets over the Internet. It is also common practice for administrators to use "short" shared secrets, and to use shared secrets created by a person, or to use secrets that are derived from a limited character set. Theses practice are simple to implement and to follow, but they are highly insecure, and do not provide adequate security. Any system using these practices is vulnerable to all of the issues which are outlined in this document. gives suggestions for how strong shared secrets can be created.

CoA-Request packets might leak Tunnel-Password contents There are a number of security problems with the use Tunnel-Password attribute in CoA-Request and Disconnect-Request packets. A full explanation requires a review of the relevant specifications. Section 2.3 describes how to calculate the Request Authenticator field for these packets: Where Section 3 says: Taken together, these definitions mean that for CoA-Request packets, all attribute obfuscation is calculated with the Reply Authenticator being all zeroes. In contrast for Access-Request packets, the Request Authenticator is mandated to be 16 octets of random data. This difference reduces the security of the obfuscation. For Tunnel-Password, Section 3.6 allows it to appear in CoA-Request packets: However, Section 3.5 says that Tunnel-Password is encrypted with the Request Authenticator: The assumption that the Request Authenticator is random data is true for Access-Request packets. That assumption is not true for CoA-Request packets. That is, when the Tunnel-Password attribute is used in CoA-Request packets, the only source of randomness in the obfuscation is the salt, as defined in Section 3.5; This chain of unfortunate definitions means that there is only 15 bits of entropy in the Tunnel-Password obfuscation (plus the RADIUS shared secret). It is not currently known if this limitation makes it sufficiently easy for an attacker to determine the contents of the Tunnel-Password, as the obfuscated value still depends on the shared secret. However, such limited entropy cannot be a good thing. Due to the above issues, the use obfuscated attributes in CoA-Request or Disconnect-Request packets needs to be avoided.

Secure transports are not enough The above analysis as to security and privacy issues focuses on RADIUS/UDP and RADIUS/TCP. These issues are partly mitigated through the use secure transports, but it is still possible for information sent over a secure transport to "leak". The reason for this leakage is that RADIUS does not provide end to end security. All security is "hop by hop", even when RadSec or IPsec are used. A server which receives packets over a secure transport can forward the packets over an insecure transport protocol. While this process could arguably be seen as a misconfiguration issue, it is never the less possible due to the design of the RADIUS protocol. There is no way for one "hop" to know anything about, or to control, the security of another "hop". The use of channel binding does not prevent these attack, as they made by parties within the trusted RADIUS system. Instead, channel binding protects from an unrelated attack by an untrusted third party. One solution to the above issues would be to create a new protocol which provides for "end to end" security by design, but that solution is not practical.

All short shared secrets have been compromised As a result of the above analysis, administrators can assume that any shared secret of 8 characters or less has been compromised as soon as it is used in RADIUS/UDP or RADIUS/TCP. Administrators can assume that any shared secret of 10 characters or less has been compromised by an attacker with significant resources. Administrators can also assume that all private information (such as User-Password or Tunnel-Password) which depend on such shared secrets have also been compromised. As the analysis in [](#user-password} below shows, a strong shared secret protects the contents of User-Password, no matter how weak the end-users password is. As such it is acceptable (for a short time) for RADIUS/UDP to continue to carry User-Password and Tunnel-Password, but only when a strong shared secret is used. Using a strong shared secret is only a partial protection from known attacks. RADIUS can carry end-user credentials such as CHAP-Password and MS-CHAP which are not protected with the shared secret. Many of those credentials have been compromised, too.

Many end-user passwords have been compromised The analyis in below shows how the construction of MS-CHAP can allow attackers to determine the underyling password in milliseconds. also shows how a different attack on CHAP-Password can recover the underlying password in milliseconds. This section explains the effects of those attacks. As the security of CHAP-Password and MS-CHAP depends only on the strength of the end-users password, those methods can be safe only if the user chooses a strong password. That is, a password which is 10 characters or more, and which is derived from a cryptograpically strong pseudo-random number generator. This requirement is unlikely to be met by a large percentage of end users. As such, the use of CHAP-Password and MS-CHAP needs to be deprecated. To be perfectly clear: if a CHAP-Password, or MS-CHAP data has been sent over the Internet via RADIUS/UDP or RADIUS/TCP in the last decade, you should assume that the underlying passwords have been compromised.

The BlastRADIUS Attack This section gives more details on the BlastRADIUS attack, so that the reader can be informed as to why makes its recommendations. In the interest of simplicity for implementers, {I-D.ietf-radext-deprecating-radius}} omits all explanation of the attack. That document also gives minimal explanation for each of the protocol changes. This document contains the full details instead. The attack depends on a few related factors. If any one of these factors are not present, the attack is not possible. These factors are outlined below:

The Access-Request packets are not authenticated, and can therefore be modified without detection.
The use of MD5 within RADIUS is subject to known prefix attacks.
The improvements to MD5 collisions in make the attack feasible.
The structure and behavior of Proxy-State makes it the perfect vector for an attacker to inject the "MD5 garbage" () which is needed to force the MD5 collision.

The attack works by having An "on path" attacker who modifies an Access-Request packet, and injects one or more Proxy-State attributes with special contents. The Proxy-State attribute itself will not trigger any overflow or “out of bounds” issue with the RADIUS client or server. Instead, the contents of the attributes allows the attacker to create an MD5 known-prefix collision when the server calculates the Response Authenticator. In effect, the attacker uses the RADIUS server, and its knowledge of the shared secret, to unknowingly authenticate packets which it has not created. The behavior of the Proxy-State attribute is extremely useful to this attack. The attribute is defined in as an opaque token which is sent by a RADIUS proxy, and is echoed back by RADIUS servers. That is, the contents of the attribute are never examined or interpreted by the RADIUS server. Even better, testing shows that all known RADIUS clients will simply ignore any unexpected Proxy-State attributes which they receive. Finally, implementations generally add Proxy-State to the end of response packets, which simplifies the attack. This attribute is therefore ideally suited to an attackers purpose of injecting arbitrary data into packets, without that data affecting client or server behavior. The reasons for this behavior are outlined below in . While those reasons were transient and decades in the past, the impact of those decisions has continued to impact RADIUS until the present. While it is possible to use other attributes to achieve the same effect, the use of Proxy-State is simple, and is sufficient to trigger the issue. For example, it is theoretically possible to use the User-Name attribute for this attack, so long as it is echoed back in an Access-Accept, or even as part of the the contents of a Reply-Message in an Access-Accept. There is no much benefit in further researching that attack, as the mitigations for attacks using Proxy-State will also protect clients and servers from a similar attacks which use other attributes. The injected data and resulting MD5 collision allows the attacker to modify the packet contents almost at will, and the client will still accept the modified packet as being authentic. The attack allows nearly arbitrary attributes to be added to the response. Those attributes are simply part of the MD5 collision calculation, and do not substantially impact the cost of that calculation. We reiterate that since the RADIUS server can be convinced to authenticate packets using a prefix chosen by the attacker, there is no need for the attacker to know the shared secret. This attack succeeds no matter how secure the shared secret is, the only mitigation against the attack for RADIUS systems to use TLS, or to require that packets contain a is valid Message-Authenticator.

Detailed Description of the Attack The specific details of the attack are outlined below, as steps which are numbered the same as in the original paper ().

The attacker requests network access from the RADIUS client (NAS). This action triggers the NAS to send an Access-Request packet to the RADIUS server.
The Access-Request is observed to obtain its contents, including the Request Authenticator field. The attacker prevents this packet from reaching the server until the MD5 collision data has been calculated. The NAS will retransmit the packet one or more times after a delay, giving the attacker time to calculate the chosen prefix.
An external resource is used to calculate an MD5 collision using the Request Authenticator, along with the expected contents of an Access-Reject. As Access-Reject packets are typically empty or can be observed, the expected packet contents are known in their entirety.
Once an MD5 collision is found, the resulting "MD5 garbage" data is placed into one or more Proxy-State attributes in the previously seen Access-Request. The attacker then sends this modified Access-Request to the RADIUS server.
The RADIUS server responds with an Access-Reject, and includes the Proxy-State attributes from the modified Access-Request packets. The packet contains the malicious Proxy-State(s), along with a Response Authenticator which depends on both those malicious attributes, and the shared secret.
The attacker discards the original Access-Reject, and uses the chosen prefix data in the Proxy-State(s) to create a different (i.e. modified) response, such as an Access-Accept. Other authorization attributes such as VLAN assignment can also be added, modified, or deleted. This modified packet is sent to the NAS.
The NAS receives the modified Access-Accept, verifies that the Response Authenticator is correct, and gives the user access, along with the attackers desired authorization.

The result of this attack is a near-total compromise of the RADIUS protocol. The attacker can cause any user to be authenticated. The attacker can give almost any authorization to any user. While the above description leverages Access-Reject responses, we reiterate that the root cause of the vulnerability is the unauthenticated Access-Request packets. The attack will therefore succeed even if the server responds with Access-Accept, Access-Challenge, or Protocol-Error . The ability for the attacker to avoid Access-Challenge allows MFA to be bypassed, as the attacker simply replaces the Access-Challenge with an Access-Accept. In addition to forging an Access-Accept for a user who has no credentials, the attacker can control the traffic of known and authenticated users. Many modern Broadband Network Gateways (BNG)s, Wireless LAN Controllers (WLCs), and Broadband Remote Access Servers (BRAS) support configuring a dynamic HTTP redirect using Vendor Specific Attributes (VSA)s. These VSAs are not protected in any way, and could be injected into an Access-Accept in order to redirect a users traffic. The attacker could then set up a malicious website to launch Zero-Day/Zero-Click attacks, driving subscribers to the website using an HTTP redirect. This issue is compounded by the fact that many devices perform automatic HotSpot 1.0 style walled garden discovery. The act of simply connecting to their home WiFi connect could be enough to compromise a subscriber's equipment. defines mitigations which will protect clients and servers from this attack when using RADIUS/UDP or RADIUS/TCP. However, we reiterate here, and in the rest of this document, that the only long-term solution is to deprecate insecure transports entirely. In the long term, implementers need to remove all uses of RADIUS/UDP and RADIUS/TCP from their products. Administrators need to stop using RADIUS/UDP and RADIUS/TCP.

Mitigating the Attack While defines the mitigations that are mandated for clients and servers, we give a summary description of those mandates here for clarity. These descriptions are not normative, and readers are instructed to refer to for the full list of normative changes to RADIUS. Clients

Clients are required to include Message-Authenticator as the first attribute in all Access-Request packets. Clients are required to have a new boolean configuration flag for each server, called "require Message-Authenticator".
- When this flag is set to "false", client behavior remains unchanged from legacy RADIUS. When this flag is set to "true", clients discard all responses to Access-Request packets which do not contain a Message-Authenticator attribute.
Clients still need to validate the contents of Message-Authenticator when it is present. Clients also need to accept valid and authenticated responses, no matter where the Message-Authenticator is located in the response.

Servers

Servers are required to include Message-Authenticor as the first attribute in all responses to Access-Request packets. Servers are required to have a new boolean configuration flag for each client, called "require Message-Authenticator".
- When this flag is set to "false", their behavior remains unchanged from legacy RADIUS, except that the "limit Proxy-State" flag below is also checked. When this flag is set to "true", clients discard all Access-Request packets which do not contain a Message-Authenticator attribute.
Servers still need to validate the contents of Message-Authenticator when it is present. Servers also need to accept valid and authenticated Access-Requests, no matter where the Message-Authenticator is located in the request.

Servers are required to have a new boolean configuration flag for each client, called "limit Proxy-State".
- When this flag is set to "false", server behavior remains unchanged from legacy RADIUS. When this flag is set to "true", servers discard all Access-Request packets that contain a Proxy-State attribute.

Why the Mitigiations Work This section explains the rationale for the mitigations defined by . Adding Message-Authenticator as the first attribute in packets means that the first attribute contains data which is impossible for the attacker to predict. That is, for the purposes of MD5 known prefix attacks, the unknown suffix begins with the Message-Authenticator, and continues for the remainder of the packet. The attacker is therefore unable to leverage the attack using a known prefix, and the vulnerability is prevented. When this change is made on clients, it is necessary to prevent the attack, but it is not sufficient. When a server does not require that Access-Request packets contain Message-Authenticator, an attacker can simply remove it from the Access-Request. The attack can then proceed, as the server will receive, process, and respond to, an unauthenticated Access-Request packet. In contrast, when both clients and servers requires that packets contain a valid Message-Authenticator, the BlastRADIUS attack is impossible. Therefore the "require Message-Authenticator" flag is needed on both clients and servers in order to secure the RADIUS protocol. In order to enable compatibility with legacy systems, this protocol change must be enabled by a configuration flag.

Protecting Clients A client is fully protected from the attack if it requires that all responses to Access-Request contain a Message-Authenticator, and it validates the contents of Message-Authenticator. The client is also protected when the server sends Message-Authenticator as the first attribute in all responses to Access-Request packets. That server behavior secures one client to server connection, even if the server does not require Message-Authenticator in Access-Request packets, and even if the client does not examine or validate the contents of the Message-Authenticator. As noted above, this location of the Message-Authenticator ensures that the unknown suffix is the entire packet, and the attack is impossible. In contrast, when the Message-Authenticator is the last attribute in a packet (as was historically common in many implementations), the attacker can treat the Message-Authenticator itself as an unknown suffix, as it does with the shared secret. The attacker can then proceed with the attack, with no additional effort. The analysis is similar if the Message-Authenticator is in the middle of the packet, with attributes existing both before an after the Message-Authenticator. Attributes before the Message-Authenticator can be modified, discarded, or added, while attributes after the Message-Authenticator need to remain in the packet. We direct the reader to Section 7.2 for a more complete description of these issues. In short, the only solution which mitigates the attack is that servers need to place Message-Authenticator as the first attribute in all responses to Access-Request packets.

Protecting Servers and Proxies Ugrading all client equipment can be difficult, if only because there are many more clients than servers. Some client products may no longer be supported, or the relevant vendor may have gone out of business. Even if upgraded software images are available, the upgrade process may impact production networks, which has a cost. As a result, any mitigations must work even when clients have not been updated. A server is vulnerable to the attack when it proxies packets, even if it adds Message-Authenticator is added as the first attribute in responses to all Access-Request packets. Due to the limitations of RADIUS, a proxy has no way of knowing whether or not a "next hop" RADIUS server has been upgraded. It therefore has to protect itself from attacks when it is the only upgraded party in a RADIUS proxy chain. In this scenario, a legacy client sends Access-Request packets to an upgraded proxy, which in turn forwards the packets to a legacy next hhop server. Responses from the next hop server are sent back to the proxy, and then to the client. Upgrading the proxy will protect only the responses from the proxy to the client. The attacker can still modify packets from the client to the proxy, or it can modify all request and response packets that are sent between the proxy and next hop server. The result is that the upgraded server is still vulnerable to the attack. The "limit Proxy-State" flag allows servers to detect and prevent attacks when Access-Request packets do not contain Message-Authenticator. This configuration is only necessary when the server is a proxy. When the server enables the "limit Proxy-State" flag, legacy clients to be used without substantially compromising security. The proxy is likely to still be vulnerable to attacks on the link between itself and the next hop server. However, the proxy can use the client "require Message-Authenticator" flag defined above to protect itself. Even when the proxy cannot set that flag, the link between the proxy and the next hop server is much more likely to be protected via TLS or IPSec than the link between the client and proxy. In addition, it is generally easier to upgrade servers than clients. The focus of the mitigations, therefore, has been on securing the link between clients and servers, not between proxy servers.

Other Attributes While it is theoretically possible to perform the BlastRADIUS attack via attributes other than Proxy-State, no such exploits are known at this time. Any such exploit would require that the server receive fields under the attackers control (e.g. User-Name), and echo those fields back in a response. Such attacks are therefore only possible when the server is configured to echo back attacker-controlled data, which is not their default behavior. As a result, the configuration flags described above in allow the maximum amount of security while adding the minimum disruption to operational networks. For the remaining attack vectors, is is RECOMMENDED that servers which echo back user-supplied data in responses do so only when their "require Message-Authenticator" flag is set to "true". If such user-supplied data is echoed back in responses when the "require Message-Authenticator" flag is set "false", then the BlastRADIUS attack is theoretically still possible, even though no exploit is currently available. The server configuration flags will protect it even if clients have not been upgraded or been configured to be secure. The server configuration flags will not protect clients (NASes or proxies) from servers which have not been upgraded or been configured to be secure.

Requirements for Full Mitigation The attack will only be mitigated in either of the following two circumstances:

The client implements the "require Message-Authenticator" flag, and has set that flag to "true",
The server places Message-Authenticator as the first attribute in all responses to Access-Request packets.

Since RADIUS has no feature negotiation, the server has no way of knowing whether or not the client has been configured securely. The only remaining choice then for server behavior then, is the second item. therefore mandates that all RADIUS servers send Message-Authenticator as the first attribute in all responses to Access-Request packets. This change is the simplest possible fix to the RADIUS protocol which will protect systems from the attack.

Mitigation Design and Rationale This section provides further explanation of the issues, and the rationale for the requirements made by this specification. The "require Message-Authenticator" flag is needed in order to secure the RADIUS protocol. Once all Access-Request packets are required to contain a valid Message-Authenticator, the BlastRADIUS attack is impossible. However, it may not be possible to upgrade all RADIUS clients. Some products may no longer be supported, or some vendors have gone out of business. Even if upgrades are available, the upgrade process may impact production networks, which has a cost. There is therefore a need for RADIUS servers to protect themselves from to the BlastRADIUS attack, while at the same time being compatible with legacy RADIUS client implementations. Enabling the "limit Proxy-State" flag allows legacy (i.e. non-upgraded) clients to be used without substantially compromising on security. While it is theoretically possible to perform the BlastRADIUS attack via attributes other than Proxy-State, no such exploits are known at this time. Any such exploit would require that the server receive fields under the attackers control (e.g. User-Name), and echo them back in a response. Such attacks are only possible when the server is configured to echo back attacker-controlled data, which is not the default behavior for most servers. As a result, these two flags allow the maximum amount of security while having the minimum disruption to operational networks. For the remaining attack vectors, is is RECOMMENDED that servers which echo back user-supplied data in responses do so only when the "require Message-Authenticator" flag is set to "true". If such user-supplied data is echoed back in responses when the "require Message-Authenticator" flag is set "false", then the BlastRADIUS attack is theoretically still possible, even though no exploit is currently available. The two configuration flags on the server will protect the server even if clients have not been upgraded or been configured to be secure. The server configuration flags will not protect clients (NASes or proxies) from servers which have not been upgraded or been configured to be secure. More behavior changes to servers and clients are required.

Limitations of the Mitigations The above mitigations have some limitations. The design of the mitigations had to allow for backwards compatibility with legacy RADIUS systems, while still allowing for (but not requiring) whole-sale network upgrades. There is a trade-off to be made between perfectly secure networks which are unusable, and networks which are usable but somewhat insecure. The mitigations defined in create as much security as possible, while still not breaking existing networks. The result is that there are situations where a network is functional, but insecure. In addition, there are situations where existing client implementations are not compatible with the mitigations. This section outlines those limitations.

Vulnerable Systems A RADIUS server is vulnerable to the attack if it does not require that all received Access-Request packets contain a Message-Authenticator attribute. This vulnerability exists for many common uses of Access-Request, including packets containing PAP, CHAP, MS-CHAP, or packets containing “Service-Type = Authorize-Only”. The vulnerability is also transitive. If any one RADIUS server in a proxy chain is vulnerable, then the entire chain is vulnerable. The attack can proceed on the vulnerable systems, and the attacker can gain unauthenticated and/or unauthorized access to any systems which depend on that proxy chain. Similarly, simply having the Message-Authenticator attribute present in Access-Request packets is not sufficient. In order to be protected, a server must require that the attribute is present, and must also discard packets which are missing it. Similarly, the client must also require that the attribute is present, and discard packets which are missing oit. Similarly, clients are vulnerable when they do not require that all responses to Access-Request packets contain Message-Authenticator. Note that clients which validate Message-Authenticator are not vulnerable even if Message-Authenticator is the last attribute in a response. The HMAC construct of Message-Authenticator makes the attack impossible in that situation. The requirement on servers to place Message-Authenticator as the first attribute in all responses to Access-Request is there only to protect legacy clients which do not validate Message-Authenticator. There is no need for a client to discard responses where the Message-Authenticator is valid, but is also not the first attribute. Such behavior is incorrect, and will cause interoperability problems.

Unaffected Systems There are a number of systems which are not vulnerable to this attack. The most important ones are systems which only perform EAP authentication, such as with 802.1X / WPA Enterprise. The EAP over RADIUS protocol is defined in which states explicitly:

If any packet type contains an EAP-Message attribute it MUST also contain a Message-Authenticator.

This requirement reiterates that of , which defines EAP-Message and Message-Authenticator, but which does not get into details about EAP. This requirement is enforced by all known RADIUS servers. As a result, when roaming federations such as eduroam use RADIUS/UDP to transport EAP, the attack is not possible. Other roaming groups such as OpenRoaming require the use of TLS, and are not vulnerable. Other roaming providers generally use VPNs to connect disparate systems, and are also not vulnerable. 802.1X / WPA enterprise systems have an additional layer of protection, due to the use of the master session keys (MSK) which are derived from the EAP authentication method. These keys are normally carried in an Access-Accept, in the MS-MPPE-Recv-Key and MS-MPPE-Send-Key attributes, and are used to secure the link between the NAS and the supplicant. The contents of the attributes are obfuscated via the same method used for Tunnel-Password, and are not visible to an "on-path" attacker. While an attacker could perhaps force an Access-Accept in some situations where EAP is used, or strip the Message-Authenticator from packets, it is not currently possible for an attacker to see, modify, or create the correct MSK for the EAP session. As a result, when 802.1X / WPA enterprise is used, even a successful attack on the Access-Accept packet would likely not result in the attacker obtaining network access.

Implementations with Incorrect Mitigations This section summarizes the various implementation issues, and the recommended fixes to them. While this section does not contain normative text, it refers to normative requirements in . This summary is necessary because multiple implementations failed to follow the normative requirements of that document. Instead, those systems either implemented behavior which was forbidden by the normative text, or else failed to implement behavior which was mandated by the normative text. It is therefore necessary to reiterate to the reader that the normative text in is, in fact, normative, and that the mandates of the normative text need to be respected. The reader should understand that any non-normative text in this specification does not over-ride the clear mandates of the normative text in . The following list outlines the problems seen, in no particular order.

Some implementations discard packets which contain Message-Authenticator.
Some implementations discard responses where the Message-Authenticator is not first, in violation of . It should be reiterated that the requirement in "Server Responses" to place Message-Authenticator first is a requirement on the server, and is not a requirement on the client.

Discarding Packets with Message-Authenticator is Wrong Nearly all clients which do not validate Message-Authenticator are known to accept responses which contain it, due to the provisions of :

A RADIUS client MAY ignore Attributes with an unknown Type.

These RADIUS clients are compatible with the protocol change outlined in this document. We note also that Message-Authenticator has been defined for almost twenty-five (25) years, since , so there are few reasons for equipment to not support it. Since the publication of the original BlastRADIUS notification, it has become known that some implementations do not behave as expected. That is, instead of ignoring an unexpected Message-Authenticator attribute, they discard all responses with contain Message-Authenticator. That behavior is entirely unreasonable, and is not required by any standard. The unfortunate reality is that the only way that RADIUS servers could be compatible with such systems is for them to never send Message-Authenticator in responses. However, doing so would open up significantly more systems to the BlastRADIUS attack. As such, there is no attempt made to be compatible with implementations that fail to implement RADIUS correctly. The only way to secure those systems is to upgrade them. Failing that, the administrators of those systems will need to accept the fact that their systems are vulnerable. The solution adopted by is to declare that clients or servers which discard packets containing Message-Authenticator are not compliant with the RADIUS specifications. It is not acceptable to decrease the security of the RADIUS protocol in order to be compatible with insecure and non-compliant implementations. That specification attempts to prevent such issues from happening in the future, by mandating behavior for unknown attributes in "Unknown Attributes". There is no reason for an implementation to discard response a packet simply because it does not recognize an attribute in the packet.

Checking the location of Message-Authenticator is Wrong Nothing in any previous RADIUS specification requires attributes to be placed in any particular location in a packet. Nothing in any previous RADIUS specification requires implementations to discard packets which contain unrecognized attributes. Further, the construction of Message-Authenticator allows for a RADIUS implementation to authenticate packets (other than Access-Request), even if the Message-Authenticator is not validated. This issue is addressed in , which clarifies and extends the requirements on attribute ordering and location. also clarifies and extends the requirements on receiving unknown attributes.

Less Effective Mitigations There was substantial discussion around the design and effectiveness of the mitigations defined in . This section outlines some obvious mitigations which were considered and rejected. As protocol design is subject to a complex series of trade-offs, it is useful to explain what those alternative mitigations are, and why they were rejected. An alternative configuration flag with a similar effect to the “limit Proxy-State” flag could be one called “this client is a NAS, and will never send Proxy-State”. The intention for such a flag would be to clearly separate RADIUS proxies (which always send Proxy-State), from NASes (which will never send Proxy-State). When the flag is set for a client, the server could then discard Access-Request packets which contain Proxy-State. Alternatively, the server could also discard Proxy-State from all responses sent to that client. Such a flag, however, depends on network topology, and fails to correct the underlying lack of packet authenticity and integrity. The flag may also work for one NAS, but it is likely to be incorrect if the NAS is replaced by a proxy. Where there are multiple different pieces of NAS equipment behind a NAT gateway, the flag is also likely to be correct for some packets, and incorrect for others. Using configuration flags which control the desired outcome is preferable to using flags which depend on network topology that is outside of the control of clients and servers.

Non-Mitigations It may be tempting to come up with other "ad hoc" solutions to this vulnerability which are simpler than the ones outlined in . Such solutions are likely to either break existing RADIUS deployments, or else they will not protect systems from the attack. The mitigations described in not only prevent the attack, they do so without negatively affecting normal RADIUS operation. There is therefore no reason to use any other methods. Other attempted mitigation factors are discussed in the BlastRADIUS document (). For example, Section 7.4 explains why decreasing timeouts simply increases the cost of the attack without preventing it. Decreasing timeouts also can negatively affect normal RADIUS traffic. Section 7.7 explains why clients validating Proxy-State, or looking for unexpected Proxy-State does not protect them from the attack. The attacker can just change the form of the attack, and bypass those checks. There is therefore no reason to implement “ad hoc” solutions when a solution exists which has passed reviews by both the BlastRADIUS cryptographers, and by the relevant RADIUS experts. There is every reason to believe that cryptographic operations designed by experts and subject to rigorous peer review are better than random guesses made by programmers who lack the relevant cryptographic and RADIUS experience.

Switch to Other Protocols is Not Appropriate Switching away from RADIUS to another protocol will not protect from the attack, as there is no other protocol which can replace RADIUS. No other protocol is supported by medium to low-end networking devices for end-user authentication, authorization, and accounting. Outside of situations where Diameter is used, the choice for nearly every use-case which controls network access is limited to one protocol: RADIUS. Despite this reality, some "security" sites have recommended "securing" the network by switching to "alternative" protocols. Such recommendations are incorrect and inappropriate. Diameter is the closest protocol in functionality to RADIUS, but the Diameter use-case is applicable to large-scale telecommunications and internet service providers (ISPs). Support for Diameter is rarely present in equipment which is available to consumers or enterprises. As such, replacing RADIUS with Diameter is not an option. Other proposals for protocols to replace RADIUS are even less effective. TACACS+ has some overlap with RADIUS for administrator login to network devices, but it cannot be used outside of that limited scope. TACACS+ does not support 802.1X, end-user authentication, or end-user accounting. It is therefore impossible for an ISP or enterprise to replace RADIUS with TACACS+. Kerberos is also not a option. It is most generally used to authenticate applications, when the underlying system already has network access. Kerberos also does not support 802.1X, and does not support accounting. The situation is much the same with any proposal to replace RADIUS with IPsec. While IPsec does authenticates devices prior to bringing up the VPN, those devices must already have network access. IPsec also requires that the end-user traffic be transported over the IPsec connection, where RADIUS does not transport any end-user traffic. In conclusion, recommendations to use alternate protocols are, at best, misguided. We do not recommend following any "security" advice which is based on a fundamental misunderstanding of networking protocols.

Intrusion Detection Rules Intrusion detection systems can be updated to detect and/or warn about the BlastRADIUS attack with the following rules. In the interests of brevity and generality, the rules are written as plain text.

Access-Request does not contain a Message-Authenticator attribute. Action: Warn the administrator that the system is vulnerable, and should be upgraded.
Access-Accept, Access-Reject, or Access-Challenge does not contain a Message-Authenticator attribute. Action: Warn the administrator that the system is vulnerable, and should be upgraded.
Access-Accept, Access-Reject, or Access-Challenge contains a Message-Authenticator attribute, but it is not the first attribute in the packet. Action: Warn the administrator that the system may be vulnerable, and should be upgraded.
Access-Request packet received by a RADIUS server contains Proxy-State, when the RADIUS client is a NAS. Action: Alert that an attack is likely taking place. Note that the check should be for packets received by the RADIUS server, and not for packets sent by the NAS. The attack involves packets being modified after they are sent by the NAS, and before they are received by the RADIUS server.
Access-Accept, Access-Reject, or Access-Challenge sent by a RADIUS server contain Proxy-State, when the RADIUS client is a NAS. Action: Alert that an attack is likely taking place. Note that the check should be for packets sent by the RADIUS server, and not for packets received by the NAS. The attacker can modify packets to "hide" Proxy-State in another attribute, such as Vendor-Specific.
Any RADIUS traffic is sent over UDP or TCP transport, without IPsec or TLS. Action: Warn that the system uses deprecated transport protocols, and should be upgraded.
Any RADIUS traffic is sent external to the organization over UDP or TCP transport, without IPsec or TLS. Action: Warn that this is an insecure configuration, and can expose users private data, identities, passwords, locations, etc. to unknown attackers.

These rules should assist administrators with ongoing security and monitoring.

Summary The RADIUS protocol as defined in is vulnerable to an attack due to Access-Request packets being entirely unauthenticated. This issue has been known and ignored for decades. It was first raised as a vulnerability in 1998 , and a fix was rejected in . A practical fix was suggested in 2007 in , but it took until before a fix was mandated, That mandate only occurred because an exploit was demonstrated in 2024, in .

General Protocol Issues This section describes protocol issues which apply to all aspects of the RADIUS protocol. Later sections describes issues specific to authentication and accounting.

NAS upgrades are rare The ability to upgrade or change the RADIUS protocol is limited by the number of RADIUS clients. As seen in the previous section, many changes to the protocol have to be made so that they are compatible with existing implementations. Or, at least, not incompatible with existing implementations. The difficulty in making incompatible changes or new features, is that there are many more RADIUS clients than servers, and client upgrades are rare. In many large enterprise and government settings, even firmware upgrades can take 6-18 months. Operators and administrators SHOULD therefore plan for upgrade processes where legacy systems co-exist with updated ones for years at a time. Operators and administrators SHOULD also take steps to monitor the networks via Intrusion Detection Systems (IDS) for known attacks.

There is no protocol-layer signaling The RADIUS protocol defines essentially no ability to perform protocol-layer signaling. That is, the information that is exchanged between client and server is limited to information about user sessions, and not about client to server connections.

There is no link status signaling There is some support for an application-layer "ping" message in Status-Server , but not all systems support that packet code. It is therefore impossible, in general, for a client to know if a server is up, down, or just slow. Similarly, there is no way for a server to know if a client is down, or is just not sending packets. TCP and TLS transport help somewhat with the above situations. If a client and server share a TCP connection and that connection goes away, the disappearance is a positive signal that the other end is either down, or unreachable. However, it a TCP connection is up, that offers clients and servers little information about the status of the application at the other end of the connection. The connection could be artificially kept up by the local OS, or by an intermediate network device. The lack of packets from a client could signal that the client application is blocked, or simply has no traffic to send. The lack of response from a server could indicate that the server application is blocked, busy, or else perhaps it has proxied the packet and has not yet seen a response.

Valid requests are silently ignored The RADIUS specifications contain repeated recommendations that implementations "silently discard" well-formed and authentic requests (, , , , , ). This discard process contributes to network instability and overload. When a server does not respond to a request, the client is left with few options. According to , the client should implement timers to determine when to either retransmit a packet, or time it out. Unfortunately, few clients other than RADIUS proxies implement those recommendations, though many do implement "ad hoc" timers which have worse behavior. Whatever the timer impelemntation, the client is forced to wait for a relatively long period of time, in the (perhaps naive) expectation that the server will respond. These delays cause issues for users trying to log in, and increase the load on the client. When a client retransmits a packet, it can sometimes retransmit the exact same packet to the same server, but this is not always possible. In some cases (a.g. Acct-Delay-Time FIXREF), the client will send a new packet to the same server on the same connection, to the same server on a different connection, or to a different server entirely. These extra packets also increase the load on the network. It would be preferable to have a canonical application-layer "NAK" response, which would indicate that the server has recieved a request, but is unable to respond to it appropriately.

Protocol-Error NAK packet There is some provision for a protocol layer NAK packet via Protocol-Error (, and ), but there are few implementations of that specification. Experiments are currently ongoing.

There is no congestion control Where Diameter has overload indication in , RADIUS is entirely lacking in congestion control. The result is that a client simply sends what packets it has, and discovers (or guesses) that the server is busy when the server stops responding. The situation is made worse by the fact that even some high-end NAS equipment does not implement the retransmission timers of . Some NAS equipment also does not implement reasonable timers for sending period accounting packets with Acct-Status-Type = Interim-Update. Instead, problematic implementations simply set fixed timers, and send packets at those fixed times. This behavior appears to work in a lab with only a small number of packets / accounting sessions. This behavior is catastrophic in the real world, when a NAS has a 100,000 users online, and fixed 10-minute timer for sending accounting packets. Few systems deal well with long periods of no traffic, followed by short periods of high-volumes of traffic. Such behavior from NAS equipment is inappropriate, and contributes to network overload and instability.

Other Protocol Failures This sections describes issues with the RADIUS protocol that are not based on the lack of signaling.

There is no reject delay It has been well known for decades that brute-force dictionary attacks can be either prevented or slowed down by delaying rejects. RADIUS has no provision to implement this behavior, though there is a proposal in .

There is no rate limiting RADIUS clients are not required to perform rate limiting on any kind of requests that they send. Where congestion control could signal to a client that a server is busy, there are no requirements on a client to have self control over packets that it sends. For example, in the accounting example above, congestion control could signal to the client that the server was overloaded. But the client could still attempt to send 100,000 packets in one second. Similarly, if an end user tries to authenticate many times in a second, existing client implementations simply send one Access-Request for every authentication. There is no attempt by the client to implement any kind of Denial of Service (DoS) prevention. This limitation means that roaming consortia such as eduroam and OpenRoaming are vulnerable to DoS attacks. Any unauthenticated user could connect to an Access Point, and send 1000's of connection attempts a second. Each connection attempt could then result in packets being sent across multiple proxies, possibly from one end of the world to another. If the server implements dynamic DNS lookups (), such an attack could cause the server to perform 1000's of DNS lookups a second, or event to cause it to connect to random, attacker-controlled, servers. With minimal coordination, attackers could perform such DoS attacks at many locations, multiplying the traffic accordingly. The result could be a catastrophic meltdown of the global RADIUS proxying fabric.

There is no end to end identifier Where Diameter defines an End-To-End Identifier (), RADIUS Identifiers are strictly hop by hop. This limitation means that there is no way for proxies to determine if a retransmitted packet is the same as a one which was previously sent. Since the RADIUS specifications suggest that packets are retransmitted (, among others), these retransmissions multiply the total load on a RADIUS server or proxy fabric. Each retransmitted packet is sent as if it a new and unique request. RADIUS servers and proxies are unable to associate these retransmissions with the original request, and must therefore manage multiple copies of the same data. In the extreme case of poorly implemented proxies, each proxy could perform its own retransmission, in violation of . The result would be an exponential explosion in the number of retransmitted packets.

There are no end to end timers While proxies are forbidden from retransmitting packets, they still need to be able to implement packet timers in order to reclaim resources. For example, if a proxy sends a request and receives a response, it will maintain a duplicate detection cache () for a period of time. On the other hand, if a proxy sends a request and never receives a response, it still needs to clean up the request and associated resources. Those timers are not discussed in previous RADIUS specifications. Some proxy implementations follow the recommendations of , with the caveat that no packets are sent when a timer expires. Instead, the timers are used to drive internal implementation-specific logic which manages the state of home servers. This behavior largely works in practice, but it highlights an additional issue. The problem is that each individual node in a proxy chain (client or proxy) implements its own timers, independently of any other node. Further, there is no defined way for nodes to signal each other as to what timers they implement. The outcome of these limitations is that a client may have shorter timeouts for a request than a later proxy. If the client does not re-use the RADIUS Identifier field for a new packet, the proxy is left managing resources for no purpose. Even if a late response makes it back to the client, the client has given up, and will ignore the response. The problem is made worse with multi-hop proxy chains. In extreme cases, many proxies could each maintain state for many thousands or tens of thousands of "dead" requests. i.e. requests where the client has timed out, and cleaned up associated resources. The only solution currently available is for administrators to manually fine-tune timers, based on experimentation with values that appear to work in practice. This process can often result in stable networks, but it does not create stable networks by design.

TLS Termination and inner-tunnel data As noted above in , using secure transports such as RadSec or IPSec is not enough to provide for full end to end RADIUS security. The only solution to that problem is therefore to minimize the number of proxies used. As RADIUS servers are often also EAP servers, there are similar issues with TLS-based EAP methods. When TLS-based EAP methods such as TTLS or PEAP are used, they generally still transport passwords inside of the TLS tunnel. It is possible for an authentication server to terminate the TLS tunnel, and then proxy the inner data over RADIUS/UDP. The design of both TTLS and PEAP make this process fairly trivial. The inner data for TTLS is in Diameter AVP format, which can be trivially transformed to RADIUS attributes. The inner data for PEAP is commonly EAP-MSCHAPv2, which can also be trivially transformed to bare EAP, or to MS-CHAPv2. This forwarding of the inner tunnel data to another system removes all of the privacy and security benefits of the TLS tunnel. The inner identity will leak, negating all privacy. If attributes such as NAS-Identifier or Calling-Station-Id are copied from the incoming packet to the proxied packet, it allows observers to correlate user identity with location and devices. Where the inner authentications credentials are PAP, the User-Password attribute is secure, as discussed in . CHAP is insecure (), as is MS-CHAP (), so forwarding of inner-tunnel CHAP or MS-CHAP data usually results in the exposure of the users clear-text password.

MAC Randomization Many end-user devices implement MAC randomization, where the MAC address is then typically sent in the Calling-Station-Id attribute. Even with MAC randomization at the L2 layer, the Calling-Station-Id attribute can be sent in the clear, in RADIUS/UDP. A motivated observer can correlate data across different sessions and/or locatios to likely identify both the device, and the end user. RadSec helps increase this privacy, but as noted in the previous section, only if there all hops use RadSec.

Proxies have no limitations As all security in RADIUS is hop by hop, proxies in RADIUS have absolute control over all aspects of the protocol. Rejects can be turned into accepts, and vice versa. Authorization information can be changed. Any passwords in packets are exposed to all intermediate proxies. The solution to this problem and the above TLS termination problems is a careful design of the overall system:

minimize the number of proxies involved. This step limits the possibility of information leaked to the proxies, and any content meddling the by proxies.
use RadSec for all client to server connections. This step limits the ability of an attacker to view any PII in the RADIUS traffic
use TLS-based EAP methods for user authentication. This step further limits the PII which is seen by proxies.

Why Proxy-State is the way it is As the BlastRADIUS paper points out in Appendix A:

The presence of this attribute makes the protocol vulnerability much simpler to exploit than it would have been otherwise.

To see why Proxy-State has this particular design, we go back to the original discussion in May 1995

The RADIUS proxy may place any state information (subject to the length limitations of a RADIUS attribute) that it will need to transform a reply from its server into a reply to its client. This is typically the original authenticator, identifier, IP address and UDP port number of the proxy's RADIUS client.

There appear to be few, if any, RADIUS servers which implemented this suggestion. In part because later discussions note:

This works only if the NAS is prepared to accept replies from a proxy server for a request issued to a different server.

This stateless proxy design has a number of additional issues, most notably violating the "end-to-end" principle. It therefore negatively impacts the stability of a RADIUS proxy system. This definition for Proxy-State later changed in to

Usage of the Proxy-State Attribute is implementation dependent. A description of its function is outside the scope of this specification.

In practice, the utility of Proxy-State is limited to detecting proxy loops. Proxies can count the number of Proxy-State attributes in received packets, and if the total is more than some number, then a proxy loop is likely. We offer no advice on what to do if a proxy loop is detected, as RADIUS has no ability to signal protocol-layer errors. It is likely that a "hop count" attribute would likely have been simpler to implement. But even in 1996, it was likely difficult to change the behavior of proxies due to multiple implementations.

Authentication Review Independent of the above security and privacy issues, there are a large number of other problems with the RADIUS authentication, and with the historic practices around the handling of authentication credentials. This section discusses those problems.

Authentication Methods There are a number of problems with authentication methods that are transported in RADIUS attributes. Even independent of security issues with a particular authentication method, the choice of authentication method can in fact decrease security, as noted below in .

User-Password is still secure While the obfuscation method used for the User-Password attribute has not been shown to be insecure, it has not been proven to be secure. The obfuscation method depends on calculating MD5(secret + Request Authenticator), which has a few helpful properties for an attacker. The cost of brute-forcing short secrets is not large, discusses that cost in detail. Even for longer secrets which are humanly generated, the MD5 state for hashing the secret can be pre-calculated and stored on disk. This process is relatively inexpensive, even for billions of possible shared secrets. The Request Authenticator can then be added to each pre-calculated state via brute-force, and compared to the obfuscated User-Password data. The MD5 digest is 16 octets long, and many passwords are shorter than that. This difference means that the final octets of the digest are placed into the User-Password attribute without modification. The result is that a brute-force attack does not need to decode the User-Password and see if the decoded password "looks reasonable". Instead, the attacker simply needs to compare the final octets of the calculated digest with the final octets of the User-Password attribute. The result is a signal which indicates with high probability that the guessed secret is correct. The only protection from this particular attack is to ensure that the secret is long, and is derived from a cryptographically strong pseudo-random number generator. To put it more clearly, if the RADIUS packet is secure due to the use of a strong shared secret, then the User-Password attribute is also secure.

CHAP-Password is not secure This section describes a viable attack on CHAP, which does not appear to have been published before. The contents of CHAP-Password are calculated using MD5 to hash an identifier, a password, and a challenge. From :

The Response Value is the one-way hash calculated over a stream of octets consisting of the Identifier, followed by (concatenated with) the "secret", followed by (concatenated with) the Challenge Value.

That is, the CHAP-Password contents are MD5(ID + password + challenge). While this construction is different from the one used to sign the Authenticator fields, attacks on CHAP-Password have substantially the same cost as for cracking the RADIUS shared secret (). That is, checking all 8 character passwords from a 93 character set is possible for a hobbyist in about day. The attack is made easier by the human practice of creating insecure passwords. An attacker can create dictionaries of hashes of potential passwords. For CHAP-Password, this also means a 256 times increase in dictionary size, due to the need to calculate the prefix of MD5(ID + password). However, that calculation can be done once, and the results then stored on disk. The only ongoing cost is the need for more disk space. Once the attacker sees a CHAP-Password, the ID field is used to select one of 256 dictionaries, and then every password hash in that dictionary extended with the challenge, and checked against the contents of CHAP-Password. As these pre-calculated dictionaries generally contain hundreds of millions or low billions of passwords, that number bounds the total number of hashes which need to be checked. As noted above in , a high-end retail GPU is capable of performing more than 64 billion hashes per second. Which means that most CHAP-Password attributes can be turned into the equivalent clear-text passwords in sub-second time. The main gating factor in this attack is the time taken to stream billions of candidate hashes from disk to the GPU. This attack means that from a cryptographic perspective, using CHAP-Password is essentially the same as sending passwords in clear-text.

Attacks on MS-CHAP are decades old MS-CHAP (v1 in and v2 in ) have major design flaws, and are not suitable for use outside of a secure tunnel such as PEAP, TEAP, or TTLS. As MS-CHAPv1 is less commonly used, the discussion in this section will focus on MS-CHAPv2, but the same analysis applies to MS-CHAPv1. MS-CHAP has been broken since 2004, as seen in . While the attack there mentions LEAP, the same attack applies to MS-CHAP. This information was apparently insufficiently clear in the attack, as and no previous sp=ecification has deprecated MS-CHAP. As a result, most implementations still support it. The attack relies on a vulnerability in the protocol design in . In that section, the response to the MS-CHAP challenge is calculated via three DES operations, which are based on the 16-octet NT-Hash form of the password. However, the DES operation requires 7 octet keys, so the 16-octet NT-Hash cannot be divided evenly into the 21 octets of keys required for the DES operation. The solution in Section 8.4 was to use the first 7 octets of the NT-Hash for the first DES key, the next 7 octets for the second DES key, leaving only 2 octets for the final DES key. The final DES key is padded with zeros. This construction means that an attacker who can observe the MS-CHAP2 exchange only needs to perform 2^16 DES operations in order to determine the final 2 octets of the original NT-Hash. If the attacker has a database which correlates known passwords to NT-Hashes, then those two octets can be used to returns a small subset (1/65536) of candidate hashes. Those hashes are then checked via brute-force operations to see if they match the original MS-CHAPv2 data. Limiting the number of candidate hashes allows the attacker to use greatly increase the size of precalculated hashes, with minimal additional cost. This process lowers the complexity of cracking MS-CHAP by nearly five orders of magnitude as compared to a brute-force attack. The attack has been demonstrated using databases which contain hundreds of millions of passwords. On a consumer-grade machine, the time required for such an attack to succeed is on the order of tens of milliseconds. While this attack requires a database of known passwords, such databases are easy to find online, or to create locally from generator functions. Passwords created manually by people are notoriously predictable, and are highly likely to be found in a database of known passwords. In the extreme case of strong passwords, they will not be found in the database, and the attacker is still required to perform a brute-force dictionary search. The result is that MS-CHAP has significantly lower security than PAP. When the MS-CHAP data is not protected by TLS, it is visible to everyone who can observe the RADIUS traffic. Attackers who can see the MS-CHAP data can therefore obtain the underlying NT-Hash with essentially zero effort as compared to cracking the RADIUS shared secret. This attack means that from a cryptographic perspective, using MS-CHAP is essentially the same as sending passwords in clear-text.

EAP methods vary in security There are too many EAP methods for them to be discussed here in any detail. Instead, we can make a few simple observations:

EAP-MD5 is essentially the same as CHAP-Password, and shares the same security analysis. EAP-MD5 is not suitable for use outside of a secure tunnel such as PEAP, TEAP, or TTLS.
EAP-MSCHAPv2 (any variant) is essentially the same as MS-CHAP, and shares the same security analysis. EAP-MSCHAPv2 is not suitable for use outside of a secure tunnel such as PEAP, TEAP, or TTLS.
TLS-based EAP methods (e.g. TTLS, PEAP, etc.) benefit from the security of TLS, and are therefore secure.
Other EAP methods are not discussed here.

Summary There are no known security issues with User-Password, or with many EAP methods. In contrast, MS-CHAP and CHAP-Password are insecure, and can only be used safely within a TLS tunnel. While the "on the wire" encoding of User-Password is secure, the passwords still have to be stored somewhere, typically in a database. The next section explains how the interaction between authentication methods and password storage methods can increase, or decrease, security of the system as a whole.

Review of password visibility and storage methods An attacker can ignore the wire protocol entirely, and bypass all of the issues described earlier in this document. One such attack is to focus on the database that holds user credentials such as account names and passwords. At the time of this writing, databases such as claim to have records of over twelve billion user accounts which have been compromised. User databases are therefore highly sought-after targets. The attack discussed in this section is dependent on vulnerabilities with the credential database, and does not assume an attacker can see or modify RADIUS traffic. As a result, issues raised here apply equally well when TTLS, PEAP, or RADIUS/TLS are used. The success of the attack depends only on how the credentials are stored in the database. Since the choice of authentication method affects the way credentials are stored in the database, the security of that dependency needs to be discussed and explained. Some organizations may desire to increase the security of their network by avoiding PAP, and using CHAP or MS-CHAP, instead. These attempts are misguided. If simple password-based methods must be used, in almost all situations, the security of the network as a whole is increased by using PAP in preference to CHAP or MS-CHAP. The reason is found through a straightforward risk analysis, which we explain in more detail below.

PAP Security Analysis When PAP is used, the User-Password is obfuscated "on the wire", but the RADIUS server sees a clear-text password from the user. The server then compares that password to credentials which have been stored in a user database, and either accepts or rejects the user. In many cases, the credentials stored in the database can be salted and/or hashed in a form which is commonly referred to as being in "crypt"ed form. The RADIUS server can take the users clear-text password, performs the same "crypt" transformation, and then compares the two "crypt"ed passwords. Any compromise of the RADIUS server can result in the compromise of clear-text passwords for users. However, in most cases, the clear-text password is available only in the memory of the RADIUS server application (i.e. not "on the wire"), and then only for a short period of time. An attacker who desires to obtain passwords for all users would have to wait for all users to log in, which can take a substantial amount of time. During that time, an administrator may discover the breach, and resolve the issue. When PAP is used, the credentials in the database are stored securely "at rest", presuming that the administrator only stores "crypt"ed credentials. Any compromise of the database results in the disclosure of minimal information to the attacker. That is, an attacker cannot easily obtain the clear-text passwords from the compromised database. The result is that the user passwords are visible in clear-text only for a short time, and then only on the RADIUS server. The security of this system is not as good as seen with EAP-pwd for example, but it is not terrible. Storing passwords securely "at rest" is significantly more secure than storing clear-text passwords in a database, even when PAP authentication is used in RADIUS.

CHAP and MS-CHAP Password Storage In contrast with PAP, when CHAP or MS-CHAP is used, those methods do not expose a clear-text password to the RADIUS server, but instead a hashed transformation of it. The design goal of those methods was to make the hash output secure even if an attacker can observe it. However, as noted above, those methods have been shown to be insecure. For the purposes of this section, we will ignore the previous attacks, and instead focus on the implications of using these hashing methods. The hash transformations for CHAP and MS-CHAP depend on a random challenge. The intent was to increase security, but their construction makes strong requirements on the form in which user credentials are stored. The process for performing CHAP and MS-CHAP is inverted from the process for PAP. Using similar terminology as above for illustrative purposes, the "hash"ed passwords are carried in the CHAP method, and are sent to the server. The server must obtain the clear-text (or NT hashed) password from the database, and then perform the "hash" operation on the password from the database. The two "hash"ed passwords are then compared as was done with PAP. This inverted process decreases system security substantially. Critically, when CHAP or MS-CHAP are used, all credentials must be stored as clear-text (or clear-text equivalent) in the database, all of the time. Even if the database contents are encrypted, the decryption keys are necessarily accessible to the application which reads that database. 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. It should go without saying that having an attacker obtain all clear-text passwords is more of an issue than having the same attacker obtain passwords in a "crypt"ed form. Similarly, it is more secure for a RADIUS server to have limited clear-text passwords (i.e. some of the time), rather than having unlimited access to all of the clear-text passwords, all of the time.

On-the-wire User-Password versus CHAP-Password There is one more security myth which should be put to rest about PAP versus CHAP. There is a common belief that CHAP is more secure, because passwords are sent "in the clear" via the User-Password attribute. This belief is false. The User-Password attribute is obfuscated when it is sent in an Access-Request packet, using keyed MD5 and the shared secret, as defined in . At the time of this writing, no attack better than brute force has been found which allows an attacker to reverse this obfuscation. There have been claims that it is preferable to use CHAP-Password as it does not "send the password in clear-text". This preference is based on a misunderstanding of how CHAP-Password and User-Password attributes are calculated. The CHAP-Password attribute depends on the hash of a visible Request Authenticator (or CHAP-Challenge) and the users password. The obfuscated User-Password depends on the same Request Authenticator, and on the RADIUS shared secret. For an attacker, the difference between the two calculations is minimal. Presuming that the user password has similar complexity to the shared secret, they can both be attacked with similar amounts of effort. As a result, any security analysis which makes the claim that "User-Password insecure because it uses MD5" ignores the fact that the CHAP-Password attribute is constructed through substantially the same method. The difference in security between the two methods is due instead to the practice of people creating their own insecure password, versus a RADIUS administrator creating a strong shared secret. The CHAP-Password contents depends only on the strength of the users chosen password. The User-Password contents instead depends on both the RADIUS shared secret, and on the users password. As such, even though their constructs are roughly similar, in practice User-Password is significantly more secure than CHAP-Password. An attacker who can crack one users password can gain network access as that user, or even administrator access to network devices. In contrast, an attacker who can crack the shared secret can gain network access as any user, and perform any authorization. The result is that it is more valuable to crack shared secrets, even if the underlying attacks are similar.

PAP vs CHAP Conclusions A careful security analysis shows that for all of PAP, CHAP, and MS-CHAP, the RADIUS server must at some point have access to the clear-text version of the password. As a result, there is minimal difference in risk exposure between the different authentication methods if a RADIUS server is compromised. However, when PAP is used, the user credentials can be stored securely "at rest" in a database, while this secure storage is impossible with CHAP and MS-CHAP. There is therefore a substantial difference in risk exposure between the different authentication methods, with PAP offering substantially higher security due to its ability to secure passwords at rest via the "crypt" construct mentioned above. In contrast, CHAP or MS-CHAP are highly insecure, as any database compromise results in the immediate exposure of the clear-text passwords for all users. The security of those methods are best described as near zero, independent of any database compromise. The construction of MS-CHAP makes it easier to crack than CHAP-Password, which makes MS-CHAP the worst of all possible choices. This security difference is shown not just in the database, but also in attacks on RADIUS systems , where attackers identified a vulnerable RADIUS system, and then:

utilized SQL commands to dump the credentials [T1555], which contained both clear-text and hashed passwords for user and administrative accounts.

The attack proceeded to leverage those passwords to gain more permissions:

Having gained credentials from the RADIUS server, PRC state-sponsored cyber actors used those credentials with custom automated scripts to authenticate to a router via Secure Shell (SSH), execute router commands, and save the output.

This attack is only possible when systems store clear-text passwords. The result is that when the system as a whole is taken into account, the risk of password compromise is substantially less with PAP than with CHAP or MS-CHAP. Administrators should therefore prefer PAP over CHAP or MS-CHAP. Administrators should also store passwords "at rest" in a secure form (salted, hashed), as with the "crypt" format discussed above. That being said, other authentication methods such as EAP-TLS and EAP-pwd do not expose clear-text passwords to the RADIUS server or to any intermediate proxy. Those methods therefore lower the risk of password exposure even more than using PAP. The conclusion is that administrators should avoid password-based authentication methods where at all possible. If passwords ahve to be used, wrap them in TLS (e.g. TTLS or PEAP). Where TLS cannot be used, prefer User-Password to CHAP-Password or MS-CHAP.

The Weakest Link RADIUS security is done on a “hop by hop” basis, which means that an attacker can take advantage of the weakest link in a proxy chain in order to attack other systems which have fully implemented the above mitigations. If the packets are passed through one or more proxies, then any one vulnerable proxy will still allow the attack to take place. If proxies are used, then the weakest link in the proxy chain limits the security of the entire chain. That is, it does not matter if one hop implements RadSec, if another hop implements RADIUS/UDP without sending or requiring Message-Authenticator. Even worse, proxies have full control over packet contents. A malicious proxy can change a reject into an accept, and can add or delete any authorization attributes it desires. While proxies are generally part of a trusted network, there is every benefit in limiting the number of participants in the RADIUS conversation. Proxy chains SHOULD therefore be avoided where possible, and dynamic discovery should be used where possible. RADIUS clients and servers SHOULD also be configured with static IP addresses, and with static routes. This static configuration also protects the systems from DHCP related attacks where an attacker spoofs DHCP to cause clients or servers to route packets through the a system of the attackers choice.

Accounting Review There are many other issues with RADIUS which are not directly related to security or privacy, but still have negative affects on security, privacy, and on operation of the protocol. At of the time of writing, those issues are being collated in . Although the focus of this document is a review of RADIUS security, it is still important to discuss problems with the protocol in general. For example, there is implicitly a RADIUS state machine which correlates multiple types of packets, but that state machine is not defined anywhere. There are common practices which are secure but which are operationally expensive. RADIUS accounting is known to be inaccurate and is often inconsistent, as seen in Some of the issues noted in the above Wiki could potentially have security impact. For example, if a RADIUS server is not implemented correctly, an attacker can perform a resource exhaustion attack on it, and effectively take it offline. Proxies are subject to Denial of Service attacks even from trusted clients, because those clients originate packets at the request of untrusted and unknown users. Rate limiting for RADIUS requests is a poorly tested or documented process, and largely relies on mutual trust of administrators.

Accounting Is Imperfect The use of RADIUS/UDP for accounting means that accounting is inherently unreliable. Unreliable accounting means that different entities in the network can have different views of accounting traffic. These differences can have multiple impacts, including incorrect views of who is on the network, to disagreements about financial obligations. These issues are discussed in substantial detail in , and we do not repeat those discussions here. We do, however, summarize a few key issues. Sites which use accounting SHOULD be aware of the issues raised in , and the limitations of the suggested solutions. As a historical note, was a document produced by the RADIUS Working Group with category "Informational". The related document was produced at the same time with category "Standards Track". The documents were categorizated differently because of reviews which expressed concern that the lossy nature of UDP could negatively affect customer billing. Experience since then has shown that this issue is manageable. Using a reliable transport such as RADIUS/TLS makes it more likely that accounting packets are delivered, and that acknowledgments to those packets are received. Reducing the number of proxies means that there are fewer disparate systems which need to have their accounting data reconciled. Using non-volatile storage for accounting packets means that a system can reboot with minimal loss of accounting data. Using interim accounting updates means that transient network issues or data losses can be corrected by later updates. As RADIUS does not provide for end-to-end signaling or transport, using RADIUS/TLS provides for reliable transport only when the client originating the accounting traffic is connected directly to the server which records it. If there are instead one or more proxies involved, the proxies increase overall unreliability. Systems which perform accounting are also subject to significant operational loads. Wheres authentication and authorization may use multiple packets, those packets are sent at session start, and then never again. In contrast, accounting packets can be sent for the lifetime of a session, which may be hours or even days. There is a large cost to receiving, processing, and storing volumes of accounting data. However, even with all of the above concerns addressed, accounting is still imperfect. The obvious way to increase the accuracy of accounting data is to increase the rate at which interim updates are sent, but doing so also increases the load on the servers which process the accounting data. At some point, the trade-off of cost versus benefit becomes negative. There is no perfect solution here. Instead, there are simply a number of imperfect trade-offs.

Incorrect Accounting Data Even if all accounting packets were delivered and stored without error, there is no guarantee that the contents of those packets are in any way reasonable. The Wireless Broadband Alliance RADIUS Accounting Assurance group has been investigating these issues. While the results are not yet public, a presentation on the topic was made at IETF 118 in the RADEXT working group . The data presented indicated that the WBA saw just about every possible counter attribute in RADIUS accounting packets as containing data which was blatantly wrong or contradictory. One example is extremely short sessions which have impossibly large amounts of data being downloaded. Other accounting packets allege that large amounts of data were downloaded via octet counters, while at the same time claiming negligible packet counters, leading to absurdly large packet sizes. The only conclusion from this analysis is that some RADIUS clients act as if it is better to produce incorrect accounting data rather than to produce no data at all. This failure to follow reasonable practices is expensive for network operators. In effect, vendors have offset their costs to produce quality data onto their customers, who have to take difficult and uncertain steps in order to sanitize or verify the confusing data which vendors provide in accounting packets. It should go without saying that accounting systems need to produce correct data.

Acct-Delay-Time increases network load requires that if a client resends an Accounting-Request packet, it updates Acct-Delay-Time. This update also requires that the client then change the RADIUS Identifier field, as the packet contents have changed. This behavior means that if a server is slow to process accounting data, clients implementing this behavior will increase the load on the network. The network then becomes congested, or the server becomes overloaded. Some implementations avoid this problem by not using Acct-Delay-Time, and instead including Event-Timestamp in Accounting-Request packets. This difference means that when a client needs to resend a packet, it can be retransmitted as an exact duplicate of a prevcious packet, and congestive collapse is avoided.

Privacy Considerations The primary focus of this document is documenting historic privacy and security considerations for RADIUS. The use of insecure transport protocols for RADIUS means that personally identifying information is sent "in the clear". As noted earlier in this document, such information can include MAC addresses, user identifiers, and user locations. In addition, this document suggests ways to increase privacy by minimizing the use and exchange of PII.

Security Considerations The primary focus of this document is documenting historic privacy and security considerations for RADIUS. The BlastRADIUS vulnerability is the result of RADIUS security being a low priority for decades. Even the recommendation of that all clients add Message-Authenticator to all Access-Request packets was ignored by nearly all implementations. If that recommendation had been followed, then the BlastRADIUS vulnerability notification would have been little more than "please remember to set the require Message-Authenticator flag on all RADIUS servers." MS-CHAP authentication was not officially deprecated, even though it has been proven to be insecure for decades (). This continued use of MS-CHAP has likely resulted in the leaking of many the clear-text passwords for many users. Prior to this document, there does not appear that there has been a security analysis of CHAP authentication. The analysis presented here shows that CHAP can be cracked in milliseconds on commodity hardware, should be considered to be plain-text equivalent.

Acknowledgements Thanks to the many reviewers and commenters for raising topics to discuss, and for providing insight into the issues related to increasing the security of RADIUS. In no particular order, thanks to Margaret Cullen, Alexander Clouter, Josh Howlett, and Premanand Seralathan. Many thanks to Nadia Heninger and the rest of the BlastRADIUS team, along with Heikki Vatiainen, for extensive discussions and feedback about that issue. The author is deeply indebted to the late Bernard Aboba for decades of advice and guidance.

Changelog

00 - copy from draft-ietf-radext-deprecating-radius, and edit to contain only historical review contents.
01 - word smithing and updated analysis of CHAP-Password.
02 - tweak organization. Address review from Premanand Seralathan. Add significant text on the lack of protocol-layer signaling.