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 am 3. Maerz 2001) Status dieses Memos Dieses RFC schreibt einen IAB-Standart 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 Standarts". 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: , 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: , : : , sind das Identische Paar wie bei der urspruenglichen Anfrage. definiert mit einem spezifizierten Schluesselwort den Antwort-Typ und ist vom Zusammenhang abhaengig. Die retournierten Informationen sind den Socket-Spezifikationen einer TCP- Verbindung unterworfen: , , und . Bei einem Verbindungsaufbau zu einem Server wird als die Adresse des entfernten Rechners und als 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 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. Standartmaessig wird als Zeichensatz "US-ASCII" verwendet (siehe unten). Erlaubte Betriebssystemnamen und Zeichensatznamen sind in RFC 1340 und seine 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 standartmaessig 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 Verwedung 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 koennt der Port-Besitzer nicht identifiziert werden; verraet normalerweise wieso. Die folgenden Aussagen spiegeln die moeglichen Wahlen und entsprechenden Bedeutungen von 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 Standart- Einstellung fuer einen anderen Error-Code definiert sein. Andere Werte werden vielleicht werden vielleicht in zukuenftigen Revisionen dieses Dokuments spezifiziert und definiert. Moechte eine Implementation mit einem nicht-standartisierten 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. FORMELLER SYNTAX ::= ::= "," ::= ::= "015 012" ; CR-LF Ende der Zeile ::= | ::= ":" "ERROR" ":" ::= ":" "USERID" ":" ":" ::= "INVALID PORT" | "NO-USER" | "UNKNOWN-ERROR" | "HIDDEN-USER" | ::= [ "," ] ::= "OTHER" | "UNIX" | ...etc. ; (Siehe "uebertragene Nummern") ::= "U.S.-ASCII" | ...etc. ; (Siehe "uebertragene Nummern") ::= ::= 1*64 ; 1-64 Zeichen ::= "X"1*63 ; 2-64 Zeichen-Anfang w/X ::= 1*5 ; 1-5 Ziffern. ::= "0" | "1" ... "8" | "9" ; 0-9 ::= /"?'~`{}[]; > ; Zusaetzlich Grossbuchstaben (a-z) ; Druckbares Minus und der Doppelpunkt (":") ; Zeichen. ::= 1*512 ::= Notizen zum Syntax: 1) Um eine Kompatibelitaet mit anderen Implementationen gewaehrleisten zu keonnen 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 die Verbindung automatisch abzubrechen. 3) Die Begraenzung 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 als eine Zeichenkette im oktalen Format uebertragen wird, muss es sich im Format und Zeichensatz den Zwaengen des 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 Kompatibelitaet 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 Kompatibelitaet 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 zusatendig 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