Zusammenfassung

  • RFC 1492 erschien im Juli 1993 als Informational, weil der Autor die vorhandene TACACS-Ursprungsspezifikation wegen Urheberrechtsfragen nicht beschaffen konnte.
  • Ciscos einfache Implementierung galt als kompatibel, war aber nicht gegen den Ursprungstext geprüft; das RFC warnte ausdrücklich vor später erkennbaren Fehlern.
  • Nonce-Korrelation, Daemon-Entscheidung, Durchsetzung durch den Terminalserver, Zielverbindung und Accounting sind getrennte Belege.

Die UDP-Darstellung verwendete Port 49. In der Anfrage stand ein Nonce, den der Daemon in die Antwort kopierte. Damit konnte der Client ein angekommenes Datagramm einer noch offenen Anfrage zuordnen. Mehr bewies die Übereinstimmung nicht. Sie authentifizierte weder Benutzer noch Server, schützte keine Nachricht kryptografisch und bestätigte keine lokale Berechtigungspolitik.

Diese enge Aussage spiegelt die Entstehung des gesamten Dokuments. Laut RFC 1492 existierte eine ursprüngliche TACACS-Spezifikation, doch der Autor konnte sie wegen Urheberrechtsfragen nicht erhalten. Gerade deshalb schrieb er die neue Beschreibung. Gemeinsam mit Cisco Systems stützte er sich auf eine einfache Implementierung, von der man annahm, dass sie mit dem Original kompatibel sei.

Eine Annahme ist kein Textvergleich. Laufender Code zeigt Felder, Verzweigungen und Antworten für beobachtete Eingaben. Er kann aber ausgelassene Optionen, Produkterweiterungen oder langlebige Fehler enthalten. Das RFC erklärte deshalb offen, ein später gefundener Ursprungstext könne Teile der Rekonstruktion als falsch erweisen.

Auch der Status zog eine Grenze: RFC 1492 war Informational und definierte keinen Internet Standard. Die Veröffentlichung machte eine praktische Beschreibung zitierbar; sie erhob Ciscos Verhalten nicht zur universellen Norm.

Einfaches und erweitertes TACACS hatten verschiedene Belege

Das Dokument unterschied eine einfache und eine erweiterte Form. Die vermutete Kompatibilität bezog sich auf Ciscos einfache Implementierung. Cisco unterstützte außerdem die erweiterte Variante; sie wurde in Cisco-Terminalservern und im verteilten Authentisierungssystem der University of Minnesota eingesetzt. Das sind benannte, begrenzte Einsatzbelege. Sie liefern weder eine Verbreitungsstatistik noch den Nachweis identischer Dialekte.

Wenn ein Quelltext fehlt, wird die verfügbare Implementierung leicht zum faktischen Bezugspunkt. Nachbauer kopieren auch ihre Eigenheiten, weil dies die günstigste Interoperabilität verspricht. Spätere Dokumente können dann Produktverhalten als ursprüngliche Absicht ausgeben. Die Unsicherheitswarnung des RFC hält diese Verschiebung sichtbar.

LOGIN und CONNECT waren zwei Entscheidungen

Der Client stellte eine Anfrage, der Daemon musste antworten und konnte jede Anfrage ablehnen. LOGIN übermittelte Zugangsdaten; bei Erfolg durfte der Terminalserver eine Login-Verbindung beginnen. CONNECT kam innerhalb einer bereits bestehenden Verbindung und fragte, ob eine TCP-Verbindung zu einer bestimmten Zieladresse und einem bestimmten Port geöffnet werden dürfe.

Erfolgreiches LOGIN war keine pauschale Zielberechtigung. Eine positive CONNECT-Antwort belegte wiederum nicht, dass der Terminalserver sie umgesetzt, das Netz den Versuch geliefert oder das Ziel ihn angenommen hatte. Ein späterer Accounting-Datensatz wäre ein weiterer Beleg.

Der Betreiber des Daemons bestimmte Algorithmen und Daten für Annahme oder Ablehnung. Das ermöglichte standorteigene Regeln, machte die Antwort aber zu einer lokalen Entscheidung. Ein gemeinsames Nachrichtenformat ist keine weltweit einheitliche Politik.

Wiederholung war nicht automatisch harmlos

Nach einem Timeout durfte der UDP-Client erneut senden; der Server wiederholte nicht. RFC 1492 bemerkte die Spannung: Der Aufbau schien idempotente Anfragen vorauszusetzen, doch die Anfragen waren tatsächlich nicht idempotent. War nur die erste Antwort verloren, konnte die erste Verarbeitung den Zustand einer größeren Verbindung bereits verändert haben.

Zwei Pakete mit gleichem Nonce dürfen daher nicht ohne Zeit, Daemon-Zustand, Wiederholungsgrund und Terminalserver-Protokoll zu einem Ereignis zusammengezogen werden. Korrelation hilft bei der Zuordnung; sie entscheidet nicht über Wirkung.

Klartext blieb Klartext, auch über TCP

Sowohl UDP- als auch TCP-Codierung transportierten Benutzername und Passwort im Klartext. Der Sicherheitsabschnitt warnte, ein Netzbeobachter könne solche Paare sammeln und der Dienst eröffne eine Fläche zum Ausprobieren von Zugangsdaten. Eine spätere Annahme verschlüsselt die vorherige Anfrage nicht nachträglich.

Die TCP-Codierung löste ein anderes Problem. Sie war ausdrücklich inkompatibel mit historischem TACACS, nutzte einfacheres Framing und TCP-Zustellung und bot mehr Raum für Antworten. Geordnete Bytezustellung authentifiziert keine Endpunkte, verbirgt keine Passwörter und beweist nicht die Durchsetzung einer Entscheidung.

TACACS+ ist ein später Vergleich

RFC 8907 beschrieb später TACACS+ als Suite mit Trennung von Authentisierung, Autorisierung und Accounting. Es warnte auch, dass eine Protokollsitzung nicht zwingend einem Benutzer oder einer Benutzerhandlung entspricht und Authentisierungsanfragen nicht automatisch mit Autorisierungsanfragen verbunden sind. Diese Präzision hilft beim Trennen von Belegen, darf aber nicht rückwirkend zu Semantik des TACACS von 1993 erklärt werden.

RFC 927 gehört ebenfalls an eine eigene Stelle: Es behandelte die TELNET-TUID-Übergabe. RFC 1492 handelt von der Rekonstruktion eines Daemon-Protokolls zwischen fehlendem Ursprungstext und verfügbarem Hersteller-Code.

Seine dauerhafte Leistung ist nicht Gewissheit, sondern sauber begrenzte Aussagekraft. Dokumentenbesitz, Implementierungsverhalten, Veröffentlichung, Transport, lokale Entscheidung, Gerätehandlung und äußeres Ergebnis stehen in einer Kette. Kein Glied darf die Identität aller anderen annehmen.

Quellen