Deprecating RADIUS/UDP and RADIUS/TCP

1.1. Overview

The rest of this document begins a summary of issues with RADIUS, and shows just how trivial it is to crack RADIUS/UDP security. We then mandate the use of secure transport, and describe what that means. We give recommendations on how current systems can be migrated to using TLS. We conclude with privacy and security considerations.¶

As IPSec has been discussed previously in the context of RADIUS, we devote little time to it here, other than to say it is an acceptable solution. As the bulk of the current efforts are focussed on TLS, this document likewise focusses on TLS.¶

3.1. Information is sent in Clear Text

Other than a few attributes such as User-Password, all RADIUS traffic is sent "in the clear". The resulting traffic has a large number of privacy issues. We refer to [RFC6973], and specifically to Section 5 of that document for detailed discussion. RADIUS is vulnerable to all of the issues raised by [RFC6973].¶

There are clear privacy and security information with sending user identifiers, and user locations [RFC5580] in clear-text across the Internet. As such, the use of clear-text protocols across insecure networks is no longer acceptable.¶

3.2. MD5 has been broken

Attacks on MD5 are summarized in part in [RFC6151]. While there have not been many 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.¶

It is reasonable to expect that new research can further break MD5, but also that such research may not be publicly available.¶

3.3. Complexity of cracking RADIUS shared secrets

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 in RADIUS. The attacker does not have to calculate the hash over the entire packet, as that can be precalculated, and cached. The attacker can simply begin with that precalculated portion, 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 passwords, there are 2^48 possible password combinations.¶

The result is that using one readily available machine, it takes approximately 32 days to brute-force the entire 8 octet / 64 character password space. 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 a bit helps. For secrets ten characters long, a GPU can search a 64-character space in about six months, and a 93 character space would take approximately 24 years.¶

The 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 is not particularly difficult.¶

Whether the above numbers exactly correct, or only approximate is immaterial. These attacks will only get better over time. The cost to crack shared secrets will only go down.¶

Even worse, 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.¶

It should be assumed that an average attacker with modest resource can crack most human-derived shared secrets 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 derived from a limited character set. Theses practice are followed for ease of use of administrators, but they are also highly insecure.¶

3.4. Tunnel-Password and CoA-Request packets

There are similar security issues for the Tunnel-Password attribute, at least in CoA-Request and Disconnect-Request packets.¶

[RFC5176] Section 2.3 says:¶

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 defintions means that for CoA-Request packets, all attribute obfuscation is calculated with the Reply Authenticator being all zeroes.¶

[RFC5176] Section 3.6 allows for Tunnel-Password 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. It 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.

Which 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 easier to determine the contents of the Tunnel-Password. However, it cannot be a good thing, and it is one more reason to deprecate RADIUS/UDP.¶

5.1. Deprecating UDP and TCP as transports

RADIUS/UDP and RADIUS/TCP MUST NOT be used outside of secure networks. A secure network is one which is known 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.¶

Similarly, RADIUS/UDP and RADIUS/TCP may be used in secure management networks. However, administrators should not assume that such uses are secure.¶

Using RADIUS/UDP and RADIUS/TCP in any environment is still NOT RECOMMENDED. 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 this misconfiguration.¶

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

5.2. Mandating Secure transports

All systems sending RADIUS packets outside of secure networks MUST use either IPSec, or RADIUS/TLS, or RADIUS/DTLS.¶

5.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, but not 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]. We now state that new RADIUS specifications MUST NOT create any new cryptographic primitives to sign individual packets, or to obfuscate the contents of any attributes. All security and privacy MUST instead be provided by a secure transport layer such as TLS. Simply using IPsec is not enough, as the use (or not) of IPsec is unknown to the RADIUS application. For example, when the IPsec connection is down, the RADIUS application sees 100% packet loss for no reason which can be determined. In constrast, 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.¶

It is NOT RECOMMENDED to define new attributes which use the content obfuscation methods defined for User-Password or Tunnel-Password. We would like to forbid such constructs entirely. We recognize that RADIUS/UDP will still be in use for many years, and that new standards may require some modicrum of privacy. As a result, it is difficult to forbid the use of these constructs.¶

That being said, there has been no need since [RFC2868] in 2000 for new attribute which use these obfuscation methods. We believe therefore that there will be no demand for this kind of new attribute.¶

6.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 10 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. One solution is to use a simple script given below. While the script is not portable to all possible systems, the intent here is to document a concise and simple method for creating secrets which are secure, and humanly manageable.¶

• #!/usr/bin/env perl use MIME::Base32; use Crypt::URandom(); print join('-', unpack("(A4)*", lc encode_base32(Crypt::URandom::urandom(12)))), "\n";¶

This script reads 96 bits of random data from a secure source, encodes it in Base32, and then makes it easier for people to work with. The generated secrets are of the form "2nw2-4cfi-nicw-3g2i-5vxq". This form of secret will be accepted by any known implementation which supports at least 24 octets for shared secrets.¶

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

RADIUS implementors SHOULD provide tools for administrators which can create and manage secure shared secrets.¶

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