Deprecating Insecure Practices in RADIUS

1.1. RADIUS over the Internet

As 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 in many ways simpler for implementations and deployment than IPSec. 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 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 BlastRADIUS attack is discussed in more detail below, in Section 5.¶

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. An more resourceful attacker (e.g. a nation-state) can check all much longer shared secrets with only modest expenditures. See Section 3.4 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 8.6 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.2).¶

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.2. 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. As such, it is RECOMMENDED that all cryptographic methods used to secure RADIUS conversations provide forward secrecy. While forward secrecy will not protect individual sessions from attack, it will prevent attack on one session from being leveraged to attack other, unrelated, sessions.¶

AAA servers SHOULD minimize the impact of such attacks by using a total throughput or time based limit before replacing the session keys. The session keys can be replaced though a process of either re-keying the existing connection, or by opening a new connection and deprecating the use of the original connection. Note that if the original connection if closed before a new connection is open, it can cause spurious errors in a proxy environment.¶

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 security issues in addition to simply adding a secure transport. The rest of this document addresses those issues in detail.¶

1.3. Overview

The rest of this document begins a summary of issues with RADIUS, including showing just how trivial it is to crack RADIUS/UDP security. We then mandate the use of secure transport, 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 is discussed in detail in [BLAST], and we only give a short summary here. We refer the reader to the original paper for a more complete description of the issue.¶

For the following description, we assume that we have texts "A", "B", "S". Following the use in [RFC2865], "+" denotes concatenation. The vulnerability then relies on the following property of MD5:¶

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

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. Even if the attacker does not know text "S", if 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 observe or predict a packet (e.g. Access-Reject), which is signed with a shared secret unknown to the attacker. The attacker can then find an Access-Accept with the same MD5 hash as the Access-Reject, and replace the Access-Reject with the Access-Accept using the Response Authenticator from the Access-Reject.¶

The client receives the packet, calculates MD5(Access-Accept + secret), verifies that the Response Authenticator is correct, and proceeds to follow the attackers instructions: give the user access, along with some authorization.¶

This process is the basic concept behind the BlastRADIUS vulnerability. We note that this attack does not expose the contents of the User-Password attribute. Instead, it bypasses all server-side authentication, and simply fools the client into accepting a forged response.¶

While this issue 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, this attack alone is sufficient reason to deprecate all uses of RADIUS/UDP and RADIUS/TCP.¶

3.2. Information is sent in Clear Text

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 Section 5 of that document for detailed discussion, and to [RFC6973], Section 6 for recommendations on threat mitigations.¶

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 too late to have any practical impact on the design of the RADIUS protocol, as [RFC5580] had already been published.¶

The effect 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 users 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).¶

When RADIUS/UDP is used across the public Internet, common Wi-Fi configurations allow the location of individuals to be tracked in real-time (usually 10 minute intervals), to within 15 meters. The user devices can be identified, and also tracked. Passwords can often be compromised by a resourceful attacker, or for MS-CHAP, by a hobbyist with a laptop. 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 these devices are publicly available, and there are multiple services selling databases of this information.¶

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

The use of clear-text protocols across insecure networks is no longer acceptable. Using clear-text protocols in networks which are believed to be secure is not a significantly better solution. The correct solution is to use secure protocols, to minimize the amount of private data which is being sent, and to minimize the number of third parties who can see any traffic.¶

3.3. 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 that no one is looking for new attacks.¶

3.4. 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 consumer-grade machine, it takes approximately 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 also trivially parallelizable. Nation-states have sufficient resources to deploy hundreds to thousands of systems dedicated to these attacks. That realization means that a "time to crack" of 24 years is simply expensive, but does not take much "wall clock" time. A thousand commodity CPUs are enough to reduce the crack time from 24 years to a little over a week.¶

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

Implementors 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 "in the clear". It is also common practice for administrators to use "short" shared secrets, and to use shared secrets created by a person, or secrets derived from a limited character set. Theses practice are easy to implement and follow, but they are highly insecure and MUST NOT be used.¶

Further requirements in shared secrets are given below in Section 7.1.¶

3.5. Tunnel-Password and CoA-Request packets

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 secret). It is not 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, implementations and new specifications SHOULD NOT use obfuscated attributes in CoA-Request or Disconnect-Request packets.¶

