Zusammenfassung

  • RFC 9950 wurde im März 2026 als Proposed Standard veröffentlicht, ersetzt RFC 9105 und erweitert das TACACS+-YANG-Modell um TLS 1.3. Es kann eine geordnete Serverliste, eine zwingende Wahl zwischen TLS und alter Verschleierung, Verweise auf Anmeldedaten, den Managementpfad und Betriebszähler ausdrücken.
  • Eine gültige Konfiguration ist keine Freigabe. Das Modell belegt weder die Fähigkeiten einer Gerätekohorte noch die korrekte Verzahnung von Authentifizierung, Autorisierung und Accounting. Auch Notzugang, Rückfall und die verantwortliche Risikoannahme bleiben außerhalb.
  • Ein zeitlich begrenzter AAA-Umstellungsbeleg sollte Konfigurations-Hashes, Fähigkeitstests, nicht geheime Kennungen von Anmeldedaten-Generationen, den echten Pfad, Zählerkontinuität, erprobten Rückfall, Freigabe und Schließung des Nicht-TLS-Wegs verbinden. Das ist ein hier vorgeschlagener Betriebsnachweis, keine neue IETF-Pflicht.

Eine grüne Verbindung ist noch keine Freigabe

Das Wartungsfenster beginnt ordentlich. Zwei TACACS+-Server stehen in der vorgesehenen Reihenfolge. Für beide ist TLS gewählt; Client-Zertifikate werden aus einem Tresor referenziert. Domänenname, SNI, Port, Quellschnittstelle und Management-VRF sind gesetzt. Das YANG-Modell akzeptiert die Konfiguration, der erste Router baut die Verbindung auf.

Offen bleibt, ob ein anderes Gerätemodell denselben Verweis auflösen kann. Darf der Bereitschaftsaccount den Wiederherstellungsbefehl ausführen? Kommen Accounting-Datensätze unter einer auffindbaren Identität an? Funktioniert der lokale oder Konsolenzugang ohne genau den zentralen AAA-Dienst, der gerade geändert wird?

RFC 9950 hat hier nichts vergessen. Es zeigt die Grenze zwischen technischer Spezifikation und organisatorischer Entscheidung. Eine Spezifikation vereinheitlicht die Bedeutung eines gewünschten Zustands. Eine Freigabe beurteilt, ob eine konkrete Organisation mit ihren Geräten, Menschen und Folgen die unsicheren Zwischenzustände durchlaufen darf.

Bei AAA ist die Grenze besonders scharf. Ein Fehler an Name, Route, Zeit, Zertifikat oder Rollenabbildung kann den administrativen Zugang sperren, der zur Fehlerbehebung nötig wäre. Bleibt umgekehrt der alte Transport unbegrenzt offen, bleibt auch die Möglichkeit eines Downgrades auf den schwächeren Schutz.

Es fehlt also kein weiteres Konfigurationsbit. Es fehlt ein Beleg dafür, dass genau diese Kohorte wechseln und zurückkehren kann, wer das Risiko akzeptiert und wann der alte Zugang tatsächlich endet.

Was RFC 9950 maschinenlesbar macht

RFC 9950 gehört zum IETF Standards Track und hat den Status Proposed Standard. Es macht RFC 9105 obsolet und nimmt die TLS-1.3-Konfiguration aus RFC 9887 in das TACACS+-YANG-Modell auf.

Die Serverliste wird vom Benutzer geordnet. Die Kombination aus Adresse und Port muss eindeutig sein. Die Reihenfolge ist keine Oberflächenpräferenz: Sie beeinflusst, welcher Server nach Zeitüberschreitung oder Fehler als Nächstes angesprochen wird. Redundanz wird damit als Absicht prüfbar.

Jeder Server verlangt eine Sicherheitswahl. Der TLS-Zweig führt TLS-Parameter und Verweise auf Client- sowie Serverauthentisierung. Der historische Zweig bewahrt das gemeinsame TACACS+-Geheimnis unter der Bezeichnung obfuscation. Der RFC stuft diesen Weg zugunsten von TLS als überholt ein, lässt ihn für die installierte Basis aber darstellbar. Eine Migration braucht ein Vokabular für Ausgang und Ziel.

