A Review of RADIUS Security and Privacy

1.1. 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 [MD5-1996], 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 [DATTACK] 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 [RFC2869], Section 5.14.¶

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 [RFC2869], Section 7.1:¶

• 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 [RFC3579], Section 4, and again in 2007 in [RFC5080], Section 2.2.2. 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 [RFC5080], 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 [BLAST] would largely have been prevented.¶

The state of MD5 security was again discussed in [RFC6151], 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 [RFC6421], Section 3. The outcome of that review was the text in the remainder of [RFC6421], 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 [RFC6614], and RADIUS/DTLS in [RFC7360]. Another outcome was a 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.¶

RADIUS/TLS has now been standardized in [I-D.ietf-radext-radiusdtls-bis]. That document standardizes TLS transport for RADIUS, and gives implementors and operators a way to securing 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 [RFC6151], which is over a decade old as of the time of publication of this document. The recommendation to use Message-Authenticator in [RFC5080] 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 [I-D.ietf-radext-deprecating-radius].¶

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. [I-D.ietf-radext-deprecating-radius] mandates the use of secure practices in RADIUS, including the use of (D)TLS via [I-D.ietf-radext-radiusdtls-bis].¶

1.2. 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 [RFC3579], Section 4.2:¶

• 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 [RFC6614] and RADIUS/DTLS [RFC7360] were then defined in order to meet the crypto-agility requirements of [RFC6421]. RADIUS/TLS has been in wide-spread use for about a decade, including eduroam [EDUROAM] [RFC7593], and more recently OpenRoaming [OPENROAMING] and [I-D.tomas-openroaming]. 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 is discussed in more detail below, in Section 4.¶

1.3. 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 test 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 Section 3.6 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 ([RFC2433] and MS-CHAPv2 [RFC2759]) are significantly worse in security than PAP, as they can be completely broken with minimal resources, which Section 5.2 describes in more detail.¶

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 therefore offers a stronger protection, it does not change the cost of attacking the shared secret. Moving to a stronger packet signatures (e.g. [RFC6218]) would still not fully address the issues with RADIUS, as the protocol still has privacy issues unrelated to the the security of packet authenticators.¶

That is, most attributes in RADIUS are sent in clear-text, and only a few attributes such as User-Password and Tunnel-Password have their contents hidden. Even the hidden attributes rely on "ad hoc" obfuscation methods using MD5, which have not been successfully attacked, but are 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 (Section 3.4).¶

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 ([SPOOFING]). 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.¶

1.4. 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. 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. If the cryptographic methods provide forward secrecy ([RFC7525], Section 6.3), 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 [RFC7585].¶

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.¶

1.5. 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.¶

3.1. The BlastRADIUS Vulnerability

The BlastRADIUS vulnerability was first described in [BLAST]. This section gives a short summary of why RADIUS is vulnerable to this attack. Section 4, below, gives a longer explanation as to how the attack works, and why the mitigations defined in [I-D.ietf-radext-deprecating-radius] protect from the attack. The reader is referred to [BLAST] for a comprehensive description of the attack.¶

The discussion below assumes that there exist plain texts "A", "B", "S". Following the use in [RFC2865], 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 [RFC2865], Section 3 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 simply 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 all too often "the entire Internet". As such, this attack alone is sufficient reason to deprecate all uses of RADIUS/UDP and RADIUS/TCP.¶

3.2. 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 [RFC2869] 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 [RFC5080], Section 2.2.2, and again was ignored by all but one vendor. If vendors had implemented this recommendation in 2007, then the BlastRADIUS attack would have been impossible.¶

3.3. 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 proxy to "next hopt" server signaling, and offers no other value for RADIUS clients. A NAS which originates packets does not send Proxy-State in an Access-Request, and should therefore 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. Such a packet could either trigger a warning message, or instead be rejected entirely.¶

That is, reception of Proxy-State in an Access-Accept response is a failure of signaling in the RADIUS protocol, and likely 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.¶

3.4. 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. Even when 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 [RFC6973], and specifically to [RFC6973], Section 5 for detailed discussion, and to [RFC6973], Section 6 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 [RFC5580] 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 [RFC6280], 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 [RFC5580] 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 [RFC5580], a user's location may be determined to within 15 or so meters outdoors, and with "meter-level accuracy indoors" [WIFILOC]. 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, [BRIGGS] noted 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.¶

