Kerberos

 

Die Schwierigkeit -
das ist eben das Problem.
Helmut Kohl

Dieses Kapitel widmet sich dem Authentisierungssystem Kerberos. Es wird seit Mitte der 80er Jahre am M.I.T. im Rahmen des Projektes Athena entwickelt. Kerberos ist ein komplexes Protokoll, welches die authentisierte Rechnernutzung in offenen Netzwerken ermöglicht.

Von Bedeutung sind heute insbesondere die Versionen 4 und 5 des Kerberos-Protokolls. Die Entwicklung der Version 4 ist mit der Veröffentlichung des Patchlevel 10 im Dezember 1992 eingestellt worden. Zum Zeitpunkt des Verfassens dieses Kapitels ist die Version 5 beta 3 vom Januar 1994 aktuell. Beide Versionen basieren auf grundlegend verschiedenen Protokollen. Weiterhin gibt es verschiedene Implementationen, die ausgehend von unterschiedlichen Protokollspezifikationen erstellt und später unabhängig von der Entwicklung beim M.I.T. weiter entwickelt wurden. So basiert z.B. der im AFS zum Einsatz kommende kaserver auf der Version 4 und das Securitymodell im OSF/DCE auf einem frühen Alpha-Release der Kerberos Version 5.

Im Mittelpunkt der Erörterung in diesem Kapitel stehen daher nicht die Feinheiten einzelner Versionen, sondern die Darstellung der prinzipiellen Funktionsweise des Protokolls. Dazu werden zunächst eine Reihe von Begriffen eingeführt, die für das Verständnis notwendig sind. Es erfolgt die Erläuterung der Arbeitsweise des Protokolls und anschließend werden Schwachstellen und Grenzen des Protokolls diskutiert.

Kerberos ist ein sog. trusted third-party authentication system. Die authentisierte Kommunikation zwischen zwei Partnern basiert auf dem Vertrauen gegenüber einer dritten Instanz. Das zugrundeliegende Modell geht zurück auf Roger M. Needham und Michael D. Schroeder vom Xerox PARC und trägt die Bezeichnung Needham-Schroeder key distribution protocol.

Die Entwicklung von Kerberos erfolgte primär mit dem Ziel, die Benutzung von relativ frei zugänglichen Rechnern am M.I.T. sicher zu machen. Es sollte keinem Nutzer gelingen, die Identität und damit die Rechte eines anderen Nutzers zu erlangen.

Begriffe

Zur Beschreibung des Kerberos-Protokolls wird eine eigene Begriffswelt benutzt, die im folgenden eingeführt werden soll.

Der Kerberos-Dienst selbst funktioniert - wie nahezu alle Netzdienste - nach dem Client/Server-Modell. Alle Teilnehmer an einer Kerberos-authentisierten Kommunikation sind Clients des Kerberos-Servers. Sie werden als principals  bezeichnet. Entsprechend der Zielsetzung des Kerberos-Dienstes sind principals also die Nutzer eines Rechnersystems und die von den Nutzern in Anspruch genommenen Dienste. Principals sind demzufolge die Server von Netzdiensten und die Nutzer, eigentlich die im Auftrag eines Nutzers arbeitenden Clients von Netzdiensten.

Für die Benennung der principals gibt es ein eigenes Namensschema. Ein principal name  besteht aus drei Teilen: primary name, instance und realm. Er wird in folgender Form notiert:

primary_name.instance@realm

Der primary name bezeichnet dabei den Namen eines Nutzers (Nutzerkennzeichen) oder eines Dienstes. Unter instance versteht man die Ausprägung oder Variation des primary names, bei Nutzern sind damit unterschiedliche Privilegien des Nutzers gemeint und bei Diensten wird damit der Name der Maschine angegeben, auf der der Server läuft. Schließlich bezeichnet die realm (wörtlich: Königreich) die admistrative Einheit, zu der das principal gehört, das können z.B. alle Maschinen einer Einrichtung, eines Instituts, einer Firma usw. sein. Der (kerberisierte) rlogin-Dienst auf dem Rechner digedag.hrz.tu-chemnitz.de in der admistrativen Einheit tu-chemnitz.de hat demzufolge den principal name

