Kerberos eine Frage des Vertrauens von Peter Wächtler  In den heutigen Netzwerken liegen immer mehr vertrauliche Daten. Diese sind zwar mit Zugriffsbeschränkungen versehen - doch Zweifel bleiben. Gibt sich jeder als der aus, der er wirklich ist?

Annahmen und Behauptungen

Eine hervorzuhebende Eigenschaft ist die Tatsache, daß sich der Client nur einmal im Netzwerk auszuweisen hat. Bei der erstmaligen Anmeldung fordert der Client ein ticket-granting ticket (TGT) an, das weiteren transparenten Zugriff auf andere Resourcen im Netz ermöglicht ohne erneut ein Paßwort abzufragen. Damit wird auch verhindert, daß der Client den privaten Schlüssel oder das Paßwort zwischenspeichern muß - der würde sonst auch in einem Speicherabzug (core dump) zu finden sein. Außerdem wurde beim Design darauf geachtet, den Aufwand gering zu halten, um bei häufig notwendigen Authentifizierungen keine unzumutbaren Verzögerungen heraufzubeschwören, die bei Diensten wie http auftreten können.

Kerberos setzt die Geheimhaltung der Schlüssel voraus. Der private Schlüssel des Benutzers wird u.a. aus dem Bezeichner und dem Paßwort generiert. Der private Schlüssel eines Applikationsserver ( server key) wird bei der Installation angelegt. Beide werden im KDC gespeichert - dieser sollte deshalb physikalisch gesichert sein. Bei den eingesetzten Desktopbetriebssystemen kann die Geheimhaltung nicht garantiert werden. Ist die Sicherheit des Arbeitsplatzes kompromittiert ( trojanische Pferde , mitlesen der Tastatur bei Eingabe des Paßwortes etc.) kann sich ein Angreifer als jemand anderes ausgeben (impersonation).

no authentication by assertion

Andere Mechanismen schenken einer IP-Adresse zuviel Glauben. Der tcpd -Wrapper nimmt diese für bare Münze. Aber auch mit einer Unix-UID läßt sich viel Ungewünschtes erreichen. Bestes Negativbeispiel ist rlogin. Der Server rlogind glaubt dem Client die übermittelte UID einfach. Bei häufiger Verwendung von .rhosts -Dateien also schnell den Quelltext nehmen und dem Server kann jede beliebige UID außer die von root untergeschoben werden. Auch ident und pcnfsd sind nicht der Weisheit letzter Schluß.

password guessing

whoami

Um den Dienst nutzen zu können, muß der Client einen Authentifizierer erzeugen und zusammen mit dem Ticket an den Server senden. Der Authentifizierer besteht aus dem Namen des Clients, seiner Netzwerkadresse und einem Zeitstempel und muß mit dem Sitzungsschlüssel chiffriert werden. An diesen kann der Client nur herankommen sein, wenn er den richtigen Schlüssel - der aus dem Paßwort abgeleitet ist - kennt.

Der Server erhält Authentifizierer und Ticket in einer weiteren Meldung (5). Er dechiffriert das Ticket mit seinem eigenen Schlüssel und gelangt so ebenfalls an den Sitzungsschlüssel. Er kann den Authentifizierer damit lesen. Fordert der Client eine gegenseitige Authentifizierung, weil er sicher gehen möchte mit dem richtigen Server zu kommunizieren, antwortet der Server mit einem optionalen Paket (6) und sendet den Nonce des Clients chiffriert mit dem Sitzungsschlüssel zurück.
 

Zeichen	Bedeutung
c	Name des Client (principal)
s	Name des Servers (principal)
n	Nonce (Zeitstempel oder Sequenznummer)
tgs	Ticket-Granting Server
Kx	geheimer Schlüssel von "x"
Kc,s	Sitzungsschlüssel für "c" und "s"
{info}Kx	"info" verschlüsselt mit Schlüssel Kx
{Tc,s}Ks	verschlüsseltes Ticket für "c" um "s" zu nutzen  {Tc,s}Ks={ s, c, addr, timestamp, lifetime, K c,s}Ks
{Ac}Kc,s	verschlüsselter Authentifizierer für "c" um "s" zu nutzen  {Ac}Kc,s= { c, addr, timestamp, chksum }Kc,s
addr	die IP Adresse des Clients
login/kinit	Client sendet: c, tgs, n  und erhält von TGS: {Kc,tgs, n}Kc, {Tc,tgs }Ktgs
Rs	Anfrage für ein Ticket um "s" zu nutzen:  s, {Tc,tgs}Ktgs, {Ac}Kc,tgs

