Zusammenfassung

  • RFC 9887 gibt TACACS+ über TLS eine eigene Dienstgrenze, verlangt TLS 1.3 und gegenseitige Authentisierung, untersagt 0-RTT-Anwendungsdaten und verbietet den Rückfall auf Nicht-TLS.
  • Alt- und Neudienst dürfen während der Umstellung koexistieren, doch diese Phase bleibt bis zum Abschluss unsicher; Erreichbarkeit des Altservers ist kein Kontinuitätsnachweis.

Der wichtigste Satz einer Sicherheitsmigration beschreibt oft nicht die Aktivierung, sondern den Ausfall. RFC 9887 bestimmt für TACACS+, dass ein Client bei gescheiterter TLS-Verbindung nicht auf Nicht-TLS zurückfallen darf – auch nicht während der Migration.

TACACS+ trägt Geräteadministration. RFC 8907 trennt Authentisierung, Autorisierung und Accounting, doch der historische Mechanismus für den Paketkörper ist Verschleierung. RFC 9887 ersetzt ihn in der geschützten Variante durch TLS-Authentisierung und Verschlüsselung.

Getrennte Dienste machen die Regel prüfbar

Nach dem TCP-Aufbau beginnt TLS sofort; ein Upgrade aus einer schwachen Sitzung ist verboten. Standardmäßig nutzt der Altdienst TCP 49 und der neue tacacss-Dienst TCP 300, wie das IANA-Register ausweist. Getrennte Hosts werden ebenfalls empfohlen.

Die Trennung ermöglicht Filterung, verhindert Manipulation einer Upgrade-Aushandlung und reduziert Fehlkonfigurationen. Geräte ohne TLS können einen eigenen Altserver benötigen. Dieser ist jedoch kein automatischer Ersatz für einen TLS-pflichtigen Client.

Ein offener Port beweist nur einen Eingang. Er beweist weder den erwarteten Peer noch die ausgehandelte Version, Zertifikatsprüfung, den abgeschlossenen Handshake, eine angenommene TACACS+-Nachricht, eine Autorisierung oder eine ausgeführte Aktion.

Transportidentität ist keine Befehlsgewalt

TLS 1.3 ist die Mindestversion. Die aktuelle Spezifikation ist RFC 9846, ergänzt durch RFC 9325. Zertifikatsbasierte gegenseitige Authentisierung muss als gemeinsame Option unterstützt werden.

Jeder Peer prüft Pfad und Widerruf nach dem X.509-Profil; die Dienstidentität folgt RFC 9525. Erfolg authentisiert den TLS-Peer. Lokale Regeln dürfen die Verbindung weiter einschränken, und TACACS+ entscheidet anschließend separat über Benutzer und Befehle.

Ein gültiges Zertifikat ist keine Befehlsautorisierung. Ein Handshake ist kein Accounting-Eintrag. Eine positive Antwort beweist weder Ausführung noch Zielzustand. Auch 0-RTT ist untersagt: early_data darf nicht vorkommen, und der Server trennt einen Client, der frühe Daten sendet. Ein Wiederaufnahmeticket erlaubt keine vorgezogene AAA-Eingabe.

Ein Fehler erteilt keine Ausnahme

Abgelaufene oder widerrufene Zertifikate, unvollständige Ketten, unerreichbare Zertifizierungs- oder Widerrufsdienste und ausgefallene TLS-Server erzeugen echten Druck. Keiner dieser Zustände macht einen erreichbaren Altserver zum zulässigen geschützten Peer.

Kontinuität braucht deshalb mehrere sichere Server, lokal verfügbare Ketten, funktionierenden Widerruf, geprobte Rotation, unabhängige Überwachung und Wiederherstellung außerhalb des betroffenen Pfads. Eine menschlich genehmigte Ausnahme benötigt Umfang, Ende und Auditspur; sie darf kein unsichtbarer Retry-Zweig sein.

Koexistenz ist noch kein Abschluss

RFC 9887 erlaubt vorübergehende Koexistenz, nennt die Migration aber bis zu ihrem Abschluss unsicher und verlangt, Doppelkonfigurationen kurz zu halten. Neunzig Prozent migrierte Clients bedeuten nicht neunzig Prozent Sicherheit. Der Restpfad kann sensible Daten tragen, und gerade ein erzwungener TLS-Ausfall könnte ihn aktivieren.

Abschluss bedeutet: migrierte Clients können nicht zu Port 49 zurückkehren, Altserver sind auf eine ausdrücklich isolierte Gruppe beschränkt. SNI bleibt im ersten Hello sichtbar; Wildcard-Zertifikate vergrößern den gemeinsamen Ausfallbereich; Diensterkennung liegt außerhalb des RFC. Diese Fakten brauchen lokale Verantwortung.

Quellen