8.4.6. Kerberos

Die Schwierigkeit -
das ist eben das Problem.
Helmut Kohl

Kerberos ist ein Netzwerk-Authentifizierungsdienst für Client-Server-Anwendungen. Er gestattet eine starke Authentifizierung auf der Basis symmetrischer Verschlüsselungsverfahren und garantiert optional die Integrität und Vertraulichkeit der zwischen Klienten und Servern ausgetauschten Daten.

Kerberos (in der griechischen Mythologie der Name eines dreiköpfigen Wachhundes, der den Eingang zur Unterwelt, d.h. zum Reich des Hades bewacht) wurde Mitte der 80er Jahre als Teil des Projektes Athena am MIT entwickelt. Von praktischer Bedeutung sind gegenwärtig die Versionen 4 und 5. Obwohl konzeptionell ähnlich, unterscheiden sich beide im Detail doch deutlich voneinander.

Version 4 wird in der Praxis breiter genutzt, ist einfacher und hat eine bessere Performance. Sie ist allerdings auf TCP/IP-Netze beschränkt und fordert DES als Chiffre. Version 5 bietet eine größere Funktionalität und überwindet verschiedene Unzulänglichkeiten des Vorgängers. So lassen sich dort z.B. prinzipiell beliebige Verschlüsselungsverfahren sowie Netze verwenden.

