RADIUS EXTensions (radext) Internet Drafts

	RADIUS ALPN and removing MD5
	draft-ietf-radext-radiusv11-04.txt   Date: 26/02/2024   Authors: Alan DeKok   Working Group: RADIUS EXTensions (radext)	This document defines Application-Layer Protocol Negotiation Extensions for use with RADIUS/TLS and RADIUS/DTLS. These extensions permit the negotiation of an additional application protocol for RADIUS over (D)TLS. No changes are made to RADIUS/UDP or RADIUS/TCP. The extensions allow the negotiation of a transport profile where the RADIUS shared secret is no longer used, and all MD5-based packet signing and attribute obfuscation methods are removed. When this extension is used, the previous Authenticator field is repurposed to contain an explicit request / response identifier, called a Token. The Token also allows more than 256 packets to be outstanding on one connection. This extension can be seen as a transport profile for RADIUS, as it is not an entirely new protocol. It uses the existing RADIUS packet layout and attribute format without change. As such, it can carry all present and future RADIUS attributes. Implementation of this extension requires only minor changes to the protocol encoder and decoder functionality. The protocol defined by this extension is named "RADIUS version 1.1", or "RADIUS/1.1".
	RADIUS and TLS-PSK
	draft-ietf-radext-tls-psk-09.txt   Date: 29/02/2024   Authors: Alan DeKok   Working Group: RADIUS EXTensions (radext)	This document gives implementation and operational considerations for using TLS-PSK with RADIUS/TLS (RFC6614) and RADIUS/DTLS (RFC7360). The purpose of the document is to help smooth the operational transition from the use of the insecure RADIUS/UDP to the use of the much more secure RADIUS/TLS.
	(Datagram) Transport Layer Security ((D)TLS Encryption for RADIUS
	draft-ietf-radext-radiusdtls-bis-01.txt   Date: 18/04/2024   Authors: Jan-Frederik Rieckers, Stefan Winter   Working Group: RADIUS EXTensions (radext)	This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP or Datagram Transport Layer Security (DTLS) over UDP as the transport protocol. This enables encrypting the RADIUS traffic as well as dynamic trust relationships between RADIUS servers. The specification obsoletes the experimental specifications in RFC 6614 (RADIUS/TLS) and RFC 7360 (RADIUS/DTLS) and combines them in this specification.
	Deprecating Insecure Practices in RADIUS
	draft-ietf-radext-deprecating-radius-00.txt   Date: 07/11/2023   Authors: Alan DeKok   Working Group: RADIUS EXTensions (radext)	RADIUS crypto-agility was first mandated as future work by RFC 6421. The outcome of that work was the publication of RADIUS over TLS (RFC 6614) and RADIUS over DTLS (RFC 7360) as experimental documents. Those transport protocols have been in wide-spread use for many years in a wide range of networks. They have proven their utility as replacements for the previous UDP (RFC 2865) and TCP (RFC 6613) transports. With that knowledge, the continued use of insecure transports for RADIUS has serious and negative implications for privacy and security. This document formally deprecates using the User Datagram Protocol (UDP) and of the Transmission Control Protocol (TCP) as transport protocols for RADIUS. These transports are permitted inside of secure networks, but their use in those networks is still discouraged. For all other environments, the use of secure transports such as IPsec or TLS is mandated. We also discuss additional security issues with RADIUS deployments, and give recommendations for practices which increase security and privacy.
	Reverse CoA in RADIUS
	draft-ietf-radext-reverse-coa-00.txt   Date: 07/11/2023   Authors: Alan DeKok, Vadim Cargatser   Working Group: RADIUS EXTensions (radext)	This document defines a "reverse change of authorization (CoA)" path for RADIUS packets. This specification allows a home server to send CoA packets in "reverse" down a RADIUS/TLS connection. Without this capability, it is impossible for a home server to send CoA packets to a NAS which is behind a firewall or NAT gateway. The reverse CoA functionality extends the available transport methods for CoA packets, but it does not change anything else about how CoA packets are handled.
	Status-Realm and Loop Prevention for the Remote Dial-In User Service (RADIUS)
	draft-ietf-radext-status-realm-00.txt   Date: 04/03/2024   Authors: Margaret Cullen, Alan DeKok, Mark Donnelly, Josh Howlett   Working Group: RADIUS EXTensions (radext)	This document describes extension to the Remote Authentication Dial- In User Service (RADIUS) protocol to allow participants in a multi- hop RADIUS proxy fabric to check the status of a remote RADIUS authentication realm, gain visibility into the path that a RADIUS request will take across the RADIUS proxy fabric, and mitigate or prevent RADIUS proxy loops.

data-group-menu-data-url="/group/groupmenu.json"> Skip to main content