Kerberos: Ticket‑basiertes Authentifizierungsprotokoll des MIT

Kerberos – MIT‑entwickeltes ticketbasiertes Authentifizierungsprotokoll für sichere Client‑Server‑Kommunikation, Schutz vor Replay‑ und Lauschangriffen mit zentralem Schlüssel‑Dienst.

Autor: Leandro Alegsa

02-03-2026 21:53

Kerberos (ausgesprochen /ˈkɜrbərəs/ "kur-ber-uhs") ist ein ticket‑basiertes Authentifizierungsprotokoll, das ursprünglich am Massachusetts Institute of Technology entwickelt wurde und in Computernetzwerken für sichere Anmelde- und Identitätsnachweise eingesetzt wird. Kerberos ermöglicht es Benutzerinnen und Benutzern, ihre Identität gegenüber Diensten oder anderen Benutzern (zum Beispiel Mohammed Hasan oder einem auf Gmail basierenden Dienst) auf eine sichere Weise nachzuweisen. Implementierungen wie die Suite von freien Softwarepaketen aus dem MIT-Bereich sind weit verbreitet.

Grundprinzip

Kerberos arbeitet nach dem Prinzip des Ticket-basierten Authentifizierens. Anstatt Passwörter bei jedem Dienst zu übermitteln, erhält der Benutzer zunächst vom zentralen Vertrauensdienst ein kryptografisch geschütztes Ticket, das er dann beim Zielservice vorlegt. Das System ist so ausgelegt, dass Nachrichten gegen Abhören und Replay-Angriffe geschützt sind und sowohl Client als auch Server gegenseitig ihre Identität überprüfen können (gegenseitige Authentifizierung).

Wesentliche Komponenten

Client: das Programm oder die Person, die Zugriff auf einen Service anfordert.
Service-Server: der Dienst, zu dem der Zugriff gewährt werden soll (z. B. Datei‑ oder Mailserver).
Key Distribution Center (KDC): das zentrale Element, das Schlüssel und Tickets ausstellt; es besteht typischerweise aus zwei logischen Teilen:
- Authentication Server (AS)
- Ticket Granting Server (TGS)
Realm und Principals: administrative Domänen (Realms) und eindeutige Identitäten (Principals) für Clients und Services.

Wie Kerberos funktioniert (vereinfacht)

1. Der Client authentifiziert sich beim Authentifizierungsdienst des KDC (AS) und erhält ein Ticket Granting Ticket (TGT), verschlüsselt mit einem Schlüssel, den nur der KDC kennt.
2. Mit dem TGT fordert der Client beim TGS ein Service‑Ticket für den gewünschten Dienst an.
3. Der TGS stellt ein Service‑Ticket aus, das der Client an den Ziel‑Service sendet.
4. Der Service prüft das Ticket und gewährt bei erfolgreicher Prüfung Zugriff; auf Wunsch werden auch gegenseitige Authentifizierung und Session‑Schlüssel verwendet, damit Client und Server sichere Nachrichten austauschen können.

Kryptografie und Schutzmechanismen

