Zusammenfassung

  • Der empfangende Host öffnete eine zweite TCP-Verbindung zurück zu Port 113. Die Adressen dieser Abfrage und das aus Sicht des antwortenden Hosts geordnete Portpaar bezeichneten einen Eintrag in dessen lokalem Verbindungszustand.
  • Aus dem Authentication Service von 1984 und dem Authentication Server Protocol von 1985 wurde 1993 das Identification Protocol. Der neue Name zog die behauptete Funktion auf die tatsächlich vorhandene Evidenz zurück.
  • RFC 1413 erlaubte USERID als Audit-Hinweis, untersagte aber seine Nutzung zur Zugriffskontrolle. HIDDEN-USER und UNKNOWN-ERROR machten sichtbar, dass Fähigkeit und Offenlegungspolitik des fremden Hosts das Ergebnis bestimmten.

Vier Felder und eine begrenzte Behauptung

A verbindet seinen lokalen Port 6191 mit Port 23 auf B. B möchte wissen, welchem Benutzer A diese Verbindung zuordnet. Dazu öffnet B eine neue TCP-Verbindung zu Port 113 auf A und sendet 6191, 23.

Die Reihenfolge folgt der Sicht des Antwortenden. Für A ist 6191 lokal und 23 entfernt; B hatte dieselbe ursprüngliche Verbindung umgekehrt gesehen. Eine Abfrage 23, 6191 bezeichnet einen anderen Zustand.

RFC 1413 übernimmt die IP-Adressen aus der TCP-Verbindung, die die Abfrage trägt. Zusammen mit den zwei Ports entsteht eine vierteilige Eingrenzung. Gefragt wird nicht nach allen Konten auf A und nicht nach einer globalen Identität. A soll in seinem lokalen Zustand genau die Verbindung zwischen A und B finden.

Eine USERID-Antwort wiederholt das Portpaar, nennt einen Betriebssystemtyp und liefert eine Zeichenfolge. Eine Zeichensatzangabe kann ihre Darstellung klären. Der Wert OTHER erlaubt sogar ein undurchsichtiges Token statt eines gewöhnlichen Kontonamens. Der Empfänger darf daraus weder ein Unix-Konto noch eine weltweit eindeutige Person ableiten.

Als der Titel noch Authentifizierung versprach

RFC 912 beschrieb im September 1984 einen Authentication Service auf Port 113. Ein FTP-Server sollte etwa einen in der Anwendung angegebenen Namen mit dem Benutzer vergleichen können, dem der entfernte Host die TCP-Verbindung zuschrieb. Auch privilegierte Operationen wurden erwogen.

Schon diese Fassung verlangte Vertrauen in die Verwaltung des fremden Rechners, seine Kontoführung und seinen Schutz gegen lokale Manipulation. Ein kompromittierter Host konnte die gewünschte Antwort erzeugen.

RFC 931 formalisierte im Januar 1985 das Authentication Server Protocol. Portpaar, USERID oder ERROR und OPSYS wurden festgelegt; lokale Zugriffsmappings wurden als Möglichkeit behandelt. Die Hoffnung war nachvollziehbar: Wenn A den Verbindungsbesitzer kennt, könnte B diese Kenntnis übernehmen.

Aber eine lokale Zuordnung ist kein Berechtigungsnachweis. Das Verfahren bewies nicht die Person an der Tastatur, schützte die Antwort nicht kryptografisch und schuf keine gemeinsame Bedeutung gleichlautender Namen über Organisationsgrenzen hinweg.

Der neue Name korrigierte die Vertrauenskette

Im Februar 1993 ersetzte die IETF-IDENT-Arbeitsgruppe RFC 931 durch RFC 1413. „Identification Protocol“ sollte die Funktion genauer beschreiben.

Die Sicherheitsregel ist eindeutig: Die Information ist höchstens für Audit-Zwecke nützlich und darf nicht als Zugriffskontrollkennung dienen. Öffnet B eine Ressource allein aufgrund der Antwort alice, kann A für jede Verbindung alice behaupten. Die Rückverbindung hat keine von A unabhängige Instanz geschaffen.

Identification bezeichnet hier die Zuordnung, die A zwischen einem TCP-Fluss und einer lokalen Kennung meldet. Sie authentifiziert keinen Menschen, gleicht keine Konten zweier Organisationen ab und genehmigt keine Handlung.

Gerade diese Begrenzung schafft einen sauberen Nutzen. B speichert Name, Zeit, Adressen, Ports und Anwendungsvorgang. A kann später mit Sitzungs-, Prozess- und Verbindungsdaten korrelieren. Das Ergebnis führt zwei Betreiber zum selben Vorfall, entscheidet ihn aber nicht allein.