3.6. TLS-based EAP methods, RADIUS/TLS, and IPSec

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 to RADIUS/TLS and IPSec. A proxy receiving packets over IPSec terminates the secure tunnel, but 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. The design of RADIUS security is that it is "hop by hop", and there is no way for one "hop" to know anything about, or to control, the security of another "hop".¶

The only solution to either issue would be to create a new protocol which is secure by design. Unfortunately that path is not possible, and we are left with the recommendations contained in this document.¶

3.7. Other Issues

There are many other issues with RADIUS which are unrelated to security or privact. As of the time of writing this document, those issues are being collated in [ISSUES]. The bulk of the problems noted in that Wiki are operational considerations, along with inconsistencies in the previous RADIUS specifications.¶

As the focus of this document is security, it does not address problems with the RADIUS protocol in general. For example, there are known problems with the RADIUS state machine. There are common practices which are secure but which are operationally expensive. RADIUS accounting is known to be inaccurate and often inconsistent.¶

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

We hope that the above issues are addressed in a future document. This document focuses on security issues related to transport protocols and authentication protocols, which will have to be sufficient for now.¶

5.1. Root Cause of the Attack

Independent of any cryptographic vulnerability, there are a number of factors which led to this vulnerability being exploited.¶

A major factor is the continued use of MD5 for security, instead of mandating the use of an HMAC with Message-Authenticator. This change could have been made in [RFC2869] in the year 2000. A reason for not mandating Message-Authenticator was the issue of backwards compatibility. Unfortunately, issues which are not fixed only grow larger over time. The issue of backwards compatibility is significantly worse now than it was in the year 2000. History shows that a better approach is to fix issues immediately when they come up.¶

Another factor 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. Looking at the Proxy-State attribute, it is intended for proxy to server signaling, and offers no other value for RADIUS clients. A NAS does not send Proxy-State in an Access-Request, and should not receive Proxy-State in an Access-Accept.¶

Reception of Proxy-State in an Access-Accept response is therefore a failure of signaling in the RADIUS protocol, and likely indicates a serious failure of configuration, implementation, or as seen in this case, an active attack. If all clients had discarded responses which contained unexpected Proxy-State attributes, then this attack would have been prevented.¶

With the benefit of experience, this specification errs on the side of security, while still allowing for backwards compatibility. It is not acceptable to maintain insecure practices 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.¶

The solution here is to fix the protocol, and to mandate that everyone change to secure practices. Implementations and/or organizations which do not update their systems will either be insecure, or will be incompatible with secure practices.¶

5.2. Changes to RADIUS

There are a number of changes required to both clients and servers in order for all possible attack vectors to be closed. Implementing only some of these mitigations means that an attacker could bypass the partial mitigations, and therefore still perform the attack.¶

This section outlines the mitigation methods which protect systems from this attack, along with the motivation for those methods.¶

We note that unless otherwise noted, the discussion here applies only to Access-Request packets, and to responses to Access-Request (i.e. Access-Accept, Access-Reject, Access-Challenge, and Protocol-Error packets). All behavior involving other types of request and response packets remains unchanged.¶

Similarly, the recommendations in this section only apply to UDP and TCP transport. They do not apply to TLS transport, and no changes to TLS transport are needed to protect from this attack. Clients and servers MUST NOT apply any of the new configuration flags to packets sent over TLS or DTLS transport. Those configuration flags are designed to protect RADIUS/UDP and RADIUS/TCP, and they serve no purpose when TLS transport is used.¶

However, Clients and servers SHOULD include Message-Authenticator in request and responses packets which are sent over TLS or DTLS transports. While the attribute serves no security purpose, we recommend including Message-Authenticator because of the behavior of some implementations. Some RADIUS proxies are known to include Message-Authenticator in forwarded packets only when the attribute exists in the packet received from the client. It is therefore useful for systems to always include Message-Authenticator in Access-Request packets, even when TLS is used. This behavior will only marginally increase the cost of RADIUS/TLS, and will increase the security of proxy implementations which might not implement the BlastRADIUS mitigations.¶

We recognize that switching to TLS transport may require a significant amount of effort. There is a substantial amount of work to perform in updating implementations, performing interoperability tests, changing APIs, changing user interfaces, and updating documentation. This effort cannot realistically be done in a short time frame.¶

There is therefore a need for a short-term action which can be implemented by RADIUS clients and servers which is both simple to do, and which is known to be safe. The recommendations in this section are known to protect implementations from the attack; to be simple to implement; and also to allow easy upgrade without breaking existing deployments.¶

