Zusammenfassung

  • RFC 1258 dokumentierte BSD rlogin im September 1991 als verbreitete bestehende Implementierung, nicht als Internetstandard. Die Verbindung begann mit einer leeren Zeichenkette, Client- und Server-Benutzernamen sowie Terminaltyp und -geschwindigkeit.
  • Passwortloser Zugang beruhte auf lokal konfigurierten vertrauten Benutzern oder Hosts. Der RFC warnt, dass ein kompromittierter vertrauenswürdiger Host alle so konfigurierten Systeme öffnen kann, dass der Host gewöhnlich durch einen Namen bestimmt wird und dass eine beschreibbare Vertrauensdatei unzuverlässige Einträge aufnehmen kann.

Die ersten Felder beschrieben einen Wunsch

Nach dem TCP-Aufbau sendete der Client vier nullterminierte Strings. Der erste war leer, danach folgten der vom Client genannte Benutzer, das gewünschte Serverkonto und Angaben zum Terminal. Ein Nullbyte vom Server bedeutete, dass diese Informationen empfangen waren und die Datenübertragung begann.

Die Sequenz enthielt also nützliche, aber verschiedenartige Aussagen. Sie machte eine gewünschte Sitzung und ihre Darstellung verständlich. Sie bewies weder, wer den Client bediente, noch wem der Ursprungshost gehörte, noch wer eine Ausnahme in der Serverkonfiguration erlaubt hatte. Auch der Eintritt in den Datenmodus bestätigte nur eine Protokollphase.

RFC 1258 verlieh diesen Angaben selbst keinen überzogenen Rang. Das Dokument beschreibt eine oft verwendete Unix-Praxis, ausdrücklich keinen Internetstandard. Rlogin konnte Terminalsemantik transportieren und dennoch die Identitätsfrage offenlassen.

Die Regel vertraute dem Namen als Eingabe

Passwortverzicht entstand erst durch die empfangende Seite. Sie konnte eine Klasse vertrauter Benutzer und/oder Hosts festlegen. Ein vertrauter Host wurde gewöhnlich über einen Hostnamen angegeben. Damit wurde der Name zum Input einer Zulassungsregel, nicht zur unabhängigen Bestätigung des Rechners.

Der RFC benennt die Lücke: Wird der Namensserver einer Organisation oder ihr Netz kompromittiert, kann sich ein nicht vertrauter Host als vertrauenswürdiges System ausgeben. Ebenso können unzuverlässige Ergänzungen in eine Liste vertrauter Logins gelangen, wenn deren Datei für andere Nutzer beschreibbar bleibt. Die korrekten Startstrings verraten keine dieser Veränderungen. Namensauflösung, Schreibhoheit über die Liste und der Protokollbeginn bleiben getrennte Beweislagen.

Eine Vertrauenskante verband mehr als zwei Rechner

Die Warnung des RFC gilt allen Systemen, die denselben Host akzeptieren: Ist einer der vertrauten Hosts kompromittiert, kann der Passwort-Bypass sie öffnen. Die lokale Bequemlichkeit hatte daher eine Reichweite, die über die erste Sitzung hinausging.

Jeder Eintrag fügte einer Menge von Systemen eine geerbte Herkunftsbehauptung hinzu. Die Anzahl und Richtung dieser Kanten bestimmen, wie weit ein Fehler oder eine Kompromittierung wirken kann. Der im RFC erwähnte engere Zuschnitt — eine Workstation darf zu anderen eigenen Systemen, statt dass alle einander vertrauen — liefert keinen Identitätsbeweis. Er begrenzt nur den Kreis der Systeme, die dieselbe Ausnahme übernehmen.

Dass RFC 1258 sichere Authentisierungserweiterungen wie Kerberos nennt, macht die historische Unterscheidung sichtbar. Eine Regel, die Eingabe spart, und ein Mechanismus, der Authentisierung liefert, sind nicht nachträglich dasselbe geworden.

Quellen und Grenzen

Dieser Beitrag verwendet RFC 1258 — BSD Rlogin. Er belegt den historischen Dokumentstatus, Startfelder, Datenmodus, Hostvertrauen und die genannten Warnungen. Er belegt keine heutige Nutzung, keinen aktuellen Portstatus, keinen konkreten Einbruch, keine Identität, keine Berechtigung und kein Sitzungsergebnis.