Zusammenfassung

  • RFC 927 schlug TUID, Telnet-Option 26, vor: Ein Host mit bereits erfolgter Benutzer-Authentisierung konnte einem zustimmenden Ziel eine binäre 32-Bit-Kennung übermitteln.
  • Erst das Zusammenspiel von WILL TUID und DO TUID erlaubte die Subnegotiation; WON'T und DON'T hielten die Verweigerung als normalen Protokollzustand fest.
  • Die vier Oktette waren eine Aussage der Quelle über einen Benutzer, nicht der Beweis des Passwortvorgangs, keine Berechtigung beim Ziel und kein Nachweis einer ausgeführten Handlung.

Die RFC 927 von Brian A. Anderson bei BBN erschien im Dezember 1984 unter dem Titel TACACS User Identification Telnet Option. Ihr Thema war die Vermeidung einer doppelten Anmeldung. Ein Benutzer hatte sich bereits mit korrekt eingegebenem Namen und Passwort an einem Terminal Access Controller, einem TAC, ausgewiesen. Wenn dieser TAC anschließend im Namen des Benutzers eine Telnet-Verbindung zu einem Zielhost eröffnete, sollte das Ziel nicht noch einmal nach demselben Geheimnis fragen müssen.

Die RFC leitete das Passwort nicht weiter. Ihre Option TUID mit Code 26 erlaubte dem Telnet auf der Benutzerseite, eine Authentisierung anzubieten und die UUID zu senden. Die Serverseite konnte erklären, dass sie diese Authentisierung annehmen wollte. Danach übertrug die Subnegotiation eine 32-Bit-Binärzahl. Dieses UUID der RFC besteht aus vier Oktetten; es ist nicht das spätere, vertraute 128-Bit-Format.

Die wichtige Begrenzung lag in dem, was die Zahl nicht mitnahm. Die Quelle konnte für ihre eigene Prüfung sprechen. Das Ziel musste selbst entscheiden, ob diese Prüfung für seinen Dienst genügte. Ein gesparter Prompt ersetzte Wiederholung durch eine bewusst gewählte Vertrauensbeziehung; er verlegte die Entscheidungsmacht nicht.

Eine lokale Prüfung wurde zur Aussage für einen anderen Host

Nach der Motivation der RFC verlangte TACACS vom Benutzer zunächst ein korrektes Name/Passwort-Paar beim TAC. Der TAC hatte damit eine lokale Tatsache: Sein Verfahren hatte einen Benutzer akzeptiert, den er mit einer Nummer verband. TUID machte es möglich, diese Tatsache dem nächsten Host anzubieten.

Das Ziel erhielt nicht das Passwort, um es nachzuprüfen. Es erhielt eine Behauptung: Die Quelle habe den Benutzer, für dessen Verbindung sie handele, authentisiert; diese vier Bytes seien ihre Kennung für ihn. Wer einen zweiten Login vermeiden wollte, musste deshalb Verfahren, Betrieb und Aussage der Quelle bewerten.

RFC 927 lässt den Zielhost ausdrücklich frei. Hosts konnten die Authentisierung des TAC akzeptieren oder nicht, nach eigener Wahl. Die Quelle bestimmte ihre Authentisierung. Das Ziel trug die Verantwortung für den Zugang zu seinem Dienst. Eine Aussage über Identität wurde nicht zur Vollmacht über die Zielentscheidung.

Vor dem Wert stand die Einwilligung

Das Format stützte sich auf Telnet-Optionsverhandlung. RFC 854 benutzt WILL, WON'T, DO und DON'T, um zusätzliche Funktionen gegenüber dem Network Virtual Terminal anzubieten, anzufordern, anzunehmen oder abzulehnen. RFC 855 verlangt, dass beide Seiten erst die Option verstehen wollen, bevor eine Subnegotiation ihre Parameter überträgt.

Bei TUID hieß IAC WILL TUID, dass die Benutzerseite den Benutzer authentisieren und die Kennung senden wollte oder dies zusagte. IAC DO TUID hieß, dass die Serverseite dies wünschte oder die Authentisierung annehmen wollte. WON'T lehnte die Quellrolle ab, DON'T die Annahme durch das Ziel. Erst nach übereinstimmendem WILL und DO folgte IAC SB TUID <uuid> IAC SE.