The mitigation methods outlined here allow systems to both protect themselves from the attack, while not breaking existing networks. There is no global "flag day" required for these changes. Systems which implement these recommendations are fully compatible with legacy RADIUS implementations, and can help protect those legacy implementations. However, when these mitigations are not implemented, systems are still vulnerable to the attack.¶

Note that in some network architectures, the attack can be mitigated simply by upgrading the RADIUS server, so that it sends Message-Authenticator as the first attribute in all responses to Access-Request packets. However, the goal of this specification is to fix all architectures supported by RADIUS systems, rather than a limited subset. We therefore mandate new behavior for all RADIUS clients and servers, while acknowledging that some organizations may choose to not deploy all of the new functionality. For overall network security and good practice, we still recommend that all RADIUS clients and servers be upgraded, and have the new "require Message-Authenticator" flag set.¶

5.3. Related Issues

This section contains discussions of issues related to the BlastRADIUS vulnerability which do not involve changes to the RADIUS protocol. It explains why some alleged solutions are inadequate or inappropriate.¶

5.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 outlined here 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. This section outlines those limitations.¶

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

5.6. Intrusion Detection Systems

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

1. Access-Request does not contain a Message-Authenticator attribute.¶

   Action: Warn the administrator that the system is vulnerable, and should be upgraded.¶

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

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

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

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

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

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

6.1. Deprecating RADIUS/UDP and RADIUS/TCP

RADIUS/UDP and RADIUS/TCP MUST NOT be used outside of secure networks. A secure network is one which is believed to be safe from eavesdroppers, attackers, etc. For example, if IPsec is used between two systems, then those systems may use RADIUS/UDP or RADIUS/TCP over the IPsec connection.¶

However, administrators should not assume that such uses are always secure. An attacker who breaks into a critical system could use that access to view RADIUS traffic, and thus be able to attack it. Similarly, a network misconfiguration could result in the RADIUS traffic being sent over an insecure network.¶

Neither the RADIUS client nor the RADIUS server would be aware of any network misconfiguration (e.g. such as could happen with IPSec). Neither the RADIUS client nor the RADIUS server would be aware of any attacker snooping on RADIUS/UDP or RADIUS/TCP traffic.¶

In contrast, when TLS is used, the RADIUS endpoints are aware of all security issues, and can enforce any necessary security policies.¶

Any use of RADIUS/UDP and RADIUS/TCP is therefore NOT RECOMMENDED, even when the underlying network is believed to be secure.¶

6.2. Mandating Secure transports

All systems which send RADIUS packets outside of secure networks MUST use either IPSec, RADIUS/TLS, or RADIUS/DTLS. For operational and security reasons, it is RECOMMENDED to use RADIUS/TLS or RADIUS/DTLS instead of IPSec.¶

Unlike (D)TLS, use of IPSec means that applications are generally unaware of transport-layer security. Any problem with IPSec such as configuration issues, negotiation or re-keying problems are typically presented to the RADIUS servers as 100% packet loss. These issues may occur at any time, independent of any changes to a RADIUS application using that transport. Further, network misconfigurations which remove all security are completely transparent to the RADIUS application: packets can be sent over an insecure link, and the RADIUS server is unaware of the failure of the security layer.¶

In contrast, (D)TLS gives the RADIUS application completely knowledge and control over transport-layer security. The failure cases around (D)TLS are therefore often clearer, easier to diagnose and faster to resolve than failures in IPSec. For example, a failed TLS connection may return a "connection refused" error to the application, or any one of many TLS errors indicating which exact part of the TLS conversion failed during negotiation.¶

6.3. Crypto-Agility

The crypto-agility requirements of [RFC6421] are addressed in [RFC6614] Appendix C, and in Section 10.1 of [RFC7360]. For clarity, we repeat the text of [RFC7360] here, with some minor modifications to update references, without changing the content.¶

Section 4.2 of [RFC6421] makes a number of recommendations about security properties of new RADIUS proposals. All of those recommendations are satisfied by using TLS or DTLS as the transport layer.¶

Section 4.3 of [RFC6421] makes a number of recommendations about backwards compatibility with RADIUS. [RFC7360] Section 3 addresses these concerns in detail.¶

Section 4.4 of [RFC6421] recommends that change control be ceded to the IETF, and that interoperability is possible. Both requirements are satisfied.¶

