1.1. The Kerberos Protocol (Das Kerberos-Protokoll)
1.1. The Kerberos Protocol (Das Kerberos-Protokoll)
Kerberos bietet ein Mittel zur Überprüfung der Identitäten von Principals (Prinzipalen, z.B. einem Workstation-Benutzer oder einem Netzwerkserver) in einem offenen (ungeschützten) Netzwerk. Dies wird erreicht, ohne sich auf Aussagen des Host-Betriebssystems zu verlassen, ohne Vertrauen auf Host-Adressen zu basieren, ohne physische Sicherheit aller Hosts im Netzwerk zu erfordern, und unter der Annahme, dass Pakete, die im Netzwerk unterwegs sind, nach Belieben gelesen, modifiziert und eingefügt werden können. Kerberos führt Authentifizierung unter diesen Bedingungen als Trusted Third-Party Authentication Service (vertrauenswürdiger Drittanbieter-Authentifizierungsdienst) durch, indem konventionelle (shared secret key, gemeinsamer geheimer Schlüssel) Kryptographie verwendet wird. Erweiterungen zu Kerberos (außerhalb des Umfangs dieses Dokuments) können die Verwendung von Public-Key-Kryptographie während bestimmter Phasen des Authentifizierungsprotokolls ermöglichen. Solche Erweiterungen unterstützen die Kerberos-Authentifizierung für Benutzer, die bei Public-Key-Zertifizierungsstellen registriert sind, und bieten bestimmte Vorteile der Public-Key-Kryptographie in Situationen, in denen sie benötigt werden.
Der grundlegende Kerberos-Authentifizierungsprozess läuft wie folgt ab: Ein Client sendet eine Anfrage an den Authentication Server (Authentifizierungsserver, AS) für "Credentials" (Berechtigungsnachweise) für einen bestimmten Server. Der AS antwortet mit diesen Credentials, verschlüsselt mit dem Schlüssel des Clients. Die Credentials bestehen aus einem "Ticket" für den Server und einem temporären Verschlüsselungsschlüssel (oft als "Session Key" bezeichnet). Der Client übermittelt das Ticket (das die Identität des Clients und eine Kopie des Session Key enthält, alles verschlüsselt mit dem Schlüssel des Servers) an den Server. Der Session Key (der jetzt vom Client und Server geteilt wird) wird verwendet, um den Client zu authentifizieren, und kann optional verwendet werden, um den Server zu authentifizieren. Er kann auch verwendet werden, um weitere Kommunikation zwischen den beiden Parteien zu verschlüsseln oder um einen separaten Sub-Session-Key auszutauschen, der verwendet wird, um weitere Kommunikation zu verschlüsseln. Beachten Sie, dass viele Anwendungen die Funktionen von Kerberos nur bei der Initiierung einer stream-basierten Netzwerkverbindung verwenden. Sofern eine Anwendung keine Verschlüsselung oder Integritätsschutz für den Datenstrom durchführt, gilt die Identitätsüberprüfung nur für die Initiierung der Verbindung, und sie garantiert nicht, dass nachfolgende Nachrichten auf der Verbindung vom selben Principal stammen.
Die Implementierung des grundlegenden Protokolls besteht aus einem oder mehreren Authentifizierungsservern, die auf physisch sicheren Hosts laufen. Die Authentifizierungsserver pflegen eine Datenbank von Principals (d.h. Benutzern und Servern) und ihren geheimen Schlüsseln. Code-Bibliotheken bieten Verschlüsselung und implementieren das Kerberos-Protokoll. Um Authentifizierung zu seinen Transaktionen hinzuzufügen, fügt eine typische Netzwerkanwendung Aufrufe an die Kerberos-Bibliothek direkt oder über das Generic Security Services Application Programming Interface (GSS-API), das in einem separaten Dokument [RFC4121] beschrieben ist, hinzu. Diese Aufrufe führen zur Übertragung der Nachrichten, die zur Erreichung der Authentifizierung notwendig sind.
Das Kerberos-Protokoll besteht aus mehreren Subprotokollen (oder Exchanges, Austauschvorgängen). Es gibt zwei grundlegende Methoden, mit denen ein Client einen Kerberos-Server um Credentials bitten kann. Im ersten Ansatz sendet der Client eine Klartext-Anfrage für ein Ticket für den gewünschten Server an den AS. Die Antwort wird verschlüsselt mit dem geheimen Schlüssel des Clients gesendet. Normalerweise ist diese Anfrage für ein Ticket-Granting Ticket (TGT), das später mit dem Ticket-Granting Server (TGS) verwendet werden kann. In der zweiten Methode sendet der Client eine Anfrage an den TGS. Der Client verwendet das TGT, um sich beim TGS zu authentifizieren, auf die gleiche Weise, als würde er jeden anderen Anwendungsserver kontaktieren, der Kerberos-Authentifizierung erfordert. Die Antwort wird mit dem Session Key aus dem TGT verschlüsselt. Obwohl die Protokollspezifikation den AS und den TGS als separate Server beschreibt, werden sie in der Praxis als unterschiedliche Protokoll-Einstiegspunkte innerhalb eines einzelnen Kerberos-Servers implementiert.
Sobald sie erhalten wurden, können Credentials verwendet werden, um die Identität der Principals in einer Transaktion zu überprüfen, um die Integrität der zwischen ihnen ausgetauschten Nachrichten sicherzustellen oder um die Privatsphäre der Nachrichten zu bewahren. Die Anwendung ist frei, welchen Schutz auch immer notwendig ist, zu wählen.
Um die Identitäten der Principals in einer Transaktion zu überprüfen, überträgt der Client das Ticket an den Anwendungsserver. Da das Ticket "in the clear" (im Klartext) gesendet wird (Teile davon sind verschlüsselt, aber diese Verschlüsselung verhindert kein Replay) und von einem Angreifer abgefangen und wiederverwendet werden könnte, werden zusätzliche Informationen gesendet, um zu beweisen, dass die Nachricht von dem Principal stammt, dem das Ticket ausgestellt wurde. Diese Information (genannt Authenticator) ist mit dem Session Key verschlüsselt und enthält einen Timestamp (Zeitstempel). Der Timestamp beweist, dass die Nachricht kürzlich generiert wurde und kein Replay ist. Die Verschlüsselung des Authenticators mit dem Session Key beweist, dass er von einer Partei generiert wurde, die den Session Key besitzt. Da niemand außer dem anfordernden Principal und dem Server den Session Key kennt (er wird niemals im Klartext über das Netzwerk gesendet), garantiert dies die Identität des Clients.
Die Integrität der zwischen Principals ausgetauschten Nachrichten kann auch garantiert werden, indem der Session Key (der im Ticket weitergegeben und in den Credentials enthalten ist) verwendet wird. Dieser Ansatz bietet Erkennung sowohl von Replay-Angriffen als auch von Nachrichtenstrom-Modifikationsangriffen. Dies wird durch die Generierung und Übertragung einer kollisionsfreien Prüfsumme (an anderer Stelle Hash- oder Digest-Funktion genannt) der Nachricht des Clients erreicht, die mit dem Session Key verschlüsselt ist. Privatsphäre und Integrität der zwischen Principals ausgetauschten Nachrichten können durch Verschlüsselung der zu übergebenden Daten unter Verwendung des im Ticket enthaltenen Session Key oder des im Authenticator gefundenen Sub-Session-Key gesichert werden.
Die oben erwähnten Authentifizierungs-Exchanges erfordern nur Lesezugriff auf die Kerberos-Datenbank. Manchmal müssen jedoch die Einträge in der Datenbank modifiziert werden, wie z.B. beim Hinzufügen neuer Principals oder beim Ändern des Schlüssels eines Principals. Dies geschieht unter Verwendung eines Protokolls zwischen einem Client und einem dritten Kerberos-Server, dem Kerberos Administration Server (KADM). Es gibt auch ein Protokoll zur Pflege mehrerer Kopien der Kerberos-Datenbank. Keines dieser Protokolle wird in diesem Dokument beschrieben.