Zusammenfassung

  • RADIUS erlaubte einem Vermittler Änderungen an bestimmten Attributen zur Umsetzung lokaler Richtlinien. Bereits vorhandene Proxy-State-, State- und Class-Attribute waren davon ausgenommen.
  • Ein Proxy konnte einen eigenen Proxy-State hinzufügen und bei der Antwort wieder entfernen. Fremde Werte und ihre relative Reihenfolge musste er bewahren, ihre interne Bedeutung dagegen nicht kennen.
  • Diese begrenzte Erhaltungspflicht machte weder das gesamte Paket unveränderlich noch die gesamte Vermittlerkette vertrauenswürdig. Dafür waren andere Entscheidungen und Nachweise erforderlich.

Die Ausnahme im Spielraum des Vermittlers

Ein Zugangsserver erhält eine Antwort, die auf dem Weg durch einen Proxy verändert worden sein kann. Das klingt zunächst nach einem Sicherheitsfehler. In RADIUS konnte es aber auch zum vorgesehenen Betrieb gehören: Ein Vermittler durfte bestimmte Attribute an lokale Richtlinien anpassen.

Der RFC 2865 vom Juni 2000 ließ diesen Spielraum nicht grenzenlos. Vorhandene Proxy-State-, State- und Class-Attribute durfte der Weiterleitungsserver nicht verändern. Das Protokoll trennte damit einen Bereich eigener Entscheidungen von Informationen, die der Vermittler für andere erhalten musste.

Diese Unterscheidung ist genauer als die Behauptung, ein Proxy müsse jedes Paket unverändert durchreichen. Sie ist auch strenger als die Vorstellung, wer technisch im Weg stehe, dürfe alles neu auslegen. Gerade ein aktiver Vermittler brauchte eine klar bezeichnete Grenze seines Eingriffs.

Proxy-State zeigt, wie diese Grenze funktionierte. Das Attribut enthielt einen privaten Wert eines Vermittlers. Andere Proxys mussten wissen, wie sie diesen Wert behandeln und zurückgeben sollten. Sie mussten nicht wissen, welches interne Problem sein Erzeuger damit löste.

Zwei Nachbarn, zwei Rollen

Im klassischen Ablauf war der Netzwerkzugangsserver der RADIUS-Client, nicht unmittelbar der Mensch am Endgerät. Er schickte eine Anfrage an einen Server. Dieser konnte sie selbst bearbeiten oder nach seiner Konfiguration an einen anderen Server weiterleiten, etwa aufgrund des Authentifizierungsbereichs.

Der weiterleitende Server war gegenüber dem bisherigen Nachbarn ein Server und gegenüber dem nächsten ein Client. Für manche Bereiche konnte er selbst zuständig sein, für andere nur vermitteln. Auch mehrere Vermittler hintereinander waren möglich. Dass dabei Schleifen vermieden werden mussten, blieb eine eigene Aufgabe; Proxy-State berechnete keinen schleifenfreien Weg.

Der informative RFC 2607 vom Juni 1999 beschrieb solche Anordnungen für Roaming zwischen Netzen. Er behandelte weniger Schlüsselbeziehungen, die Anpassung unterschiedlicher Fähigkeiten, Richtlinien und die Verarbeitung von Abrechnungsdaten. Zugleich warnte er ausdrücklich vor einer breiten Internetanwendung unter den damaligen Sicherheitsannahmen.

Ein Vertrauensmodell innerhalb einer Verwaltung ließ sich eben nicht ohne Weiteres auf unabhängige Organisationen ausdehnen. Dass der Text vorhandene Nutzung beschrieb, war keine Zusicherung universeller Sicherheit. Ebenso wenig sind seine Aussagen über die Verbreitung im Jahr 1999 Messwerte für heutige Installationen.

Die fremde Bedeutung blieb fremd

Proxy-State war bereits im RFC 2138 vom April 1997 enthalten. Die Fassung von 2000 erläuterte Weiterleitung und Reihenfolge genauer. Ein Proxy durfte seiner weitergeleiteten Anfrage genau einen eigenen Wert hinzufügen, falls er einen benötigte. Mehr als einer war nicht erlaubt.

Der neue Wert musste hinter vorhandenen Proxy-State-Werten stehen. Deren Inhalt durfte der Proxy nicht ändern; auch die Reihenfolge gleichartiger Attribute war zu erhalten. Seine Protokolloperationen durften nicht von der privaten Bedeutung der Werte abhängen, die frühere Server hinzugefügt hatten.

