Visum fürs LAN Kerberos – sicher und bequem zur netzweiten Anmeldung

Ordnungsmerkmale

erschienen in: <kes> 2006^#4, Seite 19

Zusammenfassung: Ein Klassiker unter den Authentifizierungssystemen erfreut sich steigender Beliebtheit: Seit Kerberos unter der Haube von Microsofts Active Directory werkelt, kommt es auch in heterogenen Netzen verstärkt zum Einsatz. Grund genug, sich die dahinter steckende Technik, ihre Vorzüge und auch Risiken mal wieder näher anzusehen.

Autor: Von Joachim Keltsch, Tübingen

Der mythologische Namensgeber von Kerberos hatte es leicht: Der Höllenhund musste lediglich den einzigen Ein- und Ausgang des Totenreichs bewachen. Entsprechend der höheren Komplexität von IT-Netzwerken mit etlichen Servern und Diensten ist der Wächter in seiner modernen Inkarnation indes zur Pass- und Visa-Behörde mutiert. Denn einem Computer muss sein Benutzer am Anfang einer Session erstmal die Frage "Wer bin ich?" beantworten. Mehr als Tastatureingaben stehen meist nicht zur Verfügung, um festzustellen wer sich einloggen möchte. Das Authentifizierungssystem Kerberos zeigt, wie man unter diesen Voraussetzungen ein hohes Maß an Sicherheit gewährleisten kann. Weil es für Anwender gleichzeitig besonders komfortabel ist, mausert es sich mehr und mehr zum Standard bei der Benutzeranmeldung – quer über alle Betriebssysteme hinweg. Das gilt auch für Windows-Anwender, die sich über Active Directory anmelden, denn unter der Haube steckt auch dabei nichts anderes als Kerberos.

Tatsächlich war die Integration in Active Directory der entscheidende Schritt, der Kerberos auch außerhalb der Windows-Welt zum Durchbruch verholfen hat: Denn so lassen sich nun auch in heterogenen Netzen Benutzerzugänge einheitlich verwalten. Wer zuvor Unix- und Windows-Accounts von Hand synchron halten musste, kann damit überflüssige Arbeitsschritte und Fehler vermeiden. Noch mehr handfeste wirtschaftliche Vorteile liefert demnächst das Basel-II-Abkommen, das ab Anfang 2007 die Bonität eines Unternehmens unter anderem an die Sicherheit seiner IT-Infrastruktur koppelt: Eine Benutzerauthentifizierung über Kerberos schlägt da in jedem Fall positiv zu Buche.

Man mag es als Ironie betrachten oder schlicht als Glücksfall, dass Kerberos nun aufgrund von Kostenargumenten Einzug in die Unternehmensnetze hält. Denn was als Forschungsprojekt am US-amerikanischen Massachusetts Institute of Technology (MIT) bereits in den 1980er-Jahren begann [1], besticht in Version 5 technisch schon seit über zwei Jahrzehnten durch etliche Vorteile, ist als offener Standard in RFC 4120 [2] dokumentiert und inzwischen in zwei freien Implementierungen verfügbar (siehe [1] und  www.pdc.kth.se/heimdal/).

Beliebt machte sich Kerberos dadurch in der Vergangenheit jedoch allenfalls an Universitäten. Das kommerzielle Umfeld blieb hingegen größtenteils beim althergebrachten Authentifizierungsschema: Jeder Rechner überprüft während des Einloggens mehr oder weniger eigenständig die Identität eines Benutzers, indem er eine Prüfsumme des eingegebenen Passworts mit dem passenden Hash-Wert aus einer Liste gültiger Passwörter vergleicht. Die Liste selbst liegt entweder lokal als Datei vor oder wird von einem Verzeichnisdienst über das Netzwerk geliefert (z. B. NIS oder LDAP). Will der Benutzer auf Ressourcen eines anderen Rechners zugreifen, so muss er sich dort in der Regel erneut per Passwort authentifizieren, beispielsweise um seine Post vom Mail-Server abzurufen. Komfortabel ist das nicht. Manche Server-Dienste machen es sich daher noch einfacher und vertrauen schlicht darauf, dass der Client den Benutzer schon korrekt authentifiziert hat. Das Netzwerkdateisystem NFS ist bis einschließlich Version 3 der bekannteste Vertreter dieser Kategorie und leidet so am offensichtlichen Sicherheitsproblem: Wer schon immer einmal in den persönlichen Daten der Kollegen herumstöbern wollte, muss nur das eigene Notebook mit der richtigen IP-Adresse ins Netz hängen und hat daraufhin Zugriff auf die NFS-Verzeichnisse der entsprechenden Benutzer.

