Internet DRAFT - draft-rieckers-radext-rfc6614bis
draft-rieckers-radext-rfc6614bis
RADIUS EXTensions J.-F. Rieckers
Internet-Draft DFN
Obsoletes: 6614 (if approved) S. Winter
Intended status: Standards Track RESTENA
Expires: 11 September 2023 10 March 2023
Transport Layer Security (TLS) Encryption for RADIUS
draft-rieckers-radext-rfc6614bis-02
Abstract
This document specifies a transport profile for RADIUS using
Transport Layer Security (TLS) over TCP as the transport protocol.
This enables dynamic trust relationships between RADIUS servers as
well as encrypting RADIUS traffic between servers using a shared
secret.
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-rieckers-radext-rfc6614bis/.
Discussion of this document takes place on the RADIUS EXTensions
Working Group mailing list (mailto:radext@ietf.org), which is
archived at https://mailarchive.ietf.org/arch/browse/radext/.
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 11 September 2023.
Rieckers & Winter Expires 11 September 2023 [Page 1]
Internet-Draft RADIUS over TLS March 2023
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. Conventions and Definitions . . . . . . . . . . . . . . . 3
1.2. Changes from RFC6614 . . . . . . . . . . . . . . . . . . 4
2. Transport layer security for RADIUS/TCP . . . . . . . . . . . 4
2.1. TCP port and Packet Types . . . . . . . . . . . . . . . . 5
2.2. TLS Connection setup . . . . . . . . . . . . . . . . . . 5
2.3. TLS Peer Authentication . . . . . . . . . . . . . . . . . 6
2.3.1. Authentication using X.509 certificates with PKIX trust
model . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.2. Authentication using certificate fingerprints . . . . 8
2.3.3. Authentication using TLS-PSK . . . . . . . . . . . . 8
2.3.4. Authentication using Raw Public Keys . . . . . . . . 8
2.4. Connecting Client Identity . . . . . . . . . . . . . . . 8
2.5. RADIUS Datagrams . . . . . . . . . . . . . . . . . . . . 9
3. Design Decisions . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Implications of Dynamic Peer Discovery . . . . . . . . . 11
3.2. X.509 Certificate Considerations . . . . . . . . . . . . 11
3.3. Cipher Suites and Compression Negotiation
Considerations . . . . . . . . . . . . . . . . . . . . . 11
3.4. RADIUS Datagram Considerations . . . . . . . . . . . . . 12
4. Compatibility with Other RADIUS Transports . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Lessons learned from deployments of the Experimental
RFC6614 . . . . . . . . . . . . . . . . . . . . . . . . . 17
A.1. eduroam . . . . . . . . . . . . . . . . . . . . . . . . . 17
A.2. Wireless Broadband Alliance's OpenRoaming . . . . . . . . 19
A.3. Participating in more than one roaming consortium . . . . 19
Appendix B. Interoperable Implementations . . . . . . . . . . . 20
Rieckers & Winter Expires 11 September 2023 [Page 2]
Internet-Draft RADIUS over TLS March 2023
Appendix C. Backward compatibility . . . . . . . . . . . . . . . 20
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
The RADIUS protocol [RFC2865] is a widely deployed authentication and
authorization protocol. The supplementary RADIUS Accounting
specification [RFC2866] provides accounting mechanisms, thus
delivering a full Authentication, Authorization, and Accounting (AAA)
solution. However, RADIUS has shown several shortcomings, especially
the lack of security for large parts of its packet payload. RADIUS
security is based on the MD5 algorithm, which has been proven to be
insecure.
The main focus of RADIUS over TLS is to provide a means to secure the
communication between RADIUS/TCP peers using TLS. The most important
use of this specification lies in roaming environments where RADIUS
packets need to be transferred through different administrative
domains and untrusted, potentially hostile network.
There are multiple known attacks on the MD5 algorithm that is used in
RADIUS to provide integrity protection and a limited confidentiality
protection. RADIUS over TLS wraps the entire RADIUS packet payload
into a TLS stream and thus mitigates the risk of attacks on MD5.
Because of the static trust establishment between RADIUS peers (IP
address and shared secret), the only scalable way of creating a
massive deployment of RADIUS servers under the control of different
administrative entities is to introduce some form of a proxy chain to
route the access requests to their home server. This creates a lot
of overhead in terms of possible points of failure, longer
transmission times, as well as middleboxes through which
authentication traffic flows. These middleboxes may learn privacy-
relevant data while forwarding requests. The new features in RADIUS
over TLS add a new way to identify other peers, e.g., by checking a
certificate for the issuer or other certificate properties, but also
provides a simple upgrade path for existing RADIUS connection by
simply using the shared secret to authenticate the TLS session.
1.1. Conventions and Definitions
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.
Rieckers & Winter Expires 11 September 2023 [Page 3]
Internet-Draft RADIUS over TLS March 2023
Within this document we will use the following terms:
RADIUS/TLS node: a RADIUS-over-TLS client or server
RADIUS/TLS Client: a RADIUS-over-TLS instance that initiates a new
connection
RADIUS/TLS Server: a RADIUS-over-TLS instance that listens on a
RADIUS-over-TLS port and accepts new connections
RADIUS/UDP: a classic RADIUS transport over UDP as defined in
[RFC2865]
1.2. Changes from RFC6614
Currently, there are no big changes, since this is just a
restructured spec from [RFC6614].
The following things have changed:
Required TLS versions: TLS 1.2 is now the minimum TLS version, TLS
1.3 is included as recommended.
TLS compression: [RFC6614] allowed usage of TLS compression, this
document forbids it.
TLS-PSK support: [RFC6614] lists support for TLS-PSK as OPTIONAL,
this document changes this to RECOMMENDED.
Mandatory-to-implement(MTI) cipher suites: Following the
recommendation from [RFC9325], the RC4 cipher suite is no longer
included as SHOULD, and the AES cipher suite is the new MTI cipher
suite, since it is the MTI cipher suite from TLS 1.2.
Additionally, this document references [RFC9325] for further
recommendations for cipher suites.
The following things will change in future versions of this draft:
* Usage of Server Name Indication
* More text for TLS-PSK
2. Transport layer security for RADIUS/TCP
This section specifies the way TLS is used to secure the traffic and
the changes in the handling of RADIUS packets.
Rieckers & Winter Expires 11 September 2023 [Page 4]
Internet-Draft RADIUS over TLS March 2023
2.1. TCP port and Packet Types
The default destination port number for RADIUS over TLS is TCP/2083.
There are no separate ports for authentication, accounting, and
dynamic authorization changes. The source port is arbitrary.
2.2. TLS Connection setup
The RADIUS/TLS nodes first try to establish a TCP connection as per
[RFC6613]. Failure to connect leads to continuous retries. It is
RECOMMENDED to use exponentially growing intervals between every try.
After completing the TCP handshake, the RADIUS/TLS nodes immediately
negotiate a TLS session. The following restrictions apply:
* Support for TLS 1.2 [RFC5246] is REQUIRED, support for TLS 1.3
[RFC8446] is RECOMMENDED. RADIUS/TLS nodes MUST NOT negotiate TLS
versions prior to TLS 1.2.
* The RADIUS/TLS nodes MUST NOT offer or negotiate cipher suites
which do not provide confidentiality and integrity protection.
* The RADIUS/TLS nodes MUST NOT negotiate compression.
* When using TLS 1.3, RADIUS/TLS nodes MUST NOT use early data
([RFC8446], Section 2.3)
* RADIUS/TLS implementations MUST, at minimum, support negotiation
of the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite and SHOULD follow
the recommendations for supported cipher suites in [RFC9325],
Section 4.
* In addition, RADIUS/TLS implementations MUST support negotiation
of the mandatory-to-implement cipher suites required by the
versions of TLS they support.
Details for peer authentication are described in Section 2.3.
After successful negotiation of a TLS session, the RADIUS/TLS peers
can start exchanging RADIUS datagrams. The shared secret to compute
the (obsolete) MD5 integrity checks and attribute obfuscation MUST be
"radsec".
Rieckers & Winter Expires 11 September 2023 [Page 5]
Internet-Draft RADIUS over TLS March 2023
2.3. TLS Peer Authentication
Peers MUST mutually authenticate each other at the TLS layer. The
authentication of peers can be done using different models, that will
be described here. Peers can also perform additional authorization
checks based on non-TLS information. For example, verifying that the
client IP address (source IP address of the TLS connection) falls
within a particular network range.
2.3.1. Authentication using X.509 certificates with PKIX trust model
All RADIUS/TLS implementations MUST implement this model, following
the following rules:
* Implementations MUST allow the configuration of a list of trusted
Certificate Authorities for incoming connections.
* Certificate validation MUST include the verification rules as per
[RFC5280].
* Implementations SHOULD indicate their trusted Certification
Authorities (CAs). See [RFC5246], Section 7.4.4 and [RFC6066],
Section 6 for TLS 1.2 and [RFC8446], Section 4.2.4 for TLS 1.3.
* RADIUS/TLS clients validate the server identity to match their
local configuration:
- If the expected RADIUS/TLS server was configured as a hostname,
the configured name is matched against the presented names from
the subjectAltName:DNS extension; if no such exist, against the
presented CN component of the certificate subject.
- If the expected RADIUS/TLS server was configured as an IP
address, the configured IP address is matched against the
presented addresses in the subjectAltName:iPAddr extension; if
no such exist, against the presented CN component of the
certificate subject.
- If the expected RADIUS/TLS server was not configured but
discovered as per [RFC7585], the peer executes the following
checks in this order, accepting the certificate on the first
match:
o The realm which was used as input to the discovery is
matched against the presented realm names from the
subjectAltName:naiRealm extension.
Rieckers & Winter Expires 11 September 2023 [Page 6]
Internet-Draft RADIUS over TLS March 2023
o If the discovery process yielded a hostname, this hostname
is matched against the presented names from the
subjectAltName:DNS extension; if no such exist, against the
presented CN component of the certificate subject.
Implementations MAY require the use of DNSSEC [RFC4033] to
ensure the authenticity of the DNS result before relying on
this for trust checks.
o If the previous checks fail, the certificate MAY be accepted
without further name checks immediately after the [RFC5280]
trust chain checks.
* RADIUS/TLS server validate the incoming certificate against a
local database of acceptable clients. The database may enumerate
acceptable clients either by IP address or by a name component in
the certificate.
- For clients configured by name, the configured name is matched
against the presented names from the subjectAltName:DNS
extension; if no such exists, against the presented CN
component in the certificate subject.
- For clients configured by their source IP address, the
configured IP address is matched against the presented
addresses in the subjectAltName:iPAddr extension; if no such
exist, against the presented CN component of the certificate
subject.
- It is possible for a RADIUS/TLS server to not require
additional name checks for incoming RADIUS/TLS clients. In
this case, the certificate is accepted immediately after the
[RFC5280] trust chain checks. This MUST NOT be used outside of
trusted network environments or without additional certificate
attribute checks in place.
* Implementations MAY allow the configuration of a set of additional
properties of the certificate to check for a peer's authorization
to communicate (e.g., a set of allowed values in
subjectAltName:URI or a set of allowed X.509v3 Certificate
Policies).
* When the configured trust base changes (e.g., removal of a CA from
the list of trusted CAs; issuance of a new CRL for a given CA),
implementations MAY renegotiate the TLS session to reassess the
connecting peer's continued authorization.
// Replace may with should here?
//
// -- Janfred
Rieckers & Winter Expires 11 September 2023 [Page 7]
Internet-Draft RADIUS over TLS March 2023
2.3.2. Authentication using certificate fingerprints
RADIUS/TLS implementations SHOULD allow the configuration of a list
of trusted certificates, identified via fingerprint of the DER
encoded certificate octets. When implementing this model, support
for SHA-1 as hash algorithm for the fingerprint is REQUIRED, and
support for the more contemporary has function SHA-256 is
RECOMMENDED.
2.3.3. Authentication using TLS-PSK
RADIUS/TLS implementations SHOULD support the use of TLS-PSK.
2.3.4. Authentication using Raw Public Keys
RADIUS/TLS implementations SHOULD support using Raw Public Keys
[RFC7250] for mutual authentication.
// TODO: More text here.
//
// -- Janfred
2.4. Connecting Client Identity
In RADIUS/UDP, clients are uniquely identified by their IP address.
Since the shared secret is associated with the origin IP address, if
more than one RADIUS client is associated with the same IP address,
then those clients also must utilize the same shared secret. This
practice is inherently insecure, as noted in [RFC5247],
Section 5.3.2.
Following the different authentication modes presented in
Section 2.3, the identification of clients can be done by different
means:
In TLS-PSK operation, a client is uniquely identified by its PSK
Identity.
When using certificate fingerprints, a client is uniquely identified
by the fingerprint of the presented client certificate.
When using X.509 certificates with a PKIX trust model, a client is
uniquely identified by the tuple of the serial number of the
presended client certificate and the issuer of the client
certificate.
Rieckers & Winter Expires 11 September 2023 [Page 8]
Internet-Draft RADIUS over TLS March 2023
// TODO: Client identity when using Raw Public Key needs to be
// described here.
//
// -- Janfred
Note well: having identified a connecting entity does not mean the
server necessarily wants to communicate with that client. For
example, if the issuer is not in a trusted set of issuers, the server
may decline to perform RADIUS transactions with this client.
There are numerous trust models in PKIX environments, and it is
beyond the scope of this document to define how a particular
deployment determines whether a client is trustworthy.
Implementations that want to support a wide variety of trust models
should expose as many details of the presented certificate to the
administrator as possible so that the trust model can be implemented
by the administrator. As a suggestion, at least the following
parameters of the X.509 client certificate should be exposed:
* Originating IP address
* Certificate Fingerprint
* Issuer
* Subject
* all X.509v3 Extended Key Usage
* all X.509v3 Subject Alternative Name
* all X.509v3 Certificate Policies
For TLS-PSK operation, at least the following parameters of the TLS
connection should be exposed:
* Originating IP address
* PSK Identity
2.5. RADIUS Datagrams
Authentication, Authorization, and Accounting packets are sent
according to the following rules:
RADIUS/TLS clients transmit the same packet types on the connection
they initiated as a RADIUS/UDP client would. For example, they send
Rieckers & Winter Expires 11 September 2023 [Page 9]
Internet-Draft RADIUS over TLS March 2023
* Access-Request
* Accounting-Request
* Status-Server
* Disconnect-ACK
* Disconnect-NAK
* ...
RADIUS/TLS servers transmit the same packets on connections they have
accepted as a RADIUS/UDP server would. For example, they send
* Access-Challenge
* Access-Accept
* Access-Reject
* Accounting-Response
* Disconnect-Request
* ...
Due to the use of one single TCP port for all packet types, it is
required that a RADIUS/TLS server signal which types of packets are
supported on a server to a connecting peer.
* When an unwanted packet of type 'CoA-Request' or 'Disconnect-
Request' is received, a RADIUS/TLS server needs to respond with a
'CoA-NAK' or 'Disconnect-NAK', respectively. The NAK SHOULD
contain an attribute Error-Cause with the value 406 ("Unsupported
Extension"); see [RFC5176] for details.
* When an unwanted packet of type 'Accounting-Request' is received,
the RADIUS/TLS server SHOULD reply with an Accounting-Response
containing an Error-Cause attribute with value 406 "Unsupported
Extension" as defined in [RFC5176]. A RADIUS/TLS accounting
client receiving such an Accounting-Response SHOULD log the error
and stop sending Accounting-Request packets to this server.
Rieckers & Winter Expires 11 September 2023 [Page 10]
Internet-Draft RADIUS over TLS March 2023
3. Design Decisions
This section explains the design decisions that led to the rules
defined in the previous section, as well as a reasoning behind the
differences to [RFC6614].
3.1. Implications of Dynamic Peer Discovery
One mechanism to discover RADIUS-over-TLS peers dynamically via DNS
is specified in [RFC7585]. While this mechanism is still under
development and therefore is not a normative dependency of RADIUS/
TLS, the use of dynamic discovery has potential future implications
that are important to understand.
Readers of this document who are considering the deployment of DNS-
based dynamic discovery are thus encouraged to read [RFC7585] and
follow its future development.
3.2. X.509 Certificate Considerations
(1) If a RADIUS/TLS client is in possession of multiple certificates
from different CAs (i.e., is part of multiple roaming consortia)
and dynamic discovery is used, the discovery mechanism possibly
does not yield sufficient information to identify the consortium
uniquely (e.g., DNS discovery). Subsequently, the client may not
know by itself which client certificate to use for the TLS
handshake. Then, it is necessary for the server to signal to
which consortium it belongs and which certificates it expects. If
there is no risk of confusing multiple roaming consortia,
providing this information in the handshake is not crucial.
(2) If a RADIUS/TLS server is in possession of multiple certificates
from different CAs (i.e., is part of multiple roaming consortia),
it will need to select one of its certificates to present to the
RADIUS/TLS client. If the client sends the Trusted CA Indication,
this hint can make the server select the appropriate certificate
and prevent a handshake failure. Omitting this indication makes
it impossible to deterministically select the right certificate in
this case. If there is no risk of confusing multiple roaming
consortia, providing this indication in the handshake is not
crucial.
3.3. Cipher Suites and Compression Negotiation Considerations
See [RFC9325] for considerations regarding the cipher suites and
negotiation.
Rieckers & Winter Expires 11 September 2023 [Page 11]
Internet-Draft RADIUS over TLS March 2023
3.4. RADIUS Datagram Considerations
(1) After the TLS session is established, RADIUS packet payloads are
exchanged over the encrypted TLS tunnel. In RADIUS/UDP, the
packet size can be determined by evaluating the size of the
datagram that arrived. Due to the stream nature of TCP and TLS,
this does not hold true for RADIUS/TLS packet exchange. Instead,
packet boundaries of RADIUS packets that arrive in the stream are
calculated by evaluating the packet's Length field. Special care
needs to be taken on the packet sender side that the value of the
Length field is indeed correct before sending it over the TLS
tunnel, because incorrect packet lengths can no longer be detected
by a differing datagram boundary. See Section 2.6.4 of [RFC6613]
for more details.
(2) Within RADIUS/UDP [RFC2865], a shared secret is used for hiding
attributes such as User-Password, as well as in computation of the
Response Authenticator. In RADIUS accounting [RFC2866], the
shared secret is used in computation of both the Request
Authenticator and the Response Authenticator. Since TLS provides
integrity protection and encryption sufficient to substitute for
RADIUS application-layer security, it is not necessary to
configure a RADIUS shared secret. The use of a fixed string for
the obsolete shared secret eliminates possible node
misconfigurations.
(3) RADIUS/UDP [RFC2865] uses different UDP ports for
authentication, accounting, and dynamic authorization changes.
RADIUS/TLS allocates a single port for all RADIUS packet types.
Nevertheless, in RADIUS/TLS, the notion of a client that sends
authentication requests and processes replies associated with its
users' sessions and the notion of a server that receives requests,
processes them, and sends the appropriate replies is to be
preserved. The normative rules about acceptable packet types for
clients and servers mirror the packet flow behavior from RADIUS/
UDP.
(4) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly
allocated UDP port to signal that a peer RADIUS server does not
support the reception and processing of the packet types in
[RFC5176]. These packet types are listed as to be received in
RADIUS/TLS implementations. Note well: it is not required for an
implementation to actually process these packet types; it is only
required that the NAK be sent as defined above.
(5) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly
Rieckers & Winter Expires 11 September 2023 [Page 12]
Internet-Draft RADIUS over TLS March 2023
allocated UDP port to signal that a peer RADIUS server does not
support the reception and processing of RADIUS Accounting packets.
There is no RADIUS datagram to signal an Accounting NAK. Clients
may be misconfigured for sending Accounting packets to a RADIUS/
TLS server that does not wish to process their Accounting packet.
To prevent a regression of detectability of this situation, the
Accounting-Response + Error-Cause signaling was introduced.
4. Compatibility with Other RADIUS Transports
The IETF defines multiple alternative transports to the classic UDP
transport model as defined in [RFC2865], namely RADIUS over TCP
[RFC6613], the present document on RADIUS over TLS and RADIUS over
Datagram Transport Layer Security (DTLS) [RFC7360].
RADIUS/TLS does not specify any inherent backward compatibility to
RADIUS/UDP or cross compatibility to the other transports, i.e., an
implementation that utilizes RADIUS/TLS only will not be able to
receive or send RADIUS packet payloads over other transports. An
implementation wishing to be backward or cross compatible (i.e.,
wishes to serve clients using other transports than RADIUS/TLS) will
need to implement these other transports along with the RADIUS/TLS
transport and be prepared to send and receive on all implemented
transports, which is called a "multi-stack implementation".
If a given IP device is able to receive RADIUS payloads on multiple
transports, this may or may not be the same instance of software, and
it may or may not serve the same purposes. It is not safe to assume
that both ports are interchangeable. In particular, it cannot be
assumed that state is maintained for the packet payloads between the
transports. Two such instances MUST be considered separate RADIUS
server entities.
5. Security Considerations
The computational resources to establish a TLS tunnel are
significantly higher than simply sending mostly unencrypted UDP
datagrams. Therefore, clients connecting to a RADIUS/TLS node will
more easily create high load conditions and a malicious client might
create a Denial-of-Service attack more easily.
Some TLS cipher suites only provide integrity validation of their
payload and provide no encryption. This specification forbids the
use of such cipher suites. Since the RADIUS payload's shared secret
is fixed to the well-known term "radsec", failure to comply with this
requirement will expose the entire datagram payload in plaintext,
including User-Password, to intermediate IP nodes.
Rieckers & Winter Expires 11 September 2023 [Page 13]
Internet-Draft RADIUS over TLS March 2023
By virtue of being based on TCP, there are several generic attack
vectors to slow down or prevent the TCP connection from being
established; see [RFC4953] for details. If a TCP connection is not
up when a packet is to be processed, it gets re-established, so such
attacks in general lead only to a minor performance degradation (the
time it takes to re-establish the connection). There is one notable
exception where an attacker might create a bidding-down attack
though. If peer communication between two devices is configured for
both RADIUS/TLS and RADIUS/UDP, and the RADIUS/UDP transport is the
failover option if the TLS session cannot be established, a bidding-
down attack can occur if an adversary can maliciously close the TCP
connection or prevent it from being established. Situtations where
clients are configured in such a way are likely to occur during a
migration phase from RADIUS/UDP to RADIUS/TLS. By preventing the TLS
session setup, the attacker can reduce the security of the packet
payload from the selected TLS cipher suite packet encryption to the
classic MD5 per-attribute encryption. The situation should be
avoided by disabling the weaker RADIUS/UDP transport as soon as the
new RADIUS/TLS connection is established and tested.
RADIUS/TLS provides authentication and encryption between RADIUS
peers. In the presence of proxies, the intermediate proxies can
still inspect the individual RADIUS packets, i.e., "end-to-end"
encryption is not provided. Where intermediate proxies are
untrusted, it is desirable to use other RADIUS mechanisms to prevent
RADIUS packet payload from inspection by such proxies. One common
method to protect passwords is the use of the Extensible
Authentication Protocol (EAP) and EAP methods that utilize TLS.
For dynamic discovery, this document allows the acceptance of a
certificate only after doing PKIX checks. When using publicly
trusted CAs as trust anchor, this may lead to security issues, since
an advisary may easily get a valid certificate from this CAs. In
current practice of [RFC6614], this problem is circumvented by using
a private CA as a trust anchor. This private CA only issues
certificate to members of the roaming consortium. This may still
enable a malicious member to intercept traffic not intended for them,
however, depending on the size of the consortium, this attack vector
may be negligible. If the private CA also issues certificates for
other purposes than RADIUS/TLS, the RADIUS/TLS certificates SHOULD
include RADIUS/TLS-specific attributes against the implementation can
check such as a X.509v3 Certificate Policy specific for RADIUS/TLS.
When using certificate fingerprints to identify RADIUS/TLS peers, any
two certificates that produce the same hash value (i.e., that have a
hash collision) will be considered the same client. Therefore, it is
important to make sure that the hash function used is
cryptographically uncompromised so that an attacker is very unlikely
Rieckers & Winter Expires 11 September 2023 [Page 14]
Internet-Draft RADIUS over TLS March 2023
to be able to produce a hash collision with a certificate of his
choice. While this specification mandates support for SHA-1, a later
revision will likely demand support for more contemporary hash
functions because as of issuance of this document, there are already
attacks on SHA-1.
6. IANA Considerations
Upon approval, IANA should update the Reference to radsec in the
Service Name and Transport Protocol Port Number Registry:
* Service Name: radsec
* Port Number: 2083
* Transport Protocol: tcp
* Description: Secure RADIUS Service
* Assignment notes: The TCP port 2083 was already previously
assigned by IANA for "RadSec", an early implementation of RADIUS/
TLS, prior to issuance of the experimental RFC 6614. [This
document] updates RFC 6614, while maintaining backward
compatibility, if configured. For further details see RFC 6614,
Appendix A or [This document], Appendix C.
7. References
7.1. Normative References
[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>.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866,
DOI 10.17487/RFC2866, June 2000,
<https://www.rfc-editor.org/info/rfc2866>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
Rieckers & Winter Expires 11 September 2023 [Page 15]
Internet-Draft RADIUS over TLS March 2023
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.
[RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613,
DOI 10.17487/RFC6613, May 2012,
<https://www.rfc-editor.org/info/rfc6613>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[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>.
[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>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
7.2. Informative References
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
RFC 4953, DOI 10.17487/RFC4953, July 2007,
<https://www.rfc-editor.org/info/rfc4953>.
Rieckers & Winter Expires 11 September 2023 [Page 16]
Internet-Draft RADIUS over TLS March 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>.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
RFC 5247, DOI 10.17487/RFC5247, August 2008,
<https://www.rfc-editor.org/info/rfc5247>.
[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>.
[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>.
[RFC7593] Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam
Architecture for Network Roaming", RFC 7593,
DOI 10.17487/RFC7593, September 2015,
<https://www.rfc-editor.org/info/rfc7593>.
Appendix A. Lessons learned from deployments of the Experimental
[RFC6614]
There are at least two major (world-scale) deployments of [RFC6614].
A.1. eduroam
eduroam is a globally operating Wi-Fi roaming consortium exclusively
for persons in Research and Education. For an extensive background
on eduroam and its authentication fabric architecture, refer to
[RFC7593].
Rieckers & Winter Expires 11 September 2023 [Page 17]
Internet-Draft RADIUS over TLS March 2023
Over time, more than a dozen out of 100+ national branches of eduroam
used RADIUS/TLS in production to secure their country-to-country
RADIUS proxy connections. This number is big enough to attest that
the protocol does work, and scales. The number is also low enough to
wonder why RADIUS/UDP continued to be used by a majority of country
deployments despite its significant security issues.
Operational experience reveals that the main reason is related to the
choice of PKIX certificates for securing the proxy interconnections.
Compared to shared secrets, certificates are more complex to handle
in multiple dimensions:
* Lifetime: PKIX certificates have an expiry date, and need
administrator attention and expertise for their renewal
* Validation: The validation of a certificate (both client and
server) requires contacting a third party to verify the
recovaction status. This either takes time during session setup
(OCSP checks) or requires the presence of a fresh CRL on the
server - this in turn requires regular update of that CRL.
* Issuance: PKIX certificates carry properties in the Subject and
extensions that need to be vetted. Depending on the CA policy, a
certificate request may need significant human intervention to be
verified. In particular, the authorisation of a requester to
operate a server for a particular NAI realm needs to be verified.
This rules out public "browser-trusted" CAs; eduroam is operating
a special-purpose CA for eduroam RADIUS/TLS purposes.
* Automatic failure over time: CRL refresh and certificate renewal
must be attended to regularly. Failure to do so leads to failure
of the authentication service. Among other reasons, employee
churn with incorrectly transferred or forgotten responsibilities
is a risk factor.
It appears that these complexities often outweigh the argument of
improved security; and a fallback to RADIUS/UDP is seen as the more
appealing option.
It can be considered an important result of the experiment in
[RFC6614] that providing less complex ways of operating RADIUS/TLS
are required. The more thoroughly specified provisions in the
current document towards TLS-PSK and raw public keys are a response
to this insight.
Rieckers & Winter Expires 11 September 2023 [Page 18]
Internet-Draft RADIUS over TLS March 2023
On the other hand, using RADIUS/TLS in combination with Dynamic
Discovery as per [RFC7585] necessitates the use of PKIX certificates.
So, the continued ability to operate with PKIX certificates is also
important and cannot be discontinued without sacrificing vital
funcionality of large roaming consortia.
A.2. Wireless Broadband Alliance's OpenRoaming
OpenRoaming is a globally operating Wi-Fi roaming consortium for the
general public, operated by the Wireless Broadband Alliance (WBA).
With its (optional) settled usage of hotspots, the consortium
requires both RADIUS authentication as well as RADIUS accounting.
The consortium operational procedures were defined in the late 2010s
when [RFC6614] and [RFC7585] were long available. The consortium
decided to fully base itself on these two RFCs.
In this architecture, using PSKs or raw public keys is not an option.
The complexities around PKIX certificates as discussed in the
previous section are believed to be controllable: the consortium
operates its own special-purpose CA and can rely on a reliable source
of truth for operator authorisation (becoming an operator requires a
paid membership in WBA); expiry and revocation topics can be expected
to be dealt with as high-priority because of the monetary
implications in case of infrastructure failure during settled
operation.
A.3. Participating in more than one roaming consortium
It is possible for a RADIUS/TLS (home) server to participate in more
than one roaming consortium, i.e. to authenticate its users to
multiple clients from distinct consortia, which present client
certificates from their respective consortium's CA; and which expect
the server to present a certificate from the matching CA.
The eduroam consortium has chosen to cooperate with (the settlement-
free parts of) OpenRoaming to allow eduroam users to log in to
(settlement-free) OpenRoaming hotspots.
eduroam RADIUS/TLS servers thus may be contacted by OpenRoaming
clients expecting an OpenRoaming server certificate, and by eduroam
clients expecting an eduroam server certificate.
It is therefore necessary to decide on the certificate to present
during TLS session establishment. To make that decision, the
availability of Trusted CA Indication in the client TLS message is
important.
Rieckers & Winter Expires 11 September 2023 [Page 19]
Internet-Draft RADIUS over TLS March 2023
It can be considered an important result of the experiment in
[RFC6614] that Trusted CA Indication is an important asset for inter-
connectivity of multiple roaming consortia.
Appendix B. Interoperable Implementations
[RFC6614] is implemented and interoperates between at least three
server implementations: FreeRADIUS, radsecproxy, Radiator. It is
also implemented among a number of Wireless Access Points /
Controllers from numerous vendors, including but not limited to:
Aruba Networks, LANCOM Systems.
Appendix C. Backward compatibility
TODO describe necessary steps to configure common servers for
compatibility with this version. Hopefully the differences to
[RFC6614] are small enough that almost no config change is necessary.
Acknowledgments
Thanks to the original authors of RFC 6614: Stefan Winter, Mike
McCauley, Stig Venaas and Klaas Vierenga.
TODO more acknowledgements
Authors' Addresses
Jan-Frederik Rieckers
Deutsches Forschungsnetz | German National Research and Education Network
Alexanderplatz 1
10178 Berlin
Germany
Email: rieckers@dfn.de
URI: www.dfn.de
Stefan Winter
Fondation Restena | Restena Foundation
2, avenue de l'Université
L-4365 Esch-sur-Alzette
Luxembourg
Email: stefan.winter@restena.lu
URI: www.restena.lu
Rieckers & Winter Expires 11 September 2023 [Page 20]