rcmd.digedag.hrz.tu-chemnitz.de@tu-chemnitz.de

und der Nutzer fred besitzt, wenn er mit root-Privilegien in derselben realm arbeiten möchte, den principal name

fred.root@tu-chemnitz.de

Im Kerberos-Protokoll werden verschiedene Datenstrukturen verwendet, die jeweils dem Identitätsbeweis ihres Eigentümers dienen. Diese Datenstrukturen werden zusammenfassend credentials (wörtlich: Beglaubigungsschreiben, Zeugnis ) genannt. Credentials werden ausschließlich verschlüsselt versendet. Es gibt zwei Arten von credentials: Tickets und Authentikatoren.

Tickets werden vom Kerberos-Server auf Anforderung erstellt und an den Client übermittelt. Sie müssen zur Inanspruchnahme eines Dienstes vom Client dem entsprechenden Server vorgewiesen werden. Ein Ticket dient einerseits der sicheren Weitergabe der Identität der Person, für die das Ticket ausgestellt wurde und andererseits dem Beweis, daß die Person, welche das Ticket verwendet, die Person ist, für die das Ticket ausgestellt wurde. Um diesen Beweis zu erbringen, wird zusätzlich der Authentikator benötigt.

Im Gegensatz zum Ticket wird der Authentikator vom Kerberos-Client erstellt. Er enthält Informationen, die im Zusammenhang mit dem Ticket beweisen, daß das Ticket tatsächlich von der Person verwendet wird, für die es ursprünglich ausgestellt wurde. Der Authentikator verhindert somit, daß vom Netz abgelauschte Tickets mißbräuchlich verwendet werden können.

Im Kerberos-Protokoll spielt die Verschlüsselung eine entscheidende Rolle. Als Verschlüsselungsverfahren wird DES eingesetzt. Jedes principal besitzt einen secret key. Dieser Schlüssel darf nur dem principal selbst und dem Kerberos-Server bekannt sein. Der secret key eines Nutzers wird aus dessen Paßwort berechnet. Dazu dient die sog. string-to-key-Funktion. Die secret keys der einzelnen Dienste sind in einem File (/etc/srvtab) im Filesystem jedes einzelnen Rechners abgelegt. Der Kerberos-Server hält sämtliche secret keys in der Kerberos Authentication Database, ggf. werden die keys darin selbst verschlüsselt aufbewahrt. Dazu dient das Kerberos Master Paßwort.

Der Austausch von Authentisierungsinformationen zwischen zwei Principals erfolgt ebenfalls verschlüsselt. Als Schlüssel wird ein sog. session key verwendet, der im Ticket vom Kerberos-Server an den Client übermittelt wird. Der session key wird also vom Kerberos-Server frei gewählt und dann zur Kommunikation zwischen Client und Server eines Dienstes eingesetzt.

Der Keberos-Server besteht aus zwei Teilen, die unterschiedliche Funktionen erfüllen. Der Authentication Server (AS) prüft die Identität eines Nutzers und der Ticket Granting Server (TGS) erstellt Tickets zur Benutzung verschiedener Dienste. In der Kerberos-Literatur werden die beiden Teile begrifflich deutlich unterschieden, obwohl beide Teile in einem Prozeß implementiert sind. In der Version 5 des Kerberos-Protokolls wird dieser Prozeß als Key Distribution Center (KDC) bezeichnet.

Arbeitsweise

Prinzip

