| Internet-Draft | RADIUS over TLS | October 2022 |
| Rieckers | Expires 27 April 2023 | [Page] |
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.¶
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/.¶
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 27 April 2023.¶
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.¶
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.¶
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.¶
Within this document we will use the following terms:¶
a RADIUS-over-TLS client or server¶
a RADIUS-over-TLS instance that initiates a new connection¶
a RADIUS-over-TLS instance that listens on a RADIUS-over-TLS port and accepts new connections¶
a classic RADIUS transport over UDP as defined in [RFC2865]¶
Currently, there are no big changes, since this is just a restructured spec from [RFC6614].¶
The following things have changed:¶
TLS 1.2 is now the minimum TLS version, TLS 1.3 is included as recommended.¶
[RFC6614] allowed usage of TLS compression, this document forbids it.¶
[RFC6614] lists support for TLS-PSK as OPTIONAL, this document changes this to RECOMMENDED.¶
Following the recommendation from [RFC7525], 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 [RFC7525] for further recommendations for cipher suites.¶
The following things will change in future versions of this draft:¶
This section specifies the way TLS is used to secure the traffic and the changes in the handling of RADIUS packets.¶
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.¶
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:¶
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".¶
The authentication of peers can be done using different models, that will be described here.¶
All RADIUS/TLS implementations MUST implement this model, following the following rules:¶
RADIUS/TLS implementations SHOULD allow the configuration of a list of trusted certificates, identified via fingerprint of the DER encded 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.¶
The support for TLS-PSK is OPTIONAL.¶
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 TLS identifier.¶
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.¶
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:¶
For TLS-PSK operation, at least the following parameters of the TLS connection should be exposed:¶
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¶
RADIUS/TLS servers transmit the same packets on connections they have accepted as a RADIUS/UDP server would. For example, they send¶
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.¶
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].¶
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.¶
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.¶
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.¶
See [RFC7525] for considerations regarding the cipher suites and negotiation.¶
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.¶
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.¶
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.¶
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.¶
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 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.¶
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.¶
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.¶
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.¶
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 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.¶
Upon approval, IANA should update the Reference to radsec in the Service Name and Transport Protocol Port Number Registry:¶
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.¶
Thanks to the original authors of RFC 6614: Stefan Winter, Mice McCauley, Stig Venaas and Klaas Vierenga.¶
TODO more acknowledgements¶