Section 4.5 of [RFC6421] requires that the new security methods apply to all packet types. This requirement is satisfied by allowing TLS and DTLS to be used for all RADIUS traffic. In addition, [RFC7360] Section 3, addresses concerns about documenting the transition from legacy RADIUS to crypto-agile RADIUS.¶

Section 4.6 of [RFC6421] requires automated key management. This requirement is satisfied by using TLS or DTLS key management.¶

We can now finalize the work began in [RFC6421]. This document updates [RFC2865] to state that any new RADIUS specification MUST NOT introduce new "ad hoc" cryptographic primitives to authenticate packets as was done with the Request / Response Authenticator, or to obfuscate attributes as was done with User-Password and Tunnel-Password. We allow legacy RADIUS-specific cryptographic methods existing as of the publication of this document to be used for historical compatibility. However, all new cryptographic work which is specific to the RADIUS protocol is forbidden.¶

We recognize that RADIUS/UDP will still be in use for many years, and that new standards may require some modicum of privacy. As the BlastRADIUS attack shows, RADIUS/UDP security is inadequate. The solution is not to fix RADIUS/UDP. The solution is to deprecate it entirely.¶

All new security and privacy requirements in RADIUS MUST be provided by a secure transport layer such as TLS or IPSec. As noted above, simply using IPsec is not always enough, as the use (or not) of IPsec is unknown to the RADIUS application.¶

The restriction forbidding new cryptographic work in RADIUS does not apply to the data being transported in RADIUS attributes. For example, a new authentication method could use new cryptographic methods, and would be permitted to be transported in RADIUS. This authentication method could be a new EAP method, or any other data which is opaque to the RADIUS transport. In those cases, RADIUS serves as a transport layer for the authentication method. The authentication data is treated as opaque data for the purposes of Access-Request, Access-Challenge, etc. packets. There would be no need for the RADIUS protocol to define any new cryptographic methods in order to transport this data.¶

Similarly, new specifications MAY define new attributes which use the obfuscation methods for User-Password as defined in [RFC2865] Section 5.2, or for Tunnel-Password as defined in [RFC2868] Section 3.5. However, due to the issues noted above in Section 3.5, the Tunnel-Password obfuscation method MUST NOT be used for packets other than Access-Request, Access-Challenge, and Access-Accept. If the attribute needs to be send in another type of packet, then the protocol design is likely wrong, and needs to be revisited. It is again a difficult choice to forbid certain uses of the Tunnel-Password obfuscation method, but we believe that doing so is preferable to allowing sensitive data to be obfuscated with less security than the original design intent.¶

7.1. Shared Secrets

[RFC2865] Section 3 says:¶

• It is preferred that the secret be at least 16 octets. This is to ensure a sufficiently large range for the secret to provide protection against exhaustive search attacks. The secret MUST NOT be empty (length 0) since this would allow packets to be trivially forged.¶

This recommendation is no longer adequate, so we strengthen it here.¶

RADIUS implementations MUST support shared secrets of at least 32 octets, and SHOULD support shared secrets of 64 octets. Implementations MUST warn administrators that the shared secret is insecure if it is 12 octets or less in length.¶

Administrators SHOULD use shared secrets of at least 24 octets, generated using a source of secure random numbers. Any other practice is likely to lead to compromise of the shared secret, user information, and possibly of the entire network.¶

Creating secure shared secrets is not difficult. The following figure outlines four separate ways to create shared secrets.¶

    openssl rand -base64 16

    dd if=/dev/urandom bs=1 count=16 | base64

    dd if=/dev/urandom bs=1 count=16 | base32

    dd if=/dev/urandom bs=1 count=16 |
        (hexdump -ve '/1 "%02x"' && echo)

Only one of the above commands should be run, as they are functionally equivalent. Each command reads 128 bits (16 octets) of random data from a secure source, and encodes it as printable / readable ASCII. This form of PSK will be accepted by any implementation which supports at least 32 octets for PSKs. Larger PSKs can be generated by changing the "16" number in the command to a larger value. The above derivation assumes that the random source returns one bit of entropy for every bit of randomness which is returned. Sources failing that assumption are NOT RECOMMENDED.¶

Given the simplicity of creating strong secrets, there is no excuse for using weak shared secrets with RADIUS. The management overhead of dealing with complex secrets is less than the management overhead of dealing with compromised networks.¶

