Zusammenfassung

  • RFC 1408 veröffentlichte VAR=0 und VALUE=1 für Telnet-Option 36. RFC 1571 hielt fest, dass die BSD-Referenzimplementierung die beiden Bedeutungen vertauscht verwendete.
  • RFC 1571 leitete die Wörterbuchwahl aus unzulässigen Markern, Positionen, leeren Markern, Häufigkeiten und bekannten Namen ab. Nicht jede Folge war eindeutig.
  • RFC 1572 beließ die schriftliche Zuordnung, verlagerte sie aber auf Option 39 NEW-ENVIRON. Auch ein eindeutig dekodierter Wert blieb ein lokaler Eingang, kein Befehl an den Server.

Die Nummer benannte die Option, nicht ihre Vergangenheit

RFC 1408 erschien im Januar 1993. Die neue Telnet-Option sollte Umgebungsinformationen beim Verbindungsaufbau vom Client zum Server tragen. ENVIRON erhielt Nummer 36. Für die Unteraushandlung galten IS=0, SEND=1 und INFO=2; in der Nutzlast markierten VAR=0, VALUE=1, ESC=2 und USERVAR=3 die Struktur.

Diese Marker entschieden, wo ein Name begann und ein Wert folgte. Fehlt VALUE, war die Variable undefiniert. Folgte auf VALUE sofort der nächste Typ oder das Ende, war sie definiert, aber leer. Reservierte Oktette mussten maskiert werden. Eine Umkehrung von Null und Eins veränderte deshalb nicht nur eine Beschriftung, sondern den Parse-Baum der gesamten Folge.

Im Januar 1994 beschrieb RFC 1571 den Bruch. RFC 1408 habe VAR und VALUE gegenüber der BSD-Implementierung vertauscht. Der Text bezeichnete BSD als jene Referenzimplementierung, die der RFC hätte dokumentieren sollen, sowie als Grundlage vieler bestehender Implementierungen.

Das ist keine gemessene Verbreitungsstatistik. Es reicht jedoch für die sachliche Grenze: Unter Option 36 existierten zwei historische Lesarten. Ein Empfänger konnte aus der Optionsnummer allein nicht ableiten, welches Wörterbuch das Gegenüber benutzte.

Ein allgemeiner Träger für fremde Startinformationen

Viele Betriebssysteme besaßen Startdaten, die beim entfernten Login nützlich waren. Für jede neue Information eine eigene Telnet-Option zu definieren, hätte die gemeinsame Schicht mit lokalen Sonderfällen belastet. ENVIRON bot stattdessen einen allgemeinen Umschlag.

Als bekannte Variablen nannte RFC 1408 USER, JOB, ACCT, PRINTER, SYSTEMTYPE und DISPLAY. Beliebige Nutzerpaare liefen unter USERVAR. Die Klasse dokumentierte Herkunft, nicht Vertrauenswürdigkeit. Vorsichtige Implementierungen könnten beide Klassen gleichermaßen misstrauisch behandeln; Namenskollisionen blieben implementierungsspezifisch.

Standardmäßig fand kein Austausch statt: WONT ENVIRON, DONT ENVIRON. Mit WILL erklärte sich eine Seite zum Senden bereit, mit DO die andere zum Empfangen. Nur die DO-Seite durfte SEND beginnen; nur die WILL-Seite durfte mit IS antworten oder mit INFO spätere Änderungen melden.

Die Rollen trennten Möglichkeit, Anfrage und Wirkung. WILL war noch keine Übertragung. SEND bewies keine vorhandene Variable. IS gehörte zur anfänglichen Antwort, INFO konnte danach spontan Änderungen anzeigen. Keines dieser Ereignisse belegte die Anwendung auf dem Zielsystem.

Frühe Ankunft war kein Vertrauensbeweis

Bei vielen Systemen ließ sich eine Umgebung nur bei der Prozesserzeugung weitergeben. Deshalb musste der Austausch meist früh erfolgen, häufig vor dem Login. Gerade dort behielt der Server die Entscheidung.

RFC 1408 verpflichtete ihn nicht, alle empfangenen Werte einzusetzen. Unbekannte Namen durften ignoriert werden. USER oder ACCT konnten eine Login-Auswahl beeinflussen, ohne je in die spätere Umgebung zu gelangen. Eine bereits zuverlässiger bestimmte Information durfte Vorrang haben.

Wenn etwa Terminal-Type den Terminaltyp festgestellt hatte, durfte USERVAR TERM=xterm verworfen werden. Bei einem Konflikt zwischen DISPLAY und der eigenen X-Display-Location-Option sollte die zuletzt empfangene Information gelten. Beide Beispiele zeigen: Das gemeinsame Format transportierte konkurrierende Aussagen bis zur lokalen Auflösung; es ersetzte sie nicht.