Zum Modell gehören auch Port, Quellschnittstelle, Netzinstanz, Domänenname und SNI. Zusammen bilden sie den wirklichen Pfad. Ein Zertifikatstest im Produktionsnetz beweist nichts über die Management-VRF. Das Erreichen einer IP-Adresse bestätigt nicht automatisch die erwartete Dienstidentität. Ein eingetragener Ersatzserver ist noch kein getesteter Failover.

Betriebszähler erfassen Verbindungs- und Identitätsprobleme, darunter Zertifikats- und Raw-Public-Key-Fehler. discontinuity-time zeigt, wann die Zahlen ihre Kontinuität verloren haben. Ohne diese Angabe kann ein sauberer Zähler drei Minuten nach einem Neustart wie eine stabile Woche aussehen.

Für Automatisierung und Revision ist das ein großer Gewinn. Soll und Ist lassen sich vergleichen; eine veränderte Reihenfolge, Referenz oder Fehlerquote wird sichtbar. Doch alle Felder bleiben Aussagen über Konfiguration und gemeldeten Zustand. Sie sagen nicht, ob die richtige Instanz den Wechsel erlaubt hat.

Ein Verweis erzählt nicht die Geschichte der Anmeldedaten

Private Schlüssel, Passwörter und gemeinsame Geheimnisse gehören weder in jedes Gerät noch in jedes Änderungsticket. Ein Tresorverweis reduziert Kopien und erleichtert Rotation. Aber ein syntaktisch vorhandener Verweis belegt keine funktionierende Vertrauenskette.

Auf verschiedenen Geräten kann derselbe Name auf unterschiedliche Generationen zeigen. Ein gültiges Client-Zertifikat kann serverseitig der falschen Richtliniengruppe zugeordnet sein. Die Kette des Servers kann vertrauenswürdig sein, während sein Name nicht zur konfigurierten Domäne passt. Ein gepinnter öffentlicher Schlüssel kann eine Generation zurückliegen. Die Management-VRF erreicht vielleicht TACACS+, aber nicht die Zeitquelle, die für die Gültigkeitsprüfung gebraucht wird.

Der Umstellungsbeleg darf deshalb nur nicht geheime Generationenkennungen halten: Zertifikats-Fingerabdruck, Tresorversion, Ausstellungsrichtlinie, Gültigkeitszeitraum und getestete Gerätekohorte. Das Geheimnis selbst bleibt draußen. Seine Kopie würde einen neuen Verteilungsfehler schaffen; ein Verweis ohne Generation und beobachtete Transaktion wäre dagegen später nicht überprüfbar.

Gegenseitige TLS-Authentisierung beendet die AAA-Kette ebenfalls nicht. Das Gerät prüft den Server, der Server das Gerät. Danach authentisiert die AAA-Policy den Menschen oder Automaten, autorisiert Handlungen und verbucht sie. Ein erfolgreicher TLS-Kanal beweist weder eine korrekte Rolle noch die Auffindbarkeit des Accounting-Datensatzes.

Drei A verlangen mehr als einen Login

TACACS+ trennt Authentifizierung, Autorisierung und Accounting. Der Satz „AAA funktioniert“ beruht in der Praxis oft auf einem einzigen erfolgreichen Login. Das ist eine zu große Schlussfolgerung aus einem zu kleinen Test.

Nach der Migration kann sich ein Administrator anmelden, aber ausgerechnet der Rückfallbefehl wird verweigert. Ein Lesekonto kann zusätzliche Rechte erhalten. Accounting kann unter einem neuen Clientnamen eintreffen, den die Revision nicht sucht. All das ist mit einem fehlerfreien TLS-Handshake vereinbar.

Ein repräsentativer Test umfasst deshalb einen erlaubten Administrator, eine bewusst verweigerte Aktion, eine eingeschränkte Rolle, ein Automationskonto und einen später auffindbaren Accounting-Eintrag. Er verspricht nicht die Richtigkeit jedes künftigen Befehls. Er zeigt, dass Identität, Berechtigung und Gedächtnis auf dem neuen Weg noch zusammengehören.

Der Notzugang ist Teil desselben Tests. Lokale Anmeldung, Konsole oder Out-of-Band-Pfad müssen an repräsentativen Geräten ohne den veränderten AAA-Dienst funktionieren. Es muss klar sein, wer Zugang hat und wie dessen außergewöhnliche Nutzung später geprüft wird.

Dieser Test ist unbequem und wird deshalb gern vertagt. Der normale Fernzugang ist schnell geprüft; Konsole oder physische Koordination kosten Zeit. Die Organisation misst das Bequeme und glaubt an das Entscheidende. Beim Fehler bestimmt aber gerade der Notweg die Schadenshöhe.