Over all, the security analysis of shared secrets is similar to that for TLS-PSK. It is therefore RECOMMENDED that implementors manage shared secrets with same the practices which are recommended for TLS-PSK, as defined in [RFC8446] Section E.7 and [RFC9257] Section 4.¶

On a practical node, RADIUS implementers SHOULD provide tools for administrators to help them create and manage secure shared secrets. The cost to do so is minimal for an implementer. Providing such tools can further enable and motivate administrators to use secure practices.¶

7.2. Message-Authenticator

The Message-Authenticator attribute was defined in [RFC3579] Section 3.2. The "Note 1" paragraph at the bottom of [RFC3579] Section 3.2 required that Message-Authenticator be added to Access-Request packets when the EAP-Message as present, and suggested that it should be present in a few other situations. The BlastRADIUS attack has shown that these recommendations are inadequate.¶

While the text in Section 5 goes into detail about the mitigations, we summarize them here.¶

RADIUS clients MUST include the Message-Authenticator in all Access-Request packets when UDP or TCP transport is used. RADIUS servers MUST also include the Message-Authenticator as the first attribute in responses to Access-Accept. Both clients and servers MUST have a boolean flag which we call "require Message-Authenticator". When set to "true", implementations MUST silently discard packets which do not contain Message-Authenticator. Servers MUST have a boolean flag which we call "limit Proxy-State". This flag is only examined when the "require Message-Authenticator" flag is set to "false". When the "limit Proxy-State" is set to "true", servers MUST discard packets which contain Proxy-State but do not also contain Message-Authenticator.¶

In contrast, when TLS-based transports are used, the Message-Authenticator attribute serves no purpose, and could be omitted, even when the Access-Request packet contains an EAP-Message attribute. However, implementations SHOULD include it, even if it servers no immediate purpose. As noted earlier, including Message-Authenticator can increase the security of legacy proxies which do not implement the BlastRADIUS mitigations.¶

Servers receiving Access-Request packets over TLS-based transports SHOULD NOT silently discard a packet if it is missing a Message-Authenticator attribute. However, if the Message-Authenticator attribute is present, it still MUST be validated as discussed in [RFC7360].¶

7.3. Recommending TLS-PSK

Given the insecurity of RADIUS/UDP, the absolute minimum acceptable security is to use strong shared secrets. However, administrator overhead for TLS-PSK is not substantially higher than for shared secrets, and TLS-PSK offers significantly increased security and privacy.¶

It is therefore RECOMMENDED that implementations support TLS-PSK. In some cases TLS-PSK is preferable to certificates. It may be difficult for RADIUS clients to upgrade all of their interfaces to support the use of certificates, and TLS-PSK more closely mirrors the historical use of shared secrets, with similar operational considerations.¶

Additional implementation and operational considerations for TLS-PSK are given in [I-D.ietf-radext-tls-psk].¶

8.1. Minimizing Personal Identifiable Information

One approach to increasing RADIUS privacy is to minimize the amount of PII which is sent in packets. Implementers of RADIUS products and administrators of RADIUS systems SHOULD ensure that only the minimum necessary PII is sent in RADIUS.¶

Where possible, identities should be anonymized (e.g. [RFC7542] Section 2.4). The use of anonymized identities means that the the Chargeable-User-Identifier [RFC4372] should also be used. Further discussion on this topic is below.¶

Device information SHOULD be either omitted, or randomized. e.g. MAC address randomization could be used on end-user devices. The details behind this recommendation are the subject of ongoing research and development. As such, we do not offer more specific recommendations here.¶

Information about the visited network SHOULD be replaced or anonymized before packets are proxied outside of the local organization. The attribute Operator-NAS-Identifier [RFC8559] can be used to anonymize information about NASes in the local network.¶

