Zusammenfassung

  • Der ein Byte große Identifier wählte nur eine noch offene Anfrage aus. Anschließend prüfte der Client den Response Authenticator mit dem 16 Byte großen Request Authenticator genau dieser Anfrage und dem gemeinsamen Geheimnis des Hops.
  • Bei unveränderter Wiederholung an denselben Server blieben Identifier, Request Authenticator und Quellport gleich. Der Server erkannte das Duplikat und sandte seine gespeicherte Antwort erneut; geänderte Attribute eröffneten eine neue Anfrage.

Der kleine Namensraum war auf Zeit gebaut

Im Januar 1997 erschien mit RFC 2058 die erste RADIUS-Spezifikation. RFC 2138 ersetzte sie bereits im April, RFC 2865 beschrieb 2000 das klassische Verfahren neu. Der Identifier „hilft“ in diesen Regeln bei der Zuordnung. Er behauptet nicht, jede Anmeldung dauerhaft zu benennen.

Ein Client darf einen Wert für dieselbe Quelladresse und denselben UDP-Port erst wieder benutzen, wenn eine gültige Antwort eingetroffen oder die Anfrage abgelaufen ist. RFC 5080 empfiehlt eine LRU-Vergabe, damit die Wiederverwendung möglichst weit auseinanderliegt.

Identifier 91 bezeichnet folglich den derzeit offenen Gebrauch von 91 in einem bestimmten Endpunktkontext. Nach seinem Abschluss kann dieselbe Zahl eine andere Anfrage meinen. Das Protokoll brauchte keine zentrale Nummernvergabestelle; es brauchte eine enge Lebensdauer.

Die lange Spur der ursprünglichen Frage

Ein Access-Request enthält einen 16 Byte großen Request Authenticator. Bei einem neuen Identifier muss er wechseln; über die Lebensdauer des gemeinsamen Geheimnisses soll er unvorhersehbar und einmalig sein.

Wiederholt sich der Wert mit demselben Geheimnis, kann eine abgefangene alte Antwort erneut nützlich werden. Ist ein künftiger Wert vorhersehbar, lässt sich womöglich schon vor der echten Anfrage Material für eine falsche Antwort erzeugen.

Access-Accept, Access-Reject und Access-Challenge kopieren den Identifier. Ihr Response Authenticator wird dagegen aus Code, Identifier, Länge, Antwortattributen, dem Request Authenticator der ursprünglichen Anfrage und dem gemeinsamen Geheimnis berechnet.

Der Client sucht mit dem Byte nach einem offenen Kandidaten und prüft dann gegen dessen 16 Byte. Eine verspätete Antwort mit derselben Zahl, aber aus einer früheren Verwendung, passt nicht zum aktuellen Request Authenticator und wird verworfen.

Das kurze Feld beschleunigt die Suche. Der größere Wert bindet Antwort und Frage. Das Geheimnis authentifiziert den Nachbarn auf diesem Hop. Der offene Zustand begrenzt die Gültigkeit. Erst zusammen entsteht die Transaktionsidentität.

Eine Wiederholung musste dieselbe Anfrage bleiben

Klassisches RADIUS lief über UDP. Eine Zugangsentscheidung darf Sekunden dauern; veraltete Daten, die ein zuverlässiger Transport erst Minuten später zustellt, helfen nicht. Deshalb speicherte der Client die Anfrage oberhalb des Transports, führte eigene Timer und konnte erneut senden oder einen anderen Server wählen.

Sendet er unveränderte Attributes an denselben Server, muss er Identifier, Request Authenticator und Quellport beibehalten. Das zweite Datagramm ist ein weiterer Zustellversuch derselben Frage.

Ändert sich ein Attribute, müssen auch Identifier und Request Authenticator neu sein. Ein zusätzliches Event-Timestamp, eine neue Passwortantwort oder ein anderer Dienstwunsch ist keine Auffrischung. Dass derselbe Mensch gemeint ist, macht die übermittelten Behauptungen nicht identisch.

Diese harte Grenze macht aus „derselbe Versuch“ eine prüfbare Eigenschaft statt einer Absichtserklärung.

Der Server wiederholte das Ergebnis, nicht die Arbeit

RFC 5080 verlangt, doppelte Access-Requests zu erkennen und die versandte Antwort kurz zu speichern. Trifft das Duplikat nach Access-Accept, Access-Reject oder Access-Challenge ein, sendet der Server genau diese Antwort noch einmal, ohne die Anfrage erneut zu verarbeiten. Kommt es während der laufenden Verarbeitung, wird es still verworfen.

Eine zweite Ausführung kann mehr als Rechenzeit kosten. Sie kann einen Zähler erhöhen, einen Einmalwert verbrauchen, einen Login doppelt protokollieren oder ein Backend erneut ändern. Ein verlorenes Antwortpaket darf nicht zwei geschäftliche Wirkungen erzeugen.

Zum Cache-Schlüssel gehören Quelladresse, Quellport, Identifier, empfangender Socket und Request Authenticator. Die Einträge leben typischerweise fünf bis dreißig Sekunden. Stimmen die ersten vier Merkmale überein, nicht aber der Request Authenticator, wird der alte Eintrag ungültig. Die sichtbare Zahl darf den entscheidenden Unterschied nicht verdecken.

Der Cache verleiht dem Urteil keine Dauer. Er repariert eine mögliche Transportlücke innerhalb des Zeitfensters, in dem der Client dieselbe Anfrage noch wiederholen kann.

Eine geänderte Frage entzog der alten Antwort das Mandat

Während der erste Server noch arbeitet, kann ein Client geänderte Attributes mit neuem Transaktionsmaterial senden. Die spätere Antwort des ersten Vorgangs kann für den alten Request Authenticator vollständig gültig sein. Für die aktuelle Anfrage ist sie trotzdem nicht zuständig.