[BRIGGS] 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 apply to Diameter [RFC6733], 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.¶

3.5. MD5 has been broken

Attacks on MD5 are summarized in part in [RFC6151]. The BlastRADIUS work substantially improved the speed of finding MD5 collisions, and those improvements are publicly available at [HASHCLASH].¶

While there have not been many other new attacks in the decade since [RFC6151] 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.¶

3.6. Cracking RADIUS shared secrets is not hard

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 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.¶

[I-D.ietf-radext-deprecating-radius] - shared-secrets gives further requirements on the creation of shared secrets.¶

3.7. 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 ihas been compromised by an attacker with significant resources. Administrators can also assume that all private information (such as User-Password) which depends on such shared secrets have also been compromised.¶

To be perfectly clear: if a User-Password, or 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 password has been compromised.¶

3.8. 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.¶

[RFC5176] Section 2.3 describes how to calculate the Request Authenticator field for these packets:¶

Request Authenticator

   In Request packets, the Authenticator value is a 16-octet MD5
   [RFC1321] checksum, called the Request Authenticator.  The
   Request Authenticator is calculated the same way as for an
   Accounting-Request, specified in [RFC2866].

Where [RFC2866] Section 3 says:¶

   The NAS and RADIUS accounting server share a secret.  The Request
   Authenticator field in Accounting-Request packets contains a one-
   way MD5 hash calculated over a stream of octets consisting of the
   Code + Identifier + Length + 16 zero octets + request attributes +
   shared secret (where + indicates concatenation).  The 16 octet MD5
   hash value is stored in the Authenticator field of the
   Accounting-Request packet.

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, [RFC5176] Section 3.6 allows it to appear in CoA-Request packets:¶

   ...
   Change-of-Authorization Messages

   Request   ACK      NAK   #   Attribute
   ...
   0+        0        0    69   Tunnel-Password (Note 5)
   ...
   (Note 5) When included within a CoA-Request, these attributes
   represent an authorization change request.  Where tunnel attributes
   are included within a successful CoA-Request, all existing tunnel
   attributes are removed and replaced by the new attribute(s).

However, [RFC2868] Section 3.5 says that Tunnel-Password is encrypted with the Request Authenticator:¶

   Call the shared secret S, the pseudo-random 128-bit Request
   Authenticator (from the corresponding Access-Request packet) R,

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 [RFC2868] Section 3.5;¶

 Salt
   The Salt field is two octets in length and is used to ensure the
   uniqueness of the encryption key used to encrypt each instance of
   the Tunnel-Password attribute occurring in a given Access-Accept
   packet.  The most significant bit (leftmost) of the Salt field
   MUST be set (1).  The contents of each Salt field in a given
   Access-Accept packet MUST be unique.

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, and it is one more reason to deprecate RADIUS/UDP and RADIUS/TCP.¶

Due to the above issues, the use obfuscated attributes in CoA-Request or Disconnect-Request packets should be avoided.¶

3.9. Secure Transports Can Still Leak Information

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 to "leak".¶

When TLS-based EAP methods such as TTLS or PEAP are used, they 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.¶

Similar issues apply for proxies even when RADIUS/TLS and IPsec are used. A proxy which receives packets over IPsec will terminate the IPSec tunnel, but it then might 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. As RADIUS security is "hop by hop", there is no way for one "hop" to know anything about, or to control, the security of another "hop".¶

The only solution to either of the above issues would be to create a new protocol which is secure by design.¶

4.1. Detailed Description of the Attack

The specific details of the attack are outlined via the following steps, which are numbered the same as in the original paper ([BLAST]).¶

1. 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.¶

2. 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.¶

3. 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.¶

4. 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.¶

5. 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.¶

6. 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.¶

7. 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 unauthenticate Access-Request packets. The attack will therefore succeed even if the server responds with Access-Accept, Access-Challenge, or Protocol-Error [RFC7930]. 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.¶

[I-D.ietf-radext-deprecating-radius] 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.¶

4.2. Mitigating the Attack

While [I-D.ietf-radext-deprecating-radius] 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 [I-D.ietf-radext-deprecating-radius] 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, of course. However, clients 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, of course. However, server 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.¶

