Anwendung | Kerberos | ||||
---|---|---|---|---|---|
Transport | UDP | TCP | |||
Internet | IP (IPv4, IPv6) | ||||
Netzzugang | Ethernet | Token Bus |
Token Ring |
FDDI | … |
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.
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.
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.
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.
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.
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 Angreifern die Angriffsmöglichkeit eröffnet, per Manipulation der Serverzeit ggf. alte Tickets als noch gültige zu verwenden.[6]