Ein Ticket ist immer nur für einen Dienst gültig. Es ist mit dem geheimen Schlüssel des Dienstes chiffriert den nur der Dienst und der KDC kennt. Der Client selbst kann dieses Ticket nicht entziffern und leitet es stattdessen nur an den Dienst weiter. Außerdem ist ein Ticket immer nur für eine einstellbare Zeit gültig. Nach Ablauf muß es erneuert werden.

Play it again, Sam

In [kerblimit.usenix.ps] wurde die Zuverlässigkeit des Authenticators in Frage gestellt. Es wird kritisiert, daß die Uhren einigermaßen synchronisiert sein müßten, um die Gültigkeit eines Authenticators zu prüfen, da ein client-generierter Zeitstempel verwendet wird. Die einfache Lösung: der Server speichert den Authenticator mit seiner lokalen Uhrzeit.

Im Reich der Reiche

Ein Benutzername sähe z.B. so aus: peewee@FIDO.DE während ein Dienst den Namen ftp/picklock.fido.de@FIDO.DE tragen würde.

Es ist Konvention die Realms nach der Internet-Domäne in GROßBUCHSTABEN zu benennen. Auch für die Zusammenarbeit zwischen Realms wurde gesorgt. Analog zu Vertrauensstellungen zwischen NT-Domänen (eigentlich ja DCE-Zellen) können Tickets eines Realms in einem anderen Gültigkeit haben, wenn dies die Administratoren so eingerichtet haben.

Bei den bisherigen Ausführungen wurden die Felder der einzelnen Meldungen vereinfacht dargestellt, um das Prinzip deutlicher werden zu lassen. Das Protokoll sieht weitere Felder vor, die ich hier aber nicht alle im einzelnen aufführen werde. Stattdessen folgt eine Liste weiterer "Tickets" mit ihren Eigenschaften und Einsatzgebieten:

· postdated ticket - das Ticket wird erst für eine in der Zukunft liegende Zeit gültig. Anwendungsgebiet sind z.B. cron -Jobs

· renewable ticket - das Ticket kann vor seinem Ablauf erneuert werden. Nötig für lang laufende Jobs (wie Wettervorhersagen ;-), die voraussichtlich länger als die maximale Gültigkeitsdauer der Tickets benötigen (>10 Stunden)

· forwardable ticket - das Ticket kann weitergeleitet werden, um z.B. auf einem entfernten Rechner eine telnet-Sitzung aufzubauen, und von hier aus weitere Dienste in Anspruch zu nehmen. Dabei kann die Kommunikation verschlüsselt werden (Option -x). Dies ist ein Feature von rlogin/rsh/rcp/telnet aus der Kerberos-Distribution.

· proxiable ticket - ähnlich wie forwardable tickets , nur mit der Einschränkung, daß damit keine neuen Tickets zu bekommen sind. Damit können Dienste "im Namen" eines anderen principal benutzt werden - vergleichbar mit einem setuid-Bit.

Normalerweise erhält man bereits beim login ein TGT, da die Kerberos-Version von login verwendet wird. Auf Systmen wo das nicht der Fall ist, erfüllt kinit diesen Zweck. Mit klist können die erhaltenen Tickets eingesehen und das Paßwort mit kpasswd vom Benutzer geändert werden. Am Ende einer Sitzung sollten die Tickets zerstört werden - am besten geschieht das automatisch durch einen Aufruf von kdestroy in .logout, sonst verlieren die Tickets erst mit Ablauf ihrer Lebenszeit ihre Gültigkeit.

Um jemanden Zugriff auf seinen Account zu geben ohne das Paßwort zu verraten, trägt der Urlauber den Principal in .k5login ein. Dies hat folgende Vorteile:

· der Zugriff kann jederzeit wieder rückgängig gemacht werden - durch einfaches entfernen des Eintrages

· obwohl der Benutzer vollen Zuriff auf den Account erhält, erbt er keine Netzwerkrechte

· Kerberos protokolliert auch solcherlei Zugriffe und ermöglicht die Überprüfung, wer zu gegebener Zeit in der Lage war diesen Account zu verwenden.

Typische Anwendung findet dieses Feature um den Zugriff auf root zu regeln: sei es temporär für Service-Personal oder dauerhaft - ohne das Paßwort preisgeben, eingeben oder über das Netzwerk transportieren zu müssen.

Wer darf denn nu´ was?