Kerberos-Design

Um derartige Probleme zu vermeiden, gründet das Design von Kerberos vor allem auf gesundem Misstrauen: Niemand soll sich eine fremde Identität erschleichen können, indem er Datenverkehr im Netzwerk aufzeichnet (Replay-Attacke) oder eine andere Netzwerkadresse vortäuscht (Spoofing). Selbst ein Angreifer, der einen Rechner im Netz vollständig unter seine Kontrolle gebracht hat, darf nicht in der Lage sein, das gesamte Authentifizierungssystem zu kompromittieren.

In der Praxis sieht die Authentifizierung über Kerberos dann wie folgt aus: Zunächst fordert der Benutzer von einem zentralen Authentifizierungsserver, dem Key Distribution Center (KDC), ein so genanntes Ticket Granting Ticket (TGT) an (vgl. Abb. 1). Das wird ihm verschlüsselt zugeschickt und erst dann gültig, wenn der Benutzer es mithilfe seines Passworts entschlüsselt. Danach speichert er das TGT auf seinem Rechner in einem Ticket-Cache, wo es verbleibt, bis seine Gültigkeitsdauer abläuft – typischerweise nach einigen Stunden. Währenddessen dient das TGT als alleiniger Identitätsnachweis im Kerberos-Netzwerk, sozusagen als virtueller Reisepass.

Abbildung 1: Zum Session-Start erhält der Benutzer vom Key Distribution Center (KDC) ein Ticket Granting Ticket – die Übermittlung wird mit dem User-Passwort (U) chiffriert.

Will der Benutzer anschließend beispielsweise seine E-Mail lesen, so fordert er (genauer: sein System) vom zentralen Kerberos-Server (KDC) ein Ticket für den IMAP-Dienst des Mail-Servers an und fügt sein TGT quasi als Ausweis bei (vgl. Abb. 2). Das KDC überprüft anhand des TGT, dass der Benutzer bereits authentifiziert ist und schickt ihm ein Ticket für den E-Mail-Dienst zurück, sozusagen ein virtuelles Visum. Dieses Ticket reicht der Benutzer-PC weiter an den Mail-Server, der es überprüft und dadurch die Identität des Benutzers verifiziert.

Abbildung 2: Nach Anforderung eines Tickets für Dienst 1 erhält der Benutzer einen Session Key für die Kommunikation mit diesem Dienst und ein Ticket zur Weitergabe (chiffriert mit dem Dienst-Key "D").

Geheimniskrämerei

Um zu verstehen, weshalb das besonders sicher sein soll, ist ein Blick ins Innenleben eines solchen Kerberos-Tickets nötig: Jedes Ticket authentifiziert zwei Kommunikationspartner untereinander, die so genannten Principals. Es spielt für Kerberos dabei keine Rolle, ob es sich bei einem Principal um einen realen Benutzer handelt, der gerade sein Mail-Programm bedient, oder um ein autark laufendes Programm, etwa den IMAP-Server. Jeder Principal teilt mit dem KDC ein Geheimnis (Passwort), mit dessen Hilfe er seine Identität nachweist (vgl. Abb. 1 und 2).

Will nun Principal A mit Principal B kommunizieren, erzeugt das KDC auf Anfrage von A einen zufälligen Schlüssel (Session Key) und verpackt zwei Kopien davon in ein neues Ticket (s. Abb. 2). Eine Kopie ist mit dem Geheimnis von A verschlüsselt, die andere mit dem Geheimnis von B. Das Ticket wird an A geschickt und von dort an B weitergereicht. Beide extrahieren mithilfe ihres jeweiligen Geheimnisses den Session Key und verschlüsseln damit die weitere Kommunikation untereinander. Falls das klappt, sind beide Partner erfolgreich gegeneinander authentifiziert.