Die Arbeitsweise von Kerberos ist weitestgehend vor dem Nutzer versteckt. Der Zugang zu einem UNIX-System erfolgt unter der Steuerung von Kerberos wie üblich. Ein Nutzer beweist seine Identität durch die Kenntnis des eigenen Paßworts. Die Aktionen zum Erhalt des ersten Tickets sind im kerberisierten login versteckt. Nachdem der Nutzer sein Nutzerkennzeichen eingegeben hat, wird der Authentication Server als Teil des Kerberos-Servers aufgefordert, ein Ticket Granting Ticket (TGT) für den Nutzer auszustellen. Der AS antwortet mit dem Ticket Granting Ticket und einem session key für die Kommunikation des Clients mit dem Ticket Granting Server. Das TGT verwendet der Client im folgenden, um Tickets für einzelne Dienste anzufordern. Dazu wenden sich die Client-Programme an den TGS mit der Bitte, für einen bestimmten Dienst aufgrund des mitgelieferten TGT ein Ticket für den gewünschten Dienst zu erhalten. Der TGS liefert das gewünschte Server-Ticket und einen session key für die Kommunikation des Clients mit dem Server. Der Client sendet das Server-Ticket gemeinsam mit einer Dienstanforderung an den Server, um die Kommunikation aufzunehmen. Dabei kann der Client verlangen, daß der Server sich ebenfalls gegenüber dem Client authentisiert. Dann antwortet der Server mit einer vom Client verifizierbaren Nachricht, deren Überprüfung dem Client bestätigt, daß er es tatsächlich mit dem Server zu tun hat, für den er ursprünglich das Ticket angefordert hat.

Ermitteln des TGT

Nach Eingabe des Nutzerkennzeichens wird vom kerberisierten login(1) eine Nachricht (KRB_AS_REQ) generiert und an den zuständigen Kerberos-Server gesendet. Dazu muß login(1) zuerst feststellen, zu welcher realm die Maschine gehört (/etc/realms) und auf welcher Maschine ein Kerberos-Server für diese realm läuft (/etc/krb.conf). Bestandteil der Nachricht KRB_AS_REQ ist das Nutzerkennzeichen (principal identifier des Nutzers). Die Nachricht selbst wird im Klartext übertragen (siehe Abbildung ).

 
Abbildung: Kontaktaufnahme mit dem Kerberos-Server

Beim Empfang der Nachricht prüft nun der Authentication Server als Teil des Kerberos-Servers, ob es einen Eintrag in seiner Datenbasis für das Principal gibt. Findet er einen solchen Eintrag, so generiert er das Ticket für den Ticket Granting Server (TGS). Dieses Ticket Granting Ticket (TGT) Tc,tgs besteht aus

Das TGT Tc,tgswird mit dem secret key Ktgsverschlüsselt, der nur dem TGS und dem AS bekannt ist, es entsteht also {Tc,tgs}Ktgs. Aus dem verschlüsselten TGT und weiteren Informationen erzeugt der AS die Antwortnachricht KRB_AS_REP an den Client.

In dieser Nachricht sind enthalten

Die so generierte Antwort verschlüsselt der AS mit dem secret key des Clients Kc, es entsteht also {Kc,tgs;{Tc,tgs}Ktgs}Kc (Version 5: {Kc,tgs}Kc;{Tc,tgs}Ktgs ). Anschließend sendet der AS diese Nachricht an den Client (siehe Abbildung).

 
Abbildung: Antwort des Authentication Servers

Der secret key des Clients Kc ist in der Kerberos Datenbasis enthalten. Er wird aus dem Paßwort des Nutzers berechnet und beim Eintragen des Nutzers bzw. bei der Änderung des Paßworts des Nutzers vergeben.

Wenn der Client (z.B. Login-Prozeß) diese Antwort erhalten hat, wird der Nutzer nach seinem Paßwort gefragt. Aus dem eingegebenen Paßwort wird der secret key des Clients Kc berechnet und mit Hilfe dieses Keys die Antwort entschlüsselt. Nach einigen Verifizierungen werden der session key Kc,tgs und das verschlüsselte TGT {Tc,tgs}Ktgs für die weitere Verwendung im Ticketfile des Nutzers /tmp/tktuid aufbewahrt.

Durch diese Nachricht erfährt der Client den session key Kc,tgs, der erforderlich ist, um im folgenden authentisiert mit dem TGS zu kommunizieren.