Location information ([RFC5580] SHOULD either be omitted, or else it SHOULD be limited to the broadest possible information, such as country code. For example, [I-D.tomas-openroaming] says:¶

• All OpenRoaming ANPs MUST support signalling of location information¶

This location information is required to include at the minimum the country code. We suggest the country code SHOULD also be the maximum amount of location information which is sent over third-party networks.¶

CUI = HASH(visited network data + user identifier + key)

CUI = ENCRYPT(key, visited network data + user identifier)

8.2. User-Password Visibility

The design of RADIUS means that when proxies receive Access-Request packets, the clear-text contents of the User-Password attribute are visible to the proxy. Despite various claims to the contrary, the User-Password attribute is never sent "in the clear" over the network. Instead, the password is protected by TLS (RADIUS/TLS) or via the obfuscation methods defined in [RFC2865], Section 5.2. However, the nature of RADIUS means that each proxy must first undo the password obfuscation of [RFC2865], and then re-do it when sending the outbound packet. As such, the proxy has the clear-text password visible to it, and stored in its application memory.¶

It is therefore possible for every intermediate proxy to snoop and record all User-Name and User-Password values which they see. This exposure is most problematic when the proxies are administered by an organization other than the one which operates the home server. Even when all of the proxies are operated by the same organization, the temporary existence of clear-text passwords on multiple machines is a security risk.¶

It is therefore NOT RECOMMENDED for organizations to send the User-Password attribute in packets which are sent outside of the organization. If RADIUS proxying is necessary, another authentication method which provides for end-to-end security of user information SHOULD be used, such as EAP-TLS, TTLS, or PEAP.¶

Client and server implementations SHOULD use secure programming techniques to wipe passwords and other sensitive data from memory when they are no longer needed.¶

Organizations MAY still use User-Password attributes within their own systems, for reasons which we will explain below in Section 8.7.¶

8.3. Delaying Access-Rejects

Anyone can cause a NAS to send Access-Request packets at will, simply by attempting to requesting network access, or login permissions from the NAS. If this login process is not rate-limited, it can be abused by an attacker to perform dictionary attacks.¶

In order to prvent these brute-force attacks, servers which originate Access-Reject packets MUST enforce a minimum delay between reception of the Access-Request, and transmission of a corresponding Access-Reject. This delay SHOULD be configurable. Experience shows that values between one (1) second and ten (10) seconds work well in practice.¶

Systems which simply proxy Access-Reject packets MUST NOT add any artificial delays to those packets. Doing so would result in delays accumulating across a chain of proxies.¶

Servers SHOULD also add a small random jitter to the delay for a particular packet, in order to better protect themselves from timing attacks.¶

8.4. Use Constant Time Comparisons

Both clients and servers SHOULD use constant-time operations to compare received versus calculated values which depend on secret information. If comparison operations are stopped as soon as a difference is seen, an attacker could using timing attacks to determine the correct underlying values, even without seeing them. A constant-time operation instead compares the entire value, accumulating the result along the way. Only when the entire value has been examined does the comparison return a "match" or "no-match" result.¶

Constant-time operations SHOULD be used for the Request Authenticator and Response-Authenticator fields. Constant time comparisons SHOULD be used for attributes which directly contain secret values (e.g. User-Password), or are derived from secret values (e.g. CHAP-Password, and Message-Authenticator).¶

8.5. Minimize the use of Proxies

The design of RADIUS means that even when RADIUS/TLS is used, every intermediate proxy has access to all of the information in each packet. The only way to secure the network from such observers is to minimize the use of proxies.¶

Where it is still necessary to use intermediate proxies such as with eduroam [EDUROAM] and OpenRoaming [OPENROAMING], it is RECOMMENDED to use EAP methods instead of bare PAP, CHAP, or MS-CHAP. If passwords are used, they can be can be protected from being seen by proxies via TLS-based EAP methods such as EAP-TTLS or PEAP. Passwords can also be omitted entirely from being sent over the network, as with EAP-TLS [RFC9190] or EAP-pwd [RFC5931].¶

In many cases, however, the existence of proxies is to either due contractual obligations, or to a need to solve "N by M" connection problems. A centralized proxy system can often simplify overall network management and maintenance.¶

8.6. Do Not Use MS-CHAP

MS-CHAP (v1 in [RFC2433] and v2 in [RFC2759]) have major design flaws, and should not be used 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.¶

Implementers and administrators MUST therefore treat MS-CHAP and MS-CHAPv2 as being equivalent in security to sending passwords in the clear, without any encryption or obfuscation. That is, the User-Password attribute with the [RFC2865], Section 5.2 obfuscation is substantially more secure than MS-CHAP. MS-CHAP offers little benefit over PAP, and has many drawbacks as discussed here, and in the next section.¶

As MS-CHAP can be trivially broken by an observer, this document therefore mandates that MS-CHAP or MS-CHAPv2 authentication data carried in RADIUS MUST NOT be sent in situations where the that data is visible to an observer. MS-CHAP or MS-CHAPv2 authentication data MUST NOT be sent over RADIUS/UDP or RADIUS/TCP.¶

As MS-CHAP offers no practical benefits over PAP and has many downsides, MS-CHAP authentication SHOULD NOT be used even when the transport protocol is secure, as with IPSec or RADIUS over TLS.¶

Existing RADIUS client implementations SHOULD deprecate the use of MS-CHAPv1 and MS-CHAPv2. Clients SHOULD forbid new configurations from enabling MS-CHAP authentication. New RADIUS clients MUST NOT implement the attributes used for MS-CHAPv1 and MS-CHAPv2 authentication (MS-CHAP-Challenge and MS-CHAP-Response).¶

8.7. Password Visibility and Storage

An attacker may choose to ignore the wire protocol entirely, and bypass all of the issues described earlier in this document. An attacker could instead focus on the database which 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 reaised 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.¶

8.8. Use EAP Where Possible

If more complex authentication methods are needed, there are a number of EAP methods which can be used. These methods variously allow for the use of certificates (EAP-TLS), or passwords (EAP-TTLS [RFC5281], PEAP [I-D.josefsson-pppext-eap-tls-eap])) and EAP-pwd [RFC5931].¶