Kerberos benutzt vorwiegend Kryptographie mit symmetrischen Schlüsseln: Sitzungsschlüssel werden zwischen Client und Service vergeben, und Tickets sowie Authentifizierungsnachrichten werden verschlüsselt. Das Protokoll geht davon aus, dass Pakete im [sicheres oder sichere Netzwerk gelesen, verändert oder eingefügt werden können, und schützt entsprechend gegen Abhören und Replay-Angriffe (z. B. durch Zeitstempel und Ablaufzeiten).

Kerberos verwendet ein geteiltes Geheimnis und ein Schlüsselverteilungszentrum. Erweiterungen wie PKINIT erlauben die Einbindung von Kryptographie mit öffentlichem Schlüssel in bestimmten Phasen der Authentifizierung, um z. B. die Erstauthentisierung abzusichern.

Sicherheitsmerkmale und Einschränkungen

Gegenseitige Authentifizierung: Kerberos kann Client und Server gegenseitig prüfen, so dass beide Parteien sicher sein können, mit dem richtigen Gegenüber zu kommunizieren.
Schutz vor Replay: Zeitstempel und Ablaufzeiten helfen, wiederholte Angriffe zu verhindern; deshalb sind synchronisierte Uhren in Client, Server und KDC wichtig.
Zentraler Vertrauensanker: Das KDC ist ein Single Point of Trust/Failure — seine Kompromittierung gefährdet das gesamte Realm.
Schlüsselmanagement: Sichere Speicherung von Langzeitschlüsseln (z. B. Passwort‑basierte Schlüssel) ist kritisch; längere Ticket‑Lebenszeiten erhöhen das Risiko bei Schlüsselkompromittierung.
Forward Secrecy: Klassisches Kerberos bietet keine vollständige perfekte Forward Secrecy; spezielle Erweiterungen und Protokollerweiterungen sind nötig, um dies zu verbessern.

Funktionen und Erweiterungen

Kerberos unterstützt typische Funktionen wie Single Sign‑On, erneuerbare Tickets, Delegation (Delegation of credentials) und Cross‑Realm‑Authentifizierung zwischen vertrauenswürdigen Domains. Bekannte Erweiterungen und Standards im Umfeld von Kerberos sind GSS‑API, SPNEGO und Integration in Suite-Kontexte für verschiedene Anwendungen.

Implementierungen und Einsatzgebiete

Es gibt mehrere Kerberos‑Implementierungen, unter anderem die Referenzimplementierung des MIT, Heimdal und proprietäre Varianten in kommerziellen Produkten. Microsofts Active Directory verwendet Kerberos als zentrales Authentifizierungsprotokoll in Windows‑Domänen. Kerberos ist weit verbreitet in Unternehmensnetzwerken, Campus‑Infrastrukturen und überall dort, wo sichere, skalierbare Authentifizierung und Single Sign‑On gewünscht sind.

Standards

Die heute gebräuchliche Spezifikation ist Kerberos V5 (publiziert als RFC 4120). Ältere Versionen (z. B. V4) gelten als veraltet. Kerberos kann in Kombination mit anderen Sicherheitsmechanismen und Protokollen eingesetzt werden, um moderne Anforderungen an Authentifizierung und Autorisierung zu erfüllen.

Zusammenfassend ist Kerberos ein bewährtes, weitverbreitetes Authentifizierungsprotokoll, das auf einem zentralen vertrauenswürdigen Dritten basiert und mit Hilfe von kryptografischen Mechanismen sichere Authentifizierung in unsicheren Netzwerken ermöglicht.

Geschichte und Entwicklung

Das MIT entwickelte Kerberos zum Schutz der vom Projekt Athena bereitgestellten Netzwerkdienste. Das Protokoll wurde nach der griechischen mythologischen Figur Kerberos (oder Cerberus) benannt, die in der griechischen Mythologie als der monströse dreiköpfige Wachhund des Hades bekannt ist. Es existieren mehrere Versionen des Protokolls; die Versionen 1-3 werden nur intern am MIT verwendet.

Steve Miller und Clifford Neuman, die Hauptentwickler von Kerberos Version 4 (die den DES-Verschlüsselungsalgorithmus mit 56-Bit-Schlüsseln verwendete), veröffentlichten diese Version 1989, obwohl sie sie in erster Linie für das Projekt Athena vorgesehen hatten.

Version 5, entworfen von John Kohl und Clifford Neuman, erschien 1993 als RFC 1510 (2005 durch RFC 4120 obsolet gemacht), mit der Absicht, die Einschränkungen und Sicherheitsprobleme der Version 4 zu überwinden. Das MIT stellt eine Implementierung von Kerberos Version 5 frei zur Verfügung, unter einer Software-Lizenz, die der von der BSD-Lizenz ähnlich ist.

Mehrere Unternehmen setzten Kerberos Version 5 in kommerzieller Software ein, darunter

· Microsofts Windows 2000 und später verwenden Kerberos als Standardauthentifizierungsmethode.
Einige Ergänzungen von Microsoft zur Kerberos-Protokollreihe sind in RFC 3244 "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols" dokumentiert.
RFC 4757 dokumentiert die Verwendung der RC4-Chiffre durch
Microsoft.
Während Microsoft das Kerberos-Protokoll verwendet, verwendet es nicht die MIT-Software[1].

· Auch Apples Mac OS X verwendet Kerberos sowohl in der Client- als auch in der Server-Version.

· Red Hat Linux Version 4 und später verwendet Kerberos sowohl in der Client- als auch in der Server-Version.

Im Jahr 2005 hat die IETF-Arbeitsgruppe Kerberos eine neue aktualisierte Spezifikation für Kerberos Version 5 [2] eingeführt:

· "Verschlüsselungs- und Prüfsummenspezifikationen" (RFC 3961),

· "Advanced EncryptionStandard (AES)-Verschlüsselung für Kerberos 5" (RFC 3962),

· Eine neue Ausgabe der Kerberos-Version 5-Spezifikation "Der Kerberos-Netzwerk-Authentifizierungsdienst (V5)" (RFC 4120). Diese Version obsolet RFC 1510, klärt Aspekte des Protokolls und des Verwendungszwecks in einer detaillierteren klaren Erklärung,

· Eine neue Ausgabe der GSS-API-Spezifikation "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism": Version 2". (RFC 4121).

Im Jahr 2007 gründete das MIT das Kerberos-Konsortium zur Fortsetzung der Entwicklung.

Protokoll

Kerberos verwendet als Grundlage das Needham-Schroeder-Protokoll. Es verwendet eine vertrauenswürdige Authentifizierung von dritter Seite, die als "Key Distribution Center (KDC)" bekannt ist und aus zwei logisch getrennten Teilen besteht: einem Authentifizierungsserver (AS) und einem Ticket Granting Server (TGS). Kerberos arbeitet auf der Grundlage von "Tickets" (sog. Kerberos-Tickets), die zum Nachweis der Identität von Benutzern dienen.

Kerberos-Datenbank: Das Key Distribution Center (KDC) unterhält eine Datenbank mit geheimen Schlüsseln; jede Entität im Netzwerk - sei es ein Client oder ein Server - teilt einen geheimen Schlüssel, der nur ihr selbst und dem KDC bekannt ist. Die Kenntnis dieses Schlüssels dient dazu, die Identität jeder Entität nachzuweisen. Für die Kommunikation zwischen zwei Entitäten erzeugt das KDC einen Sitzungsschlüssel, mit dem sie ihre Kommunikation sichern können.

Der Begriff "Kerberos-Server" bezieht sich im Allgemeinen auf den KDC. Aus Gründen der Zuverlässigkeit ist es möglich, Backup-KDCs zu haben. Diese werden als "Kerberos-Slaveserver" bezeichnet. Alle Slaves synchronisieren ihre Datenbanken vom Master-Kerberos-Server.

Der Begriff "kerberisierter Anwendungsserver" bezieht sich im Allgemeinen auf kerberisierte Programme, mit denen Clients über Kerberos-Tickets zur Authentifizierung kommunizieren. Beispielsweise ist der Kerberos-Telnet-Server ein Beispiel für einen kerberisierten Anwendungsserver . Während sich der Begriff "kerberisierte Anwendungen" auf die Clientseite des kerberisierten Anwendungsservers bezieht, ist beispielsweise der Kerberos-Telnet-Client ein Beispiel für kerberisierte Anwendungen.

Die Sicherheit des Protokolls hängt stark davon ab:

Teilnehmer, die eine lose synchronisierte Zeit beibehalten.
Eine kurzlebige Echtheitserklärung: die Kerberos-Tickets.

Vereinfachte Beschreibung des Protokolls

Die folgenden Abkürzungen werden verwendet:

· AS = Authentifizierungs-Server

· TGS = Ticket gewährender Server

· SS oder Server = Service Server (Server-Benutzer, der seinen Dienst anfordert, wie z.B. ein Druckserver, ein Dateiserver, usw...)

· TGT = Ticket Granting Ticket (Kerberos-Fahrausweis für den TGS, der von der AS erstellt wurde und dann zum Gespräch mit dem TGS verwendet wurde).

Der Klient authentifiziert sich kurzzeitig bei der AS unter Verwendung eines langfristigen gemeinsamen Geheimnisses und erhält von der AS ein Ticket. Später kann der Klient dieses Ticket verwenden, um weitere Tickets für die AS zu erhalten, die dasselbe geteilte Geheimnis verwenden. Diese Tickets können zum Nachweis der Authentifizierung gegenüber der SS verwendet werden.

Das Protokoll im Detail

Benutzer-Client-basierte Anmeldeschritte:

Ein Benutzer gibt einen Benutzernamen und ein Passwort auf dem Client-Computer ein.
Der Kunde führt eine Einwegfunktion (meist eine Hash-Funktion) auf das eingegebene Passwort aus, und dieses wird zum geheimen Schlüssel des Kunden/Benutzers.

Schritte zur Client-Authentifizierung:

Der Kunde sendet eine Klartextnachricht an die AS, die im Namen des Benutzers Dienstleistungen anfordert.
Muster einer Nachricht: "Benutzer XYZ möchte Dienstleistungen anfordern".
Bemerkung: Weder der geheime Schlüssel noch das Passwort werden an die FTB geschickt.
Die AS prüft, ob sich der Kunde in ihrer Datenbank befindet. Ist dies der Fall, sendet die AS die folgenden beiden Meldungen an den Kunden zurück:

Nachricht A: Client/TGS Session Key verschlüsselt mit dem geheimen Schlüssel des Client/Benutzers.
Nachricht B: TGT (die die Client-ID, die Client-Netzadresse, die Ticket-Gültigkeitsdauer und den Client/TGS-Sitzungsschlüssel enthält), verschlüsselt mit dem geheimen Schlüssel des TGS.

Sobald der Client die Nachrichten A und B erhält, entschlüsselt er Nachricht A, um den Client/TGS-Sitzungsschlüssel zu erhalten. Dieser Sitzungsschlüssel wird für die weitere Kommunikation mit TGS verwendet. Zu diesem Zeitpunkt hat der Client genügend Informationen, um sich gegenüber dem TGS zu authentifizieren.
Hinweis: Der Client kann Nachricht B nicht entschlüsseln, da sie mit dem geheimen Schlüssel von TGS verschlüsselt ist.

Autorisierungsschritte für den Kundenservice:

Bei der Anforderung von Dienstleistungen sendet der Kunde die folgenden zwei Nachrichten an den TGS:

Nachricht C: Zusammengesetzt aus dem TGT aus Nachricht B und der ID des angeforderten Dienstes.
Nachricht D: Authentifikator (der sich aus der Client-ID und dem Zeitstempel zusammensetzt), verschlüsselt mit dem Client/TGS-Sitzungsschlüssel.

Beim Empfang der Nachrichten C und D holt der TGS aus Nachricht C Nachricht B ab. Er entschlüsselt Nachricht B mit dem geheimen Schlüssel des TGS. Dadurch erhält er den Client/TGS-Sitzungsschlüssel. Unter Verwendung dieses Schlüssels entschlüsselt der TGS Nachricht D (Authentifikator) und sendet die folgenden beiden Nachrichten an den Client:

Nachricht E: Client-zu-Server-Ticket (das die Client-ID, die Client-Netzwerkadresse, die Gültigkeitsdauer und den Client/Server-Sitzungsschlüssel enthält), verschlüsselt mit dem geheimen SS-Schlüssel.
Nachricht F: Client/Server-Sitzungsschlüssel, verschlüsselt mit dem Client/TGS-Sitzungsschlüssel.

Schritte für Kundendienstanfragen:

Nach Erhalt der Nachrichten E und F von TGS hat der Kunde genügend Informationen, um sich bei der SS zu authentifizieren. Der Client verbindet sich mit dem SS und sendet die folgenden beiden Nachrichten:

Nachricht E: aus dem vorherigen Schritt (das Client-zu-Server-Ticket, verschlüsselt mit dem geheimen Schlüssel SS).
Nachricht G: ein neuer Authentifikator, der die Client-ID und den Zeitstempel enthält und mit dem Client/Server-Sitzungsschlüssel verschlüsselt wird.

Der SS entschlüsselt das Ticket mit seinem eigenen geheimen Schlüssel, um den Client/Server-Sitzungsschlüssel abzurufen. Mit dem Sitzungsschlüssel entschlüsselt der SS den Authentifikator und sendet die folgende Nachricht an den Client, um seine wahre Identität und seine Bereitschaft, dem Client zu dienen, zu bestätigen:

Nachricht H: der im Authenticator des Clients gefundene Zeitstempel plus 1, verschlüsselt mit dem Client/Server-Sitzungsschlüssel.

Der Client entschlüsselt die Bestätigung unter Verwendung des Client/Server-Sitzungsschlüssels und prüft, ob der Zeitstempel korrekt aktualisiert wird. Wenn dies der Fall ist, dann kann der Client dem Server vertrauen und mit der Ausgabe von Dienstanforderungen an den Server beginnen.
Der Server stellt dem Client die angeforderten Dienste zur Verfügung.

Nachteile

Einzelner Punkt des Scheiterns: Es erfordert die ständige Verfügbarkeit eines zentralen Servers. Wenn der Kerberos-Server ausgefallen ist, kann sich niemand einloggen. Dies kann durch den Einsatz mehrerer Kerberos-Server und Notfall-Authentifizierungsmechanismen gelöst werden.
Für Kerberos müssen die Uhren aller beteiligten Hosts synchronisiert werden. Die Tickets haben eine Zeitverfügbarkeitsperiode, und wenn die Uhr des Hosts nicht mit der Uhr des Kerberos-Servers synchronisiert ist, schlägt die Authentifizierung fehl. Die Standardkonfiguration erfordert, dass die Uhrzeiten nicht mehr als 10 Minuten auseinander liegen. In der Praxis wird normalerweise das Network Time Protocol (NTP) verwendet, um alle Hosts synchronisiert zu halten.
Das Verwaltungsprotokoll ist nicht standardisiert und unterscheidet sich von Server-Implementierung zu Server-Implementierung. Kennwortänderungen sind in RFC 3244 beschrieben.
Da die geheimen Schlüssel für alle Benutzer auf dem zentralen Server gespeichert sind, werden bei einer Kompromittierung dieses Servers die geheimen Schlüssel aller Benutzer kompromittiert.
Ein kompromittierter Client wird das Passwort des Benutzers kompromittieren.

Fragen und Antworten

F: Was ist Kerberos?

A: Kerberos ist ein Authentifizierungsprotokoll für Computernetzwerke, das es Personen, die über ein unsicheres Netzwerk kommunizieren, ermöglicht, ihre Identität gegenseitig sicher nachzuweisen.

F: Wer hat Kerberos entwickelt?

A: Die Entwickler von Kerberos zielten in erster Linie auf ein Client-Server-Modell ab und stammten vom Massachusetts Institute of Technology (MIT).

F: Wie sorgt Kerberos für die gegenseitige Authentifizierung?

A: Durch die Verwendung kryptographischer gemeinsamer Geheimnisse können sowohl der Benutzer als auch der Server die Identität des jeweils anderen überprüfen.

F: Wie schützt Kerberos vor Spionage- und Replay-Angriffen?

A: Durch die Verschlüsselung von Nachrichten, die zwischen Benutzern gesendet werden, wird verhindert, dass diese von Dritten gelesen oder verändert werden können.

F: Welche Art von Kryptographie wird bei Kerberos verwendet?

A: Es verwendet eine symmetrische Kryptographie, für die ein Schlüsselverteilungszentrum erforderlich ist.

F: Unterstützt Kerberos Kryptographie mit öffentlichen Schlüsseln?

A: Ja, Erweiterungen des Protokolls können deren Verwendung in bestimmten Phasen der Authentifizierung vorsehen.

Suche in der Enzyklopädie