Kerberos (Protokoll)
Kerberos ist ein verteilter Authentifizierungsdienst (Netzwerkprotokoll) für offene und unsichere Computernetze (wie zum Beispiel das Internet), der von Steve Miller und Clifford Neuman basierend auf dem Needham-Schroeder-Protokoll zur Authentifizierung (1978) entwickelt wurde. Die zurzeit aktuelle Version ist Kerberos 5. Sie ist in RFC 4120 definiert und nutzt ASN.1 zur Codierung.
| Anwendung | Kerberos | ||||
| Transport | UDP | TCP | |||
| Internet | IP (IPv4, IPv6) | ||||
| Netzzugang | Ethernet | Token Bus |
Token Ring |
FDDI | … |
Kerberos entstand im Rahmen des Projekt Athena am MIT; erst die Version 4 Ende der 1980er Jahre wurde auch außerhalb des MIT verwendet. Kerberos soll eine sichere und einheitliche Authentifizierung in einem ungesicherten TCP/IP-Netzwerk auf sicheren Hostrechnern bieten. Die Authentifizierung übernimmt eine vertrauenswürdige dritte Partei (auch als Trusted Third Party bezeichnet). Diese dritte Partei ist ein besonders geschützter Kerberos-5-Netzwerkdienst. Kerberos unterstützt Single Sign-on, das heißt ein Benutzer muss sich nur einmal anmelden. Im Anschluss kann er alle verfügbaren Netzwerkdienste nutzen, ohne ein weiteres Mal sein Passwort eingeben zu müssen.
Der Name leitet sich vom dreiköpfigen Höllenhund Kerberos aus der griechischen Mythologie ab, der den Eingang zur Unterwelt bewacht.
Funktionsweise
Bei Kerberos sind drei Parteien beteiligt:
Der Kerberos-Dienst authentifiziert sowohl den Server gegenüber dem Client, als auch den Client gegenüber dem Server, um Man-in-the-middle-Angriffe zu unterbinden. Auch der Kerberos-Server selbst authentifiziert sich gegenüber dem Client und dem Server und verifiziert selbst deren Identität.
Kerberos verwendet Tickets zur Authentifizierung. Um den Kerberos-Dienst nutzen zu können, muss sich ein Client zuerst beim Kerberos-Server anmelden. Er fordert vom Kerberos-Server ein Ticket Granting Ticket (TGT) an. Hierzu muss der Nutzer des Clients entweder ein Passwort eingeben, oder das TGT wird direkt bei der Benutzeranmeldung angefordert. Mit dem TGT ist der Client in der Lage, weitere Tickets für Dienste anzufordern, ohne nochmal ein Passwort eingeben zu müssen. Es wird auch ein Session Key für die Kommunikation zwischen Client und Kerberos-Server ausgehandelt. Er kann benutzt werden, um den Datenverkehr zu verschlüsseln.
Um einen Dienst, der Kerberos unterstützt, benutzen zu können, fordert der Client ein weiteres Ticket an. Dieses Ticket sendet der Client dann an den Dienst, der überprüft, ob er dem Client den Zugriff gestatten soll. Auch hierbei wird ein Sitzungsschlüssel vereinbart und die Identität von Client, Server und Kerberos-Server überprüft.
Der RFC verlangt für beteiligte Hosts einen Zeitabgleich der beteiligten Systeme, um Zeitunterschiede über fünf Minuten zu vermeiden.[1] Hier bietet sich die Verwendung von NTP an.
Schematischer Ablauf der Kerberos-Authentifikation
Erläuterungen zur Abbildung:
Szenario: Nutzer u möchte Service s nutzen, er besitzt noch kein TGT. Die kleineren Rechtecke (hell-grün, hell-orange, hell-lila) sind Datenpakete, die jeweils mit dem nach dem Stern (*) stehenden Schlüssel verschlüsselt sind. Das Kürzel ST steht für: Ticket zur Nutzung des Services s. In den großen Rechtecken (Server) und in der Ellipse (Client) stehen nach den Pfeilen diejenigen Informationen, die dem jeweiligen Service/Client bekannt sind in Weiß, und diejenigen die zugesandt werden in der Farbe des Absenders. Kerberos Authentication-Server und Ticket Granting Server (TGS) haben beide Zugriff auf die Schlüsseldatenbank ihres Administrationsbereiches (Realm), sie kennen also beide alle Client- und Server-Schlüssel. Die Pakete am Pfeilende sind dabei zuerst verschickt worden (um das Entschlüsseln des folgenden zu ermöglichen).
Ein Kerberos-Server ist für einen Realm zuständig, das heißt, er verwaltet nur Konten, die zu seinem Realm gehören. Der Realm kann beispielsweise der DNS-Domänen-Name in Großbuchstaben, etwa EXAMPLE.COM, sein. Ein Rechner kann immer nur zu einem Realm gehören. Um auf Dienste in anderen Realms über Kerberos zugreifen zu können, müssen Vertrauensstellungen zwischen den einzelnen Realms hergestellt werden. So ist es möglich, dass ein Benutzer aus A.EXAMPLE.COM auf Dienste in B.EXAMPLE.COM zugreifen kann, ohne sich erneut authentifizieren zu müssen.
Bei Kerberos4 wird als Chiffre nur DES unterstützt. Kerberos5 ist in der Lage, die verwendete Chiffre und das verwendete Prüfsummenverfahren auszuhandeln.
Nutzer, Hosts und Dienste werden bei Kerberos über symmetrische Schlüssel authentifiziert. Dem Schlüssel ist ein Name, der Kerberos Principal, zugeordnet. Für Hosts ist der Principal host/<hostname>@<REALM> (z. B. host/www.example.com@EXAMPLE.COM), für Dienste <servicename>/<hostname>@<REALM> (z. B. imap/www.example.com@EXAMPLE.COM) und für Nutzer <benutzer>/<instanz>@<REALM> (z. B. mueller/admin@EXAMPLE.COM). Die Instanz gibt bei einem Nutzer-Principal die Art des Accounts an. Der Nutzer mueller/admin@EXAMPLE.COM ist ein Kerberos-Administrator.
Durch Kerberos werden insbesondere Angriffe durch passives Sniffing unterbunden, aber auch Spoofing, Wörterbuch-, Replay- und andere Angriffe erschwert.
Kerberos-Unterstützung
Damit ein Netzwerkdienst Kerberos nutzen kann, ist es nötig, dass der Dienst in der Lage ist, mit Kerberos-Tickets umzugehen. Auf dem Server- und Client-Host muss jeweils ein Kerberos-Client installiert und konfiguriert sein. Sowohl die Client- als auch die Server-Software muss Kerberos unterstützen. Für Kerberos5 müssen Client, Server und Kerberos-Server ein gemeinsames Verschlüsselungs- und Prüfsummenverfahren verwenden.
Es gibt zwei unterschiedliche Arten von Kerberos-Unterstützung: Entweder Kerberos wird vollständig unterstützt oder der Client sendet dem Server den Kerberos-Principal und das Passwort im Klartext.
Für den Apache HTTP Server gibt es das Kerberos-Modul mod_auth_kerb.[2] Darüber hinaus kann auch mod_auth_gssapi verwendet werden.
Implementierungen
- MIT Kerberos
- Das MIT bietet eine freie Implementierung des Kerberos-Protokolls für Unix und Linux an. Es werden die Versionen 4 und 5 unterstützt. Als Verschlüsselungsverfahren werden DES, 3DES, AES und RC4 unterstützt, als Prüfsummenverfahren stehen MD5, SHA-1, HMAC und CRC32 zur Verfügung.
- Heimdal Kerberos
- An der KTH entstand eine weitere freie, unter BSD-Lizenz stehende Kerberos-Implementierung für Unix, Linux und Mac, namens Heimdal.[3] Der Hauptentwickler ist Love Hörnquist Åstrand. Da Heimdal kompatibel zur MIT Implementierung ist, werden dieselben Verschlüsselungsverfahren und Hashfunktionen unterstützt. Samba benutzt mit Samba4 auch Heimdal.[4]
- GNU Shishi
- Eine weitere freie, weil unter der GPL stehende, Kerberos-Implementierung für Unix und Linux ist Shishi[5].
- Active Directory
- Microsoft verwendet Kerberos als Standardprotokoll für die Authentifizierung ab Windows-2000/2003-basierten Netzwerken sowie für Clients ab Windows 2000 / XP. Hier werden die Kerberos-Schlüssel in Active Directory gespeichert. Unter Windows 2000 wird nur die Verschlüsselung mit RC4 oder DES unterstützt, was diesen Verzeichnisdienst verwundbar für Brute-Force-Angriffe macht. In den Versionen ab Windows XP, SP1, sind Erweiterungen implementiert worden, die das System gegen solche Angriffe stärker absichern.
Schwachstellen
Mit Version 5 von Kerberos wurden bereits viele Schwachstellen aus Version 4 beseitigt. Unter anderem wurde das Login-Verfahren verbessert. In Version 4 konnte jeder unter Angabe eines Benutzernamens ein Initialticket anfordern, welches mit dem Passwort des Benutzers verschlüsselt wird. Der Clientrechner fragt den Benutzer nun nach dem Passwort, um das Ticket zu entschlüsseln. Die Problematik hierbei ist, dass der Benutzer nun in Besitz des Tickets ist und offline eine Wörterbuch-Attacke auf das Passwort starten kann.
Aber auch in Version 5 sind einige Schwachstellen enthalten. Die Sitzungsschlüssel werden lokal auf dem Clientrechner im /tmp-Verzeichnis verwaltet und nach Ablauf der Gültigkeit gelöscht. Als das Protokoll im Projekt Athena entwickelt wurde, war es nur für Einbenutzersysteme vorgesehen. In Mehrbenutzersystemen ist es nun ohne Probleme möglich, Tickets anderer Benutzer zu stehlen. Ein weiterer wesentlicher Schwachpunkt ist die Masterkey-Verwaltung des Kerberos Authentication Servers. Dieser verschlüsselt alle Passwörter der Benutzer mit demselben Masterkey. Da dieser Schlüssel aber auch lokal auf der Festplatte des Servers gespeichert ist, müssten alle Passwörter der Benutzer erneuert werden, wenn das System kompromittiert wurde. Um Replay-Angriffe zu verhindern, wird unter anderem ein Zeitstempel verwendet. Dies hat jedoch zur Folge, dass sich die beteiligten Rechner auf eine gemeinsame Zeit einigen und synchronisiert werden müssen. Hierdurch wird es Angreifern ermöglicht, die Zeit der Server zu manipulieren und so ggf. alte Tickets als noch gültige verwenden zu können.[6]
Siehe auch
Literatur
- Roland Bless u. a.: Sichere Netzwerkkommunikation. Grundlagen, Protokolle und Architekturen. In: X.systems.press. Springer Verlag, 2005, ISBN 978-3-540-21845-6, ISSN 1611-8618 (sineko.de).
- Claudia Eckert: IT-Sicherheit. Oldenbourg Verlag, München 2006, ISBN 978-3-486-57851-5.
- Jason Garman: Kerberos. The Definitive Guide. O’Reilly Media, Sebastopol 2003, ISBN 978-0-596-00403-3.
- Mark Pröhl: Kerberos. Single Sign-on in gemischten Linux/Windows-Umgebungen. dpunkt.verlag, Heidelberg 2011, ISBN 978-3-89864-444-0 (kerberos-buch.de).
- William Stallings: Network Security Essentials. Applications and Standards: International Version, 4/E. Pearson Higher Education, New York 2010, ISBN 978-0-13-706792-3.
Weblinks
- RFC 4120 (englisch)
- MIT Kerberos (englisch)
- Heimdal Kerberos (englisch)
- Shishi Kerberos (englisch)
- Kerberos – Single Sign On Benutzerauthentisierung (PDF; 94 kB)
- Kerberos: An Authentication Service for Open Network Systems (PostScript; englisch; ausführlich)
Einzelnachweise
- rfc:4120 #section-1.6 – The Kerberos Network Authentication Service (V5). Environmental Assumptions
- mod_auth_kerb
- Heimdal. In: h5l.org. Abgerufen am 16. März 2012 (englisch).
- Samba & Kerberos. In: SambaWiki. 26. Februar 2007, abgerufen am 4. Juni 2012 (englisch).
- GNU Shishi Projektseite. In: GNU Shishi. Abgerufen am 26. Juni 2013 (englisch).
- Eckert, Claudia. IT-Sicherheit. Oldenbourg, 2014, pp. 522–523.