Internet DRAFT - draft-ietf-radext-deprecating-radius
draft-ietf-radext-deprecating-radius
RADEXT Working Group A. DeKok
Internet-Draft FreeRADIUS
Intended status: Standards Track 7 November 2023
Expires: 10 May 2024
Deprecating Insecure Practices in RADIUS
draft-ietf-radext-deprecating-radius-00
Abstract
RADIUS crypto-agility was first mandated as future work by RFC 6421.
The outcome of that work was the publication of RADIUS over TLS (RFC
6614) and RADIUS over DTLS (RFC 7360) as experimental documents.
Those transport protocols have been in wide-spread use for many years
in a wide range of networks. They have proven their utility as
replacements for the previous UDP (RFC 2865) and TCP (RFC 6613)
transports. With that knowledge, the continued use of insecure
transports for RADIUS has serious and negative implications for
privacy and security.
This document formally deprecates using the User Datagram Protocol
(UDP) and of the Transmission Control Protocol (TCP) as transport
protocols for RADIUS. These transports are permitted inside of
secure networks, but their use in those networks is still
discouraged. For all other environments, the use of secure
transports such as IPsec or TLS is mandated. We also discuss
additional security issues with RADIUS deployments, and give
recommendations for practices which increase security and privacy.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-ietf-radext-deprecating-
radius/.
Discussion of this document takes place on the RADEXT Working Group
mailing list (mailto:radext@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/radext/.
Source for this draft and an issue tracker can be found at
https://github.com/freeradius/deprecating-radius.git.
DeKok Expires 10 May 2024 [Page 1]
Internet-Draft Deprecating RADIUS November 2023
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 10 May 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Simply using IPSec or TLS is not enough . . . . . . . . . 6
1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Overview of issues with RADIUS . . . . . . . . . . . . . . . 9
3.1. Information is sent in Clear Text . . . . . . . . . . . . 9
3.2. MD5 has been broken . . . . . . . . . . . . . . . . . . . 9
3.3. Complexity of cracking RADIUS shared secrets . . . . . . 10
3.4. Tunnel-Password and CoA-Request packets . . . . . . . . . 11
4. All short Shared Secrets have been compromised . . . . . . . 13
5. Deprecating Insecure transports . . . . . . . . . . . . . . . 13
5.1. Deprecating UDP and TCP as transports . . . . . . . . . . 13
5.2. Mandating Secure transports . . . . . . . . . . . . . . . 14
5.3. Crypto-Agility . . . . . . . . . . . . . . . . . . . . . 15
6. Migration Path and Recommendations . . . . . . . . . . . . . 16
DeKok Expires 10 May 2024 [Page 2]
Internet-Draft Deprecating RADIUS November 2023
6.1. Shared Secrets . . . . . . . . . . . . . . . . . . . . . 17
6.2. Message-Authenticator . . . . . . . . . . . . . . . . . . 18
6.3. Recommending TLS-PSK . . . . . . . . . . . . . . . . . . 18
7. Increasing the Security of RADIUS . . . . . . . . . . . . . . 19
7.1. Minimizing Personal Identifiable Information . . . . . . 19
7.1.1. Chargeable-User-Identity . . . . . . . . . . . . . . 20
7.2. User-Password and Proxying . . . . . . . . . . . . . . . 24
7.3. Password Visibility and Storage . . . . . . . . . . . . . 25
7.4. MS-CHAP . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.5. EAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.6. Eliminating Proxies . . . . . . . . . . . . . . . . . . . 28
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 28
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 29
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
13.1. Normative References . . . . . . . . . . . . . . . . . . 29
13.2. Informative References . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction
The RADIUS protocol [RFC2865] was first standardized in 1997, though
its roots go back much earlier to 1993. The protocol uses MD5
[RFC1321] to sign some packets types, and to obfuscate certain
attributes such as User-Password. As originally designed, Access-
Request packets were entirely unauthenticated, and could be trivially
spoofed as discussed in [RFC3579] Section 4.3.2. In order to prevent
such spoofing, that specification defined the Message-Authenticator
attribute ([RFC3579] Section 3.2) which allowed for packets to carry
a signature based on HMAC-MD5.
The state of MD5 security was discussed in [RFC6151], which led to
the state of RADIUS security being reviewed in [RFC6421] Section 3.
The outcome of that review was the remainder of [RFC6421], which
created crypto-agility requirements for RADIUS.
RADIUS was historically secured with IPSec, as described in [RFC3579]
Section 4.2:
DeKok Expires 10 May 2024 [Page 3]
Internet-Draft Deprecating RADIUS November 2023
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], and more recently OpenRoaming [OPENROAMING] and
[I-D.tomas-openroaming]. RADIUS/DTLS has seen less use across the
public Internet, but it nonetheless has multiple implementations.
As of the writing of this specification, RADIUS/UDP is still widely
used, even though it depends on MD5 and "ad hoc" constructions for
security. While MD5 has been broken, it is a testament to the design
of RADIUS that there have been (as yet) no attacks on RADIUS
Authenticator signatures which are stronger than brute-force.
However, the problems with MD5 means that if a someone can view
unencrypted RADIUS traffic, even a hobbyist attacker can crack all
possible RADIUS shared secrets of eight characters or less. Such
attacks can also result in compromise of all passwords carried in the
User-Password attribute.
Even if a stronger packet signature method was used as in [RFC6218],
it would not fully address the issues with RADIUS. Most information
in RADIUS is sent in clear-text, and only a few attributes are hidden
via obfuscation methods which rely on more "ad hoc" MD5
constructions. The privacy implications of this openness are severe.
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
DeKok Expires 10 May 2024 [Page 4]
Internet-Draft Deprecating RADIUS November 2023
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, the location of
individuals can potentially be tracked in real-time (usually 10
minute intervals), to within 15 meters. Their devices can be
identified, and tracked. Any passwords they send via the User-
Password attribute can be be compromised. 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 [RFC2759]) is significantly worse for security,
as it can be trivially cracked with minimal resources even if the
shared secret is not known (Section 7.4).
The implications for security and individual safety are large, and
negative.
These issues are only partly mitigated when the authentication
methods carried within RADIUS define their own processes 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. The use
of MAC address randomization can limit device information
identification to a particular manufacturer, instead of to a unique
device.
However, these authentication 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.
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
deprecates insecure uses of RADIUS, and mandates the use of secure
TLS-based transport layers. We also discuss related security issues
with RADIUS, and give many recommendations for practices which
increase security and privacy.
DeKok Expires 10 May 2024 [Page 5]
Internet-Draft Deprecating RADIUS November 2023
1.1. 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 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. However,
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 (recommended) or time based limit before replacing
the session keys. The session keys can be replaced though a process
of either rekeying 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 ([RFC7585].
There are many additional issues on top of simply adding a secure
transport. The rest of this document addresses those issues in
detail.
DeKok Expires 10 May 2024 [Page 6]
Internet-Draft Deprecating RADIUS November 2023
1.2. 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
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 privacy and security considerations.
As IPSec has been discussed previously in the context of RADIUS, we
do not discuss it in detail to it here, other than 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. However, all of the issues raised here about the RADIUS
protocol also apply to IPSec transport.
While this document tries to be comprehensive, it is necessarily
imperfect. There may be issues which should have been included, but
which were missed due to oversight or accident. Any reader should be
aware that there are good practices which are perhaps not documented
here, and bad behaviors which are likewise not forbidden.
There is also a common tendency to suggest that a particular practice
is "allowed" by a specification, simply because the specification
does not forbid that practice. This belief is wrong. That is, a
behavior which is not mentioned in the specification cannot honestly
be said to be "permitted" or "allowed" by that specification.
Instead, the correct description for such behaviors is that they are
not forbidden. In many cases, documents such as [RFC5080] are
written to both correct errors in earlier documents, and to address
harmful behaviors have been seen in practice.
By their very nature, documents include a small number of permitted,
required, and/or forbidden behaviors. There are a much larger set of
behaviors which are undefined. That is, behaviors which are neither
permitted nor forbidden. Those behaviors may be good or bad,
independent of what the specification says.
DeKok Expires 10 May 2024 [Page 7]
Internet-Draft Deprecating RADIUS November 2023
Outside of published specifications, there is also a large set of
common practices and behaviors which have grown organically over
time, but which have not been written into a specification. These
practices have been found to be valuable by implementers and
administrators. Deviations from these practices generally result in
instabilities and incompatibilities between systems. As a result,
implementers should exercise caution when creating new behaviors
which have not previously been seen in the industry. Such behaviors
are likely to be wrong.
It is RECOMMENDED that implementations follow widely accepted
practices which have been proven to work, even if those practices are
not written down in a public specification. Failure to follow common
industry practices usually results in interoperability failures.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
* RADIUS
The Remote Authentication Dial-In User Service protocol, as
defined in [RFC2865], [RFC2865], and [RFC5176] among others.
* RADIUS/UDP
RADIUS over the User Datagram Protocol as define above.
* RADIUS/TCP
RADIUS over the Transport Control Protocol [RFC6613]
* RADIUS/TLS
RADIUS over the Transport Layer Security protocol [RFC6614]
* RADIUS/DTLS
RADIUS over the Datagram Transport Layer Security protocol
[RFC7360]
* TLS
DeKok Expires 10 May 2024 [Page 8]
Internet-Draft Deprecating RADIUS November 2023
the Transport Layer Security protocol. Generally when we refer to
TLS in this document, we are referring to RADIUS/TLS and/or
RADIUS/DTLS.
* NAS
Network Access Server, which is a RADIUS client.
3. Overview of issues with RADIUS
There are a large number of issues with RADIUS. The most serious is
that RADIUS sends most information "in the clear", with obvious
privacy implications.
Further, MD5 has been broken for over a decade, as summarized in
[RFC6151]. For traffic sent across the Internet, no protocol should
depend on MD5 for security. Even if MD5 was not broken, computers
have gotten substantially faster in the past thirty years. This
speed increase makes it possible for the average hobbyist to perform
brute-force attacks to crack even seemingly complex shared secrets.
We address each of these issues in detail below.
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 data exposure has a large
number of privacy issues. We refer to [RFC6973], and specifically to
Section 5 of that document for detailed discussion. RADIUS/UDP and
RADIUS/TCP are 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.
DeKok Expires 10 May 2024 [Page 9]
Internet-Draft Deprecating RADIUS November 2023
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 to sign 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, one GPU can
search a 64-character space in about six months, and a 93 character
space 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 is not
particularly difficult. 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.
DeKok Expires 10 May 2024 [Page 10]
Internet-Draft Deprecating RADIUS November 2023
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. 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.
It should be assumed 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 derived from a limited character set.
Theses practice are easy to implement and follow, but they are highly
insecure and SHOULD NOT be used.
Further requirements in shared secrets are given below in
Section 6.1.
3.4. Tunnel-Password and CoA-Request packets
There are a number of security problems with the Tunnel-Password
attribute, at least 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:
DeKok Expires 10 May 2024 [Page 11]
Internet-Draft Deprecating RADIUS November 2023
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 there to be 16 octets of random
data. This difference has negative impacts on security.
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;
DeKok Expires 10 May 2024 [Page 12]
Internet-Draft Deprecating RADIUS November 2023
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. However,
such limited entropy cannot be a good thing, and it is one more
reason to deprecate RADIUS/UDP.
Due to the above issues, implementations and new specifications
SHOULD NOT permit obfuscated attributes to be used in CoA-Request or
Disconnect-Request packets.
4. All short Shared Secrets have been compromised
Unless RADIUS packets are sent over a secure network (IPsec, TLS,
etc.), administrators SHOULD assume that any shared secret of 8
characters or less has been immediately compromised. Administrators
SHOULD assume that any shared secret of 10 characters or less has
been compromised by an attacker with significant resources.
Administrators SHOULD also assume that any private information (such
as User-Password) which depends on such shared secrets has also been
compromised.
In conclusion, if a User-Password, or CHAP-Password, or MS-CHAP
password has been sent over the Internet via RADIUS/UDP or RADIUS/TCP
in the last decade, you should assume that underlying password has
been compromised.
5. Deprecating Insecure transports
The solution to an insecure protocol which uses thirty year-old
cryptography is to deprecate the use insecure cryptography, and to
mandate modern cryptographic transport.
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.
DeKok Expires 10 May 2024 [Page 13]
Internet-Draft Deprecating RADIUS November 2023
Similarly, RADIUS/UDP and RADIUS/TCP could be used in secure
management networks. However, administrators should not assume that
such uses are always secure. An attacker who breaks into a key
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.
Using RADIUS/UDP and RADIUS/TCP in any environment is therefore NOT
RECOMMENDED.
5.2. Mandating Secure transports
All systems sending RADIUS packets outside of secure networks MUST
use either IPSec, RADIUS/TLS, or RADIUS/DTLS. It is RECOMMENDED, for
operational and security reasons that RADIUS/TLS or RADIUS/DTLS are
preferred over 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.
DeKok Expires 10 May 2024 [Page 14]
Internet-Draft Deprecating RADIUS November 2023
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]. This document
updates [RFC2865] et al. to state that any new RADIUS specification
MUST NOT introduce new "ad hoc" cryptographic primitives to sign
packets as was done with the Request / Response Authenticator, or to
obfuscate attributes as was done with User-Password and Tunnel-
Password. That is, RADIUS-specific cryptographic methods existing as
of the publication of this document can continue to be used for
historical compatibility. However, all new cryptographic work in 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 a result,
it is a difficult choice to forbid the use of these constructs. If
an attack is discovered which breaks RADIUS/UDP (e.g. by allowing
attackers to forge Request Authenticators or Response Authenticators,
or by allowing attackers to de-obfuscate User-Password), the solution
would be to simply deprecate the use of RADIUS/UDP entirely. It
would not be acceptable to design new cryptographic primitives in an
attempt to "secure" RADIUS/UDP.
DeKok Expires 10 May 2024 [Page 15]
Internet-Draft Deprecating RADIUS November 2023
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 protocol could use new cryptographic
methods, and would be permitted to be transported in RADIUS. This
protocol could be a new EAP method, or it could use updates to TLS.
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 RADIUS 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.4,
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.
6. Migration Path and Recommendations
We recognize that it is difficult to upgrade legacy devices with new
cryptographic protocols and user interfaces. The problem is made
worse because the volume of RADIUS devices which are in use. The
exact number is unknown, and can only be approximated. Our best
guess is that at the time of this writing, there could be in the
order of hundreds of thousands, if not millions of RADIUS/UDP devices
in daily use.
We therefore need to define a migration path to using secure
transports. We give a a number of migration steps which could be
done independently. We recommend increased entropy for shared
secrets. We also mandate the use of Message-Authenticator in all
Access-Request packets for RADIUS/UDP and RADIUS/TCP. Finally, where
[RFC6614] Section 2.3 makes support for TLS-PSK optional, we suggest
that RADIUS/TLS and RADIUS/DTLS implementations SHOULD support TLS-
PSK.
DeKok Expires 10 May 2024 [Page 16]
Internet-Draft Deprecating RADIUS November 2023
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 all 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.
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.
DeKok Expires 10 May 2024 [Page 17]
Internet-Draft Deprecating RADIUS November 2023
On a practical node, RADIUS implementers SHOULD provide tools for
administrators which can create and manage secure shared secrets.
The cost to do so is minimal for implementors. Providing such a tool
can further enable and motivate administrators to use secure
practices.
6.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. Experience has shown
that these recommendations are inadequate.
Some RADIUS clients never use the Message-Authenticator attribute,
even for the situations where the [RFC3579] text suggests that it
should be used. When the Message-Authenticator attribute is missing
from Access-Request packets, it is often possible to trivially forge
or replay those packets.
For example, an Access-Request packet containing CHAP-Password but
which is missing Message-Authenticator can be trivially forged. If
an attacker sees one packet such packet, it is possible to replace
the CHAP-Password and CHAP-Challenge (or Request Authenticator) with
values chosen by the attacker. The attacker can then perform brute-
force attacks on the RADIUS server in order to test passwords.
This document therefore requires that RADIUS clients MUST include the
Message-Authenticator in all Access-Request packets when UDP or TCP
transport is used.
In contrast, when TLS-based transports are used, the Message-
Authenticator attribute serves no purpose, and can be omitted, even
when the Access-Request packet contains an EAP-Message attribute.
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] and [RFC3579].
6.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.
DeKok Expires 10 May 2024 [Page 18]
Internet-Draft Deprecating RADIUS November 2023
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.
Implementation and operational considerations for TLS-PSK are given
in [I-D.ietf-radext-tls-psk], and we do not repeat them here.
7. Increasing the Security of RADIUS
While we still permit the use of UDP and TCP transports in secure
environments, there are opportunities for increasing the security of
RADIUS when those transport protocols are used. The amount of
personal identifiable information sent in packets should be
minimized. Information about the size, structure, and nature of the
visited network should be omitted or anonymized. The choice of
authentication method also has security and privacy impacts.
The recommendations here for increasing the security of RADIUS
transports also applies when TLS is used. TLS transports protect the
RADIUS packets from observation by from third-parties. However, TLS
does not hide the content of RADIUS packets from intermediate
proxies, such as ones uses in a roaming environment. As such, the
best approach to minimizing the information sent to proxies is to
minimize the number of proxies which see the RADIUS traffic.
Implementers and administrators need to be aware of all of these
issues, and then make the best choice for their local network which
balances their requirements on privacy, security, and cost. Any
security approach based on a simple "checklist" of "good / bad"
practices is likely to result in decreased security, as compared to
an end-to-end approach which is based on understanding the issues
involved.
7.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.
DeKok Expires 10 May 2024 [Page 19]
Internet-Draft Deprecating RADIUS November 2023
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.
7.1.1. Chargeable-User-Identity
Where the Chargeable-User-Identity (CUI) [RFC4372] is used, it SHOULD
be unique per session. This practice will help to maximize user
privacy, as it will be more difficult to track users across multiple
sessions. Due to additional constraints which we will discuss below,
we cannot require that the CUI change for every session.
What we can do is to require that the home server MUST provide a
unique CUI for each combination of user and visited network. That
is, if the same user visits multiple networks, the home server MUST
provide different CUIs to each visited network for that user. The
CUI MAY be the same across multiple sessions for that user on one
particular network. The CUI MAY be the same for multiple devices
used by that user on one particular network.
We note that the MAC address is likely the same across multiple user
sessions on one network. Therefore changing the CUI offers little
additional benefit, as the user can still be tracked by the
unchanging MAC address. Never the less, we believe that having a
unique CUI per session can be useful, because there is ongoing work
on increasing user privacy by allowing more MAC address
randomization. If we were to recommend that the CUI remain constant
across multiple sessions, that would in turn negate much of the
effort being put into MAC address randomization.
DeKok Expires 10 May 2024 [Page 20]
Internet-Draft Deprecating RADIUS November 2023
One reason to have a constant CUI value for a user (or user devices)
on one network is that network access providers may need to enforce
limits on simultaneous logins. Network providers may also need to
correlate user behavior across multiple sessions in order to track
and prevent abuse. Both of these requirements are impossible if the
CUI changes for every user session.
The result is that there is a trade-off between user privacy and the
needs of the local network. While perfect user privacy is an
admirable goal, perfect user privacy may also allow anonymous users
to abuse the visited network. The network would then likely simply
refuse to provide network access. Users may therefore have to accept
some limitations on privacy, in order to obtain network access.
We spend some time here in order to give recommendations for creating
and managing of CUI. We believe that these recommendations will help
implementers satisfy the preceding requirements, while not imposing
undue burden on the implementations.
In general, the simplest way to track CUIs long term is to associate
the CUI to user identity in some kind of cache or database. This
association could be created at the tail end of the authentication
process, and before any accounting packets were received. This
association should generally be discarded after a period of time if
no accounting packets are received. If accounting packets are
received, the CUI to user association should then be tracked along
with the normal accounting data.
The above method for tracking CUI works no matter how the CUI is
generated. If the CUI can be unique per session, or it could be tied
to a particular user identity across a long period of time. The same
CUI could also be associated with multiple devices.
Where the CUI is not unique for each session, the only minor issue is
the cost of the above method is that the association is stored on a
per-session basis when there is no need for that to be done. Storing
the CUI per session means that is it possible to arbitrarily change
how the CUI is calculated, with no impact on anything else in the
system. Designs such as this which decouple unrelated architectural
elements are generally worth the minor extra cost.
For creating the CUI, that process should be done in a way which is
scalable and efficient. For a unique CUI per user, implementers
SHOULD create a value which is unique both to the user, and to the
visited network. There is no reason to use the same CUI for multiple
visited networks, as that would enable the tracking of a user across
multiple networks.
DeKok Expires 10 May 2024 [Page 21]
Internet-Draft Deprecating RADIUS November 2023
Before suggesting a method for creating the CUI, we note that
[RFC4372] Section 2.1 defines the CUI as being of data type 'string'
([RFC8044] Section 3.5). [RFC4372] Section 2.1 further suggests that
the value of the CUI is interpreted as an opaque token, similar to
the Class attribute ([RFC2865] Section 5.25). Some organizations
create CUI values which use the Network Access Identifier (NAI)
format as defined in [RFC7542]. This format can allow the home
network to be identified to the visited network, where the User-Name
does not contain a realm. Such formats SHOULD NOT be used unless all
parties involved have agreed to this behavior.
The CUI SHOULD be created via a construct similar to what is given
below, where "+" indicates concatenation:
CUI = HASH(visited network data + user identifier + key)
This construct has the following conceptual parameters.
HASH
A cryptographic hash function.
visited network data
Data which identifies the visited network.
This data could be the Operator-Name attribute ([RFC5580]
Section 4.1).
user identifier
The site-local user identifier. For tunnelled EAP methods such
as PEAP or TTLS, this could be the user identity which is sent
inside of the TLS tunnel.
key
A secret known only to the local network. The key is generally
a large random string. It is used to help prevent dictionary
attacks on the CUI.
Where the CUI needs to be constant across multiple user sessions or
devices, the key can be a static value. It is generated once by the
home network, and then stored for use in further CUI derivations.
Where the CUI needs to be unique per session, the above derivation
SHOULD still be used, except that the "key" value will instead be a
random number which is different for each session. Using such a
DeKok Expires 10 May 2024 [Page 22]
Internet-Draft Deprecating RADIUS November 2023
design again decouples the CUI creation from any requirement that it
is unique per session, or constant per user. That decision can be
changed at any time, and the only piece which needs to be updated is
the derivation of the "key" field. In contrast, if the CUI is
generated completely randomly per session, then it may be difficult
for a system to later change that behavior to allow the CUI to be
constant for a particular user.
If an NAI format is desired, the hash output can be converted to
printable text, truncated if necessary to meet length limitations,
and then an "@" character and a realm can be appended to it. The
resulting text string is then in NAI form.
We note that the above recommendation is not invertible. That is,
given a particular CUI, it is not possible to determine which visited
network or user identifier was used to create it. If it is necessary
to use the CUI to determine which user is associated with it, the
local network still needs to store the full set of CUI values which
are associated with each user.
If this tracking is too complex for a local network, it is possible
to create the CUI via an invertible encryption process as follows:
CUI = ENCRYPT(key, visited network data + user identifier)
This construct has the following conceptual parameters.
ENCRYPT
A cryptographically secure encryption function
key
The encryption key. Note that the same key must not be used
for more both hashing and encryption.
visited network data
Data which identifies the visited network.
This data could be the Operator-Name attribute ([RFC5580]
Section 4.1).
user identifier
The site-local user identifier. For tunnelled EAP methods such
as PEAP or TTLS, this could be the user identity which is sent
inside of the TLS tunnel.
DeKok Expires 10 May 2024 [Page 23]
Internet-Draft Deprecating RADIUS November 2023
However, the use of a hash-based method is RECOMMENDED.
In short, the intent is for CUI to leak as little information as
possible, and ideally be different for every session. However,
business agreements, legal requirements, etc. may mandate different
behavior. The intention of this section is not to mandate complete
CUI privacy, but instead to clarify the trade-offs between CUI
privacy and business realities.
7.2. User-Password and Proxying
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 identities and passwords 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
existence of clear-text passwords on multiple machines is a security
risk.
It is therefore NOT RECOMMENDED for organizations to send User-
Password attributes in packets which are sent outside of the local
organization. If RADIUS proxying is necessary, another
authentication method SHOULD be used.
Client and server implementations SHOULD use programming techniques
to securely wipe passwords 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 in the next section.
DeKok Expires 10 May 2024 [Page 24]
Internet-Draft Deprecating RADIUS November 2023
7.3. Password Visibility and Storage
Some organizations may desire to increase the security of their
network by using alternate authentication methods such as CHAP or MS-
CHAP, instead of PAP. These attempts are largely 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 simple
risk analysis, which we explain in more detail below.
When PAP is used, any compromise of a system which sees the User-
Password will result in that password leaking. In contrast, when
CHAP or MS-CHAP is used, those methods do not share the password, but
instead a hashed transformation of it. That hash output is in theory
secure from attackers. However, the hashes used (MD5 and MD4
respectively) are decades old, have been broken, and are known to be
insecure. Any security analysis which makes the claim that "User-
Password insecure because it is protected with MD5" ignores the fact
that the CHAP-Password attribute is constructed through substantially
similar methods.
The difference between the two constructs is that the CHAP-Password
depends on the hash of a visible Request Authenticator (or CHAP-
Challenge) and the users password, while the obfuscated User-Password
depends on the same Request Authenticator, and on the RADIUS shared
secret. For an attacker, the difference between the two calculations
is minimal. They can both be attacked with similar amounts of
effort.
Further, any security analysis can not stop with the wire protocol.
It must include all related systems which are affected by the choice
of authentication methods. In this case, the most important piece of
the system affected by these choices is the database which stores the
passwords.
When PAP is used, the information stored in the database can be
salted, and/or hashed in a form is commonly referred to as being in
"crypt"ed form. The incoming clear-text password then undergoes the
"crypt" transformation, and the two "crypt"ed passwords are compared.
The passwords in the database are stored securely at all times, and
any compromise of the database results in the disclosure of minimal
information to an attacker. That is, the attacker cannot easily
obtain the clear-text passwords from the database compromise.
The process for CHAP and MS-CHAP is inverted from the process for
PAP. Using similar terminology as above for illustrative purposes,
the "crypt"ed passwords are sent to the server. The server must
obtain the clear-text (or NT hashed) password from the database, and
DeKok Expires 10 May 2024 [Page 25]
Internet-Draft Deprecating RADIUS November 2023
then perform the "crypt" operation on the password from the database.
The two "crypt"ed passwords are then compared as was done with PAP.
This inverted process has substantial and negative impacts on
security.
When PAP is used, passwords are stored in clear-text only ephemerally
in the memory of an application which receives and then verifies the
password. Any compromise of that application results in the exposure
of a small number of passwords which are visible at the time of
compromise. If the compromise is undetected for an extended period
of time, the number of exposed passwords would of course increase.
However, when CHAP or MS-CHAP are used, all of passwords are stored
in clear-text in the database, all of the time. The database
contents might be encrypted, but the decryption keys are necessarily
accessible to the application which reads that database. Any
compromise of the application means that the entire database can be
immediately read and exfiltrated as a whole. The attacker then has
complete access to all user identities, and all associated clear-text
passwords.
The result is that when the system as a whole is taken into account,
the risk of password compromise is less with PAP than with CHAP or
MS-CHAP. It is therefore RECOMMENDED that administrators use PAP in
preference to CHAP or MS-CHAP.
7.4. MS-CHAP
MS-CHAP (v1 in [RFC2433] and v2 in [RFC2759]) has major design flaws,
and should not be used outside of a secure tunnel. As MS-CHAPv1 is
not normally used, the discussion in this section will focus on MS-
CHAPv2.
Recent developments demonstrate just how easy it is to attack MS-
CHAPv2 exchanges, and obtain the "NT-hash" version of the password
([SENSEPOST]). 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.
DeKok Expires 10 May 2024 [Page 26]
Internet-Draft Deprecating RADIUS November 2023
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 against databases containing 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-CHAPv2 SHOULD be considered in most situations
as being equivalent in security and privacy to PAP. It offers little
benefit over PAP, and has many drawbacks as discussed here, and in
the previous section.
There is one situation where MS-CHAP is significantly worse than PAP;
where the MS-CHAP data is sent over the network in the clear. 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.
This document therefore mandates that MS-CHAP authentication data
carried in RADIUS MUST NOT be sent in situations where the MS-CHAP
data is visible to an observer. That is, MS-CHAP authentication MUST
NOT be sent over RADIUS/UDP or RADIUS/TCP
DeKok Expires 10 May 2024 [Page 27]
Internet-Draft Deprecating RADIUS November 2023
7.5. EAP
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].
Where it is necessary to use intermediate proxies such as with
eduroam [EDUROAM] and OpenRoaming [OPENROAMING], it is RECOMMENDED to
use EAP instead of PAP, CHAP, or MS-CHAP. If passwords are used,
they can be can be protected 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].
We also note that the TLS-based EAP methods which transport passwords
also hide the passwords from intermediate RADIUS proxies. However,
for the home authentication server, those EAP methods are still
subject to the analysis above about PAP versus CHAP, along with the
issues of storing passwords in a database.
7.6. Eliminating Proxies
The best way to avoid compromise of 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.
8. Privacy Considerations
The primary focus of this document is addressing privacy and security
considerations for RADIUS.
Deprecating insecure transport for RADIUS, and requiring secure
transport means that personally identifying information is no longer
sent "in the clear". As noted earlier in this document, such
information can include MAC addresses, user identifiers, and user
locations.
In addition, this document suggests ways to increase privacy by
minimizing the use and exchange of PII.
9. Security Considerations
The primary focus of this document is addressing security and privacy
considerations for RADIUS.
DeKok Expires 10 May 2024 [Page 28]
Internet-Draft Deprecating RADIUS November 2023
Deprecating insecure transport for RADIUS, and requiring secure
transport means that many historical security issues with the RADIUS
protocol no longer apply, or their impact is minimized.
We reiterate the discussion above, that any security analysis must be
done on the system as a whole. It is not enough to put an expensive
lock on the front door of a house while leaving the window next to it
open, and then declare the house to be "secure". Any approach to
security based on a simple checklist is at best naive, more
truthfully is deeply misleading, and at worst such practices will
serve to decrease security.
Implementers and administrators need to be aware of the issues raised
in this document. They can then make the best choice for their local
network which balances their requirements on privacy, security, and
cost.
10. IANA Considerations
There are no IANA considerations in this document.
RFC Editor: This section may be removed before final publication.
11. Acknowledgements
Thanks to the many reviewers and commenters for raising topics to
discuss, and for providing insight into the issues related to
increasing the security of RADIUS. In no particular order, thanks to
Margaret Cullen, Alexander Clouter, and Josh Howlett.
12. Changelog
* 01 - added more discussion of IPSec, and move TLS-PSK to its own
document,
* 02 - Added text on Increasing the Security of Insecure Transports
* 03 - add text on CUI. Add notes on PAP vs CHAP security
* 04 - add text on security of MS-CHAP. Rearrange and reword many
sections for clarity.
* 05 - Rework title to deprecating "insecure practices".
Clarifications based on WG feedback.
13. References
13.1. Normative References
DeKok Expires 10 May 2024 [Page 29]
Internet-Draft Deprecating RADIUS November 2023
[BCP14] 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/info/rfc8174>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[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/info/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/info/rfc6421>.
[RFC8044] DeKok, A., "Data Types in RADIUS", RFC 8044,
DOI 10.17487/RFC8044, January 2017,
<https://www.rfc-editor.org/info/rfc8044>.
[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/info/rfc8174>.
13.2. Informative References
[EDUROAM] eduroam, "eduroam", n.d., <https://eduroam.org>.
[I-D.ietf-radext-tls-psk]
DeKok, A., "RADIUS and TLS-PSK", Work in Progress,
Internet-Draft, draft-ietf-radext-tls-psk-03, 24 August
2023, <https://datatracker.ietf.org/doc/html/draft-ietf-
radext-tls-psk-03>.
[I-D.josefsson-pppext-eap-tls-eap]
Palekar, A., Josefsson, S., Simon, D., and G. Zorn,
"Protected EAP Protocol (PEAP) Version 2", Work in
Progress, Internet-Draft, draft-josefsson-pppext-eap-tls-
eap-10, 21 October 2004,
<https://datatracker.ietf.org/doc/html/draft-josefsson-
pppext-eap-tls-eap-10>.
[I-D.tomas-openroaming]
Tomas, B., Grayson, M., Canpolat, N., Cockrell, B. A., and
S. Gundavelli, "WBA OpenRoaming Wireless Federation", Work
DeKok Expires 10 May 2024 [Page 30]
Internet-Draft Deprecating RADIUS November 2023
in Progress, Internet-Draft, draft-tomas-openroaming-00,
14 June 2023, <https://datatracker.ietf.org/doc/html/
draft-tomas-openroaming-00>.
[OPENROAMING]
Alliance, W. B., "OpenRoaming: One global Wi-Fi network",
n.d., <https://wballiance.com/openroaming/>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992,
<https://www.rfc-editor.org/info/rfc1321>.
[RFC2433] Zorn, G. and S. Cobb, "Microsoft PPP CHAP Extensions",
RFC 2433, DOI 10.17487/RFC2433, October 1998,
<https://www.rfc-editor.org/info/rfc2433>.
[RFC2759] Zorn, G., "Microsoft PPP CHAP Extensions, Version 2",
RFC 2759, DOI 10.17487/RFC2759, January 2000,
<https://www.rfc-editor.org/info/rfc2759>.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866,
DOI 10.17487/RFC2866, June 2000,
<https://www.rfc-editor.org/info/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/info/rfc2868>.
[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/info/rfc3579>.
[RFC4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney,
"Chargeable User Identity", RFC 4372,
DOI 10.17487/RFC4372, January 2006,
<https://www.rfc-editor.org/info/rfc4372>.
[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/info/rfc5080>.
DeKok Expires 10 May 2024 [Page 31]
Internet-Draft Deprecating RADIUS November 2023
[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/info/rfc5176>.
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication
Protocol Tunneled Transport Layer Security Authenticated
Protocol Version 0 (EAP-TTLSv0)", RFC 5281,
DOI 10.17487/RFC5281, August 2008,
<https://www.rfc-editor.org/info/rfc5281>.
[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/info/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/info/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/info/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/info/rfc6218>.
[RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613,
DOI 10.17487/RFC6613, May 2012,
<https://www.rfc-editor.org/info/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/info/rfc6614>.
[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/info/rfc6973>.
DeKok Expires 10 May 2024 [Page 32]
Internet-Draft Deprecating RADIUS November 2023
[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/info/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/info/rfc7525>.
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542,
DOI 10.17487/RFC7542, May 2015,
<https://www.rfc-editor.org/info/rfc7542>.
[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/info/rfc7585>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8559] DeKok, A. and J. Korhonen, "Dynamic Authorization Proxying
in the Remote Authentication Dial-In User Service (RADIUS)
Protocol", RFC 8559, DOI 10.17487/RFC8559, April 2019,
<https://www.rfc-editor.org/info/rfc8559>.
[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/info/rfc9190>.
[RFC9257] Housley, R., Hoyland, J., Sethi, M., and C. A. Wood,
"Guidance for External Pre-Shared Key (PSK) Usage in TLS",
RFC 9257, DOI 10.17487/RFC9257, July 2022,
<https://www.rfc-editor.org/info/rfc9257>.
[SENSEPOST]
Sensepost, "Cracking MS-CHAP", n.d.,
<https://github.com/sensepost/assless-chaps>.
[SPOOFING] Cudbard-Bell, A., "Wi-Fi Spoofing for Fun and Profit",
n.d., <https://networkradius.com/articles/2021/08/04/wifi-
spoofing.html>.
DeKok Expires 10 May 2024 [Page 33]
Internet-Draft Deprecating RADIUS November 2023
[WIFILOC] Alliance, W.-F., "Accurate indoor location with Wi-Fi
connectivity", n.d.,
<https://www.wi-fi.org/discover-wi-fi/wi-fi-location>.
Author's Address
Alan DeKok
FreeRADIUS
Email: aland@freeradius.org
DeKok Expires 10 May 2024 [Page 34]