Ermitteln eines Server-Tickets

Möchte ein Nutzer einen kerberisierten Dienst in Anspruch nehmen, so muß er ein Ticket dafür vorweisen. Ein solches Ticket erhält er vom Ticket Granting Server (TGS). Der TGS verhält sich dabei wie jeder andere (kerberisierte) Dienst. Das Ticket für den TGS ist das im ersten Schritt erhaltene Ticket Granting Ticket (TGT). Insofern ist der TGS ein "ganz normaler" Dienst (wie z.B. rlogin). Seine Dienstleistung besteht eben darin, ein Ticket für einen anderen Dienst zu ermitteln.

Der TGS ist genau wie der AS ein Teil des Kerberos-Servers (Kerberos 5: Key Distribution Center KDC).

Besitzt der Nutzer in seinem Ticketfile für die Inanspruchnahme eines bestimmten Servers noch kein Ticket, so muß dieses zuerst vom TGS besorgt werden. Das kerberisierte Client-Programm erzeugt dazu eine Nachricht KRB_TGS_REQ an den TGS. Hier wird vernachlässigt, daß zunächst noch ermittelt werden muß, in welcher Realm der entsprechende Server registriert ist. Falls für dies Relam noch kein TGT existiert, muß erst ein TGT angefordert werden, dafür gibt es selbst wieder ein kompliziertes Protokoll.

Diese Nachricht besteht aus folgenden Teilen

Der Authentikator Ac enthält

Diese Nachricht wird vom Client an den TGS gesendet (siehe Abbildung ).

 
Abbildung: Anforderung eines Server-Tickets

Der TGS untersucht diese Nachricht. Dazu entschlüsselt er mit seinem secret key Ktgs das TGT. Mit dem im TGT enthaltenen session key Kc,tgs kann er den Authentikator entschlüsseln. Wenn die Informationen aus dem TGT und dem Authentikator übereinstimmen, gilt die Identität des Clients als bewiesen.

Der Client ist nicht in der Lage, das TGT zu dechiffrieren, da es mit dem secret key des TGS verschlüsselt ist. Den darin enthaltenen session key Kc,tgs konnte der Client nur erfahren, wenn er in der Lage war, die Antwort des AS zu entschlüsseln. Das konnte er aber nur, weil der Nutzer das richtige Paßwort eingegeben hat.

Die Verwendung von Zeitstempeln und die Angabe einer Lebensdauer soll zusätzlich replay attacks verhindern. Während ein Ticket standardmäßig eine Lebensdauer von acht Stunden hat, ist ein Authentikator nur etwa fünf Minuten gültig. Diese Annahmen setzen natürlich voraus, daß die Systemuhren der beteiligten Maschinen synchron laufen.

Nach der Verifizierung erzeugt der TGS das Server-Ticket Tc,s für den gewünschten Server. Dieses Ticket ist analog dem TGT aufgebaut, es enthält

Dieses Ticket Tc,s wird mit dem secret key des Server Ks verschlüsselt, es entsteht {Tc,s}Ks. Der secret key des Servers ist ebenfalls Bestandteil der Kerberos Datenbasis.

Der TGT erzeugt aus dem verschlüsselten Ticket {Tc,s}Ks und weiteren Informationen die Antwortnachricht KRB_TGT_REP an den Client. Bestandteil dieser Nachricht sind

Die so generierte Antwort wird mit dem aus dem TGT bekannten session key Kc,tgs verschlüsselt. Es entsteht {{Tc,s}Ks;Kc,s}Kc,tgs (Version 5: {Tc,s}Ks;{Kc,s}Kc,tgs). Diese Nachricht wird an den Client gesendet (siehe Abbildung).


Abbildung: Antwort des TGS

Der Client entschlüsselt die Nachricht unter Verwendung des in seinem Ticketfile gespeicherten session keys Kc,tgs. Nach einigen Verifizierungen werden der session key für die Kommunikation mit dem gewünschten Server Kc,s und das verschlüsselte Server-Ticket {Tc,s}Ks für die weitere Verwendung wiederum im Ticketfile des Nutzers aufbewahrt.

