Zusammenfassung

  • RFC 933 schlug OUTMRK, Telnet-Option 27, vor: Der Server sendet ein Sicherheitsbanner einmal, der User-Telnet hält es außerhalb der Anwendungsfläche sichtbar.
  • WILL/DO vereinbarten die Option; das konkrete Banner konnte der Empfänger weiterhin mit ACK oder NAK beantworten und lokal platzieren.
  • ACK bestätigte keine Einstufung, Berechtigung, Zugriffserlaubnis, kryptografische Bindung oder dauerhafte Darstellung auf dem echten Bildschirm.

Die RFC 933 von Januar 1985 behandelte einen Rand des Terminals. Bestimmte militärische Systeme ordneten einer Telnet-Verbindung eine Sicherheitsstufe zu und brauchten dafür ein sichtbares Banner. Bis dahin wurde der Hinweis als Teil jeder Bildschirmseite übertragen.

Das wiederholte Text, koppelte die Anwendung an die Seitengröße des entfernten Geräts und machte den Hinweis für Lösch- und Cursorbefehle anfällig. S. Silverman schlug eine andere Arbeitsteilung vor: Text und gewünschte Position einmal vom Server senden; Raumreservierung und Abbildung der Anwendung dem User-Telnet überlassen.

Die Option hieß OUTMRK und erhielt Code 27. Das IANA-Verzeichnis der Telnet-Optionen führt diese Zuordnung weiterhin. Es belegt die Nummer, nicht Implementierung, Verbreitung oder Wahrheit des Banners.

Die Option und der konkrete Text brauchten getrennte Antworten

Nach RFC 854 bot WILL OUTMRK den Versand von Markierungsdaten an; DO OUTMRK akzeptierte ihren Empfang. WON'T und DON'T lehnten ab. Ohne Einigung fand kein Austausch statt.

Erst danach sendete der Server IAC SB OUTMRK CNTL data IAC SE. CNTL bestimmte die Lage, data enthielt ASCII. War diese Markierung für den Client annehmbar, antwortete er mit ASCII ACK, Wert 6; andernfalls mit NAK, Wert 21.

Nach NAK durfte der Server akzeptablere Daten versuchen oder anders reagieren, bis hin zur Verbindungsbeendigung. Der RFC erklärte die Ablehnung nicht selbst zur Sicherheitsentscheidung. Ebenso bedeutete ACK nur, dass der Client diese Daten zur Anzeige akzeptierte.

RFC 855 beschreibt den Grund: Zuerst einigen sich beide Seiten darauf, Parameter zu besprechen; erst danach folgen sie in SB/SE. Deshalb sind DO, Banner-ACK und die Berechtigung zu einer Anwendungshandlung drei getrennte Tatsachen.

Der Client verwaltete eine bewegliche Grenze

Nach ACK musste User-Telnet Cursorbefehle so übersetzen, dass Anwendungsdaten in der verbleibenden Fläche blieben. Das Banner wurde zu lokalem Zustand. Ein Paketstrom konnte die Vereinbarung tragen, doch der Client musste sie unter realen Anzeigeverhältnissen erhalten.

D überließ die Position dem Client. T und B bezeichneten oben und unten. Für L und R nannte RFC 933 links und rechts, ließ deren genaue Bedeutung aber ausdrücklich offen. Ein gemeinsamer Optionscode ersetzte keine gemeinsame Geometrie.

CRLF trennte Zeilen. Mehrere Markierungen konnten, durch ASCII Group Separator getrennt, in einer Subnegotiation stehen. Fenstergrößenwechsel, Bildschirm-Löschung oder Emulatorfehler konnten die geschützte Fläche später trotzdem überdecken. Ein ACK im Trace beweist daher keinen fortdauernden sichtbaren Zustand.

Der Server beendete die Markierung mit WON'T. Der Client konnte sie mit DO anstoßen und mit DON'T verlassen, wenn nach der Einigung keine Markierungsdaten folgten. Ablehnung und Beendigung gehörten zum Vertrag.

Markierung und Zugriff waren verschiedene Kontrollen

RFC 933 berief sich auf die US-Kriterien für vertrauenswürdige Systeme. Die vom NIST offiziell archivierte Ausgabe des DoD 5200.28-STD erschien erst im Dezember 1985 und ersetzte die 1983 zitierte Fassung. Sie ist Kontext, kein Nachweis vollständiger RFC-Konformität.

Sie trennt lesbare Ausgabekennzeichnung und Mandatory Access Control. Die Kennzeichnung soll die Empfindlichkeit richtig darstellen und Überschreibungen auditierbar machen. Eine andere Kontrolle erzwingt Zugriffe zwischen Subjekten, Objekten und Geräten. Sichtbare Beschreibung und wirksame Entscheidung sind verwandt, aber nicht identisch.

OUTMRK definierte keine Signatur, keinen MAC, keine Frische, keine authentisierte Kanalbindung und keinen Namensraum für Stufen. Korrekte Syntax zeigt, dass ein Endpunkt Text als Markierung anbot. Für dessen Wahrheit braucht es die zuweisende Autorität, die Verbindung zur richtigen Sitzung und einen vertrauenswürdigen Darstellungsweg.

Das Banner konnte Nutzer vor einem unerwarteten Kontext warnen. Seine Wirkung entstand jedoch aus einer Kette: Einstufung, Texterzeugung, Protokollannahme, lokale Anzeige und separate Zugriffskontrolle.

Die Einsparung verschob die Verwahrung

Der Server wiederholte weniger und musste die entfernte Höhe nicht kennen. Dafür verwahrte der Client Banner, Raum, Cursorabbildung, Mehrfachmarkierungen und Größenänderungen. Die Arbeit verschwand nicht.

Ein Protokollvermerk „Option 27 aktiv“ reicht deshalb nicht. Benötigt werden vorgeschlagener Text, ACK/NAK, Platzierung, Lebensdauer, zugrunde liegende Richtlinie und spätere Zugriffsentscheidung. Sonst erhält ein vertrauter Streifen mehr Autorität als das Kontrollsystem, auf das er nur hinweisen sollte.

Quellen und Grenzen

Die geschlossene Grundlage bilden RFC 933, RFC 854, RFC 855, das IANA-Telnet-Verzeichnis und die NIST-Archivkopie von DoD 5200.28-STD. Sie belegen weder Verbreitung noch heutige Unterstützung, Produktkonformität, reale klassifizierte Sitzungen, korrektes Rendering, menschliches Verständnis oder Betriebserfolg.