Der Client verarbeitet die erste gültige Antwort auf eine noch offene Anfrage. Danach gelten weitere Antworten als unaufgefordert und werden verworfen. Kryptografische Gültigkeit ersetzt keine aktuelle Zuständigkeit.

Access-Challenge zeigt dasselbe über mehrere Runden. Der Server kann State zurückgeben und eine weitere Eingabe verlangen. Der NAS sendet einen neuen Access-Request mit neuem Identifier und Request Authenticator, führt State fort und übermittelt die neue Antwort. State verbindet die Sitzung; es verschmilzt ihre Runden nicht zu einer Transaktion.

Alternative Server können bei abweichender Daten- oder Policy-Lage zu anderen Ergebnissen kommen. Die erste gültige Antwort schließt den Vorgang beim Client. Die Verantwortung für konsistente Regeln bleibt beim Betreiber.

Ein Accept konnte lokale Fähigkeit nicht herbeizaubern

Kann der NAS einen im Access-Accept genannten Dienst nicht liefern, muss er die Antwort nach RFC 2865 wie einen Reject behandeln. Eine gültige Nachricht erzeugt weder eine fehlende VLAN-Konfiguration noch ein nicht unterstütztes Protokoll oder eine unmögliche Route.

Der historische Response Authenticator belegt innerhalb seiner Grenzen, dass der Inhaber des Hop-Geheimnisses diese Antwort an die offene Anfrage gebunden hat. Er beweist nicht unabhängig die Identität des Menschen, die Richtigkeit der Autorisierung, den Abschluss der Buchführung oder die tatsächliche Dienstbereitstellung.

Die Ausführung bleibt eine lokale Kontrollfläche mit eigener Evidenz.

Am Proxy endete ein Beweis und begann ein neuer

Ein RADIUS-Proxy prüft die Antwort des entfernten Servers mit dem Geheimnis des nachgelagerten Hops. Er entfernt seinen letzten Proxy-State-Eintrag, stellt den vom vorherigen Client erwarteten Identifier wieder her und berechnet mit dem Geheimnis des vorgelagerten Hops einen neuen Response Authenticator.

Der NAS erhält keine durchgehende Signatur des Home-Servers. Er erhält einen Nachweis seines direkten RADIUS-Peers. Proxy-State führt die Antwort durch die Kette zurück und bleibt für andere undurchsichtig, erteilt aber keine Zugangsberechtigung.

Ein Langzeitprotokoll mit „ID 91, Accept“ ist daher fast wertlos. Nötig sind Hop, Adressen, Ports, Socket, offene Dauer, geschützter Fingerabdruck des Request Authenticators, Anfrageform, Cache-Aktion, Proxy-Pfad und lokal angewandte Wirkung. Geheimnisse und sensible Credentials gehören nicht in normale Logs.

Gleich getaktete Zuverlässigkeit konnte zum Ausfall werden

RFC 5080 beschreibt Clients mit festen Intervallen von einer Sekunde oder weniger und ohne Stau-Backoff. Nach einem Stromausfall können Tausende NAS zugleich starten, zugleich ablaufen und zugleich erneut senden. Die Wiederherstellung überlastet dann den Authentifizierungsdienst.

Das empfohlene Verfahren vergrößert die Frist, fügt Jitter hinzu und begrenzt Intervall, Versuche und Gesamtdauer. Der Jitter muss nur Geräte entkoppeln und braucht keine kryptografische Qualität. Die Unvorhersehbarkeit des Request Authenticators schützt gegen Angriffe. Beides darf nicht wegen des gemeinsamen Wortes „zufällig“ auf denselben schwachen Generator reduziert werden.

Unter Last kann der Server Anfragen mit gültigem State bevorzugen, damit begonnene Gespräche enden. Ein Proxy kann Antworten vor neuen Anfragen behandeln. Das ist Stabilitätssteuerung, keine Rangordnung von Zugangsrechten.

TLS verschob später die Schutzgrenze

RFC 6614 transportierte RADIUS 2012 über TLS/TCP, behielt aber die historische MD5-Paketverarbeitung und das feste Geheimnis radsec innerhalb des Tunnels. Der Transport schützte die Verbindung, während die alten Felder weiterarbeiteten.

RFC 9765 definierte 2025 RADIUS/1.1. Nur wenn zwei Peers das Profil per ALPN über TLS 1.3 oder neuer aushandeln, entfallen RADIUS-Geheimnis und MD5-Verarbeitung. Die 16 Byte werden zu einem undurchsichtigen Token, das auch die Zuordnungsfunktion des alten Identifiers übernimmt.

Hier liegt die Grenze zum bereits veröffentlichten RADIUS/1.1-Artikel. Das Profil ändert RADIUS/UDP nicht und modernisiert keine gesamte Proxy-Kette automatisch. Für diese Geschichte zeigt es lediglich: Auch wenn der Transport Authentizität trägt, bleibt eine ausreichend große, kontextgebundene Anfragekennung nötig.

Historische Beschreibung ist keine MD5-Empfehlung

Der klassische Response Authenticator macht MD5 nicht zu einer zeitgemäßen Wahl. Er bestätigt weder gute Policy noch verbuchte Accounting-Daten, ehrliche Proxies oder übertragenen Dienst. RFCs belegen die spezifizierte Mechanik, nicht Produktkonformität oder heutigen Einsatzumfang.

Die bleibende Lehre betrifft den Umfang von Evidenz. Ein kurzer Name kann genügen, solange Reichweite, Zeit und ergänzender Kontext erhalten bleiben. Gefährlich wird er, wenn ein Archiv das Byte bewahrt und alles verwirft, was ihm Bedeutung gab.