Sicher ist das vorgestellte Prozedere bereits jetzt, doch am Komfort mangelt es noch. Schließlich müsste ein Benutzer für jedes angeforderte Ticket sein Passwort aufs Neue eingeben. Um das zu vermeiden, besorgt er sich zu Beginn einer Sitzung ein Ticket für die Kommunikation mit dem KDC selbst, das bereits erwähnte Ticket Granting Ticket (TGT). Wie ein normales Ticket enthält auch das TGT zwei Kopien eines Session Keys. Die eine ist mit dem (gehashten) Passwort des Benutzers verschlüsselt. Die zweite Kopie, die mit dem Passwort des KDC selbst verschlüsselt ist, legt der Benutzer bei allen weiteren Ticketanforderungen bei (s. Abb. 1). Das KDC benutzt daraufhin zum Verschlüsseln des neuen Session Keys als Geheimnis nicht das Passwort des Benutzers, sondern den Session Key aus dem TGT. Das funktioniert vollautomatisch und ermöglicht ein Single Sign-on (SSO): Der Benutzer gibt nur einmal zu Beginn einer Sitzung sein Passwort an und ist anschließend für alle (Kerberos-unterstützten) Dienste im Netzwerk authentifiziert.

Das bringt neben dem offensichtlichen Komfortgewinn für die Nutzer auch Sicherheitsvorteile: So liegen die Passwortdaten aller Benutzer nur noch auf wenigen KDCs und werden im Normalbetrieb nie – nicht einmal verschlüsselt – über das Netzwerk verschickt. Statt getrennter Anmeldedaten für jeden Netzwerkdienst muss sich jeder Benutzer nur noch ein einziges Passwort merken und es in der Regel nur einmal am Tag eintippen. Daher ist ihm in der Regel zuzumuten, sich an höhere Sicherheitsstandards zu halten, beispielsweise längere und kompliziertere Zeichenketten zu verwenden und vor allem darauf zu verzichten, Passwörter auf den berühmt-berüchtigten gelben Zettelchen zu notieren.

Als Bonus erhält der Anwender mehr Schutz vor Man-in-the-Middle-Attacken, da sich nicht nur der Benutzer gegenüber dem Netzwerkdienst authentifizieren muss, sondern auch der Dienst gegenüber dem Benutzer. Überdies macht es Kerberos den Diensten besonders einfach, nicht nur die Authentifizierungsphase per Session Key zu verschlüsseln, sondern diesen auch gleich für den Schutz der gesamten Kommunikation zu nutzen. So werden selbst Oldtimer wie telnet, eigentlich als Prototyp des unsicheren Netzwerkprotokolls verschrien, im Verbund mit Kerberos plötzlich wieder salonfähig.

Haken und Ösen

Kerberos besitzt jedoch auch Schwachstellen, allem voran den Ticket-Cache: Damit voneinander unabhängige Client-Programme automatisiert neue Tickets anfordern können, enthält der Cache unter anderem das entschlüsselte TGT. Wer es schafft, sich unberechtigten Zugriff darauf zu verschaffen, darf sich daraufhin unter falschem Namen im gesamten Netzwerk tummeln – jedenfalls so lange, bis das Ticket abläuft. Ticket-Caches auf unverschlüsselten Netzwerkdateisystemen sind geradezu eine Einladung zum Missbrauch. Gerät zudem einmal das Passwort eines Benutzers in falsche Hände, so ist bei (wohlbemerkt jedem) Single Sign-on prinzipbedingt nicht nur der Zugang zu einem Dienst oder Server betroffen, sondern es sind gleich alle kompromittiert.

Auch Kerberos ist zudem kein Allheilmittel, das umfassende Sicherheit ins Netzwerk bringt. Erlangt ein Angreifer die Kontrolle über einen Rechner, so droht auch mit Kerberos höchste Gefahr: Gegen einen Keylogger, der heimlich jeden Tastendruck protokolliert, ist so ziemlich jedes passwortbasierte Authentifizierungssystem machtlos. Die Microsoft-Implementierung von Kerberos unterstützt zwar auch asymmetrische Verschlüsselungsverfahren mithilfe einer Smartcard, ein universeller Standard dazu ist jedoch erst in Vorbereitung.