Koexistenz ist geliehene Zeit

RFC 9887 verlangt eine eindeutige Konfiguration von TLS und Nicht-TLS auf getrennten Ports. Ein opportunistisches Erraten des Protokolls ist nicht vorgesehen. Solange beide Wege bestehen, ist ein Downgrade möglich; die Migration bleibt bis zu ihrem Abschluss unsicher und soll kurz sein. Nicht TLS-fähige Clients sollen auf getrennten Nicht-TLS-Servern bleiben.

Damit ist der Altpfad kein kostenloses Sicherheitsnetz. Er erkauft Erholungszeit mit einer bekannten Sicherheitsschuld.

Ein belastbarer Rückfall nennt die vorige Konfiguration, das Verfahren, den Ausführenden, den Zugangsweg und den letzten sicheren Zeitpunkt. „Port 49 vorsichtshalber offen lassen“ enthält weder Test noch Eigentümer noch Ende. So wird ein Übergangszustand unbemerkt zur Architektur.

Schnelles Schließen ersetzt die Erprobung ebenfalls nicht. Vor Beginn sollte der Rückweg an einer kleinen Kohorte ausgeführt werden. Hängt er selbst vom AAA-Dienst im Umbau ab, ist die zirkuläre Abhängigkeit ein Abbruchgrund. Die Beobachtungsphase muss nach dem letzten discontinuity-time beginnen und innerhalb der Gültigkeit der Anmeldedaten liegen. Ein Zählerreset in der Mitte trägt nicht dieselbe Stabilitätsaussage.

Verantwortlich ist weder ewiger Parallelbetrieb noch ein ungetesteter harter Schnitt, sondern eine kurze, beobachtbare und zugeordnete Phase, die mit einem Schließungsnachweis endet.

Acht Bausteine eines Umstellungsbelegs

Der AAA-Umstellungsbeleg gehört bewusst nicht in das YANG-Modul. Ein gemeinsamer Standard soll weder die Freigabestelle eines Unternehmens noch dessen Wartungskalender festlegen. Das Unternehmen darf seine interne Genehmigung umgekehrt nicht als IETF-Gebot ausgeben.

  1. Konfigurationsidentität. Modulrevision, gegebenenfalls Herstellerabbildung, Hashes von Kandidat und laufender Konfiguration sowie exakte Serverreihenfolge.
  2. Kohortenfähigkeit. Geräte, Softwarestände, TLS-Versionen und Authentisierungsformen, die tatsächlich geprüft wurden; Ausnahmen werden einzeln benannt.
  3. Sicherheits- und Generationsstand. Gewählter Zweig je Server, nicht geheime Kennungen, Name/SNI-Erwartung und Version der Vertrauensrichtlinie.
  4. Pfadnachweis. Test über wirkliche Management-VRF, Quelle, Ziel und Port einschließlich Identitätsprüfung. Ein anderer Laborpfad ist kein Ersatz.
  5. AAA-Nachweis. Authentifizierung, erlaubte und verweigerte Autorisierung, Rollen sowie auffindbares Accounting, gebunden an dieselben Hashes.
  6. Kontinuierliche Beobachtung. Fenster nach discontinuity-time mit Raten und Nennern für Verbindungs- und Identitätsfehler.
  7. Erholung und Autorität. Freigebender, akzeptierte Risiken, getestete lokale oder Konsolenroute, Rückfallartefakt, Ausführender und spätester Umkehrpunkt.
  8. Schließung. Ablauf des Altmodus und Beleg seiner Entfernung oder Isolation; jede Ausnahme behält Kohorte, Verantwortlichen und nächsten Entscheidungstermin.

Ein Hash des Belegs macht Veränderungen sichtbar, nicht die Entscheidung unfehlbar. Der Nutzen liegt in den Verknüpfungen: Welche Bytes wurden getestet, welche Generation war aktiv, blieben die Zähler kontinuierlich, wer entschied und wurde der ungeschützte Weg wirklich geschlossen?

Der Beleg nennt seine eigenen Verfallsbedingungen. Eine neue Serverliste, Rotation, Softwareaktualisierung, Vertrauenswurzel oder Route kann eine begrenzte neue Prüfung auslösen. Er ist weder dauerhaftes Sicherheitszertifikat noch IETF-Konformitätszeichen.