Inanspruchnahme eines Servers

Zur Inanspruchnahme eines Dienstes sendet der Client eine entsprechende Nachricht (KRB_AP_REQ) an den Server. Diese Nachricht ist der Nachricht KRB_TGS_REQ an den TGS vergleichbar. Jedoch fehlt die Angabe des gewünschten Servers. Die Nachricht KRB_AP_REQ dient der Initiierung der Kommunikation und der Übertragung des session keys Kc,s innerhalb des Server-Tickets.

Falls der Client die Identität des Servers prüfen möchte, so kann er veranlassen, daß der Server mit einer Nachricht KRB_AP_REP antwortet, die der Bestätigung seiner Identität dient. Bestandteil dieser Nachricht ist der Wert des vom Client gesendeten Zeitstempels erhöht um 1. Diese Antwortnachricht ist ebenfalls mit dem session key Kc,s verschlüsselt.

Durch Prüfung dieser Antwort kann der Client feststellen, daß die Identität des Servers stimmt, denn nur dieser kann den session key Kc,s kennen, da nur er in der Lage ist, das vom Client gelieferte Ticket zu entschlüsseln. Dieses Ticket ist mit dem secret key des Servers Ks verschlüsselt, welcher im File /etc/srvtab enthalten und sonst nur dem Kerberos Server bekannt ist.

Randbedingungen

An den Einsatz von Kerberos sind einige Bedingungen gestellt. Diese sind teilweise so gravierend, daß sie die Verwendung von Kerberos ggf. völlig in Frage stellen.

Besondere Anforderungen muß die Maschine erfüllen, auf der der Kerberos-Server läuft. Sie muß physikalisch sicher untergebracht sein und darf nur ausgewählten Personen zugänglich sein. Diese Maschine sollte auch keine anderen Aufgaben erfüllen, als Kerberos-Server zu sein. Insbesondere sollte es nicht möglich sein, rlogin(1), rsh(1) oder telnet(1) zu verwenden, um die Maschine entfernt zu nutzen. Auch sollte die Maschine nicht als NFS-Server oder Client fungieren und sie sollte auch nicht in NIS eingebunden sein.

Wenn es nämlich einem Angreifer gelingt, die Kerberos-Server-Maschine zu komprimitieren, so sind alle Maschinen der Kerberos-Realm komprimitiert. Die Ursache dafür ist die Schutzwürdigkeit der äußerst sensiblen Informationen, die auf dieser Maschine gehalten werden. Diese Informationen befinden sich in der Kerberos Authentication Database und umfassen sämtliche secret keys, sowohl der Nutzer als auch der einzelnen Server in der Realm. Die secret keys werden in der Regel verschlüsselt in der Authentication Database aufbewahrt.

Zum Verschlüsseln dient das Kerberos Master Paßwort. Somit nützt einem Angreifer der Diebstahl der Authentication Database nicht viel, da er das Master Paßwort nicht kennt. Jedoch wird dieses Paßwort zum Starten des Kerberos Servers benötigt. Damit der Kerberos Server auch starten kann, wenn gerade kein verantwortlicher Administrator in der Nähe ist, um das Paßwort einzugeben, z.B. im Zuge eines reboots nach einem Systemabsturz, wird das Master Paßwort in dem File /.k auf der Kerberos-Server-Maschine abgelegt.

Aber auch auf den Kerberos-Client-Maschinen gibt es eine Reihe sensibler Files. Besonders schutzwürdig ist das File /etc/srvtab, es enthält die secret keys der Server, die auf dieser Maschine laufen. Weiterhin sind natürlich die Files von Interesse, die die Binaries der kerberisierten Programme enthalten (z.B. /bin/login) und zahlreiche weitere Systemfiles, wie /etc/inetd.conf und /etc/services. Insofern hat sich die Situation gegenüber dem Betrieb ohne Kerberos nicht geändert, es besteht auf den einzelnen Maschinen kein Schutz vor dem Austausch oder der Manipulation von Systemfiles.