Nichtsdestotrotz mildert Kerberos in aller Regel die Auswirkungen eines Angriffs: In einem Netzwerk mit "klassischer" Authentifizierung ermöglicht ein kompromittierter Computer dem Angreifer eventuell Zugang zu den Passwortdaten aller Teilnehmer, sei es beispielsweise aufgrund der .htpasswd-Datei des Web-Servers oder von Passwort-Listen im LDAP- oder NIS-Verzeichnis. Mit Kerberos hingegen kann er mithilfe eines gehackten Arbeitsplatzrechners nur die Passwörter einzelner Benutzer abgreifen, nämlich genau derjenigen, die sich dort per Tastatur einloggen. Auf einem Server kann der Angreifer das Service-Passwort genau eines Netzwerkdienstes in der Keytab auslesen und damit eine Man-in-the-Middle-Attacke starten – gegen die ein rein passwortbasiertes Authentifizierungsverfahren von vornherein keinen Schutz bietet. Alle anderen Services – und vor allem das Benutzerpasswort – werden jedoch nicht kompromitiert.

Fazit

Unterm Strich sorgt Kerberos in jedem Fall für deutliches Plus an Sicherheit im Netz, auch wenn man es sich durch ein ebenso deutliches Plus an Komplexität erkauft. Denn Kerberos ist kein Leichtgewicht: Gut eine Viertelmillion Zeilen Code umfasst beispielsweise die Referenzimplementierung des MIT – die bleiben nicht ohne Fehler. In den vergangenen sechs Jahren hat das MIT zwanzig Sicherheitswarnungen herausgegeben und Lücken gestopft, vom einfachen Denial-of-Service-Angriff bis hin zum Exploit, der Angreifern über das Netz Administratorzugang auf das KDC verschafft. Das KDC und mögliche Replikate davon sind als Sammelbecken sensitiver Passwortinformationen schon prinzipbedingt besonders gefährdet und sollten daher nach Möglichkeit auf je einem eigenen, besonders gesicherten Rechner laufen.

Nicht zu vernachlässigen ist zudem der administrative Aufwand für die Umstellung eines Netzwerks auf Kerberos-Authentifizierung: Jedes Server-Programm muss dazu eigens konfiguriert, jeder Netzwerkdienst mit seinem Schlüssel dem KDC bekannt gemacht werden. Immerhin hat die Verbreitung von Active Directory dazu geführt, dass die wichtigsten Applikationen inzwischen Kerberos überhaupt unterstützen, wenngleich der Administrator mitunter noch etwas an der Konfiguration basteln muss. Größtes Problem während der Umstellungsphase sind jedoch typischerweise die Benutzerpasswörter: Kerberos speichert sie parallel mit mehreren Hash-Verfahren, andere Systeme hingegen nur mit einem. Daher lassen sich die Passwort-Hashes nicht automatisch übernehmen. Im einfachsten Fall weist der Administrator jedem Benutzer ein neues Passwort zu, doch in großen Netzen kann selbst das zur logistischen Herausforderung werden.

Lohn der Mühen ist letztlich ein Authentifizierungssystem, das den Anforderungen der aktuellen Trends im IT-Bereich gewachsen ist. Dieser, so verkünden es die Whitepaper der Computerriesen, entwickelt sich aktuell unter dem Schlagwort Serverside Computing: Web-Services und Portale sollen zunehmend die bisherigen Desktop-Applikationen ersetzen. Serverseitige Programme sparen Ressourcen und sind leichter zentral zu administrieren, bergen für die Benutzer jedoch den Nachteil, sich jeweils am Server authentifizieren zu müssen. Die Single-Sign-on-Lösung Kerberos umschifft dieses Problem auf ebenso elegante wie sichere Art und macht die Netzinfrastruktur sicher für die Zukunft.

Joachim Keltsch ist Senior Solution Architect bei der science + computing ag in Tübingen ( www.science-computing.de).

zurück zum Inhalt
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2006^#4, Seite 19