Richtung und Zeit gehören zum Beleg

Die Umkehrung des Portpaars bewahrt die Rollen. Die Zeit bewahrt die Verbindung. Flüchtige Ports werden wiederverwendet; ein Paar ohne Zeitpunkt kann später zu einem anderen Fluss gehören. Eine prüfbare Spur umfasst daher beide Adressen, beide Ports, Richtung und Zeit des Originals sowie die vollständige IDENT-Abfrage.

Dass die Adressen aus der Abfrageverbindung stammen, reduziert Mehrdeutigkeit. Es stellt keine kryptografische Bindung her. Der fremde Host kontrolliert weiterhin den Inhalt. Korrekte Syntax belegt, dass nach dem passenden Fluss gefragt wurde, nicht dass die Antwort wahr ist.

Empfohlen war eine Kennung, mit der der Administrator des Antwortenden das Ereignis wiederfinden konnte. Befehle oder Prozessdetails sollten nicht unnötig offengelegt werden. Das Verfahren war ein Korrelationskanal, kein Fenster für beliebige Ferninspektion.

Fehler beschreiben auch Datenschutz

INVALID-PORT bedeutet ungültiges Format oder einen unzulässigen Port. NO-USER bedeutet, dass kein Benutzer für die Verbindung bestimmt werden kann. HIDDEN-USER drückt eine bewusste Nichtoffenlegung aus. UNKNOWN-ERROR verbirgt interne Einzelheiten; ein Abbruch vor der Antwort wird ebenso behandelt.

Diese Ergebnisse beweisen wenig über den Benutzer. NO-USER bedeutet nicht anonym. HIDDEN-USER bedeutet nicht verdächtig. UNKNOWN-ERROR bedeutet nicht, dass keine Zuordnung existiert. Sie sagen nur, was der fremde Dienst zu diesem Zeitpunkt mitteilen kann oder will.

RFC 1413 vergleicht die Privatsphäre mit CallerID und Finger. Ein lokaler Kontoname wird zu einer neuen Offenlegung, wenn jeder Verbindungsgegner ihn abfragen kann. Abschalten, Verbergen oder ein Token sind legitime lokale Entscheidungen und verändern jeweils den Audit-Wert.

Die MIB spiegelte die Struktur, nicht die Gewissheit

RFC 1414 definierte eine MIB mit lokaler Adresse und Port sowie entfernter Adresse und Port als Indizes. Benutzerkennung und Status machten die gleiche Geometrie in einem Managementsystem abfragbar.

RFC 1414 ist heute Historic, RFC 1413 beim RFC Editor Proposed Standard. Daraus folgt keine aktuelle Verbreitungszahl. Die MIB wiederholt zudem: Die Identifikation ist nicht autoritativ und nicht zur Zugriffskontrolle geeignet. Struktur macht Daten auffindbar, nicht wahr.

Im heutigen IANA-Register für Dienstnamen und Ports stehen ident und der ältere Name auth bei TCP 113. Registriert wird der Treffpunkt, nicht das Konto, Betriebssystem, die Offenlegungspolitik oder Ehrlichkeit hinter einer Antwort.

Ein Benutzername ohne Schlüsselgewalt

Attribution fragt, welche lokale Kennung A einem Fluss zuordnet. Autorisierung fragt, welche Handlung B aufgrund eigener Regeln zulässt. Dass beide Vorgänge dieselbe Zeichenfolge sehen können, vereinigt ihre Zuständigkeiten nicht.

Die Abfrage war durch zwei Hosts, zwei Ports und einen Zeitpunkt begrenzt. Fehler gestanden Unwissen ein, HIDDEN-USER Geheimhaltung, die Sicherheitsregeln Täuschbarkeit. Innerhalb dieser Grenzen ergänzt USERID eine Chronologie. Außerhalb davon kann der fremde Host das Wort prägen, das eine Berechtigung auslöst.

Der Wechsel von Authentication zu Identification war deshalb keine sprachliche Kosmetik. Der Titel gab eine Macht auf, die der Austausch nie belegt hatte.

Quellen und Evidenzgrenzen

Die Quellen dokumentieren Spezifikationen, MIB und Dienstregistrierung. Sie messen keine heutige Verbreitung, Genauigkeit, Datenschutzpraxis oder Angriffshäufigkeit. Nicht belegtes Verhalten von NAT, Proxys oder Containern wird nicht angenommen.