Beim Entwurf von Kerberos ist man von den spezifischen Bedingungen des Betriebs des Campusnetzes am M.I.T. ausgegangen. Dazu gehört die Annahme, daß die von den Nutzer verwendeten Workstations im Sinne von dataless Workstations eingesetzt werden. Sie besitzen also lokale Festplatten für das Betriebssystem, temporäre Files und den Swap-Bereich, jedoch keine Nutzerdaten. Demzufolge ist es nicht notwendig, daß diese Maschinen anders benutzt werden als über ihre Konsole. Entfernte Nutzung mittels remote login, batch jobs o.ä. Nutzung ist nicht vorgesehen.

Diskless Workstation sind für den Betrieb von Kerberos gänzlich ungeeignet, da geheime Informationen (session keys) in Files aufbewahrt werden und diese Informationen beim Lesen oder Schreiben dieser Files sonst unverschlüsselt über das Netz übertragen werden.

Ebenso ungeeignet sind Maschinen mit mehreren Netz-Interfaces und damit mehreren Netzadressen. Da die Gültigkeit der Tickets an die Netz-Adresse gebunden ist, entstehen Probleme, wenn die Server-Rechner über mehrere Routen erreicht werden können.

Schwachstellen des Protokolls

Kerberos hat viele Kritiker. Nicht zuletzt deshalb wurde das Protokoll so vielen Revisionen unterzogen. Die im folgenden besprochenen Probleme beziehen sich auf die Version 4 von Kerberos, zum Teil sind Hinweise enthalten, wie die Probleme in Version 5 gelöst wurden.

Wiederholungsangriffe - Replay Attacks

Ein Wiederholungsangriff besteht darin, Nachrichten vom Netz abzuhören und zu einem späteren Zeitpunkt erneut abzusenden. Dabei kann entweder die gesamte Nachricht oder auch nur einzelne Teile daraus für Angriffszwecke verwendet werden. Kerberos ist für solche Angriffe anfällig. Die Tickets sind sogar dafür ausgelegt, mehrfach verwendet zu werden. Sie besitzen eine standardmäßige Lebensdauer von acht Stunden und können innerhalb dieser Zeit immer wiederverwendet werden.

Zum Schutz von Wiederholungsangriffen wurden die Authentikatoren eingeführt, die nur fünf Minuten gültig sind und dazu dienen, die Rechtmäßigkeit der Verwendung eines Tickets zu beweisen. Jedoch innerhalb dieser fünf Minuten sind auch die Authentikatoren wiederverwendbar.

Der Entwurf des Kerberos-Protokolls sah das Authentication Caching vor. Hinter diesem Mechanismus verbirgt sich der Gedanke, daß sich jeder Server den letzten gesendeten Authentikator merkt, um so mehrfach gesendete Nachrichten zu erkennen.

Dieser Mechanismus ist aber nicht implementiert worden und er läßt sich eigentlich auch nicht implementieren. Das liegt in der "`Natur"' der Implemetierung von Netzdiensten. TCP-basierte Dienste arbeiten in der Regel so, daß jeder eingehende Request durch einen neuen, mit fork(2) erzeugten Prozeß bearbeitet wird. Dieser neue Prozeß besitzt aber keine gemeinsamen Speicherbereiche mit seinem Elternprozeß oder seinen "`Geschwisterprozessen"' und kann demzufolge diese auch nicht über die verwendeten Authentikatoren informieren. UDP-basierte Dienste haben es da etwas einfacher, da sie meist so implemetiert sind, daß ein einzelner Prozeß alle eingehenden Request bearbeitet. Jedoch haben solche Implementationen Probleme mit legitimen Wiederholungen des Request durch den Client. Solche Wiederholungen sind möglich, da das UDP-Protokoll die Zustellung von Nachrichten nicht garantiert und es demzufolge geschehen kann, daß die Antwort des Servers beim Client nicht ankommt.

