next up previous contents
Next: Alternativen zu Kerberos Up: Authentifizierung Previous: Authentifizierung   Contents


Das Kerberos-Protokoll

Die eben genannten Probleme waren die Hauptgründe der Entwicklung von Kerberos; die zentrale Authentifizierung in einer verteilten Umgebung, ein Single-Sign-On und die Vermeidung der Übertragung von Klartext-Passworten.
Kerberos ist ein Produkt des Athena-Projekts, welches ursprünglich den Einsatz von Computern und Software im Alltag im Massachusetts Institute for Technology (MIT) koordinieren sollte. Ein anderes Produkt dieses Projekts war beispielsweise das X Window System. Die Weiterentwicklung und Vereinheitlichung des Kerberos-Standards wird derzeit in einem Projekt mittels Declarations vorangetrieben, deren Internet-Portal auf [Ker05] zu finden ist. Der Name Kerberos wurde der griechischen Mythology entliehen und bezieht sich auf den Wächter des Hades, der den Zugang zur Welt der Toten bewachte und Lebenden diesen versagen musste - sozusagen ein historisches Zugangssystem darstellte.

Kerberos ist ein Single-Sign-On-System, da nach einmaligem Anmelden am Kerberos-System eine Nutzung aller "`kerberisierten"' Dienste möglich ist. Kerberos stellt durch seine zentrale Position eine Vermittlung zwischen unterschiedlichen administrativen Diensten dar - ein Nutzer kann Dienste eines anderen administrativen Bereichs nutzen, wenn der dortige Administrator dies erlaubt, da der Kerberos-Dienst gesichert die Nutzer authentifiziert. Außerdem gilt Kerberos aus zwei Gründen als sicher: Erstens wird nicht nur der Nutzer darauf überprüft, ob er derjenige ist, der er vorgibt zu sein, sondern auch die Kommunikationspartner also die Computer. Zweitens werden nur verschlüsselte Informationen übertragen und selbst wenn ein Angreifer ein Ticket für sich nutzbar machen kann, ist dieses zeitlich in seiner Gültigkeit begrenzt und damit die Sicherheit auf lange Sicht gegeben. Diese Aussage ist natürlich immer mit der Notwendigkeit verknüpft, dass die Nutzer sichere Passworte wählen und diese nicht ausspionieren lassen - wie bei den meisten Systemen ist der Nutzer das schwächste Glied in der Kette.

Die wesentlichen Begriffe im Zusammenhang mit Kerberos lauten:

  1. Realm,
  2. Principal,
  3. Instance,
  4. Ticket,
  5. Keys, Salt und
  6. Key Distribution Center (KDC).
Wie die Übersetzung des ersten Begriffs schon besagt, definiert der Realm ein Hoheitsgebiet, hier natürlich ein administratives. Ein Realm ist ein Namensraum, der sich eindeutig von allen anderen weltweiten Kerberos-Installationen unterscheidet. Dazu gilt die Vereinbarung, dass der durchgängig großgeschriebene DNS-Domänenname der Realm-Bezeichnung entspricht. Die Realm-Bezeichnung ist case-sensitive. Der Kerberos-Server beziehungsweise das Key Distribution Center (KDC) des Realms ist der zentrale Administrationspunkt für das gesamte Zugangssystems aller dem Realm angeschlossenen Systeme; somit ein sehr sensibler Punkt.
Das KDC stellt somit in der Betrachtung eines verteilten Dienstes nach Client-Server-Modell den Server dar. Die Principals sind die Clienten.
Jeder Nutzer, jeder Rechner und jeder Dienst eines Realms bekommt einen eigenen Bezeichner und einen zugeordneten Schlüssel. Diesen Bezeichner nennt man Principal. Der Schlüssel ist das gemeinsame Geheimnis; mehr dazu in der Folge. Der Principal wiederum ist weltweit eindeutig, was dadurch begründet ist, dass der Bezeichner innerhalb des Realms eindeutig sein muss und der Realm ebenfalls eindeutig ist, somit auch der Gesamtkonstrukt aus Realm und zugehörigem Principal eindeutig ist. Eng verknüpft damit ist der Begriff der Instance, die eine spezielle Ausprägung eines Principals bezeichnet. Am Beispiel eines Nutzers "`Max Mustermann"' im Realm "`BEISPIEL.REALM"' kann dieser das Principal $mmax@BEISPIEL.REALM$ haben. Ist er aber auch mit administrativen Aufgaben betreut, kann er zusätzlich auch die Instance $mmax/admin@BEISPIEL.REALM$ besitzen.
Zwischen allen beteiligten Partnern einer Kerberos-Kommunikation werden ausschließlich verschlüsselte Datenpakete ausgetauscht, die kryptografische Informationen zur Authentizitätskontrolle der Kommunikationspartner enthalten. Diese Informationspakete heißen bei Kerberos Tickets. Es dient als eine Art Ausweis dem Dienst gegenüber, der genutzt werden soll.
Schließlich bleibt noch der Begriff des Salts. Jedem Principal ist wie bereits erwähnt ein Key zugeordnet, also ein gemeinsames Geheimnis zwischen Principal und KDC. Dieser Key ist ein kryptografischer Schlüssel, also das Ergebnis einer Transformations- und Hashingfunktion. Diesen kann sich natürlich kein menschlicher Nutzer merken und bei jedem Login eingeben, weshalb dieser Key aus seiner Passwort-Eingabe transformiert wird. Um die Stärke der Verschlüsselung zu erhöhen, wird vor der Transformation eine Zeichenkette an die Eingabe angehangen. Diese Zeichenkette nennt man Salt, also Salz. Kerberos V5 beispielsweise hängt standardmäßig den Realm-Namen an, was verhindern soll, dass einem Nutzer bei Verwendung gleicher Passworte in unterschiedlichen Realms der gleiche Key zugeordnet wird.