Damit entstand kein universelles Zustandsformat für alle Vermittler. Das Protokoll überließ die konkrete Nutzung dem Standort oder der Anwendung. Ein Betreiber konnte seine eigene interne Zuordnung wählen, ohne sie allen Nachbarn erklären zu müssen. Gemeinsam waren die Regeln der Behandlung, nicht sämtliche Bedeutungen innerhalb der Werte.

Der empfangende Endserver übernahm die erhaltenen Proxy-State-Werte unverändert und in ihrer Reihenfolge in die Antwort. Dies galt für Access-Accept, Access-Reject und Access-Challenge. Auch eine Ablehnung oder eine weitere Authentifizierungsanforderung musste den Vermittlern ihre Informationen zurückbringen. Die Rückgabe war keine Bestätigung, dass Zugang gewährt worden war.

Nur der eigene Wert wurde herausgenommen

Auf dem Rückweg entfernte ein Proxy den letzten Proxy-State, wenn er zuvor selbst einen hinzugefügt hatte. Aufgrund der Einfügeregel war das sein eigener. Die Werte der früheren Vermittler blieben erhalten und konnten weiter zurücklaufen.

Das ähnelt einem Stapel, der in umgekehrter Reihenfolge abgearbeitet wird. Als Erklärung ist dieses Bild nützlich; als genaue Aussage über den Paketaufbau wäre es zu stark. Der letzte Proxy-State musste nicht das letzte Attribut des gesamten Pakets sein.

RFC 2865 verlangte die Reihenfolge innerhalb eines Attributtyps, aber keine feste Anordnung verschiedener Typen. Empfänger durften auch nicht voraussetzen, dass gleichartige Attribute unmittelbar nebeneinanderstanden. Andere Attribute konnten zwischen zwei Proxy-State-Werten oder hinter dem letzten folgen.

Ein Produkt, das nur seine bevorzugte Anordnung akzeptierte, konnte daher kompatible Variation zum Fehler erklären. Die gemeinsame Regel war weniger umfangreich als ein einheitlicher Paketstil, aber für die Zuordnung strenger: Niemand durfte beim Zurückgeben die Werte anderer Teilnehmer umsortieren oder den falschen entfernen.

Aufbewahren statt weitertragen

Eine weitere Wahlmöglichkeit begrenzte, was sich aus Proxy-State über einen Weg ableiten ließ. Ein Vermittler durfte bereits empfangene Werte in der weitergeleiteten Anfrage weglassen. Dann musste er sie allerdings wieder an die Antwort anhängen, bevor er diese seinem Client zurückgab.

Er konnte fremde Informationen also vorübergehend selbst aufbewahren, statt sie bis zum Endserver mitzuschicken. Die äußere Verpflichtung blieb dieselbe: Was vom vorherigen Teilnehmer zurückzuerwarten war, musste diesem korrekt zurückgegeben werden.

Eine fehlende Darstellung auf dem nächsten Leitungsabschnitt bewies deshalb noch keinen Verlust. Ein zurückgekehrter Wert bewies umgekehrt nicht, dass er den Endserver erreicht hatte. Das Attribut war kein vollständiges Protokoll aller besuchten Stationen. Für eine Prüfung musste die richtige Grenze betrachtet werden: Empfang und Rückgabe an den jeweiligen Client.

Die Wahl der Aufbewahrung war keine kostenlose Freiheit. Der Proxy musste die zurückzuholenden Werte noch kennen, wenn die Antwort eintraf. Wie er sie speicherte, blieb intern. Dass er sie wiederherstellte, war Teil des gemeinsamen Vertrags.

Ein Binärwert ist kein zu bereinigender Text

Proxy-State bestand aus einer Folge von Oktetten. Typ und Länge bezeichneten das Attribut; die Länge begrenzte den Inhalt. Ein Nulloktett im Wert durfte nicht wie das Ende einer gewöhnlichen Zeichenkette behandelt werden. Ebenso konnten das Entfernen von Leerzeichen oder eine Änderung der Schreibweise Daten beschädigen, deren Bedeutung nur dem Erzeuger bekannt war.

„Undurchsichtig“ bedeutete dabei nicht verschlüsselt. Es beschrieb, dass ein anderer Vermittler die private Kodierung nicht als eigene Anweisung auslegen sollte. Ein Verbot der Interpretation verbirgt keine Bytes vor einem Teilnehmer, der sie verarbeiten kann, und verhindert allein keine böswillige Manipulation.