4.3. Why the Mitigiations Work

This section explains the rationale for the mitigations defined by [I-D.ietf-radext-deprecating-radius].¶

Adding Message-Authenticator as the first attribute in packets means that 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.¶

4.4. 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 [I-D.ietf-radext-deprecating-radius] 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.¶

4.5. 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 [I-D.ietf-radext-deprecating-radius]. 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 [I-D.ietf-radext-deprecating-radius] is really is normative, and that the mandates 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 [I-D.ietf-radext-deprecating-radius].¶

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 [RFC2865], Section 5. It should be reiterated that the requirement in [I-D.ietf-radext-deprecating-radius] "Server Responses" to place Message-Authenticator first is a requirement on the server, and is not a requirement on the client.¶

• TBD¶

4.6. Less Effective Mitigations

There was substantial discussion around the design and effectiveness of the mitigations defined in [I-D.ietf-radext-deprecating-radius]. 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.¶

4.7. 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 [I-D.ietf-radext-deprecating-radius]. Such solutions are likely to either break existing RADIUS deployments, or else they will not protect systems from the attack. The mitigations described in [I-D.ietf-radext-deprecating-radius] 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 ([BLAST]). For example, [BLAST] Section 7.4 explains why decreasing timeouts simply increases the cost of the attack without preventing it. Decreasing timeouts also can negatively affect normal traffic.¶

[BLAST] 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 lacking relevant cryptographic and RADIUS experience.¶

4.8. Summary

The RADIUS protocol as defined in [RFC2865] 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 [DATTACK], and a fix was rejected in [RFC2869]. A practicl fix was suggested in 2007 in [RFC5080], Section 2.2.2, but it took until [I-D.ietf-radext-deprecating-radius] before a fix was mandated, That mandate only occurred because an exploit was demonstrated in 2024, in [BLAST].¶

5.1. Obfuscation of User-Password

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, Section 3.6 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 derived from a cryptographically strong pseudo-random number generator.¶

5.2. Attacks on MS-CHAP

MS-CHAP (v1 in [RFC2433] and v2 in [RFC2759]) have major design flaws, and are not suitable for use outside of a secure tunnel such as PEAP 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 [ASLEAP]. While the attack there mentions LEAP, the same attack applies to MS-CHAP. This information was apparently insufficiently clear in the [ASLEAP] attack, as most implementations still support MS-CHAP, and no previous standard has deprecated it.¶

The attack relies on a vulnerability in the protocol design in [RFC2759], Section 8.4. 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 [RFC2759] Section 8.4 is 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 as an index into that database, which returns a subset of candidate hashes. Those hashes are then checked via brute-force operations to see if they match the original MS-CHAPv2 data.¶

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 tens to 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 does require 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 traffic can therefore obtain the underlying NT-Hash with essentially zero effort, as compared to cracking the RADIUS shared secret. In contrast, the User-Password attribute is obfuscated with data derived from the Request Authenticator and the shared secret, and that method has not yet been successfully attacked.¶

5.3. Password Visibility and Storage

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 [PWNED] 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.¶

