Network Working Group M. St. Johns
Request for Comments: 1413 US Departement of Defense
Obsoletes: 931 Februar 1993
Identification Protocol
(Uebersetzung ins Deutsche von Marc Ruef
< marc.ruef@computec.ch > am 3. Maerz 2001)
Status dieses Memos
Dieses RFC schreibt einen IAB-Standard in Form eines Protokolls der Internet-
Gemeinde vor, und bangt auf Vorschlaege und Verbesserungen in Form einer
Diskussion. Den Status dieser Protokoll-Spezifikation entnehmen Sie bitte dem
"IAB Official Protocol Standards". Das Vervielfaeltigen dieses Dokuments ist
uneingeschraenkt moeglich.
1. EINFUEHRUNG
Das Identifikation-Protokoll (aka. "ident", aka. "das Ident-Protokoll")
stellt einen Service zur Verfuegung, um die Identitaet des Benutzers einer
bestimmten TCP-Verbindung zu bestimmen. Diese Identifizierung wird durch
Rueckgabe einer Zeichenkette vollfuehrt, die durch einen Verbindungsaufbau
zu einem spezifizierten TCP-Port vom Server-System zurueckgegeben wird.
Das Ident-Protokoll wurde urspruenglich das Authentifikations Server
Protokoll genannt. Das Protokoll wurde daher umbenannt, um den Nutzen
des Systems besser darstellen zu koennen. Dieses Dokument ist somit ein
Resultat der TCP Client Identity Protocol Working Group der Internet
Engineering Task Force (IETF).
2. UEBERBLICK
Dies ist eine verbindungsorientierte, auf TCP basierende Applikation. Ein
Server horcht auf TCP-Port 113 (dezimal). Ist eine Verbindung zu diesem Port
zustandegekommen, liest der Server die Wuensche des Clients ein. Falls eine
kompetente Antwort auf die Frage gegeben werden kann, schickt der Server
die richtige Reply. Ist dieser Vorgang beendet, wird die bestehende TCP-
Verbindung durch den Server terminiert, um auf weitere Anforderungen zu
hoeren.
Der Server sollte eine Verbindung je nach Konfiguration bei ungetaetigter
Anfrage zwischen 60 und 180 Sekunden unterbrechen. Der Client ist berechtigt
nach Belieben eine Verbindung zu terminieren. Es empfiehlt sich jedoch je
nach Netzwerkstruktur die Wartezeit von mindestens 30 Sekunden einzuhalten.
3. BESCHRAENKUNGEN
Anfragen werden lediglich als komplett spezifizierte Verbindungen erlaubt.
Eine solche Anfrage beinhaltet das TCP-uebliche Port-/Adress-Paar (Socket)
um parallele Anforderungen stoerungsfrei vollziehen zu koennen. Damit ist
gleichzeitig gemeint, dass der Benutzer am Host A durch eine Anfrage beim
Server B lediglich Informationen zwischen Host A und Server B in Erfahrung
bringen kann.
4. ANFRAGE-/ANTWORT-FORMAT
Der Server nimmt einfache Text-Anfragen in der folgenden Form an:
< Port beim Server > , < Port beim Client >
Bei der Angabe des Ports beim Server wird der TCP-Port des ident-
Dienstes am Server-Computer in dezimaler Schreibweise angegeben. Die
Angabe des Ports beim Client gilt als Darlegung des Quell-TCP-Ports beim
Client-System.
Moechte der Client auf dem Host A eine Anfrage beim Server B ueber die
lokale Verbindung (auf der Client-Maschine) auf TCP-Port 23, 6191 (eine
interne Telnet-Verbindung) machen, so muss der Client nach 6191, 23 fragen,
welches die Spezifizierung der Verbindung aus Sicht des Servers B wieder-
spiegelt.
Zum Beispiel:
6191, 23,
Die Antwort ist von folgender Form:
< Port beim Server >, < Port beim Client >: < Antwort-Typ >: < Zusaetzliche
Information >
< Port beim Server >, < Port beim Client > sind das identische Paar wie bei
der urspruenglichen Anfrage. < Antwort-Typ > definiert mit einem spezifizierten
Schluesselwort den Antwort-Typ und < Zusaetzliche Information > ist vom
Zusammenhang abhaengig.
Die retournierten Informationen sind den Socket-Spezifikationen einer TCP-
Verbindung unterworfen: < Server-Adresse >, < Client-Adresse >, < Port beim
Server > und < Port beim Client >. Bei einem Verbindungsaufbau zu einem Server
wird als < Server-Adresse > die Adresse des entfernten Rechners und als
< Client-Adresse > jene des lokalen Rechners angegeben.
Zum Beispiel:
6193, 23 : USERID : UNIX mruef
6195, 23 : ERROR : NO-USER
5. ANTWORT-ARTEN
Eine Antwort kann eine von zwei Arten sein:
USERID
In diesem Fall ist < Zusaetzliche Information > eine Zeichenkette, welche
das Betriebssystem spezifiziert (mit optionaler Angabe des Zeichensatzes),
gefolgt von einem Doppelpunkt (":") und einem Identifikations-String.
Der Zeichensatz (falls gegenwaertig) wird von der Angabe des
Betriebssystes durch ein Komma (",") getrennt. Die Angabe des
Zeichensatzes spezifiziert den Zeichensatz der Identifikations-Antwort.
Standardmaeßig wird als Zeichensatz "US-ASCII" verwendet (siehe unten).
Erlaubte Betriebssystemnamen und Zeichensatznamen sind in RFC 1340 und
seinen etwaigen Nachfolger spezifiziert.
Zusaetzlich zu all jenen Betriebssystem- und Zeichensatznamen ist ein
weiterer Begriff mit einer Sonderstellung versehen - "OTHER".
Ausser wenn "OTHER" als Betriebssystem spezifiziert worden ist, wird, wie
man es standardmaeßig vom Server erwartet, die "normale" Benutzer-
identifikation des Besitzers einer Verbindung zurueckgegeben. "Normal"
bedeutet in diesem Zusammenhang, dass der normale Benutzername angegeben
wird; so wie dies auch durch den Administrator bei der Verteilung von
elektronischer Post oder der Authentifikation bei Arbeitssitzungen
Verwendung findet. Wird ein Betriebssystem spezifiziert (also alles ausser
"OTHER" angegeben), so muss die Benutzeridentifizierung in verwertbarer
Form angegeben werden. Zum Beispiel um die Ausgabe als Argument fuer
eine "finger"-Anfrage oder als Mail-Adresse nutzen zu koennen.
"OTHER" zeigt an, dass die Benutzeridentifizierung unformatiert ist, und
lediglich druckbare Zeichen des exotischen Zeichensatzes genutzt werden.
"OTHER" sollte genutzt werden, wenn die Benutzeridentifizierung nicht
den Bestimmungen im vorausgegangenen Abschnitt nachempfunden wurden. Das
Versenden von verschluesselten Token, oder die Rueckgabe einer non-userid
Information ueber einen Benutzer (zum Beispiel den Realname and die
Telefonnummer des Benutzers aus der UNIX-passwd-Datei) sind gute Beispiele
fuer Situationen, wo "OTHER" nuetzlich sein kann.
Retournierte Benutzeridentifikationsinformationen sind als druckfaehige
Zeichen des gewaehlten Zeichensatzes auszuwaehlen und anzuzeigen.
Die Identifikationsinformationen werden als unformatierte oktale
Zeichenkette publiziert. Alle Oktette ausser octal 000 (NUL), 012 (LF) und
015 (CR) sind zulaessig. Achtung: Leerzeichen (040) gefolgt von einem
Semikolon (";") sind Teil der Identifikationsinformation und duerfen nicht
ignoriert werden. Eine Antwort ist stets mit CR/LF abgeschlossen. Achtung:
Eine Zeichenkette muss stets druckfaehig, aber durch den Druck nicht
*zwingend* sichtbar sein.
FEHLER
Aus irgendeinem Grund koennte der Port-Besitzer nicht identifiziert werden;
< Zusaetzliche Information > verraet normalerweise wieso. Die folgenden
Aussagen spiegeln die moeglichen Wahlen und entsprechenden Bedeutungen von
< Zusaetzliche Information > wieder:
INVALID-PORT
Entweder war der lokale oder entfernte Port unpassend definiert.
Dies sollte zurueckgegeben werden, wenn einer oder beide Portnummern
ausserhalb des spezifizierten Nummernbereichs (TCP-Portnummern
reichen von 1 bis 65535), negative Ganzzahlen oder Nicht-Zahlen
gewaehlt wurden.
NO-USER
Die Verbindung, die vom Port-Paar vorgeschrieben wird, ist
gegenwaertig nicht im Gebrauch oder momentan nicht Im Besitz eines
identifizierbaren Benutzers.
HIDDEN-USER
Der Server war zwar in der Lage den Besitzer eines Ports zu
identifizieren, durfte diese Information jedoch auf Bitten dessen
nicht liefern.
UNKNOWN-ERROR
Der Besitzer einer Verbindung konnte nicht bestimmt werden; der
Grund ist unbekannt. Irgendein Fehler, der keiner der oben genannten
Vorstellungen entspricht ist aufgetreten. Optional kann dieser Code
als Ersatz fuer einen anderen zurueckgegeben werden, zum Beispiel
moechte der Server Informationen aus sicherheitstechnischen oder
-politischen Gruenden zurueckhalten. Wird dieses Feature
implementiert, so muss es konfigurierbar und darf nicht als Standard-
Einstellung fuer einen anderen Error-Code definiert sein.
Andere Werte werden vielleicht in zukuenftigen Revisionen
dieses Dokuments spezifiziert und definiert. Moechte eine Implementation mit
einem nicht-standardisierten Error-Code aufwarten, so muessen jene mit einem
"X" beginnen.
Dem Server wird ausserdem erlaubt die Anfrage ohne Antwort zu verwerfen
(engl. drop). Irgendein vorzeitiges Ende (d.h., wo der Client kein EOL
erhaelt) ob gewollt oder ungewollt wird mit "ERROR : UNKNOWN-ERROR" quittiert.
FORMELLE SYNTAX
< Anfrage > ::= < Port-Paar > < EOL >
< Port-Paar > ::= < Ganzzahl > "," < Ganzzahl >
< Antwort > ::= < Antwort-Text > < EOL >
< EOL > ::= "015 012" ; CR-LF Ende der Zeile
< Antwort-Text > ::= < Fehler-Antwort > | < ident-Antwort >
< Fehler-Antwort > ::= < Port-Paar > ":" "ERROR" ":" < Fehler-Typ >
< ident-Antwort > ::= < Port-Paar > ":" "USERID" ":" < opsys-Feld >
":" < Benutzer-ID >
< Fehler-Typ > ::= "INVALID PORT" | "NO-USER" | "UNKNOWN-ERROR"
| "HIDDEN-USER" | < Fehler-Token >
< opsys-Feld > ::= < opsys > [ "," < Zeichensatz >]
< opsys > ::= "OTHER" | "UNIX" | < Token > ...etc.
; (Siehe "uebertragene Nummern")
< Zeichensatz > ::= "U.S.-ASCII" | ...etc.
; (Siehe "uebertragene Nummern")
< Benutzer-ID > ::= < Oktett-Kette >
< Token > ::= 1*64< Token-Zeichen > ; 1-64 Zeichen
< Fehler-Token > ::= "X"1*63< Token-Zeichen >
; 2-64 Zeichen-Anfang w/X
< Ganzzahl > ::= 1*5< Ziffer > ; 1-5 Ziffern.
< Ziffer > ::= "0" | "1" ... "8" | "9" ; 0-9
< Token-Zeichen > ::=
< Keine dieser ASCII-Zeichen: a-z, A-Z,
- (Bindestrich), .!@#$%^&*()_=+., < > /"?'~`{}[]; >
; Zusaetzlich Grossbuchstaben (a-z)
; Druckbares Minus und der Doppelpunkt (":")
; Zeichen.
< Oktett-Kette > ::= 1*512 < Oktett-Zeichen >
< Oktett-Zeichen > ::=
< irgendein Oktett von 00 bis 377 (oktal) ausser
ASCII NUL (000), CR (015) und LF (012) >
Notizen zur Syntax:
1) Um eine Kompatibilitaet mit anderen Implementationen gewaehrleisten zu
koennen empfiehlt sich mit Respekt an die Philosophie mit dem Grundsatz
"sei konservativ in dem was Du sendest und sei liberal in dem was Du
ampfaengst" zu halten. Clients und Server sollten nicht unnoetige
Leerzeichen (Space- und Tabulator-Zeichen) produzieren. Sie sollten
jedoch einen Ueberschuss derer in einer Uebergabe richtig verarbeiten
koennen. Leerzeichen sind jedoch vor und nach einer Ausgabe erlaubt;
nicht jedoch mittendrin. Dies gilt nicht fuer die Uebergabe der
Benutzer-ID, da alles nach dem abschliessenden Komma des Betriebssystems
bis zum terminierenden CR/FL als Teil einer Benutzer-ID gewertet werden
muss. Die abschliessende CR/FL-Sequenz ist NICHT Teil der Benutzer-ID.
2) Sollte das oben erwaehnte sich nicht komplett verhindern lassen, so
ist es fuer alle Beteiligten von Vorteil, wenn der Server den
Ueberschuss an unnoetigen Leerzeichen so gut als moeglich einzudaemmen
versucht. Clients sollten sich das Recht vorbehalten duerfen nach
Erhalt von mehr als 1000 Leerzeichen ohne temporaer abschliessendes
< EOL > die Verbindung automatisch abzubrechen.
3) Die Begrenzung von 512 Zeichen fuer eine Benutzer-ID and die
Begraenzung von 64 Zeichen auf die Token sollen wie folgt gewertet
werden: a) Kein neues Token (d.h. OPSYS oder FEHLER-TYP) wird definiert,
wenn es mehr als 64 Zeichen umfassen sollte und b) ein Server darf nicht
mehr als 512 Oktette in Form einer Benutzer-ID versenden, der Client
muss jedoch mindestens 512 solcher verarbeiten koennen. Aufgrund dieser
Restriktion muss der Server den essentiellen Teil der Benutzer-ID in die
512 erlaubten ersten Portionen setzen.
4) Der Zeichensatz und die Identifikation dessen wird direkt mit den
Spezifikationen aus RFC 1340 und dessen Nachfolgern in Verbindung
gebracht. Der spezifische Zeichensatz bezieht sich lediglich auf das
Feld der Benutzer-ID - Alle anderen Felder muessen in US-ASCII gesendet
werden.
5) Obwohl < Benutzer-ID > als eine Zeichenkette im oktalen Format uebertragen
wird, muss es sich im Format und Zeichensatz den Zwaengen des < opsys-
Feld > anpassen; siehe dazu die Diskussion oben.
6) Der retournierte, durch den Zeichensatz definierte Inhalt der Benutzer-
Identifikation muss durch den Client durch- oder speicherbar sein. Ist
dies aufgrund fehlender Kompatibilitaet dem Client nicht moeglich, so
muss mit Oktetten gearbeitet werden; zusaetzlich ist der fehlende
Zeichensatz beim Client zu vermerken. Eine Oktett-Zeichenfolge muss
in hexadezimaler Schreibweise (0-9a-f) gedruckt, gespeichert und
verarbeitet werden um eine gewisse Kompatibilitaet zwischen den
differenten Implementierungen gewaehrleisten zu koennen.
6. Sicherheitsueberlegungen
Die Informationen, die mit diesem Protokoll bereitgestellt werden koennen
sind meistens als vertrauenswuerdig einzustufen. Aus diesem Grund macht es
Sinn den Dienst nur vertrauenswuerdigen Personen und Organisationen
bereitzustellen. Zum Beispiel macht es wenig Sinn in einem oeffentlichen
Labor zusaetzliche Kontrollmechanismen einzurichten. Ebenso wird ein
Angreifer auf einem schon kompromittierten System dem ident-Protokoll wenig
Aufmerksamkeit schenken: Die Informationen sind nicht wirklich
vertrauenswuerdig.
Das Identifikations-Protokoll wurde nicht konzipiert um eine Authenti-
fizierung oder Zugangskontrolle in Form eines einheitlichen Protokolls
zu gewaehrleisten. Es stellt bestmoeglich einen zusaetzlichen Dienst zur
Verfuegung um weitere Informationen ueber TCP-Verbindungen in Erfahrung zu
bringen. Im schlechtesten Fall koennen falsche, fehlerhafte oder boshaft
inkorrekte Informationen verbreitet werden.
Da die auf diesem Protokoll basierenden Antworten als nicht wirklich
vertrauenswuerdig eingestuft werden koennen, wird das Resultat ihrer
Ueberpruefung als entmutigend entgegengenommen werden muessen. Das Nutzen des
ident-Protokolls als einzige Zugangskontrolle und Authentifikations-
Moeglichkeit muss als Einbruch in die Systemsicherheit betrachtet werden.
Ein Identifikations-Server enthuellt vielleicht Informationen ueber Benutzer,
Entitaeten, Objekte oder Prozesse, welche normalerweise als privat eingestuft
werden - Er stellt jedoch in erster Linie einen Dienst bereit, der grob
vergleichbar mit den CallerID-Diensten einiger Telefongesellschaften ist.
Viele Ueberlegungen zur Wahrung der Privatsphaere werden diese Dienste als
ueberfluessig oder gefaehrlich einschaetzen lassen. So ist es, genauso wie
beim finger-Dienst, fragwuerdig, ob man in sicherheitsbewussten Umgebungen
dieses Protokoll nutzen moechte.
7. ANMERKUNGEN
Anmerkungen zum Protokoll selber werden bitte direkt an Dan Bernstein
gerichtet, der primaer fuer das Erneuern der Protokoll-Spezifikationen in
RFC 931 zustendig ist.
Anmerkungen zur Uebersetzung ins Deutsche werden bitte direkt an Marc Ruef
gerichtet.
Referenzen
[1] St. Johns, M., "Authentication Server", RFC 931, TPSC, Januar 1985.
[2] Reynolds, J., und J. Postel, "Assignet Numbers", STD 2, RFC 1340, USC/
Information Sciences Institute, Juli 1992.
Adresse der Autoren
Michael C. St. Johns
DARPA/CSTO
3701 N. Fairfax Dr
Arlington, VA 22203
Telefon: +1 703 696-2271
E-Mail : stjohns@DARPA.MIL
Marc Ruef
Neufeldstrasse 13b
5430 Wettingen
Schweiz
Telefon: +41 (0)79 / 295 40 14
E-Mail : marc.ruef@computec.ch
|