Kerberos: Ticket‑basiertes Authentifizierungsprotokoll des MIT

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.

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:

1. Teilnehmer, die eine lose synchronisierte Zeit beibehalten.
2. 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:

1. Ein Benutzer gibt einen Benutzernamen und ein Passwort auf dem Client-Computer ein.
2. 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:

1. 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.
2. 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.
3. 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:

1. 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.
2. 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:

1. 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.
2. 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.
3. 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.
4. Der Server stellt dem Client die angeforderten Dienste zur Verfügung.

• 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.

• Identitätsverwaltung
• Sicheres Fernkennwort-Protokoll (SRP)
• Anwendungsprogrammschnittstelle für generische Sicherheitsdienste (GSS-API)