Die Schreibberechtigung ist selbst ein Hochrisikopfad

RFC 9950 bezeichnet seine beschreibbaren Knoten als sensibel. Eine unbefugte Änderung der Serverliste kann einem Angreifer vollständige Gerätekontrolle ermöglichen. Denn diese Liste bestimmt, wo Identitäten geprüft, Rechte entschieden und Handlungen verzeichnet werden.

NACM kann Lese- und Schreibzugriff auf YANG-Daten begrenzen. Das ist nötig, bindet eine einzelne Änderung aber noch nicht an einen gültigen Beschluss. Ein technisch berechtigtes Konto kann außerhalb des Fensters oder mit anderen Bytes handeln.

Vorbereitung, Freigabe und Anwendung sollten getrennt sein. Die Freigabe wird an Konfigurations- und Evidenz-Hashes gebunden, läuft ab und hält Notausnahmen fest. Ein dauerhaftes Privileg „Netzwerkadministrator“ darf keine transaktionsgenaue Erlaubnis ersetzen.

Hier wird Infrastruktur zum Spiegel der Politik. Wer eine Nicht-TLS-Ausnahme verlängern kann, setzt die tatsächliche Frist. Wer fehlendes Accounting akzeptieren kann, setzt den tatsächlichen Nachweisstandard. Weichen Betriebssystem und Richtlinie voneinander ab, beschreibt das System die Machtverteilung ehrlicher.

Lokale Entscheidung ist kein Mangel der Norm

Von RFC 9950 ein universelles Freigabeobjekt zu fordern, würde Ebenen verwechseln. Eine wiederverwendbare Norm definiert minimale interoperable Semantik und lässt die spätere Entscheidung bei den lokal Wissenden und Verantwortlichen. Der Betreiber kann seinen Beleg ergänzen, ohne das Protokoll abzuspalten.

Freiwillige Übernahme bedeutet ebenfalls keine folgenlose Entscheidung. Hat eine Organisation TACACS+ für administrative Kontrolle gewählt, können Verträge, Arbeitsregeln, Kundenzusagen und Auditvorgaben die Umstellung verbindlich machen. Diese Autorität stammt aus lokalen Instrumenten, nicht aus der RFC-Nummer allein.

Auch die Tatsachengrenze bleibt wichtig: Die ausgewerteten Quellen belegen keinen Lockout oder Downgrade eines namentlich bekannten Netzes bei einer RFC-9950-Migration. Die beschriebenen Szenarien sind prüfbare Mechanismen, keine erfundenen Vorfälle. Ein Beleg für Realität darf seine Rechtfertigung nicht selbst fabrizieren.

Fertig ist die Umstellung erst nach der Schließung

Nach dem Wechsel wird die laufende Konfiguration mit dem genehmigten Hash verglichen. Die Zählerkontinuität wird bestätigt, das erwartete Accounting gefunden und ein Nicht-TLS-Versuch unternommen. Dieser muss scheitern oder ausschließlich die ausdrücklich isolierte Altgeräte-Kohorte erreichen.

Der Schließungsnachweis verdient dieselbe Sichtbarkeit wie die Startfreigabe. Sonst feiert die Organisation den neuen Kanal und vergisst die alte offene Tür.

RFC 9950 liefert eine bessere Sprache für das Ziel. RFC 9887 erklärt, warum die Mischphase enden muss. Keiner von beiden kann für den Betreiber unterschreiben. Zu dieser Unterschrift gehören die überführten Geräte, die aktiven Identitäten, die drei geprüften AAA-Funktionen, der erprobte Rückweg, der Risikoträger und der Zeitpunkt, an dem die alte Brücke tatsächlich hochging.

Quellen

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. RFC Editor — Datensatz zu RFC 9950
  5. RFC 9950 — YANG-Datenmodell für TACACS+
  6. RFC Editor — Datensatz zu RFC 9887
  7. RFC 9887 — TACACS+ über TLS 1.3
  8. RFC Editor — Datensatz zu RFC 9105
  9. RFC 9105 — YANG-Datenmodell für TACACS+
  10. RFC 8907 — Das TACACS+-Protokoll
  11. RFC 8341 — Zugriffskontrollmodell für Netzkonfiguration
  12. RFC 9645 — YANG-Datenmodell für TLS und DTLS
  13. RFC 9525 — Dienstidentität in TLS