Probleme durch Zeitsynchronisation

Die Funktionstüchtigkeit von Kerberos setzt eine einheitliche Vorstellung von der aktuellen Zeit auf allen beteiligten Maschinen in einer Realm voraus. Es wird also ein Mechanismus benötigt, welcher die Systemuhren der einzelnen Maschinen synchronisiert. Dieses Problem ist relativ schwierig. Die Verwendung von Zeitstempeln in den Credentials ist daher kritisch, weil ein Synchronisationsdienst vorausgesetzt wird, der ebenfalls gesichert sein muß.

In Kerberos Version 5 kann alternativ beim Ermitteln des TGT und beim Ermitteln der Server-Tickets ein sog. challenge/response Mechanismus verwendet werden. Dabei wird in den Authentikator ein nonce identifier (Zufallszahl) aufgenommen. In der Antwort des Servers ist dieser nonce identifier wiederum enthalten und der Client kann diesen prüfen und somit die Aktualität der Antwort der Servers feststellen.

Weiterhin kann in Version 5 der Server den Client zu einem weiteren challenge/response Authentisierungsschritt auffordern. Dazu sendet der Server dem Client eine spezielle Fehlernachricht (KRB_AP_ERR_METHOD) und einen nonce identifier, welchen der Client modifiziert zurücksenden muß.

Erraten von Passworten - Password Guessing attacks

Der Authentication Server beantwortet im ersten Schritt des Kerberos Protokolls bereitwillig alle Anfragen nach Ticket Granting Tickets. Da diese Anfragen im Klartext gestellt werden, kann ein Angreifer Antworten des AS sammeln und mit sog. brute force attacks versuchen, die Antwort zu entschlüsseln. Diese Vorgehensweise ist möglich, da der Algorithmus zum Berechnen des secret keys Kc ausgehend von einem Paßwort bekannt ist und der Erfolg einer versuchten Entschlüsselung an der Lesbarkeit der entschlüsselten Daten erkannt werden kann. Somit schützt Kerberos also nicht vor der Verwendung schlechter Paßworte.

Für dieses Problem wurden verschiedene Lösungen vorgeschlagen. So könnte bereits die Anfrage an den AS nach dem TGT mit dem secret key Kc verschlüsselt erfolgen. Diese Vorgehensweise entspricht einer initialen Authentisierung des Clients gegenüber dem Kerberos-Server. Dieser dürfte dann fehlerhafte Anfragen, die aufgrund eines falschen Paßworts entstehen, nicht oder mit einer entsprechenden Fehlernachricht beantworten. Außerdem kann er die Anzahl solcher Anfragen registrieren und beim Überschreiten einer bestimmten Anzahl Fehlerprotokolle generieren, die Verbindung zum Client völlig unterbrechen, den Systemadministrator informieren o.ä. Aktionen vornehmen. Tatsächlich enthält die Version 5 des Kerberos-Protokolls die Möglichkeit, in die Nachricht KRB_AS_REQ derartige Preauthentisierungsinformationen aufzunehmen.

Umgang mit den session keys

Session Keys sind an Tickets gebunden. Tickets und damit auch die session keys sind wiederverwendbar. Es handelt sich also eigentlich um Multi-session keys. Wenn ein Nutzer zu einem Zeitpunkt mehrere Verbindungen zu einem Server aufrecht erhält, dann verwenden alle diese Verbindungen denselben session key. Zumindest sind dann Angriffe denkbar, bei denen Nachrichten, die zu einer Verbindung (session) gehören durch Nachrichten aus einer anderen Verbindung ersetzt oder anderweitig manipuliert werden.

Kerberos Version 5 sieht daher die Möglichkeit vor, daß für jede individuelle Verbindung sub-session keys verwendet werden können, die Client und Server unter Verwendung des session keys austauschen.

