Zusammenfassung

  • RADIUS/1.1 gilt nur, wenn eine TLS- oder DTLS-Verbindung per ALPN radius/1.1 auswählt; erst dann entfallen das RADIUS Shared Secret sowie MD5-basierte Paketauthentisierung und Attributverschleierung auf diesem Hop.
  • RFC-Veröffentlichung, Softwareunterstützung, Angebot, Auswahl, Pflicht und Abschaltung des Altprofils sind verschiedene Zustände und müssen für jeden notwendigen Hop getrennt belegt werden.

Eine Spezifikation mit Gedächtnis

RFC 9765 beginnt mit einer ungewöhnlich offenen Rückschau. Als RADEXT RADIUS über TLS und DTLS definierte, blieben Shared Secret und MD5-Verarbeitung im Paket erhalten. TLS sollte die bestehende Kodierung und Prüfung wie eine Hülle umgeben. So konnten Implementierungen einen geschützten Transport hinzufügen, ohne gleichzeitig ihre komplette Paketlogik umzustellen. DeKok schreibt, diese Entscheidung sei rückblickend wahrscheinlich falsch gewesen, und vermerkt seine eigene Beteiligung.

Die frühere Wahl war nicht grundlos. Sie senkte das Koordinationsrisiko zwischen bereits eingesetzten Clients und Servern. Ihre Folgekosten entstanden später: TLS bot bereits Vertraulichkeit und Integrität, während RADIUS darunter weiterhin einen zweiten Schutzmechanismus mit einem problematischen Digest betrieb. In Umgebungen, die bekannte schwache Verfahren grundsätzlich ausschließen, wurde diese Redundanz zum Prüf- und Beschaffungshindernis.

DeKoks IETF-Profil datiert seinen Einstieg in RADIUS auf 1997 und den Beginn von FreeRADIUS auf 1999. Das FreeRADIUS-Projekt pflegt einen laufenden Policy-Server, Bibliotheken und Integrationskomponenten. Diese Nähe zum Betrieb erklärt, warum die Korrektur Rückwärtskompatibilität nicht ignoriert. Trotzdem ist RFC 9765 kein Privatdekret: Er ist ein Experimental-Dokument des IETF, öffentlich geprüft und zur Implementierung und Bewertung veröffentlicht.

Welche Aufgabe die Transportschicht übernimmt

RFC 2865 beschreibt RADIUS mit einem gemeinsamen Geheimnis zwischen Client und Server. Es fließt in die Absicherung von Transaktionen ein; Werte wie User-Password werden mit einer MD5-basierten Konstruktion verborgen. RFC 6614 und RFC 7360 brachten RADIUS auf TLS beziehungsweise DTLS, ließen diese Paketmechanismen im historischen RADIUS/TLS jedoch bestehen.

RADIUS/1.1 verankert den Wechsel im TLS-Handshake. Nach dem ALPN-Verfahren aus RFC 7301 bietet der Client Namen von Anwendungsprotokollen an, und der Server wählt einen gemeinsamen Namen. Nur die Auswahl radius/1.1 aktiviert das Profil; außerdem ist TLS 1.3 oder neuer erforderlich.

Auf dieser Verbindung wird das RADIUS Shared Secret nicht mehr verwendet. Der Raum von Request und Response Authenticator wird zu einem undurchsichtigen Token für die Zuordnung von Anfrage und Antwort. Identifier verliert seine alte Funktion. Message-Authenticator wird nicht gesendet. Zuvor mit MD5 verschleierte Attribute liegen in ihrer normalen Kodierung innerhalb des von TLS geschützten Kanals.

Vertrauen verschwindet damit nicht. Es wandert in die Authentisierung und Autorisierung des TLS-Peers, in Zertifikate, Schlüsselverwaltung, Bibliotheksupdates und die korrekte ALPN-Auswahl. Wer die doppelte Kryptografie entfernt, muss den verbleibenden Schutz besser betreiben und beobachten.

Alte Form, neuer Verbindungszustand

