RADEXT S. Yue
Internet Draft China Mobile
Intended status: Standards Track C. Lin
Expires: January 19, 2025 New H3C Technologies
F. Yang
China Mobile
July 19, 2025
RADIUS over QUIC
draft-yl-radext-quic-transport-01
Abstract
The Remote Authentication Dial-In User Server (RADIUS) Protocol can
use the User Datagram Protocol (UDP) and the Transport Control
Protocol (TCP) as its underlying transport layer. But it permits TCP
to be used as a transport protocol for RADIUS only when a transport
layer such as TLS or IPsec provides confidentiality and security.
QUIC inherently supports encryption (using TLS 1.3), which could
provide a higher level of security. And QUIC supports multiple
streams over a single connection, enhancing throughput and
efficiency. This document defines RADIUS over the QUIC transport
protocol, named RADIUSoQUIC.
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 January 19, 2025.
Copyright Notice
Copyright (c) 2025 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
Yang & Lin, et al. Expires January 19, 2025 [Page 1]
Internet-Draft RADIUS Protocol over QUIC July 2025
(http://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...................................................2
2. Terminology and Definitions....................................3
3. Connection Management..........................................4
3.1. Connection Establishment..................................4
3.2. Connection Termination....................................4
3.2.1. QUIC Connection Termination Process..................4
3.2.2. RADIUSoQUIC Considerations for Connection Termination4
4. Stream Mapping and Usage.......................................5
4.1. Bidirectional Stream between Client and Server............6
5. Endpoint Authentication........................................6
6. Operational Considerations.....................................6
7. IANA Considerations............................................7
8. Security Considerations........................................7
9. References.....................................................7
9.1. Normative References......................................7
9.2. Informative References....................................8
Author's Address.................................................10
1. Introduction
RADIUS (Remote Authentication Dial-In User Service) is a networking
protocol that provides centralized authentication, authorization,
and accounting for users who connect and use a network service. It
is typically used in environments such as Internet service providers
(ISPs), corporate networks, and other places where secure access
management is required.
The RADIUS protocol was originally defined in [RFC2865] as using the
User Datagram Protocol (UDP) for the underlying transport layer.
Since UDP has some limitations (such as unreliable transport, packet
fragmentation, connectionless transport, and lack of congestion
control), the TCP transport is recommended to be used [RFC6613] when
another method such as IPsec [RFC4301] or RADIUS/TLS [RFC6614] is
used to provide additional confidentiality and security of RADIUS in
Yang & Lin, et al. Expires January 19, 2025 [Page 2]
Internet-Draft RADIUS Protocol over QUIC July 2025
inter-server communications scenarios, such as inter-domain
communication between proxies.
QUIC is developed based on the UDP protocol and aims to address
certain limitations of TCP. Compared with the traditional TCP/UDP
protocol used by RADIUS, QUIC provides the following enhancements:
* Improved Security. QUIC inherently supports encryption (using TLS
1.3), which could provide a higher level of security for RADIUS
communications compared to the standard RADIUS protocol that relies
heavily on IPsec or TLS over TCP for encryption.
* Enhanced Performance. QUIC reduces connection establishment time
with its zero-round-trip setup for repeat connections, potentially
speeding up the authentication process significantly.
* Reliability and Robustness. QUIC's congestion control, loss
recovery, and reduced latency features could make RADIUS
communications more reliable, especially over less-stable network
connections.
* Connection Migration. The ability of QUIC to handle connection
migrations seamlessly could enhance user mobility, allowing users to
change networks (e.g., moving from Wi-Fi to cellular) without
disrupting authentication sessions.
* Multiplexing. QUIC's support for multiple streams over a single
connection could enable multiple RADIUS transactions to be processed
simultaneously, enhancing throughput and efficiency.
Therefore, for inter-server communication scenarios that require
secure connections and reliable data transmission, QUIC is a
competitive transport protocol for the message transmission
mechanism of RADIUS Protocol. This document specifies how to use
QUIC as the transport protocol for RADIUS Protocol, named
RADIUSoQUIC.
2. Terminology 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.
In this document, the terms "client" and "server" are used to refer
to the two ends of the QUIC connection. The client actively
initiates the QUIC connection. The terms "RADIUS client" and "RADIUS
Yang & Lin, et al. Expires January 19, 2025 [Page 3]
Internet-Draft RADIUS Protocol over QUIC July 2025
server" are used to refer to the two ends of the RADIUS Protocol
session. Generally, an "RADIUS client" provides an access service
for a user to a network, meanwhile a "RADIUS server" provides one or
more of authentication, authorization, and/or accounting (AAA)
services to a Network Access Server (NAS). In addition, A RADIUS
Proxy acts as a RADIUS server to the NAS, and a RADIUS client to the
RADIUS server.
* Client: The endpoint that initiates a QUIC connection, the RADIUS
client or RADIUS proxy.
* Server: The endpoint that accepts a QUIC connection, the RADIUS
server or RADIUS proxy.
3. Connection Management
3.1. Connection Establishment
QUIC connection establishment is described in [RFC9000]. During
establishing connection, RADIUSoQUIC support is indicated by
selecting the Application-Layer Protocol Negotiation (ALPN)
[RFC7301] token as listed in the IANA Section 7 in the TLS
handshake.
The RADIUS Client or Proxy as client should be the initiator of the
QUIC connection to the RADIUS Server meanwhile the RADIUS Server or
Proxy as server acts as a connection acceptor.
3.2. Connection Termination
3.2.1. QUIC Connection Termination Process
The typical QUIC connection termination process is described in
[RFC9000].
3.2.2. RADIUSoQUIC Considerations for Connection Termination
When an RADIUS session is implemented based on a QUIC connection,
the idle timeout should be disabled or the QUIC max_idle_timeout
should be set appropriately in order to keep the QUIC connection
persistent even if the RADIUS session is idle.
If the QUIC connection is broken or closed, retransmissions over new
connections are permissible. RADIUS request packets that have not
yet received a response MAY be transmitted by a RADIUS client over a
new QUIC connection. Since this procedure involves using a new
source port, the ID of the packet MAY change. If the ID changes, any
Yang & Lin, et al. Expires January 19, 2025 [Page 4]
Internet-Draft RADIUS Protocol over QUIC July 2025
security attributes such as Message-Authenticator MUST be
recalculated.
If a QUIC connection is broken or closed, any cached RADIUS response
packets ([RFC5080], Section 2.2.2) associated with that connection
MUST be discarded. A RADIUS server SHOULD stop the processing of any
requests associated with that QUIC connection. No response to these
requests can be sent over the QUIC connection, so any further
processing is pointless. This requirement applies not only to RADIUS
servers, but also to proxies. When a client's connection to a proxy
server is closed, there may be responses from a home server that
were supposed to be sent by the proxy back over that connection to
the client. Since the client connection is closed, those responses
from the home server to the proxy server SHOULD be silently
discarded by the proxy.
RADIUS clients using QUIC MUST mark a connection DOWN if the network
stack indicates that the connection is no longer active. If the
network stack indicates that the connection is still active, clients
MUST NOT decide that it is down until the application-layer watchdog
algorithm has marked it DOWN ([RFC3539], Appendix A). RADIUS clients
using QUIC MUST NOT decide that a RADIUS server is unresponsive
until all QUIC connections to it have been marked DOWN.
A client should proactively close connections or mark a server as
DOWN due to an administrative decision.
4. Stream Mapping and Usage
QUIC [RFC9000] uses multiple simultaneous streams to carry data in
one direction. QUIC Streams provide a lightweight, ordered byte-
stream abstraction to an application. Streams can be unidirectional
or bidirectional meanwhile streams can be initiated by either the
client or the server. Unidirectional streams carry data in one
direction: from the initiator of the stream to its peer.
Bidirectional streams allow for data to be sent in both directions.
QUIC uses Stream ID to identify the stream. The least significant
bit (0x1) of the stream ID identifies the initiator of the stream
(client with the bit set to 0). The second least significant bit
(0x2) of the stream ID distinguishes between bidirectional streams
(with the bit set to 0) and unidirectional streams [RFC9000].
RADIUS packets include request packets and response packets. RADIUS
request packet is a packet originated by a RADIUS client to a RADIUS
server. For example, Access-Request, Accounting-Request, CoA-
Request, or Disconnect-Request. RADIUS response packet is a packet
sent by a RADIUS server to a RADIUS client, in response to a RADIUS
Yang & Lin, et al. Expires January 19, 2025 [Page 5]
Internet-Draft RADIUS Protocol over QUIC July 2025
request packet. For example, Access-Accept, Access-Reject, Access-
Challenge, Accounting-Response, or CoA-ACK [RFC6613].
4.1. Bidirectional Stream between Client and Server
If RADIUS request packets are carried via transport protocol from
RADIUS client to RADIUS server, RADIUS response packet are needed to
be sent from RADIUS server to RADIUS client in response to the
RADIUS request packets. Therefore, the RADIUS connection should be
bidirectional between Client and Server.
Based on the above description, The RADIUS request messages are
initiated by the Client and the replies are needed from the Server.
So the RADIUS messages MAY be mapped into one bidirectional stream
whose stream type is 0x0 according to section 2.1 of [RFC9000].
5. Endpoint Authentication
RADIUSoQUIC uses QUIC which uses TLS version 1.3 or greater.
Therefore, the TLS handshake process can be used for RADIUSoQUIC
endpoint authentication. A third-party authentication mechanism can
also be applied for RADIUSoQUIC endpoint authentication, such as a
TLS client certificate.
6. Operational Considerations
The decision to use RADIUSoQUIC instead of the TCP-based/UDP-based
mechanism is an operational decision, and an implementation MUST
provide a configuration mechanism to enable RADIUSoQUIC on the
RADIUS session.
As QUIC is a reliable transport, if there is no response to a RADIUS
packet over one QUIC connection, implementations MUST NOT retransmit
that packet over a different QUIC connection to the same destination
IP address and port, while the first connection is in the OKAY state
([RFC3539], Appendix A).
The use of QUIC transport does not change the calculation of
security-related fields (such as the Response-Authenticator) in
RADIUS [RFC2865] or RADIUS Dynamic Authorization [RFC5176].
Calculation of attributes such as User-Password [RFC2865] or
Message-Authenticator [RFC3579] also does not change. In addition,
Clients and servers MUST be able to store and manage shared secrets
based on the key described at the section 2.6 of [RFC3539] (i.e., IP
address, port, transport protocol).
Yang & Lin, et al. Expires January 19, 2025 [Page 6]
Internet-Draft RADIUS Protocol over QUIC July 2025
7. IANA Considerations
This document creates a new registration for the identification of
RADIUSoQUIC in the "Application Layer Protocol Negotiation (ALPN)
Protocol IDs" registry established in [RFC7301].
The "RADIUSoQ" string identifies RADIUSoQUIC:
* Protocol: RADIUSoQUIC
* Identification Sequence: 0x52 0x41 0x44 0x49 0x55 0x53 0x6f 0x51
("RADIUSoQ")
* Specification: This document
In addition, it is requested for IANA to reserve a UDP port TBD for
'RADIUS over QUIC'.
8. Security Considerations
This document replaces the transport protocol layer of RADIUS from
other transport protocols to QUIC. The basic protocol specification
of RADIUS is not modified, and therefore the new security risks are
not introduced to the basic RADIUS protocol. RADIUSoQUIC enhances
transport-layer security for RADIUS session according to [RFC9000].
This document does not require to support third-party authentication
(e.g., backend Authentication) due to the fact that TLS does not
specify this way of authentication. If third-party authentication is
needed, TLS client certificates are recommended to be used here.
9. References
9.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>.
Yang & Lin, et al. Expires January 19, 2025 [Page 7]
Internet-Draft RADIUS Protocol over QUIC July 2025
[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
Accounting (AAA) Transport Profile", RFC 3539, DOI
10.17487/RFC3539, June 2003, <https://www.rfc-
editor.org/info/rfc3539>.
[RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, DOI
10.17487/RFC6613, May 2012, <https://www.rfc-
editor.org/info/rfc6613>.
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"Transport Layer Security (TLS) Encryption for RADIUS",
RFC 6614, DOI 10.17487/RFC6614, May 2012,
<https://www.rfc-editor.org/info/rfc6614>.
[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>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, DOI
10.17487/RFC9000, May 2021, <https://www.rfc-
editor.org/info/rfc9000>.
9.2. Informative References
[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>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication
Dial In User Service (RADIUS) Implementation Issues and
Suggested Fixes", RFC 5080, DOI 10.17487/RFC5080, December
2007, <https://www.rfc-editor.org/info/rfc5080>.
[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>.
Yang & Lin, et al. Expires January 19, 2025 [Page 8]
Internet-Draft RADIUS Protocol over QUIC July 2025
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>.
Yang & Lin, et al. Expires January 19, 2025 [Page 9]
Internet-Draft RADIUS Protocol over QUIC July 2025
Author's Address
Shengnan Yue
China Mobile
Beijing
China
Email: yueshengnan@chinamobile.com
Changwang Lin
New H3C Technologies
Beijing
China
Email: linchangwang.04414@h3c.com
Feng Yang
China Mobile
Beijing
China
Email: yangfeng@chinamobile.com
Yang & Lin, et al. Expires January 19, 2025 [Page 10]