Deprecating RADIUS/UDP and RADIUS/TCP
draft-dekok-radext-deprecating-radius-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Author | Alan DeKok | ||
| Last updated | 2022-10-04 | ||
| Replaced by | draft-ietf-radext-deprecating-radius | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-dekok-radext-deprecating-radius-00
RADEXT Working Group A. DeKok
Internet-Draft FreeRADIUS
Intended status: Standards Track 4 October 2022
Expires: 7 April 2023
Deprecating RADIUS/UDP and RADIUS/TCP
draft-dekok-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 the use of the User Datagram
Protocol (UDP) and of the Transport Congestion Protocol (TCP) as
transport protocols for RADIUS. These transports are permitted
inside of secure networks, but their use even in that environment is
strongly discouraged. For all other environments, the use of TLS-
based transports is mandated.
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-dekok-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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
DeKok Expires 7 April 2023 [Page 1]
Internet-Draft Deprecating RADIUS October 2022
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 7 April 2023.
Copyright Notice
Copyright (c) 2022 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. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview of issues with RADIUS . . . . . . . . . . . . . . . 5
3.1. Information is sent in Clear Text . . . . . . . . . . . . 6
3.2. MD5 has been broken . . . . . . . . . . . . . . . . . . . 6
3.3. Complexity of cracking RADIUS shared secrets . . . . . . 6
3.4. Tunnel-Password and CoA-Request packets . . . . . . . . . 8
4. All short Shared Secrets have been compromised . . . . . . . 9
5. Deprecating RADIUS, and mandating TLS. . . . . . . . . . . . 9
5.1. Deprecating UDP and TCP as transports . . . . . . . . . . 9
5.2. Mandating TLS transport . . . . . . . . . . . . . . . . . 10
5.3. Crypto-Agility . . . . . . . . . . . . . . . . . . . . . 10
6. Migration Path and Recommendations . . . . . . . . . . . . . 11
6.1. Shared Secrets . . . . . . . . . . . . . . . . . . . . . 11
6.2. TLS-PSK . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2.1. PSK Identities . . . . . . . . . . . . . . . . . . . 13
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
DeKok Expires 7 April 2023 [Page 2]
Internet-Draft Deprecating RADIUS October 2022
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
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 obfsucate 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/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, and more recently 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 probmens 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 cleartext, 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.
DeKok Expires 7 April 2023 [Page 3]
Internet-Draft Deprecating RADIUS October 2022
Any observer of non-TLS RADIUS traffic is able to 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. An observer can 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
corporate executives 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. The negative implications
for security and individual safety are obvious.
These issues are only partly mitigated when the attributes RADIUS is
carrying define their own 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. The use of MAC address randomization can limit device
informationidentification to a particular manufacterer, 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
when RADIUS/UDP or RADIUS/TCP is used.
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. This document therefore deprecates insecure uses of
RADIUS, and mandates the use of secure TLS-based transport layers.
The use of TLS-based transport 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.
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 TLS 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.
DeKok Expires 7 April 2023 [Page 4]
Internet-Draft Deprecating RADIUS October 2022
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 Congestion Protocol [RFC6613]
* RADIUS/TLS
RADIUS over the Transport Layer Security protocol [RFC6614]
* RADIUS/DTLS
RADIUS over the Datagram Transport Layer Security protocol
[RFC7360]
* TLS
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 number of issues with RADIUS. For one, RADIUS sends most
information "in the clear", with obvious privacy implications.
Further, MD5 has been broken for over a decade, as summarized in
[RFC6151]. No protocol should be using MD5 for anything. Even if
MD5 was not broken, computers have gotten substantially faster in the
DeKok Expires 7 April 2023 [Page 5]
Internet-Draft Deprecating RADIUS October 2022
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 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
DeKok Expires 7 April 2023 [Page 6]
Internet-Draft Deprecating RADIUS October 2022
processing units (GPUs) are used. A high-end GPU is capable of
performing more than 64 billion hashes per second.
(https://gist.github.com/Chick3nman/e4fcee00cb6d82874dace72106d73f).
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.
DeKok Expires 7 April 2023 [Page 7]
Internet-Draft Deprecating RADIUS October 2022
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,
DeKok Expires 7 April 2023 [Page 8]
Internet-Draft Deprecating RADIUS October 2022
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.
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.
Further, if a User-Password has been sent over the Internet via
RADIUS/UDP or RADIUS/TCP in the last decade, you should assume that
password has been compromised by an attacker with sufficient
resources.
5. Deprecating RADIUS, and mandating TLS.
The solution to an insecure protocol using thirty year-old
cryptography is to deprecate the 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.
DeKok Expires 7 April 2023 [Page 9]
Internet-Draft Deprecating RADIUS October 2022
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 TLS transport
All RADIUS systems MUST support RADIUS/TLS and/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.
DeKok Expires 7 April 2023 [Page 10]
Internet-Draft Deprecating RADIUS October 2022
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 obfscate 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.
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.
hat 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. 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
guesses would be in the order of hundreds of thousands, if not
millions of RADIUS/UDP devices are in daily use.
We therefore need to define a migration path to using secure
transports. We give a few migration steps by making stronger
recommendations for shared secrets. Where [RFC6614] Section 2.3
makes support for TLS-PSK optional, we now require support for TLS-
PSK.
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.
DeKok Expires 7 April 2023 [Page 11]
Internet-Draft Deprecating RADIUS October 2022
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.
#!/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.
RADIUS implementors SHOULD provide tools for administrators which
automatically create secure shared secrets.
Given the insecurity of RADIUS, the absolute minimum acceptable
security is to use strong shared secrets. However, TLS-PSK is not
substantially more complex, and offers significantly increased
security and privacy.
6.2. TLS-PSK
TLS uses certificates in most common uses. However, we recognize
that it may be difficult to fully upgrade client implementations to
allow for certificates to be used with RADIUS/TLS and RADIUS/DTLS.
It is therefore RECOMMENDED that client implementations allow the use
of a pre-shared key (TLS-PSK). The client implementation can then
expose a flag "TLS yes / no", and then a shared secret (now PSK)
entry field.
Any shared secret used for RADIUS/UDP MUST NOT be used for TLS-PSK.
DeKok Expires 7 April 2023 [Page 12]
Internet-Draft Deprecating RADIUS October 2022
Implementations MUST support PSKs of at least 32 octets, and SHOULD
support PSKs of 64 octets. Implementations MUST require that PSKs be
at least 16 octets in length. That is, short PSKs MUST NOT be
permitted to be used.
Administrators SHOULD use PSKs of at least 24 octets, generated using
a source of secure random numbers. The script given above can again
be used.
We also incorporate by reference the requirements of Section 10.2 of
[RFC7360] when using PSKs.
6.2.1. PSK Identities
[RFC6614] is silent on the subject of PSK identities, which is an
issue that we correct here.
The need to manage identities associated with PSK is a new
requirement for NAS management interfaces, and is a new requirement
for RADIUS servers. As such, implementors and operators require
guidance.
RADIUS systems implementing TLS-PSK MUST support identities as per
[RFC4279] Section 5.3, and MUST enable configuring TLS-PSK identities
in management interfaces as per [RFC4279] Section 5.4.
A RADIUS client implementing TLS-PSK MUST update their management
interfaces and application programming interfaces (APIs) to label the
PSK field as "PSK" or "TLS-PKS, and MUST NOT label the PSK field as
"shared secret".
Where dynamic server lookups [RFC7585] are not used, RADIUS clients
MUST still permit the configuration of a RADIUS server IP address.
When a RADIUS server implements TLS-PSK, the PSK identity replaces
the IP address as the logical identifier for a RADIUS client. RADIUS
servers MUST be able to look up PSK identity in a subsystem which
then returns the actual PSK.
We note that due to NAT, etc. there may be multiple RADIUS clients
using one public IP address. RADIUS servers MUST support such a
configuration, and MUST support unique PSK identities for each client
which is deployed in such a scenario.
RADIUS servers SHOULD tie PSK identities to a particular permitted IP
address or permitted network, as doing so will lower the risk if a
PSK is leaked. RADIUS servers MUST permit multiple clients to share
one permitted IP address or network.
DeKok Expires 7 April 2023 [Page 13]
Internet-Draft Deprecating RADIUS October 2022
A RADIUS server which accepts TLS-PSK MUST support a unique PSK
identifier per RADIUS client. There is no reason to use the same
identifier for multiple clients. A RADIUS server which accepts TLS-
PSK MUST have a unique PSK per RADIUS client.
It is RECOMMENDED that RADIUS clients and server track all used
shared secrets and PSKs, and then verify that the following
requirements all hold true:
* no shared secret is used for more than one RADIUS client
* no PSK is used for more than one RADIUS cleint
* no shared secret is used as a PSK
* no PSK is used as a shared secret
7. Privacy Considerations
The primary focus of this document is addressing privacy
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.
8. Security Considerations
The primary focus of this document is addressing security
considerations for RADIUS.
Deprecating insecure transport for RADIUS, and requiring secure
transport means that historical and/or future security issues with
the RADIUS protocol no longer apply.
Experience has shown that it can be difficult to configure and update
certificates in a RADIUS environment. Public Certification
Authorities (CAs) will not issue certificates specifically for use by
RADIUS servers. As for updates, certificates may be valid for many
years. By the time a certificate is up for renewal, the people and
processes responsible for it may have changed. Which means that
updating certificates can be a complex and error-prone task.
DeKok Expires 7 April 2023 [Page 14]
Internet-Draft Deprecating RADIUS October 2022
Therefore while [RFC6614] suggested that TLS-PSK was optional, we
mandate support for TLS-PSK here. We also correct the omission of
any discussion related to TLS-PSK identies in that specification, and
explain how those identities are used on clients and servers.
9. IANA Considerations
There are no IANA considerations in this document.
RFC Editor: This section may be removed before final publication.
10. Acknowledgements
TBD.
11. Changelog
12. References
12.1. Normative References
[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>.
[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key
Ciphersuites for Transport Layer Security (TLS)",
RFC 4279, DOI 10.17487/RFC4279, December 2005,
<https://www.rfc-editor.org/info/rfc4279>.
[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>.
[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>.
DeKok Expires 7 April 2023 [Page 15]
Internet-Draft Deprecating RADIUS October 2022
12.2. Informative References
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992,
<https://www.rfc-editor.org/info/rfc1321>.
[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>.
[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>.
[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>.
[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>.
DeKok Expires 7 April 2023 [Page 16]
Internet-Draft Deprecating RADIUS October 2022
[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>.
[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>.
[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>.
Author's Address
Alan DeKok
FreeRADIUS
Email: aland@freeradius.org
DeKok Expires 7 April 2023 [Page 17]