Die Arbeiten an der Version 4 wurden mit der Veröffentlichung von Patchlevel 10 im Dezember 1992 eingestellt. Es gibt allerdings viele kommerzielle Produkte, die darauf basieren (z.B. das verteilte Filesystem AFS). Seit 1989 wird die Version 5 entwickelt, die heute als Standard anzusehen ist. Zum Zeitpunkt der letzten Modifikation des vorliegenden Abschnitts ist Kerberos V5 Release 1.0.6 aktuell. Den jeweils neusten Stand finden Sie im WWW auf der Kerberos-Seite des MIT: [http://web.mit.edu/kerberos/www/index.html].

Das Kerberos-Protokoll ist ein sog. Trusted Third-Party Authentication Protocol. Die authentifizierte Kommunikation zwischen zwei Partnern erfordert das Vertrauen gegenüber einer dritten Instanz. Im konkreten Fall ist das der Kerberos-Server. Das zugrunde liegende Modell basiert teilweise auf dem nach seinen Autoren Roger M. Needham und Michael D. Schroeder benannten Needham-Schroeder Shared-Key Protocol bzw. nur kurz Needham-Schroeder-Protokoll.

Der Kerberos-Server, der stets nur auf einem physikalisch gesicherten Rechner laufen sollte, fungiert als Schlüsselverteilungszentrum (Key Distribution Center), kurz KDC. Er hält in seiner Datenbasis die Namen und geheimen Schlüssel (Secret Keys) aller seiner als Principals bezeichneten Klienten, konkret der Nutzer und der Applikations-Server. Die Kenntnis des geheimen Schlüssels wird als Identitätsbeweis betrachtet.

Die Schlüssel der Nutzer werden aus deren Paßwörtern unter Verwendung einer geeigneten Hashfunktion (string_to_key), möglichst mit Einweg-Charakter, abgeleitet. In der Regel verschlüsselt man aus Sicherheitsgründen die in der Datenbasis des Kerberos-Servers hinterlegten Secret Keys unter Verwendung eines Master Keys, um die geheimen Schlüssel zu schützen, falls die Datenbasis, nicht aber der Master Key kompromittiert wird. Die administrative Einheit, für die ein bestimmter Kerberos-Server zuständig ist, heißt Realm.

Da Kerberos die geheimen Schlüssel der Beteiligten kennt, kann es Nachrichten generieren, die einen Principal von der Identität seines Kommunikationspartners überzeugen. Kerberos kreiert außerdem temporäre Sitzungsschlüssel (Session Keys) für jeweils zwei Partner (Klient und Server oder auch 2 Klienten), die nur für die Verschlüsselung der Nachrichten einer einzigen Kommunikationsbeziehung gültig sind.

Als Chiffre kommt in den verfügbaren Kerberos-Implementierungen DES zum Einsatz, wobei in der Version 5 prinzipiell auch andere Verfahren nutzbar sind. Wir hatten bei der Diskussion der Betriebsmodi der Blockchiffren bereits darauf hingewiesen, daß Kerberos 4 zur Integritätssicherung einen nicht standardisierten Modus PCBC verwendet, der allerdings eine Schwäche enthält und deshalb in der Version 5 gegen den CBC ersetzt wurde.

Arbeitsweise

Die prinzipielle Arbeitsweise von Kerberos ist bei den Versionen 4 und 5 gleich, wobei sich aber die jeweils verwendeten Protokolle unterscheiden. Die einzelnen Nachrichten weisen eine deutlich andere innere Struktur auf. Die folgende Abbildung gibt einen Überblick über die Authentifizierungsschritte:

Das KDC, also der Kerberos-Server, wird oft logisch in zwei Teile untergliedert: den Authentication Server (AS) und den Ticket-Granting Server (TGS). Der Klient fordert im Auftrag seines Nutzers zunächst beim AS ein sog. Ticket-Granting Ticket (TGT) an, das ihn nachfolgend berechtigt, Dienste des TGS in Anspruch zu nehmen. Das TGT wird (bei Version 4 komplett und bei Version 5 zu großen Teilen) vom AS mit dem geheimen Schlüssel des TGS chiffriert.

Um nun einen speziellen Applikations-Server verwenden zu können, benötigt der Klient ein Server-Ticket, das er vom TGS ausgestellt bekommt, sofern er sich diesem gegenüber unter Angabe des TGT korrekt ausgewiesen hat. Mit Hilfe des Server-Tickets kann er dann dem Applikations-Server seine Identität nachweisen und so den gewünschten Dienst in Anspruch nehmen.

Diese Abläufe sollen nachfolgend etwas genauer betrachtet werden. Dabei beschränken wir uns auf die Version 5. Die konkret dargestellten Abläufe und Nachrichten zeigen nur ausgewählte, für unsere Zwecke relevant erscheinende Aspekte des Protokolls, die das Prinzip verdeutlichen sollen. Weitere Details sind bei Bedarf den technischen Spezifikationen (z.B. RFC 1510) bzw. geeigneter Literatur (z.B. Kaufman oder Stallings) zu entnehmen.

Um die Identität eines Principals nachzuweisen, dienen zwei Arten von Informationen: die schon erwähnten Tickets sowie Authenticators. Zusammenfassend bezeichnet man sie als Credentials. Sie werden ausschließlich verschlüsselt versendet, um zu verhindern, daß sie von Unberechtigten gelesen oder modifiziert werden können. Ein Ticket hat die Aufgabe, die Identität des Klienten, für den es ausgestellt wurde, sicher zum Server zu übertragen. Der Authenticator wird immer zusammen mit dem Ticket übergeben und dient dem Nachweis, daß auch wirklich derjenige Principal das Ticket vorweist (d.h. sendet), für den es ausgestellt wurde.

Protokoll der Version 5

Die folgende Tabelle enthält die nachfolgend bei der Darstellung des Protokolls der Version 5 benutzte Symbolik:
c = Name des Nutzers am Klienten-Rechner
s = Name des Servers
realm = Name der Realm
addr = Netzwerk-Adresse des Klienten
val = Beginn und Ende der Gültigkeit des Tickets (validity, manchmal auch lifetime genannt)
timex = Zeitstempel (timestamp) der Uhr des Principals x
nonce = vom Klienten gewählter Nonce (s. unten)
subkeyx = von Principal x gewählter Subkey (s. unten)
Kx = geheimer Key des Principals x
Kx, y = Sitzungsschlüssel für x und y
Tx, y = für x ausgestelltes Ticket zur Benutzung von y
Ax, y = von x für y generierter Authenticator
Ein Nonce ist ein Wert, der (theoretisch) höchstens einmal für denselben Zweck verwendet wird und meist zur Erkennung von sonst nicht entdeckbaren Replay-Attacken dient. In der Praxis nutzt man oft zufällig generierte Werte als Nonces, so auch bei Kerberos Version 5, wo sie Bestandteil der zwischen Klient und KDC ausgetauschten Nachrichten sind. Zur Unterscheidung verschiedener Nonces werden wir Indexe verwenden, z.B. nonce1.

Ein Ticket, das für den Klienten c zur Nutzung der Dienste des Servers s ausgestellt wurde, hat prinzipiell folgende Form:

Tc, s = s, {c, realm, addr, val, Kc, s}Ks
Tickets werden generell nur vom KDC ausgestellt. Jedes Ticket gilt genau für einen Server und einen Klienten und darf von letzterem beliebig oft verwendet werden, bis es verfällt. Der Klient kann einen Großteil des Ticket-Inhalts nicht analysieren und daher auch nicht gezielt manipulieren, da dieser mit dem dem Klienten unbekannten geheimen Key des Servers chiffriert wurde. Der Klient weist dem Server das Ticket in verschlüsselter Form vor, so wie er es vom KDC erhalten hat.

Ein zum Ticket Tc, s gehörender Authenticator sieht im wesentlichen folgendermaßen aus:

Ac, s = {c, realm, timec, subkeyc}Kc, s

Authenticators werden ausschließlich von den Klienten generiert und gelten im Gegensatz zu den Tickets jeweils nur genau einmal. D.h., für jede Nutzung eines Servers muß der Klient einen neuen Authenticator erzeugen, was aber kein Problem darstellt, da er den dazu benötigten Sitzungsschlüssel kennt. Das optionale Element subkeyc stellt einen vom Klienten gewählten Schlüssel zum Schutz genau derjenigen Sitzung dar, der der betreffende Authenticator zugeordnet ist. Verzichtet der Klient auf die Angabe eines Subkeys, so wird an seiner Stelle der Sitzungsschlüssel verwendet.

Authenticators dienen zwei Zwecken. Sie enthalten zum einen etwas Klartext bekannten Inhalts (den Namen des Nutzers sowie der Realm), der mit dem Sitzungsschlüssel Kc, s chiffriert wurde. Daran erkennt der Server, daß der Klient wirklich im Besitz von Kc, s ist. Außerdem verhindert der Zeitstempel (in bestimmten Grenzen) Replay-Attacken, d.h. das Wiedereinspielen abgelauschter Ticket-Authenticator-Paare. Dies erfordert natürlich, daß alle Maschinen einer Realm ihre Uhren hinreichend gut und sicher synchronisieren müssen, um ungefähr dieselbe Vorstellung von der aktuellen Zeit zu haben.

Wie oben schon gesagt, stellt der ausschließlich verschlüsselt erfolgende Transport der Tickets und Authenticators über das Netz sicher, daß ein Angreifer nicht in der Lage ist, deren Inhalt zu lesen oder ihn unbemerkt zu verändern.

Folgende Nachrichten spielen bei Kerberos Version 5 eine Rolle, wobei das Zeichen || als Trennzeichen zwischen den Bestandteilen der Nachricht zu verstehen ist:

(1) Klient zu AS: c || tgs || nonce1
(2) AS zu Klient: {Kc, tgs || nonce1}Kc || Tc, tgs
(3) Klient zu TGS: Ac, tgs || Tc, tgs || nonce2
(4) TGS zu Klient: {Kc, s || nonce2}Kc, tgs || Tc, s
(5) Klient zu Server: Ac, s || Tc, s
(6) Server zu Klient: {timec, subkeys}Kc, s
Wenn sich ein Nutzer an seiner Klienten-Maschine anmeldet, authentifiziert er sich mit seinem Paßwort. Dieses Paßwort wird bei Kerberos niemals über das Netz übertragen. Statt dessen sendet der Klient die Nachricht (1) an den AS, wobei tgs einen von evtl. mehreren TGS spezifiziert. Der AS sucht den Klienten (Nutzer) c in seiner Datenbasis. Falls dieser vorhanden ist, generiert der AS das TGT (Ticket-Granting Ticket), das einen vom AS zuvor erzeugten Sitzungsschlüssel für eine gesicherte Kommunikation zwischen Klient und TGS enthält. Dann chiffriert er diesen Sitzungsschlüssel sowie den in (1) enthaltenen Nonce mit dem geheimen Schlüssel des Klienten und sendet das Ergebnis zusammen mit dem TGT in der Nachricht (2) an den Klienten.

Der Klient entschlüsselt den Sitzungsschlüssel sowie den Nonce mit dem aus dem Paßwort über eine geeignete (Einweg-)Hashfunktion abgeleiteten geheimen Key des Nutzers und akzeptiert die Antwort des AS nur, wenn der Nonce korrekt ist. Einem Angreifer, der das Paßwort nicht kennt, gelingt die Dechiffrierung nicht. Er ist deshalb nicht in der Lage, das Protokoll korrekt mit Nachricht (3) fortzusetzen.


Frage 8.4.6.1:

Wieso gelingt dem Angreifer die korrekte Fortsetzung des Protokolls nicht?


Der Klient bewahrt lediglich den Sitzungsschlüssel sowie das TGT auf, löscht aber das Paßwort. Damit soll dessen Diebstahl verhindert werden, falls es jemandem gelingt, den Speicherbereich zu lesen, in dem diese sensiblen Informationen stehen. Natürlich sind auch der Sitzungsschlüssel und das TGT wertvoll, allerdings nur für eine begrenzte Zeit, da jedes Ticket verfällt.

Der Klient muß mit Nachricht (3) für jeden zu nutzenden Dienst (Server) ein separates Server-Ticket vom TGS anfordern. Der TGS entschlüsselt das TGT mit seinem geheimen Key, erfährt so den darin enthaltenen Sitzungsschlüssel und dechiffriert anschließend den Authenticator. Jetzt kann er feststellen, ob der Klient authentisch ist. Dies gilt nur, wenn die Klienten- und Realm-Namen in Ticket und Authenticator übereinstimmen, die Netzadresse des Absenders derjenigen gleicht, die im Ticket eingetragen wurde, und wenn der Zeitstempel des Authenticators nur um einen relativ geringen Betrag (meist max. einige Minuten) von der aktuellen Zeit des TGS abweicht.

Wenn alles stimmt, sendet der TGS in Nachricht (4) das angeforderte Ticket für einen Applikations-Server. Darin ist ein Sitzungsschlüssel enthalten, den der TGS eigens für die Kommunikation zwischen Klient und Server kreiert hat und den er dem Klienten außerhalb des Tickets und mit dessen geheimem Key verschlüsselt zusendet. Der verschlüsselte Nonce dient wieder wie oben der Erkennung von Replay-Attacken. Durch die Dechiffrierung von (4) erfährt der Klient den Sitzungsschlüssel, den er für die Kommunikation mit dem Applikations-Server benötigt.

Mit Hilfe des Server-Tickets sowie eines gültigen Authenticators kann der Klient unter Verwendung von Nachricht (5) den gewünschten Dienst nutzen. Der Applikations-Server führt dieselben Tests durch wie zuvor der TGS (gültiger Name des Nutzers sowie der Realm, korrekte Adresse, aktueller Zeitstempel). Stimmt alles, akzeptiert er die Anfrage als authentisch, da er Kerberos vertraut.

Um die Zeitstempel überprüfen zu können, sind bekanntlich die Uhren aller Kerberos-Maschinen einer Realm zu synchronisieren, zumindest im Bereich von einigen Minuten. Das dabei verwendete Synchronisationsprotokoll ist geeignet gegen Attacken aus dem Netz zu schützen. Der TGS sowie die Applikations-Server sollten eine Liste bereits empfangener, noch aktiver Authenticators führen, da wiedereingespielte Anforderungen rein vom Zeitstempel her noch gültig sein können, wenn der Angriff kurz nach dem Aussenden der authentischen Nachricht erfolgt. Empfängt ein Server ein bestimmtes Ticket-Authenticator-Paar noch einmal, so sollte er es ignorieren.

Wird eine gegenseitige Authentifizierung gewünscht, so sendet der Server die Nachricht (6), die neben dem optionalen Subkey des Servers vor allem den Zeitstempel enthält, der beweist, daß der Server echt ist. Ein Angreifer kann ihn nämlich nicht ermitteln, da er den geheimen Server-Key nicht kennt, den er benötigt, um zuerst das Ticket und dann mit dem darin enthaltenen Sitzungsschlüssel den Authenticator zu dechiffrieren. Falls der Server in (6) einen optionalen Subkey spezifiziert, so verwirft und ersetzt dieser den evtl. in (5) vorgeschlagenen Subkey des Klienten.

Klient und Server verfügen über einen gemeinsamen Sitzungsschlüssel. Das ist entweder einer der Subkeys oder der vom KDC generierte Session Key. Da nur sie beide ihn kennen, ist er nutzbar, um die Integrität, Vertraulichkeit und (zusammen mit den Zeitstempeln) auch die Authentizität der Kommunikation zu gewährleisten. Meist findet aus Gründen der Performance nur eine Authentifizierung statt.

Eine Chiffrierung der gesamten Nutzdaten erfolgt in der Regel nur bei besonders sensiblen Informationen, z.B. bei Paßwörtern bzw. geheimen Schlüsseln. Für Kerberos Version 5 wurden verschiedene kryptographische Algorithmen spezifiziert, von denen einige nur die Integrität und andere zusätzlich die Vertraulichkeit der Kommunikation sicherstellen. Details finden sich z.B. bei Kaufman sowie im RFC 1510.

Randbedingungen

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

Besondere Anforderungen muß die Maschine erfüllen, auf der der Kerberos-Server läuft. Sie ist physikalisch sicher unterzubringen 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 ihre entfernte Nutzung über die r-Utilities, SSH, Telnet etc. unterbunden werden. Außerdem sollte die Maschine nicht als NFS-Server oder -Klient fungieren und auch auf die Verwendung von NIS verzichten.

Wenn es nämlich einem Angreifer gelingt, die Kerberos-Server-Maschine zu kompromittieren, so sind u.U. alle Maschinen der Kerberos-Realm kompromittiert, da sämtliche Server und Klienten dem Kerberos-Dienst voll vertrauen. Die Sicherheit des gesamten Systems basiert in hohem Maße auf dem zuverlässigen Schutz der in der Kerberos Authentication Database gehaltenen Secret Keys der Nutzer sowie der Server einer Realm.

Wie wir schon gesehen hatten, werden die Secret Keys in der Regel verschlüsselt in der Authentication Database aufbewahrt. Zur Chiffrierung dient das Kerberos Master Password. 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. beim automatischen Reboot nach einem Systemabsturz, wird das Master-Paßwort in dem File /.k auf der Kerberos-Server-Maschine abgelegt.

Aber auch auf den Kerberos-Klienten-Maschinen gibt es eine Reihe sensibler Files. Besonders schutzwürdig ist die Datei /etc/srvtab. Sie enthält die Secret Keys der Server, die auf dieser Maschine laufen. Weiterhin sind natürlich Systemfiles wie /etc/inetd.conf und /etc/services sowie ganz besonders jene Dateien von Interesse, die den Maschinen-Code der "kerberisierten", d.h. um die Kerberos-Klienten-Funktionalität erweiterten Programme enthalten (z.B. /bin/login). 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 MIT ausgegangen. Dazu gehört die Annahme, daß die von den Nutzern 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. Eine entfernte Nutzung über Telnet, SSH, Batch-Jobs o.ä. ist nicht vorgesehen.

Diskless Workstations sind für den Betrieb von Kerberos gänzlich ungeeignet, da man geheime Informationen (Session Keys) in Files aufbewahrt und diese Daten beim Lesen oder Schreiben der betreffenden Files sonst unverschlüsselt über das Netz übertragen würden.

Ebenso ungeeignet sind Maschinen mit mehreren Netz-Interfaces und damit mehreren Netz-Adressen. 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.

Replay-Attacken

Kerberos ist gegen Replay-Attacken anfällig, bei denen ein Angreifer Ticket-Authenticator-Paare wiedereinspielt, die er zuvor vom Netz abgelauscht hat. 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 beliebig oft wiederverwendet werden.

Zum Schutz vor Replay-Attacken wurden die Authenticators 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 Authenticators wiederverwendbar.

Der Entwurf des Kerberos-Protokolls sah vor, daß jeder Server eine Liste (einen Cache) aller noch aktiven Authenticators führt, um so wiedereingespielte Nachrichten erkennen zu können. Dieser Mechanismus ist aber nicht implementiert worden, da er sich (speziell auf älteren UNIX-Systemen) nicht sinnvoll oder nur sehr unbequem realisieren läßt. Das liegt in der Natur der Sache begründet. TCP-basierte Dienste arbeiten in der Regel so, daß jeder eingehende Request durch einen neuen, mit dem Systemruf fork erzeugten Prozeß bearbeitet wird. Dieser neue Prozeß besitzt von Hause aus aber keine gemeinsamen Speicherbereiche mit seinem Elternprozeß oder seinen Geschwisterprozessen und kann demzufolge diese auch nicht ohne weiteres über die verwendeten Authenticators informieren.

UDP-basierte Dienste haben es da etwas einfacher, da sie meist so implementiert sind, daß ein einzelner Prozeß alle eingehenden Anforderungen bearbeitet. Jedoch haben solche Implementationen Probleme mit legitimen Wiederholungen des Requests durch den Klienten. Wie Sie wissen, sind Sendewiederholungen möglich, da das UDP-Protokoll die Zustellung von Nachrichten nicht garantiert und es demzufolge geschehen kann, daß eine Anfrage oder die Antwort des Servers verlorengeht.

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ß.

Kerberos Version 5 gestattet, beim Ermitteln des TGT und beim Ermitteln der Server-Tickets anstelle der zeitbasierten Authentifizierung einen von der Zeit unabhängigen Challenge-Response-Mechanismus zu verwenden. Dazu nutzt man den bei der Protokolldiskussion genannten Nonce, der bei Kerberos 4 noch nicht existiert. In der Antwort des Servers ist dieser Nonce wiederum enthalten, so daß ihn der Klient prüfen und somit die Aktualität der Antwort der Servers feststellen kann.

Durch eine spezielle Fehlernachricht (KRB_AP_ERR_METHOD) besteht in Version 5 auch für Applikations-Server die Möglichkeit, dem Klienten die Nutzung eines Challenge-Response-Verfahrens zu signalisieren. Der Server sendet einen Nonce, den der Klient modifiziert zurücksenden muß.

Erraten von Paßwörtern - 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 einer Brute-force-Attacke versuchen, die Antwort zu entschlüsseln. Diese Vorgehensweise ist möglich, da der Algorithmus zum Berechnen des Secret Keys eines Principals aus dessen 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ßwörter.

Für dieses Problem wurden verschiedene Lösungen vorgeschlagen. So könnte man bereits die Anfrage an den AS nach dem TGT mit dem Secret Key verschlüsseln. Diese Vorgehensweise entspricht einer initialen Authentifizierung des Klienten 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 eines bestimmten Limits Fehlerprotokolle generieren, die Verbindung zum Klienten 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 Informationen zur Präauthentifizierung aufzunehmen. In der Regel benutzt man konkret einen verschlüsselten Zeitstempel.

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 aufrechterhä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 die oben gezeigten Subkeys verwendet werden können, die Klient und Server unter Verwendung des Session Keys austauschen.

Ein weiterer Kritikpunkt ist die 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 sowohl zeitlich (Lebensdauer) als auch räumlich (Netz-Adresse des Klienten) beschränkt. Mit einem Ticket kann ein Nutzer innerhalb der Lebensdauer des Tickets den Dienst des entsprechenden Servers in Anspruch nehmen, solange die Klienten-Programme direkt auf der Maschine laufen, für die das Ticket ausgestellt wurde. Die Beschränkung der Gültigkeit der Tickets auf genau eine Netz-Adresse stellt ein echtes Problem dar.

Möchte man nämlich von einer entfernten Maschine aus, auf die man z.B. per kerberisiertem rlogin gelangt ist, Dienste nutzen, so benötigt man ein für diesen Rechner gültiges Ticket. Um es zu beschaffen, muß sich der Nutzer auf dem entfernten Rechner authentifizieren, also sein Paßwort eingeben. Die Vermeidung der Übertragung des Paßworts war aber gerade eines der wichtigsten Ziele von Kerberos.

Anmerkung: Bei SSH oder anderen Werkzeugen, die den gesamten Datenstrom verschlüsseln und eine zuverlässige gegenseitige Authentifizierung der Partner durchführen, steht dieses Problem so nicht. Dort stellt die mehrfache Paßworteingabe primär eine Unbequemlichkeit dar, die man aber nach Möglichkeit vermeidet.

Kerberos Version 5 enthält Mechanismen zum Ticket Forwarding, die es gestatten, sich ein für die neue (entfernte) Maschine gültiges Ticket auf der Basis des bereits vorhandenen Tickets ausstellen zu lassen, so daß keine Paßwort-Übertragung erforderlich ist. Damit entsteht aber das vom Konzept der Trusted Hosts her bekannte Problem des transitiven Vertrauens. D.h., Partner A müßte Partner C vertrauen, nur weil A dem Partner B und dieser seinerseits C vertraut. Dies ist nicht generell akzeptabel.

Ticket Forwarding ist natürlich nur dann sinnvoll, wenn im Ticket die Netz-Adresse des Klienten enthalten ist. Verzichtet man auf die Netz-Adresse (was prinzipiell möglicht ist, wovon man aber abrät), dann 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 Klient 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. Dort wird eine Hierarchie der Realms organisiert, die etwa der hierarchischen Organisation des Domain Name Systems vergleichbar ist. Pro Realm werden dann nur noch für alle Eltern- und Kind-Realms derartige Inter-Realm Keys benötigt. Allerdings sind hier an der Etablierung einer authentifizierten 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 Authentifizierungsdienste 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, die Auswahl von Kerberos als Authentifizierungsprotokoll für OSF/DCE sowie die Unterstützung von Kerberos durch Windows 2000.

Literatur


Vertiefung:

Unter http://www.pdc.kth.se/kth-krb finden Sie neben weiteren Informationen zu Kerberos eine frei verfügbare, leistungsfähige, gut gepflegte und international eingesetzte Implementierung der Version 4.

Außerdem existiert unter dem Namen Heimdal [http://www.pdc.kth.se/heimdal/] eine freie, allerdings noch nicht ganz ausgereifte Implementierung von Kerberos 5, die bisher auch noch nicht offiziell angekündigt wurde.

SESAME (A Secure European System for Applications in a Multi-vendor Environment) ist ein europäisches, dem Kerberos sehr ähnliches System. Es beinhaltet viele Eigenschaften von Kerberos 5. Einer der wesentlichsten Unterschiede zwischen beiden ist die Verwendung von Public-Key-Verfahren in SESAME, da diese in Europa im Gegensatz zu den USA nicht patentgeschützt waren bzw. sind. Dadurch werden verschiedene Schwierigkeiten, mit denen man beim Betrieb von Kerberos-Systemen konfrontiert ist, vermieden. In der unter https://www.cosic.esat.kuleuven.ac.be/sesame/html/sesame_what.html verfügbaren Kurzvorstellung von SESAME werden folgende Erweiterungen gegenüber Kerberos genannt:

SESAME adds to Kerberos : Heterogeneity, sophisticated access control features, scalability of public key systems, better manageability, audit and delegation.

In diesem Zusammenhang sei noch angemerkt, daß es auch für Kerberos Vorschläge gibt, Public-Key-Verfahren einzusetzen, z.B. bei der sog. Cross-Realm Authentication, also der Authentifizierung über Realm-Grenzen hinweg.

Informationen zu SESAME sowie eine freie Implementierung finden Sie unter https://www.cosic.esat.kuleuven.ac.be/sesame/.


© Thomas Müller, April 1994
Holger Trapp, 1.7.1999