Zusammenfassung

  • RFC 9813 verwendet bei RADIUS über TLS-PSK die PSK-Identität statt der Quell-IP als Suchschlüssel. Die Identität kommt jedoch unverschlüsselt und vor der Authentisierung an; sie wählt nur eine mögliche Beziehung aus.
  • Belastbare Nachweise halten globale Netzfreigabe, Eingabeprüfung, Tabellengeneration, beziehungsspezifischen Quellbereich, PSK-Prüfung, RADIUS-Integrität, lokale Richtlinie, Wiederaufnahme und erbrachten Zugang auseinander.

Im klassischen RADIUS-Modell wählte die Quelladresse eine Client-Zeile. Der Server fand dort das Shared Secret und oft auch Regeln für das Gerät. Solange Adressen stabil und exklusiv waren, konnten Ort, Beziehung und Richtlinie wie eine einzige Eigenschaft wirken.

NAT lässt mehrere Clients unter derselben sichtbaren Adresse erscheinen. Mobilität und Umnummerierung verteilen einen Client auf mehrere Adressen. Größere Netze stellen Erreichbarkeit her, aber keine eindeutige Beziehung; kopierte Zeilen für mögliche Adressen werden schnell zu veraltetem Zustand.

Der im Juli 2025 als BCP 243 veröffentlichte RFC 9813 ergänzt die Betriebsregeln für TLS-PSK bei RADIUS über TLS und DTLS. Die PSK Identity ersetzt die Quell-IP als Client-Identifier. „Ersetzt“ betrifft nur den Lookup: Die Adresse bleibt Filter, die Identität bleibt bis zum Schlüsselnachweis untrusted, und ein TLS-Erfolg ersetzt weder RADIUS-Autorisierung noch NAS-Ausführung.

Der Selektor ist vor seinem Absender da

Der Server muss zuerst erfahren, welchen PSK er prüfen soll. Daher sendet der Client eine Identität im TLS-Austausch. Sie ist im Klartext sichtbar und stammt zu diesem Zeitpunkt von einem nicht authentisierten Peer. Jeder erreichende Absender kann eine plausible Zeichenfolge erfinden. Bedeutungsvolle Namen verraten zudem Organisation oder Standort; ein opaker Benutzerteil oder eine NAI-Form verringert die Offenlegung, wird dadurch aber nicht geheim.

Ein Treffer beweist nur, dass gespeicherter Zustand zu einem String passt. Er beweist weder Schlüsselbesitz noch erlaubte Herkunft, zulässige RADIUS-Nachrichten oder ein bestimmtes physisches Gerät. Wer „bekannte Identität“ als „authentisierter Client“ protokolliert, verschiebt den alten IP-Irrtum in ein neues Feld.

Vor dem Lookup liegt eine feindliche Eingabeschnittstelle

Die Identität kann ungültiges UTF-8, NUL, Metazeichen für SQL, LDAP, REST oder Shell und bis zu 65.535 Oktette enthalten. Direkte String-Konkatenation macht aus dem Protokollselektor eine Injection-Fläche. Sichere Verarbeitung begrenzt die Länge, klassifiziert den Namensraum, validiert die Darstellung, wendet versionierte Normalisierung an, escaped für die konkrete Schnittstelle und schließt bei Fehlern die Verbindung.

Normalisierung darf zwei administrative Identitäten nicht unbemerkt vereinigen. Der Nachweis enthält einen begrenzten Hash der Rohdaten, Prüfergebnis, kanonischen Suchwert, Regelversion und ausgewählte Zeile. Ablehnungsgrund, Parsergeneration und beobachteter Bereich reichen zur Analyse, ohne Angreifertext in jedes Log zu kopieren.

Die Zeile gehört einer Client-Server-Beziehung

Die logische TLS-PSK-Tabelle kann erlaubte Netzbereiche, Identität, PSK, alternative TLS-Credentials und Zertifikatspflichten binden. Danach wirkt die RADIUS-Client-Policy weiter. Inventareinheit ist deshalb nicht die globale Identität eines Geräts, sondern eine konkrete Beziehung zu einem Server.

Ein Gerät kann für Primär- und Ersatzserver getrennte Beziehungen führen. RFC 9813 verlangt Unterstützung für eindeutige Identität und eindeutigen PSK je möglicher Beziehung. Wiederverwendung bleibt eine lokale Wahl, doch sie vergrößert die symmetrische Autorität: Bei zwanzig Clients mit einem PSK kann jeder denselben Nachweis erzeugen; die Sperre eines kompromittierten Clients betrifft alle. Ein clientseitiger Leak kann auch Server-Imitation erlauben, weshalb PSK zwischen unabhängigen Organisationen problematisch ist.