Das RADIUS-Register von IANA gibt State, Class und Proxy-State die gemeinsamen Attributnummern 24, 25 und 33. Dieser Bezugspunkt hilft beim Erkennen der Typen. Er registriert nicht die private Zustandsorganisation jedes Betreibers und bescheinigt nicht den erfolgreichen Verlauf einer konkreten Anfrage.

Gleiche Undurchsichtigkeit, unterschiedliche Lebensdauer

State konnte eine laufende Authentifizierung zusammenhalten: Der Server lieferte einen Wert mit einer Herausforderung, der Client gab ihn in der folgenden Anfrage zurück. Class konnte aus einer Zugangsbestätigung in Accounting-Anfragen weitergetragen werden; die Grundspezifikation empfahl dies unverändert, wenn Accounting unterstützt wurde. Proxy-State gehörte dagegen zum Rückweg eines Vermittlers und wurde von diesem entfernt.

Der RFC 5080 vom Dezember 2007 stellte klar, dass eine neue oder neu begonnene Authentifizierung nicht einfach den State der alten Unterhaltung übernehmen durfte. Derselbe Benutzer und derselbe Port machten aus zwei Vorgängen nicht automatisch einen einzigen fortdauernden Vorgang.

Auch eine Accounting-Bestätigung hatte ihre eigene Bedeutung. Nach dem informativen RFC 2866 vom Juni 2000 setzte Accounting-Response voraus, dass eine Anfrage empfangen und aufgezeichnet worden war. Reiner Paketempfang genügte nicht. Vermittler konnten jedoch unterschiedliche Verantwortung für Speicherung und Weiterleitung übernehmen. Eine lokale Bestätigung war deshalb nicht ohne Weiteres der Nachweis, dass sämtliche beteiligten Organisationen bereits dieselbe Aufzeichnung besaßen.

Diese Unterschiede sind nicht bloß Benennungsfragen. Wer alle drei Attribute zu einem allgemeinen Benutzer- oder Sitzungsschlüssel zusammenfasst, kann Informationen zu lange aufbewahren, zu früh entfernen oder aus der falschen Bestätigung eine weitreichende Schlussfolgerung ziehen.

Ein gültiger Nachbar war nicht die ganze Kette

Im ursprünglichen Austausch prüfte der Proxy den Antwortauthentifikator anhand des Geheimnisses, das er mit seinem entfernten Nachbarn teilte. Nach erfolgreicher Prüfung und Bearbeitung des eigenen Zustands stellte er den Identifier der ursprünglichen Client-Anfrage wieder her und berechnete den Authentifikator für die Rückgabe an diesen Client neu.

Es gab also kein einziges unverändert authentifiziertes Paket, das jede Verwaltungsgrenze durchlief. Die Prüfung belegte etwas über die unmittelbare Beziehung. Sie belegte nicht allein, dass jeder frühere Vermittler jede Entscheidung unverändert gelassen hatte.

Spätere Schutzverfahren änderten die Sicherheit solcher Beziehungen, nicht diese logische Grenze. Der experimentelle RFC 6614 führte im Mai 2012 RADIUS über TLS aus; Vermittler konnten die von ihnen verarbeiteten Nachrichten weiterhin einsehen. Der ebenfalls experimentelle RFC 9765 definierte im April 2025 RADIUS/1.1 für TLS und DTLS und entfernte dort die alten paketbezogenen Verfahren auf Grundlage von MD5 und gemeinsamen Geheimnissen.

Die Darstellung der älteren Verfahren ist keine heutige Einsatzempfehlung. Die neuen Dokumente beweisen umgekehrt keine flächendeckende Einführung. Ein Proxy kann die Verbindungen auf seinen beiden Seiten unabhängig aushandeln. Ein geschützter Abschnitt sagt daher nicht alles über den nächsten und noch weniger über alle Richtlinienentscheidungen der Kette aus.

Proxy-State teilte die Arbeit an einer engeren Stelle. Wer vermittelte, durfte handeln, aber nicht jede fremde Information vereinnahmen. Der gemeinsame Vertrag bestimmte, was erhalten und zurückgegeben werden musste. Er machte aus einer privaten Zustandsmarke weder eine allgemeine Anweisung noch ein Mandat über alle Teilnehmer.