USER bezeichnete daher das gewünschte Konto, keine authentifizierte Person. PRINTER besaß damals nicht einmal ein einheitliches Netz-Namensformat und belegte weder Erreichbarkeit noch Druck. DISPLAY bewies keine X-Verbindung und keine sichtbare Ausgabe.

Der Sicherheitsteil warnte vor Variablen, die schon vor dem Login das Authentifizierungsprogramm beeinflussen. Eine unsichere Wahl könne Umgehung oder Kompromittierung ermöglichen. Der RFC dokumentierte keinen konkreten Angriff; er markierte die Trennlinie zwischen entfernter Eingabe und lokaler Ausführungsbefugnis.

Grammatik wurde zum Messinstrument für Kompatibilität

Option 36 enthielt kein Versionsfeld für ihre beiden Wörterbücher. RFC 1571 musste daher aus Formen schließen.

Ein SEND durfte lediglich VAR und USERVAR enthalten. Traf der Client nach seinem eigenen Wörterbuch auf VALUE, war das ein Hinweis auf die umgekehrte Serverdefinition. Er sollte die Interpretation für den Rest der Anfrage sowie beim Erzeugen von IS oder INFO umstellen. Enthielt die Anfrage weder Null noch Eins, fehlte jede Probe; dann galt die veröffentlichte Ordnung als Annahme.

Beim Server konnten IS und INFO legitime Werte enthalten. Unmittelbares VAR deutete auf RFC-Reihenfolge, unmittelbares VALUE auf die umgekehrte. Begann die Folge mit USERVAR, waren weitere Prüfungen nötig: aufeinanderfolgende Marker, leere Marker, Mengenverhältnisse und Zeichenketten, die wie bekannte Variablennamen aussahen.

Das Verfahren authentifizierte niemanden. Es klassifizierte, welche historische Syntax die Bytes plausibel machte. Manche Beobachtungen waren stark, weil die andere Lesart illegal wäre; manche nur wahrscheinlich. Scheiterten alle Tests, wurde die publizierte Definition angenommen. Diese Vorgabe verwandelte Unwissen nicht in Messung.

Ein sauberer Endwert reicht daher nicht für eine spätere Prüfung. Benötigt werden Rohbytes, Optionsnummer, Richtung, Aushandlungszustand, Decoderstand, gewähltes Wörterbuch, auslösende Regel und verbleibende Unsicherheit.

Option 39 gab der Eindeutigkeit einen eigenen Namen

RFC 1572 behielt VAR=0, VALUE=1, setzte die Grammatik aber unter die neue Nummer 39: NEW-ENVIRON. Der neue Wert ermögliche Interoperabilität ohne Mehrdeutigkeit, erklärte der Text.

Eine weitere Deklaration für Nummer 36 hätte nicht verraten, welcher alte Binärstand am Gegenende lief. Die Aushandlung von 39 wählte hingegen zugleich eine neue Kennung und eine einzige Grammatik. Die Korrektur beanspruchte keine rückwirkende Herrschaft über Installationen; sie eröffnete einen deterministischen Zukunftspfad.

Das IANA-Register der Telnet-Optionen führt weiterhin 36 als Environment Option aus RFC 1408 und 39 als New Environment Option aus RFC 1572. Der Eintrag bewahrt die Trennung. Er beweist weder Implementierung noch erfolgreiche Aushandlung, Prozesszustand oder Ergebnis.

Auch NEW-ENVIRON blieb standardmäßig aus, richtungsbezogen ausgehandelt und der lokalen Validierung unterworfen. Die gemeinsame Schicht bestimmte den Drahtsinn. Der Empfänger bestimmte weiterhin die operative Zukunft.

Ein dekodiertes Feld war nur eine Zwischenstufe

Die Beweiskette umfasst veröffentlichte Zuordnung, Wörterbuch des Senders, Rohbytes, Lesart des Empfängers, Heuristik, Kandidatenpaar, Herkunftsklasse, lokale Annahme, Prozesserzeugung, Anwendungssicht und Außenwirkung.

Veröffentlichung programmierte BSD nicht um. Aushandlung bewies keine Sendung. USER authentifizierte keine Identität. Annahme belegte keine Prozessvererbung. Prozesszustand belegte keine Ausführung. Jede Stufe verlangte ein eigenes Ereignis.

Quellen

Die Quellen belegen Grammatik, zeitgenössische BSD-Konfliktbeschreibung, Heuristiken, neue Nummer und Register. Sie belegen keine benannte Implementierung, Verbreitung, Attacke, Identität, erfolgreichen Login, angewandte Umgebung, ausgeführten Befehl oder heutiges Risiko.