We also note that the TLS-based EAP methods which transport passwords also hide the passwords from intermediate RADIUS proxies, which also increases security.¶

Finally, password-based EAP methods still send PAP / CHAP / MS-CHAP inside of the TLS tunnel. As such, the security of a home server which checks those passwords is subject to the analysis above about PAP versus CHAP, along with the issues of storing passwords in a database.¶

8.9. Eliminating Proxies

The best way to avoid malicious proxies is to eliminate proxies entirely. The use of dynamic peer discovery ([RFC7585]) means that the number of intermediate proxies is minimized.¶

However, the server on the visited network still acts as a proxy between the NAS and the home network. As a result, all of the above analysis still applies when [RFC7585] peer discovery is used. There is an intermediate system which may have access to passwords or PII. The only solution is using end-to-end security for AAA, which would involve a completely new protocol.¶

8.10. 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 variety of imperfect trade-offs.¶

8.11. Unknown Attributes

Unknown attributes are attributes which are well-formed, but which are not recognized by the implementation. Processing of unknown attributes is discussed in [RFC2866], Section 5:¶

• A RADIUS server MAY ignore Attributes with an unknown Type.¶

  A RADIUS client MAY ignore Attributes with an unknown Type.¶

We note this recommendation is to "ignore" these attributes, and not to discard the encapsulating packet. Instead of ignoring unknown attributes, some implementations are known instead to discard packets which contain an unknown attribute. This behavior is incorrect, and leads to interoperability issues and network problems.¶

Implementations MUST NOT discard packets if they receive attributes with an unknown Type. We update [RFC2865] to require that implementations MUST ignore Attributes with an unknown Type. Those attributes MUST be treated in the same manner as an "Invalid Attribute" which is defined in [RFC6929], Section 2.8.¶

This behavior is secure, so long as implementations follow some additional guidance for Access-Accept packets. This guidance follows logically from existing text in [RFC2865], Section 4.4 for similar situations with Access-Challenge:¶

• If the NAS does not support challenge/response, it MUST treat an Access-Challenge as though it had received an Access-Reject instead.¶

And also for Service-Type in [RFC2865], Section 5.6:¶

• A NAS is not required to implement all of these service types, and MUST treat unknown or unsupported Service-Types as though an Access-Reject had been received instead.¶

A client is not required to implement all possible authorizations which can be sent in an Access-Accept. We therefore extend the above scenarios to packets which contain unknown Types. A client SHOULD treat Access-Accepts with no known or supported authorizations as though an Access-Reject had been received instead.¶

This requirement for unknown Types is already met by most, if not all, RADIUS implementations. That is, experience has shown that discarding packets for x3arbitrary reasons causes problems. Existing implementations have largely chosen to follow reasonable practices, and the recommendation here simply documents that wide-spread practice.¶

11.1. Historical Considerations

The BlastRADIUS vulnerability is the result of RADIUS security being a low priority for decades. Even the recommendation of [RFC5080], Section 2.2.2 that all clients add Message-Authenticator to all Access-Request packets was ignored by nearly all implementers. 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."¶

For MS-CHAP, it has not previously been deprecated for similar reasons, 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 users clear-text passwords.¶

11.2. Practical Implications

This document either deprecates or forbids methods and behaviors which have been common practice for decades. While insecure practices have been viewed as tolerable, they are no longer acceptable.¶