Ein weiterer Kritikpunkt liegt in der Art und Weise der Aufbewahrung der session keys. Die Verwendung eines Ticketfiles im Verzeichnis /tmp ist zumindest für Maschinen, die gleichzeitig von mehreren Nutzern verwendet werden, denkbar schlecht geeignet. Kerberos Version 5 sieht verschiedene Cache-Variationen für die Aufbewahrung der Tickets und session keys vor.

Gültigkeit von Tickets

Die Gültigkeit der Tickets ist beschränkt in Zeit (Lebensdauer) aber auch in Raum (Netz-Adresse des Clients). Mit einem Ticket kann ein Nutzer innerhalb der Lebensdauer des Tickets den Dienst des entsprechenden Servers nutzen, solange die Client-Programme direkt auf seiner Login-Workstation laufen. Die Beschränkung der Gültigkeit der Tickets auf eine Netz-Adresse stellt ein echtes Problem dar. Die Nutzung von Diensten ausgehend von einem entfernten Rechner, zu dem der Nutzer per keberisiertem rlogin gelangt ist, setzt das Vorhandensein eines von diesem entfernten Rechner aus gültigen Tickets voraus. Dazu muß sich der Nutzer auf dem entfernten Rechner authentisieren, also sein Paßwort eingeben. Die Vermeidung der Übertragung des Paßworts war aber gerade eines der wichtigsten Ziele von Kerberos.

Kerberos Version 5 enthält Mechanismen zum ticket forwarding. Damit entsteht aber das vom Mechanismus Trusted Hosts bekannte Problem des transitiven Vertrauens. Überhaupt macht ticket forwarding nur Sinn, wenn im Ticket die Netz-Adresse des Clients enthalten ist. Verzichtet man auf die Netz-Adresse, kann das Ticket von jedem Rechner in der Realm aus als gültig betrachtet werden. Man braucht dann aber einen Mechanismus, mit dessen Hilfe Tickets sicher auf einen anderen Rechner kopiert werden können.

Ein weiteres Problem stellt die Nutzung von Diensten in einer anderen Realm dar. In Version 4 von Kerberos ist dieses Problem so gelöst, daß zwei kooperierende Realms einen Key austauschen, der als sekundärer Key für den TGS verwendet wird. Ein Client erhält Tickets vom Kerberos-Server in einer entfernten Realm, indem er zuerst ein Ticket für den TGS von seinem lokalen Kerberos-Server einholt und dieses benutzt, um Tickets für die Server in der entfernten Realm vom dortigen Kerberos-Server anzufordern. Diese Verfahrensweise ist sehr aufwendig, da bereits bei nur wenigen so zusammenarbeitenden Realms die Vergabe und Verwaltung der Inter-Realm Keys eine aufwendige Arbeit ist.

Kerberos Version 5 enthält eine alternative Lösung für dieses Problem. Es wir dort eine Hierarchie der Realms organisiert, die etwa der hierarchischen Organisation des Domain Name Service vergleichbar ist. Pro Realm werden dann nur noch pro Eltern- und Kind-Realms derartige Inter-Realm-Keys benötigt. Allerdings sind hier an der Einrichtung einer authentisierten Verbindung ggf. zahlreiche Transit-Realms beteiligt, denen jeweils vertraut werden muß.

Ausblick

Obwohl Kerberos immer noch der Entwicklung unterliegt, kann heute eingeschätzt werden, daß Kerberos-basierte Authentisierungsdienste in naher Zukunft auch in kommerziellen Umgebungen mehr und mehr an Bedeutung gewinnen werden. Indizien für diese Entwicklung sind einerseits die Verfügbarkeit kommerzieller Kerberos-Implementationen wie im Rahmen des von Transarc vertriebenen Andrew File Systems als auch die Auswahl von Kerberos als Authentisierungsprotokoll für OSF/DCE.

Literatur

About this document ...

This document was generated using the LaTeX2HTML translator Version 96.1 (Feb 5, 1996) Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.

The command line arguments were:
latex2html -split 0 -no_navigation kerberos.tex.

The translation was initiated by Thomas Mueller on Mon Apr 21 06:41:07 METDST 1997

Thomas Müller, April 1994