Die RFC zeigt zwei erfolgreiche Reihenfolgen und zwei klare Verweigerungen. Nichtwissen führte nicht zu stiller Zustimmung: Ein nicht unterstützender Benutzerhost antwortete WON'T, ein nicht unterstützender Server DON'T. Die Verbindung blieb dann im gewöhnlichen Telnet, mit der lokalen Login-Regel des Ziels.

Vier Oktette bewiesen sich nicht selbst

Das Wort UUID darf hier nicht mit heutigen Annahmen überladen werden. RFC 927 definiert eine 32-Bit-Binärzahl und illustriert 1, 255 und alle Bits auf eins. Sie definiert keine globale Vergabe, keine Kollisionsregel, keine Laufzeit, keinen Zeitstempel, keine Signatur und keine Wiederholungssperre.

Im Telnet ist Oktett 255 IAC. Kommt es als Datenwert vor, muss es verdoppelt werden, damit es nicht als Befehl gelesen wird. Dieses Escaping bewahrt die Byte-Grenze; es verschlüsselt und authentisiert nichts. Ein Mitschnitt kann zeigen, dass vier Bytes nach einer Optionseinigung als Kennung vorgelegt wurden. Er beweist weder die Passwortprüfung, noch die Eindeutigkeit der Zahl, noch die Kontozuordnung des Ziels oder den Erfolg eines Befehls.

Anerkennung einer Aussage war keine Aktionsfreigabe

Die Annahme der vorgelagerten Authentisierung beantwortete nur, ob das Ziel die Aussage als hinreichenden Identitätsnachweis für diese Verbindung behandeln wollte. Sie bestimmte nicht, welche Datei gelesen, welcher Befehl ausgeführt oder welche Berechtigung verliehen werden durfte.

RFC 1492, eine spätere informationelle TACACS-Rekonstruktion, trennt Login-Annahme und eine CONNECT-Entscheidung über Adresse und Port; ihr Autor warnt, dass ihm die Ursprungsspezifikation fehlte und spätere Erkenntnisse Fehler zeigen könnten. RFC 8907 beschreibt das viel spätere TACACS+ und trennt Authentisierung, Autorisierung und Accounting; es verbindet Authentisierungs- und Autorisierungsanfrage nicht auf Protokollebene. Beides sind Vergleichsgrenzen, keine nachträgliche Semantik für TUID.

Das IANA-Register für Telnet-Optionen führt Code 26 weiterhin als TACACS User Identification mit Verweis auf RFC 927. Das bestätigt die Codezuordnung, nicht Verbreitung oder aktuellen Einsatz.

Weniger Reibung verlangte mehr Belegkette

Für den Benutzer war der Gewinn sofort sichtbar. Für das Ziel änderte sich die Last: Es musste vertrauenswürdige Quellen, deren Namensräume, die Abbildung auf lokale Konten und den Entzug dieses Vertrauens nach einem Vorfall verwalten.

Ein Protokoll mit nur „Login erfolgreich“ löscht den Handel. Es unterscheidet nicht lokale Passwortprüfung, TUID-Annahme, Kontoabbildung, konkrete Autorisierung und Anwendungsergebnis. Zu bewahren sind deshalb Quellen-Authentisierung, WILL/DO-Folge, unescaped Wert und Namensraum, Zielvertrauensentscheidung, lokale Berechtigung und beobachtete Handlung.

RFC 927 löste keine universelle digitale Identität. Sie gab zwei kooperierenden Hosts eine kleine Sprache, um Wiederholung zu sparen, ohne dass einer die Verantwortung des anderen beanspruchte. Vier Bytes überquerten die Verbindung. Die Verantwortung für ihre Annahme blieb beim Ziel.

Quellen und Grenzen

Grundlage sind RFC 927, RFC 854, RFC 855 und das IANA-Register; RFC 1492 und RFC 8907 dienen nur als zeitlich begrenzte spätere Vergleiche. Sie belegen weder breite Nutzung noch kryptografischen Schutz, moderne Föderation oder ein konkretes Sitzungsergebnis.