Um sicherzustellen, dass keine Passworte übertragen werden, wurde ein Protokoll für Kerberos entwickelt, welches auf dem Needham-Schroeder-Protokoll basiert. Dieses Protokoll baut darauf auf, dass eine zentrale Stelle mit Kenntnis über alle Schlüssel aller Principals die Authentizität aller Kommunikationspartner sicherstellt. Diese zentrale Stelle ist das Key Distribution Center (KDC), welches aus zwei Komponenten besteht:

  1. dem Authentication Server (AS) und
  2. einem Ticket Granting Server (TGS).
Die Erteilung eines Zugangs zu einem Dienst oder System geschieht bei Kerberos in 2 Schritten. Erst wird für ein Realm, in dem das System oder Dienst angesiedelt sind, ein Kerberos Ticket Granting Ticket (KRBTGT) abgefragt. Dies ist für die Dauer seiner Gültigkeit der Nutzerausweis, also ein zeitlich begrenztes Sitzungsvisum. Mit diesem durch den AS erteilten Ticket kann der Client beliebige Service Tickets beim TGS anfordern. Das KRBTGT ist sozusagen die Überprüfung der Authentizität des Principals, die Service Tickets sichern die Authentizität der Kommunikationspartner und Principals untereinander.
Um ein solches KRBTGT zu erlangen, sendet der Client sein Principal und den Namen des KRBTGT-Principals, welches er anfordert, kombiniert mit Zeitinformationen an den AS. Dieser erteilt, wenn alle beteiligten Principals in seiner Datenbank bekannt sind, ein Ticket, in dem ein Session-Key einmal für den TGS, verbunden mit Informationen zum anfragenden Client-Principal, und einmal für das Client-Principal jeweils mit deren Key verschlüsselt enthalten ist. Dadurch kann der echte Client-Principal mit Hilfe seines Passworts seinen Session-Key entpacken. Der im zweiten Schritt angefragte TGS bekommt vom Client den mit seinem Schlüssel kodierten Teil des Tickets übermittelt, in dem ja auch Informationen zum Principal enthalten sind, der das KRBTGT bekommen hat. Auf dieser Grundlage kann der TGS die Authentizität des übermittelten Session-Keys und des übermittelnden Principals überprüfen. Im Ergebnis wird der TGS ein Service-Ticket erteilen, welches einen Session-Key für den Service inklusive Informationen zum ermächtigten Principal enthält und mit dem Schlüssel des angefragten Dienstes verschlüsselt ist. Dieses Ticket wird natürlich auch verschlüsselt übermittelt, diesmal wiederum mit dem Session-Key, der in der AS-Kommunikation ausgeteilt wurde.

