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:
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:
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
und
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.