Die gemeinsame Spezifikation fordert Isolierbarkeit, während Betreiber Rotation und Topologie verantworten. Das entspricht Minimum Initial Specification.

Die IP-Adresse wird zur eigenständigen Koordinate

Vor der Identitätsverarbeitung lehnt der Server Quellen außerhalb allgemein erlaubter Bereiche ab. Nach Auswahl der Beziehung prüft er deren spezifische Quellbereiche. Die erste Stufe begrenzt Exposition, die zweite fragt, ob diese Beziehung vom beobachteten Ort erscheinen darf.

Innerhalb dieser Grenzen können mehrere Identitäten eine NAT-Adresse teilen und eine Identität mehrere Adressen nutzen. Die Netzprüfung belegt den beobachteten Ort; die PSK-Prüfung belegt den Besitz eines symmetrischen Credentials. Beide zusammen identifizieren noch keine Person oder Hardware.

TLS-PSK und RADIUS Shared Secret sind getrennte Rollen

Der TLS-PSK authentisiert den Kanal. Das RADIUS Shared Secret dient Prüfungen des eingebetteten Protokolls. RFC 9813 verbietet denselben Wert und verlangt Ablehnung einer solchen Konfiguration. Auch über TLS 1.3 und ältere Versionen darf derselbe PSK nicht wandern. RFC 9258 bindet importierte PSKs an Version, KDF und Kontext.

Eine Oberfläche mit nur einem Feld „Standortgeheimnis“ verwischt diese Grenzen. Rollen und nicht geheime Generationen müssen getrennt sichtbar sein; Gleichheit ist ohne Key-Logging zu verhindern. Ein grüner Handshake ersetzt keine RADIUS-Prüfung oder Autorisierungsentscheidung.

Rotation bedeutet eine neue Beziehungsgeneration

Weil die Identität den PSK findet, müssen beide gemeinsam wechseln. Ein Key-Tausch unter unverändertem Namen macht veraltete Clients, fehlerhafte Verteilung und Angriffe ununterscheidbar. Kontrollierte Rotation erzeugt eine neue Generation, beobachtet deren erste Nutzung, begrenzt die Überlappung, erfasst die letzte Nutzung der alten und deaktiviert sie. Verteilung ist nicht Abschluss; Entzug alter Autorität ist es.

„Zuletzt gesehen“ hilft bei ruhenden Clients, doch Stille kann Stilllegung, Defekt, Saisonalität oder Diebstahl heißen. Automatische Sperren brauchen Eigentümer, Schwelle, Ausnahme und Wiederherstellung.

Wiederaufnahme schafft einen zweiten Namensraum

TLS 1.3 nutzt ebenfalls PSKs und Identities zur Session-Wiederaufnahme. Sie entstehen im TLS-Subsystem und sind keine statischen Client-Namen. RFC 9813 rät hier von Wiederaufnahme ab. Wo Übergänge sie erfordern, müssen opake Tickets und administrative Identities getrennt bleiben; unbekannte Werte schließen die Verbindung, Kollisionen dürfen nie die Tabellen wechseln.

Wiederaufnahme konserviert keine Autorisierung. Der Server rekonstruiert Identität und Policy des ursprünglichen Handshakes, bewertet geänderte Quellen neu und führt bei unsicherem Cache einen vollen Handshake aus. Ticket und Cache dürfen höchstens sieben Tage bestehen.

Auditierbar ist die Kette, nicht das Label

Für jede Annahme sollten globaler Bereich, Eingabeprüfung, Normalisierung, genaue Tabellengeneration, Client-Bereich, TLS-Version und KDF, PSK-Nachweis, Resume-Cache, RADIUS-Prüfung, lokale Policy, NAS-Aktion und beobachteter Dienst rekonstruierbar sein. Jeder Schritt kann gelingen, während der nächste scheitert.

Running-Code Primacy verlangt den Nachweis aus laufendem Parser, Lookup und Policy Engine statt aus einer Soll-Konfiguration. On Reality Layers verhindert, dass ein symbolischer Treffer für Kryptografie und Wirkung spricht.

RFC 9813 krönt also keinen neuen Namen. Es trennt Ort, Auswahl, Nachweis, Erlaubnis und Ergebnis. Diese Trennung muss im Datenmodell fortbestehen.

Quellen