In Kerberos V4 standen Probleme im Protokoll, welche einen sicheren Einsatz in heutigen Umgebungen nicht mehr vollständig gewährleistet. So war eine feste Bindung an Single-DES als kryptografische Funktion ebenso hinderlich, wie keine Bindung an eine Byte-Order, sondern ein Flag in der Kommunikation, das in jeder Nachricht deren Byte-Order anzeigte. Kerberos V5 wurde daher grundlegend neu entworfen unter Einfluss der Erkenntnisse aus dem Kerberos V4-Einsatz.
Die nennenswerten Erweiterung sind in erster Linie die Einführung eines beliebigen Verschlüsselungsverfahrens, sogar innerhalb einer Sitzung. Unterstützt so beispielsweise das Client-Principal nur Single-DES, der angefragte Dienst aber Triple-DES kann das KDC die Tickets in unterschiedlichen Verfahren verschlüsseln, solange sichergestellt ist, dass die beteiligten Kommunikationspartner jeweils ihren Teil des Tickets entschlüsseln kann. In Kerberos V4 wurde das verschlüsselte Ticket für den angefragten Dienst (beispielsweise auch der Teil eines KRBTGT, welches dem TGS als Ausweis des Principals dient) ebenfalls in die Verschlüsselung des Principals einbezogen. Dies erwies sich als unnotig, da das Geheimnis auch durch die Verschlüsselung für den Zieldienst bei einer Übertragung gewahrt werden kann. Somit wird in Kerberos V5 das Ticket aus zwei getrennt verschlüsselten Teilen übermittelt. Auch das vereinfacht den Einsatz unterschiedlicher Kodierungsverfahren in den Ticket-Teilen.
Außerdem wurden Optionen für Tickets eingeführt. So können Tickets eines Nutzerprincipals auf andere Rechner verschoben werden (forwardable tickets und proxiable tickets - ermöglicht die Anforderung eines neuen TGTs beziehungsweise nicht) oder der Gültigkeitszeitstempel kann erneuert (renewable ticket) beziehungsweise für einen zukünftigen Zeitpunkt angefordert (postdated ticket) werden.
Ebenfalls mit Kerberos V5 wurde das Prinzip der Pre-Authentication eingeführt. Pre-Authentication soll die Daten der Kerberos-Datenbank gegen offline Wörterbuch- und brute-force-Attacken besser schützen. In Kerberos V4 wurde durch den AS jedem anfragenden Client ein TGT für ein beliebig angefragtes Principal erteilt. Dieses war zwar mit dem Schlüssel des angefragten Principals kodiert, aber damit gegen oben genannte Angriffe verwundbar. Bei der Pre-Authentication wird seitens des Client-Principals ein Zeitstempel mit dem Key des Principals verschlüsselt und an den Request zum AS angehangen. Dieser kann mit dem Key des anfragenden Principals dessen Zeitstempel entschlüsseln und mit seiner Zeiteinstellung vergleichen. Innerhalb einer administrierten Zeittoleranz wird der Principal als "`echt"' anerkannt und das angefragte TGT erteilt.

Eine weitere sehr interessante Eigenschaft von Kerberos sind so genannte "`Cross Realm Trusts"'. Dabei handelt es sich um Vertrauensstellungen zwischen mehreren administrativen Hoheitsgebieten. Dadurch wird es ermöglicht, Ressourcen fremder Realms für Nutzer des eigenen zugänglich zu machen. Dazu werden in den Kerberos-Datenbanken jeweils zwei Principals eingepflegt, die den Mustern $krbtgt/EIGENER.REALM@FREMD.REALM$ und
$krbtgt/FREMD.REALM@EIGENER.REALM$ entsprechen und jeweils mit dem selben
Schlüssel in beiden Datenbeständen erstellt sind. Dadurch kann jeder Nutzer ein "`Intermediate Ticket Granting Ticket"' des Fremdrealms anfordern und mit diesem direkt beim Fremd-TGS Service Tickets für die Ressourcen des Fremdrealms anfordern. Diese Form nennt sich direkter Cross-Realm Trust und ist in Kerberos V4 die einzige unterstützte Form. In Kerberos V5 wurde zusätzlich das Prinzip des "`certification path"' eingeführt und damit der impliziten oder transitiven Vertrauensstellung. Der direkte Trust wird nur noch zu einem zwischengeschaltenen Realm erstellt, der wiederum anderen Realms vertraut. Dadurch wird implizit auch eine Vertrauensstellung zu dem dritten Realm über den zwischengeschaltenen Realm aufgebaut. In einem Windows-Domänen-Baum wird durch die Root-Domäne automatische solch eine Vertrauensstellung aufgebaut. Mehr dazu in Kapitel 4.

In allen Definitionen von Kerberos fehlt eine Festlegung zur Änderung des Passworts eines Nutzers selbst. Der Moment der Änderung bedarf als einziger der Übertragung eines kryptografischen Geheimnisses - entweder des Klartextpasswort oder des neuen Schlüssels. Dazu wird implementationsabhängig ein Dienst genutzt, der ein externes Protokoll nutzt und meist das Ergebnis der Kodierung des neuen Passworts überträgt. Dadurch wird auch dabei kein Klartextpasswort übertragen. Die Protokolle in Kerberos V4, die dabei zum Einsatz kamen, waren die administrativen Protokolle des jeweiligen Herstellers. In Kerberos V5 kommt nun hingegen meist das Horowitz-Protokoll zum Einsatz, allerdings oft auch noch mit implementationsabhängigen Anpassungen. [Gar03] erwähnt noch die Einführung eines einheitlichen Protokolls, welches auf Horowitz aufsetzt, aber Nutzern das Ändern des eigenen und Administratoren zusätzlich das Ändern von Fremdpassworten ermöglicht. Dieses befand sich 2003 noch in der Phase der Definition, wodurch bisher noch kein Einsatz stattfindet.
Ein Problem bei den Verfahren, bei denen seitens des Clienten die Transformation vorgenommen wird, liegt in der leistungsstarken Überprüfung der kryptografischen Stärke des neuen Passworts.


next up previous contents
Next: Alternativen zu Kerberos Up: Authentifizierung Previous: Authentifizierung   Contents
Marko Damaschke 2006-03-25