5.4. Note on Proxy-State

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 [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 [RFC3539] "end-to-end" principle. It therefore negatively impacts the stability of a RADIUS proxy system.¶

This definition for Proxy-State later changed in [RFC2865], Section 5.33 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.¶

6.1. 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 [RFC2975], 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 [RFC2975], and the limitations of the suggested solutions.¶

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.¶

11.1. Normative References

[I-D.ietf-radext-deprecating-radius]

DeKok, A., "Deprecating Insecure Practices in RADIUS", Work in Progress, Internet-Draft, draft-ietf-radext-deprecating-radius-07, 27 August 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-radext-deprecating-radius-07>.

[I-D.ietf-radext-radiusdtls-bis]

Rieckers, J. and S. Winter, "(Datagram) Transport Layer Security ((D)TLS) Encryption for RADIUS", Work in Progress, Internet-Draft, draft-ietf-radext-radiusdtls-bis-10, 20 October 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-radext-radiusdtls-bis-10>.

[RFC2865]

Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, <https://www.rfc-editor.org/rfc/rfc2865>.

[RFC6421]

Nelson, D., Ed., "Crypto-Agility Requirements for Remote Authentication Dial-In User Service (RADIUS)", RFC 6421, DOI 10.17487/RFC6421, November 2011, <https://www.rfc-editor.org/rfc/rfc6421>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

11.2. Informative References

[ASLEAP]

Wright, J., "asleap - recovers weak LEAP and PPTP passwords", n.d., <https://github.com/joswr1ght/asleap>.

[BLAST]

Goldberg, S , et al, "RADIUS/UDP Considered Harmful", n.d., <https://www.blastradius.fail/pdf/radius.pdf>.

[BRIGGS]

Briggs, K., "Comments on the FCC’s Public Notice DA 24-308 on SS7 and Diameter Vulnerabilities", n.d., <https://www.fcc.gov/ecfs/document/10427582404839/1>.

[DATTACK]

DeKok, A., "CHAP and Shared Secret", n.d., <https://www.ietf.org/ietf-ftp/ietf-mail-archive/radius/1998-11.mail>.

[EDUROAM]

eduroam, "eduroam", n.d., <https://eduroam.org>.

[EXPLOIT]

Agency, A. C. D., "People’s Republic of China State-Sponsored Cyber Actors Exploit Network Providers and Devices", n.d., <https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-158a>.

[HASHCLASH]

Stevens, M., "Project HashClash - MD5 & SHA-1 cryptanalytic toolbox", n.d., <https://github.com/cr-marcstevens/hashclash>.

[I-D.tomas-openroaming]

Tomas, B., Grayson, M., Canpolat, N., Cockrell, B. A., and S. Gundavelli, "WBA OpenRoaming Wireless Federation", Work in Progress, Internet-Draft, draft-tomas-openroaming-06, 16 September 2025, <https://datatracker.ietf.org/doc/html/draft-tomas-openroaming-06>.

[ISSUES]

RADEXT, "Issues and Fixes 2", n.d., <https://github.com/radext-wg/issues-and-fixes-2/wiki>.

[MAY-1995]

O'Dell, M., "Proxy-State radius extension to support stateless proxies", n.d., <http://ftp.cerias.purdue.edu/pub/doc/network/radius/archive/ietf-radius.9506>.

[MD5-1996]

group, I. R. W., "MD5 Key recovery attack", n.d., <https://www.ietf.org/ietf-ftp/ietf-mail-archive/radius/1998-02>.

[OPENROAMING]

Alliance, W. B., "OpenRoaming: One global Wi-Fi network", n.d., <https://wballiance.com/openroaming/>.

[PWNED]

Hunt, T., "Have I been Pwned", n.d., <https://haveibeenpwned.com/>.

[RFC1321]

Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, <https://www.rfc-editor.org/rfc/rfc1321>.

[RFC2433]

Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions", RFC 2433, DOI 10.17487/RFC2433, October 1998, <https://www.rfc-editor.org/rfc/rfc2433>.

[RFC2759]

Zorn, G., "Microsoft PPP CHAP Extensions, Version 2", RFC 2759, DOI 10.17487/RFC2759, January 2000, <https://www.rfc-editor.org/rfc/rfc2759>.

[RFC2866]

Rigney, C., "RADIUS Accounting", RFC 2866, DOI 10.17487/RFC2866, June 2000, <https://www.rfc-editor.org/rfc/rfc2866>.

[RFC2868]

Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, DOI 10.17487/RFC2868, June 2000, <https://www.rfc-editor.org/rfc/rfc2868>.

[RFC2869]

Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, DOI 10.17487/RFC2869, June 2000, <https://www.rfc-editor.org/rfc/rfc2869>.

[RFC2975]

Aboba, B., Arkko, J., and D. Harrington, "Introduction to Accounting Management", RFC 2975, DOI 10.17487/RFC2975, October 2000, <https://www.rfc-editor.org/rfc/rfc2975>.

[RFC3539]

Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, DOI 10.17487/RFC3539, June 2003, <https://www.rfc-editor.org/rfc/rfc3539>.

[RFC3579]

Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, DOI 10.17487/RFC3579, September 2003, <https://www.rfc-editor.org/rfc/rfc3579>.

[RFC3748]

Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, <https://www.rfc-editor.org/rfc/rfc3748>.

[RFC4120]

Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, DOI 10.17487/RFC4120, July 2005, <https://www.rfc-editor.org/rfc/rfc4120>.

[RFC5080]

Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, DOI 10.17487/RFC5080, December 2007, <https://www.rfc-editor.org/rfc/rfc5080>.

[RFC5176]

Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, DOI 10.17487/RFC5176, January 2008, <https://www.rfc-editor.org/rfc/rfc5176>.

[RFC5580]

Tschofenig, H., Ed., Adrangi, F., Jones, M., Lior, A., and B. Aboba, "Carrying Location Objects in RADIUS and Diameter", RFC 5580, DOI 10.17487/RFC5580, August 2009, <https://www.rfc-editor.org/rfc/rfc5580>.

[RFC5931]

Harkins, D. and G. Zorn, "Extensible Authentication Protocol (EAP) Authentication Using Only a Password", RFC 5931, DOI 10.17487/RFC5931, August 2010, <https://www.rfc-editor.org/rfc/rfc5931>.

[RFC6151]

Turner, S. and L. Chen, "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms", RFC 6151, DOI 10.17487/RFC6151, March 2011, <https://www.rfc-editor.org/rfc/rfc6151>.

[RFC6218]

Zorn, G., Zhang, T., Walker, J., and J. Salowey, "Cisco Vendor-Specific RADIUS Attributes for the Delivery of Keying Material", RFC 6218, DOI 10.17487/RFC6218, April 2011, <https://www.rfc-editor.org/rfc/rfc6218>.

[RFC6280]

Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, DOI 10.17487/RFC6280, July 2011, <https://www.rfc-editor.org/rfc/rfc6280>.

[RFC6613]

DeKok, A., "RADIUS over TCP", RFC 6613, DOI 10.17487/RFC6613, May 2012, <https://www.rfc-editor.org/rfc/rfc6613>.

[RFC6614]

Winter, S., McCauley, M., Venaas, S., and K. Wierenga, "Transport Layer Security (TLS) Encryption for RADIUS", RFC 6614, DOI 10.17487/RFC6614, May 2012, <https://www.rfc-editor.org/rfc/rfc6614>.

[RFC6733]

Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, <https://www.rfc-editor.org/rfc/rfc6733>.

[RFC6973]

Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/rfc/rfc6973>.

[RFC7360]

DeKok, A., "Datagram Transport Layer Security (DTLS) as a Transport Layer for RADIUS", RFC 7360, DOI 10.17487/RFC7360, September 2014, <https://www.rfc-editor.org/rfc/rfc7360>.

[RFC7525]

Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/rfc/rfc7525>.

[RFC7585]

Winter, S. and M. McCauley, "Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI)", RFC 7585, DOI 10.17487/RFC7585, October 2015, <https://www.rfc-editor.org/rfc/rfc7585>.

[RFC7593]

Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam Architecture for Network Roaming", RFC 7593, DOI 10.17487/RFC7593, September 2015, <https://www.rfc-editor.org/rfc/rfc7593>.

[RFC7930]

Hartman, S., "Larger Packets for RADIUS over TCP", RFC 7930, DOI 10.17487/RFC7930, August 2016, <https://www.rfc-editor.org/rfc/rfc7930>.

[RFC8907]

Dahm, T., Ota, A., Medway Gash, D.C., Carrel, D., and L. Grant, "The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol", RFC 8907, DOI 10.17487/RFC8907, September 2020, <https://www.rfc-editor.org/rfc/rfc8907>.

[RFC9190]

Preuß Mattsson, J. and M. Sethi, "EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3", RFC 9190, DOI 10.17487/RFC9190, February 2022, <https://www.rfc-editor.org/rfc/rfc9190>.

[SPOOFING]

Cudbard-Bell, A., "Wi-Fi Spoofing for Fun and Profit", n.d., <https://networkradius.com/articles/2021/08/04/wifi-spoofing.html>.

[WBA]

Alliance, W. B., "RADIUS Accounting Assurance", n.d., <https://wballiance.com/radius-accounting-assurance/>.

[WBA-ACCT]

Alliance, W. B., "RADIUS Accounting Assurance at IETF 118", n.d., <https://youtu.be/wwmYSItcQt0?t=3953>.

[WIFILOC]

Alliance, W.-F., "Accurate indoor location with Wi-Fi connectivity", n.d., <https://www.wi-fi.org/discover-wi-fi/wi-fi-location>.