Zusammenfassung

  • Ident machte die Anfrage verbindungsspezifisch: Die Portnummern bezeichneten Server und Client so, wie der abgefragte Host sie sah; dieser lieferte die lokale Kennung für den betreffenden Socket.
  • RFC 931 schlug einen experimentellen Einsatz beim automatischen FTP-Login vor. RFC 1413 nannte den Dienst 1993 Identification Protocol und stellte klar, dass die Antwort höchstens die Prüfung von Verbindungen ergänzen, aber keine Authentifizierung oder Zugriffskontrolle tragen konnte.

Zwei Zahlen und die Sicht eines Hosts

Das anschauliche Beispiel in RFC 1413 wirkt zunächst wie eine Korrektur. Ein Endpunkt führt die Verbindung als 23, 6191; fragt der andere Endpunkt danach, muss er 6191, 23 senden. Die Verbindung ist dieselbe. Nur wer einen Port als lokal und den anderen als entfernt bezeichnet, hängt vom betrachteten Rechner ab.

Diese Umkehrung war der praktische Schlüssel des Protokolls. Ein Ident-Client verband sich mit TCP-Port 113 eines Hosts und sendete eine Zeile nach dem Muster <Port-am-Server>, <Port-am-Client>. Die IP-Adressen stammten aus der TCP-Verbindung zum Ident-Dienst selbst. Zusammen mit den zwei Ports bezeichneten sie eine bereits bestehende TCP-Verbindung. Der Server konnte daraufhin die systemabhängige Kennung zurückgeben, die sein eigenes System dieser Verbindung zuordnete.

Der Umfang der Anfrage war bewusst eng. Kein zentraler Dienst sollte eine Person im ganzen Internet finden. Ein Host sollte melden, welche lokale Benutzerzeichenfolge sein System einem bestimmten Socket zuwies. Eine USERID-Antwort enthielt Betriebssystem und Kennung; ERROR konnte melden, dass sich kein Besitzer feststellen ließ. RFC 1413 definierte außerdem HIDDEN-USER, falls der Server den Nutzer zwar erkannte, die Information auf dessen Wunsch aber zurückhielt.

Das war nicht dieselbe Abfragefläche wie beim früheren Name/Finger-Dienst. Eine leere Finger-Anfrage konnte einen Host um eine Liste der gerade angemeldeten Nutzer bitten. Ident wählte über das Portpaar eine einzelne TCP-Verbindung aus. Anwesenheitsliste und Socket-Kennung beantworten unterschiedliche Betriebsfragen. Der frühere Artikel zu Name/Finger behandelt die hostweite Präsenzgrenze.

„Authentication Server“ war ein Anwendungsvorschlag

Die Entwicklung beginnt mit RFC 912 von Mike St. Johns, der im September 1984 unter dem Titel „Authentication Service“ erschien. Vorgeschlagen wurde ein Dienst auf TCP-Port 113, der die Kennung des Besitzers einer bestimmten TCP-Verbindung zurückgeben sollte. Als mögliche Nutzung nannte der Text die automatische Benutzeranmeldung bei FTP und Prüfungen privilegierter Netzwerkaktionen. Zugleich warnte er, dass sich die Vertrauenswürdigkeit der Hosts stark unterscheide; die jeweilige Anwendung müsse selbst entscheiden, wie viel Vertrauen sie in eine Antwort setzt.

RFC 931 löste den Vorschlag im Januar 1985 ab. Die Antwort sollte nun formaler aus Betriebssystemname und Benutzerkennung bestehen. Für FTP skizzierte der Text einen USER-Befehl ohne Argument, auf den der Server möglicherweise den Authentifizierungsdienst anwenden würde. Diese Nutzung wurde ausdrücklich als experimentell bezeichnet; auch der Hinweis auf die unterschiedliche Host-Vertrauenswürdigkeit blieb bestehen. Das Memo dokumentiert einen Integrationsvorschlag, keinen breiten Einsatz in FTP-Servern.

Entscheidend ist die Trennung zwischen Protokollantwort und Anwendungsentscheidung. Der Authentication Server prüfte kein Passwort unabhängig und bewies nicht, wer vor einem Terminal saß. Er meldete, welche lokale Kennung der Host einer Verbindung zuordnete. Ein FTP-Server konnte diese Zeichenfolge verwenden; die Entscheidung und ihre Folgen lagen jedoch bei der Anwendung und ihrer Vertrauensbeziehung zum anderen Host.

1993 machte die Umbenennung die Grenze sichtbar

RFC 1413 erschien im Februar 1993, löste RFC 931 ab und benannte das frühere Authentication Server Protocol in Identification Protocol, kurz Ident, um — „to better reflect its function“. TCP-Port 113 und die verbindungsspezifischen Ports blieben erhalten. Der RFC erklärte genauer, wie mehrere Anfragen über eine Ident-Verbindung sowie Antworten wie HIDDEN-USER zu behandeln sind.

Die Sicherheitshinweise lassen kaum eine stärkere Auslegung zu. Die Informationen waren höchstens so vertrauenswürdig wie der Host oder die Organisation, die ihn betrieb. Ident war nicht für Autorisierung oder Zugriffskontrolle gedacht; im besten Fall ergänzte es Prüfinformationen über TCP-Verbindungen. Der RFC riet dringend von anderen Zwecken ab und warnte davor, dass der Dienst normalerweise private Informationen offenlegen kann.

Diese Grenze folgt aus dem Datenweg. Der abgefragte Host erzeugte die Kennung anhand der Sicht seines eigenen Betriebssystems. Ein kompromittierter Rechner konnte irreführende Angaben liefern; auf einem offenen Laborrechner konnte ein Nutzer womöglich selbst bestimmen, welche Kennung erschien. Eine syntaktisch gültige USERID-Zeile machte die Behauptung des Servers nicht zu einer unabhängig geprüften Tatsache. Der Client erfuhr, was der abgefragte Host meldete, nicht, ob eine Person an anderer Stelle authentifiziert worden war.

Die Namensänderung markiert deshalb eine nützliche historische Grenze, beweist aber nicht, dass alle früher vorgeschlagenen Einsätze endeten. RFC 1413 nannte den Dienst Identifikation statt Authentifizierung und schränkte ein, welche Schlüsse seine Antwort tragen sollte. Die RFCs zeigen weder, wie viele Standorte Ident betrieben, noch wie oft HIDDEN-USER zurückkam oder welche FTP-Programme davon abhingen. Ein Standardtext dokumentiert den Protokollvertrag, nicht die Verbreitung.

Was sich aus dem Portpaar ableiten lässt

In einem Audit-Protokoll kann eine hostseitige Kennung hilfreicher Kontext sein, wenn Host, Verbindungsrichtung, Ports, Zeitpunkt und Antwort gemeinsam erhalten bleiben. Sie kann zeigen, welches lokale Konto der andere Endpunkt einem Socket zuordnete. Sie belegt nicht, dass die genannte Person den Verkehr ausgelöst hat, den entfernten Rechner kontrollierte oder zum Zugriff auf die Anwendung berechtigt war.

Die Geschichte des Protokolls dreht sich um diese Trennung. RFC 931 beschrieb einen möglichen Weg, wie eine Anwendung eine entfernte Benutzerkennung verwenden könnte. RFC 1413 benannte den Dienst nach der Identifikation, die er tatsächlich zurückgab, und warnte davor, diesen Bericht als Autorität zu behandeln. Das Portpaar machte eine konkrete Verbindung für ihren Host lesbar. Die Vertrauensentscheidung blieb bei dem System, das über die Verwendung der Antwort bestimmte.

Quellen