Das Profil behält bewusst viel bei. Der Header bleibt gleich groß, Code und Length behalten ihre Bedeutung, einfach kodierte Attribute bleiben semantisch gleich, und die bestehenden TLS- und DTLS-Ports werden weitergenutzt. RFC 9765 spricht deshalb von einem Transportprofil statt von einem vollständig neuen Protokoll.

Die ähnliche Form darf jedoch keine Vermischung der Versionen rechtfertigen. 1.0 und 1.1 interpretieren einzelne Felder und Prüfungen anders. Werden auf einer Verbindung die falschen Regeln angewendet, verwerfen Server die meisten Anfragen oder Clients alle Antworten. Das verhindert eine leise Fehlakzeptanz, erzeugt aber weiterhin Ausfälle, Wiederholungen und Diagnosearbeit.

Auch die Aussage über MD5 hat eine Grenze. CHAP- oder MS-CHAP-Daten können als undurchsichtige Attribute transportiert werden. RADIUS/1.1 entfernt MD5 aus dem Schutz des RADIUS-Pakets auf diesem Hop; es modernisiert nicht automatisch jedes darin transportierte Authentisierungsverfahren oder jedes Backend.

Hinter jedem Proxy beginnt eine neue Prüfung

RADIUS-Ketten können mehrere Proxys und Roaming-Partner umfassen. Der Access-Client kann mit dem ersten Server 1.1 aushandeln, während der nächste Hop historisches RADIUS/TLS, UDP oder eine andere erlaubte Konfiguration nutzt. Nur die beiden Parteien einer Verbindung kennen deren Profil. Aus dem ersten sicheren Hop folgt keine Ende-zu-Ende-Aussage.

ALPN liefert deshalb eine nützliche lokale Evidenz. Ohne das Signal radius/1.1 darf die Implementierung das neue Profil nicht annehmen. Für Produkte, die beide Varianten beherrschen, empfiehlt der RFC zunächst die Zulassung von radius/1.0 und radius/1.1. Nach Prüfung beider Enden und beobachteter Auswahl kann der Betreiber 1.1 verlangen und die Verbindung überwachen. Bei Störungen ist eine vorübergehende Rückkehr in den Dualbetrieb möglich, bis die Ursache behoben ist.

Genau diese Sicherheitsschleuse kann zur Dauereinrichtung werden. Unterstützung heißt noch nicht Angebot; Angebot heißt nicht Auswahl; Auswahl heißt nicht Pflicht; und Pflicht auf einem Hop sagt nichts über den folgenden aus.

Zustand Nachweis
Unterstützt Client, Server und TLS-Version erfüllen die Profilanforderungen.
Angeboten Der Client sendet den ALPN-Namen im realen Handshake.
Ausgewählt Produktionstelemetrie zeigt radius/1.1.
Erzwungen Ein Gegenüber mit ausschließlich 1.0 wird kontrolliert abgewiesen.
Altweg geschlossen Historische Profile und ungeschützte Transporte sind im definierten Hop nicht mehr zulässig.

Eine Migrationsquote ohne diese Zustandsunterscheidung misst Verfügbarkeit von Funktionen, nicht deren Nutzung.

DeKoks Rolle ohne Heldenerzählung

InkBridge bezeichnet DeKok als Schöpfer und Leiter von FreeRADIUS. Das belegt seine Nähe zum Thema, macht ihn aber nicht zum alleinigen Erfinder oder Eigentümer von RADIUS. Frühere RFC-Autoren, RADEXT und IETF, TLS-Implementierer, Hersteller, Identitätsteams und Betreiber jedes Proxy-Hops kontrollieren jeweils einen Teil des Ergebnisses.

Interessant ist seine Form der Korrektur: Er benennt den früheren Kompromiss, bewahrt nützliche Paketkontinuität, überträgt die Schutzaufgabe an die ohnehin zuständige Schicht und schafft einen ausgehandelten Messpunkt. Der Experimental-Status lässt offen, wie breit diese Lösung trägt. Praktische Autorität entsteht erst aus verfügbarer Implementierung, nachgewiesener Auswahl und der Fähigkeit, den alten Pfad ohne Dienstverlust zu schließen.

Quellen