Benutzer oder Clients müssen Credentials (Berechtigungsnachweise) vorweisen können, die sie berechtigen, Dienste anzufordern. Kerberos kennt zwei Arten von Berechtigungsnachweisen — Tickets und Authenticators.

Ein Ticket ist ein serverbezogener Berechtigungsnachweis, den ein Client benutzt, um sich bei einem Server zu authentifizieren, von dem er einen Dienst anfordert. Es enthält den Namen des Servers, den Namen des Clients, die Internetadresse des Clients, einen Zeitstempel (engl. timestamp), eine Lebensdauer und einen zufällig generierten Session Key. Alle diese Daten werden mit dem Schlüssel des Servers verschlüsselt.

In Verbindung mit dem Ticket wird ein Authenticator benutzt, um zu beweisen, dass der Client, der ein Ticket vorlegt, tatsächlich derjenige ist, der er zu sein vorgibt. Ein Authenticator wird anhand des Namens des Clients, der IP-Adresse des Arbeitsplatzrechners und der aktuellen Uhrzeit am Arbeitsplatzrechner erstellt — verschlüsselt mit dem Session Key, der nur dem Client und dem Server, von dem er einen Dienst anfordert, bekannt ist. Im Gegensatz zu einem Ticket kann ein Authenticator nur einmal benutzt werden. Ein Client kann selbst einen Authenticator erzeugen.

Ein Kerberos-Principal ist eine unverwechselbare Einheit (ein Benutzer oder ein Dienst), der ein Ticket zugewiesen werden kann. Ein Principal setzt sich aus den folgenden Bestandteilen zusammen:

Kerberos sorgt dafür, dass sich sowohl der Client als auch der Server über die Identität der jeweiligen Gegenpartei sicher sein können. Sie teilen sich einen Session Key, mit dem sie sicher kommunizieren können.

Session Keys (Sitzungsschlüssel) sind temporäre private Schlüssel, die von Kerberos generiert werden. Sie sind dem Client bekannt und werden zur Verschlüsselung der Kommunikation zwischen dem Client und dem Server benutzt, von dem der Client ein Ticket angefordert und bekommen hat.

Fast alle Nachrichten, die in einem Netzwerk versendet werden, können abgehört, entwendet und erneut versendet werden. Im Zusammenhang mit Kerberos könnte dies äußerst gefährlich sein, falls es einem Angreifer gelingen sollte, Ihre Anforderung für einen Dienst abzufangen, die Ihr Ticket und Ihren Authenticator enthält. Er könnte daraufhin versuchen, sie erneut zu versenden („Replay“) und sich als Sie ausgeben. Allerdings implementiert Kerberos verschiedene Mechanismen, um diesem Problem vorzubeugen.

„Service“ (Dienst) wird benutzt, wenn eine bestimmte Aktion durchgeführt werden soll. Der zugrunde liegende Prozess wird als „Server“ bezeichnet.

Ihr erster Kontakt mit Kerberos ähnelt dem gewöhnlichen Einloggen an einem normalen Netzwerksystem. Geben Sie Ihren Benutzernamen ein. Diese Information und der Name des Ticket-Granting Services werden dem Authentifizierungsserver (Kerberos) zugesendet. Falls der Authentifizierungsserver von Ihrer Existenz weiß, generiert er einen (zufälligen) Session Key für den weiteren Gebrauch zwischen Ihrem Client und dem Ticket-Granting Server. Nun wird der Authentifizierungsserver ein Ticket für den Ticket-Granting Server erstellen. Das Ticket enthält die folgenden Informationen, die alle mit einem Session Key verschlüsselt sind, den nur der Authentifizierungsserver und der Ticket-Granting Server kennen:

Dann wird das Ticket zusammen mit dem Session Key nochmals in verschlüsselter Form dem Client zurückgesendet, jedoch unter Benutzung des privaten Schlüssels des Clients. Dieser private Schlüssel ist nur Kerberos und dem Client bekannt, da er von Ihrem Benutzerpasswort abgeleitet ist. Sobald der Client diese Antwort erhält, werden Sie nach Ihrem Passwort gefragt. Dieses Passwort wird in den Schlüssel konvertiert, welcher das vom Authentifizierungsserver gesendete Paket entschlüsseln kann. Das Paket wird entpackt und das Passwort und der Schlüssel werden aus dem Arbeitsspeicher des Arbeitsplatzrechners gelöscht. Ihr Arbeitsplatzrechner kann Ihre Identität nachweisen, bis die Lebensdauer des Ticket-Granting Tickets erlischt.

Um von einem beliebigen Server im Netzwerk einen Dienst anfordern zu können, muss die Client-Anwendung dem Server ihre Identität nachweisen. Daher generiert die Anwendung einen so genannten „Authenticator“. Dieser setzt sich aus den folgenden Bestandteilen zusammen:

Alle diese Informationen werden mit dem Session Key, den der Client bereits für diesen speziellen Server empfangen hat, verschlüsselt. Der Authenticator und das Ticket für den Server werden an den Server gesendet. Der Server benutzt seine Kopie des Session Keys, um den Authenticator zu entschlüsseln, der ihm sämtliche benötigte Informationen über den Client liefert, der seinen Dienst anfordert. Diese Informationen können mit denen verglichen werden, die im Ticket enthalten sind. So prüft der Server, ob Ticket und Authenticator vom gleichen Client stammen.

Gäbe es auf der Serverseite keine Sicherheitsmaßnahmen, so wäre diese Stufe das ideale Ziel für Replay-Attacken. Jemand mit schlechten Absichten könnte versuchen, eine vorher aus dem Netz gestohlene Anforderung erneut zu versenden. Um dies zu verhindern, nimmt der Server keine Anforderungen an, die mit einem Zeitstempel und einem Ticket versehen sind, die ihm schon vorher zugesendet worden waren. Außerdem können Anforderungen abgelehnt werden, deren Zeitstempel in Bezug auf den Zeitpunkt, an dem die Anforderung empfangen wurde, zu sehr abweichen (in die Zukunft und in die Vergangenheit).

Die Kerberos-Authentifizierung kann in beide Richtungen benutzt werden. Es geht nicht nur darum, ob der Client wirklich derjenige ist, der er zu sein vorgibt; auch der Server sollte in der Lage sein, sich gegenüber dem Client zu authentifizieren, der seinen Dienst anfordert. Daher versendet er selber auch eine Art Authenticator. Er addiert der Prüfsumme, die er im Authenticator des Clients erhalten hat, eins hinzu und verschlüsselt sie mit dem Session Key, den er mit dem Client teilt. Der Client betrachtet diese Antwort als Nachweis für die Echtheit des Servers, wonach die Zusammenarbeit zwischen dem Client und dem Server beginnen kann.

Tickets sind für den Gebrauch für jeweils einen Server bestimmt. Das bedeutet, dass Sie ein neues Ticket brauchen, sobald Sie einen anderen Dienst anfordern. Kerberos implementiert einen Mechanismus zur Beschaffung von Tickets für einzelne Server. Dieser Dienst wird als „Ticket-Granting Service“ (Dienst zur Ausstellung von Tickets) bezeichnet. Der Ticket-Granting Service ist ein Dienst wie jeder andere und unterliegt daher den gleichen Zugriffsprotokollen, die bereits erwähnt wurden. Jedes Mal, wenn eine Anwendung ein Ticket benötigt, das noch nicht angefordert wurde, nimmt sie mit dem Ticket-Granting Server Kontakt auf. Diese Anforderung setzt sich aus den folgenden Bestandteilen zusammen:

Ähnlich wie bei jedem anderen Server überprüft der Ticket-Granting Server das Ticket-Granting Ticket sowie den Authenticator. Falls sie als gültig anerkannt werden, erstellt der Ticket-Granting Server einen neuen Session Key zur Benutzung durch den ursprünglichen Client und den neuen Server. Dann wird das Ticket für den neuen Server mit den folgenden Informationen erstellt:

Dem neuen Ticket wird eine Lebensdauer zugewiesen, die der verbleibenden Lebensdauer des Ticket-Granting Tickets oder dem Standardwert für den Dienst entspricht, je nachdem, was kürzer ist. Dieses Ticket und der Session Key werden dem Client vom Ticket-Granting Service zugesendet. Dieses Mal ist die Antwort jedoch mit dem Session Key verschlüsselt, der mit dem ursprünglichen Ticket-Granting Ticket empfangen wurde. Wenn ein neuer Dienst angefordert wird, kann der Client nun die Antwort entschlüsseln, ohne das Benutzerpasswort erneut anzufordern. So kann Kerberos für den Client ein Ticket nach dem anderen erlangen, ohne den Benutzer mehr als einmal beim Login zu belästigen.

Windows 2000 enthält eine Microsoft-Implementierung von Kerberos 5. Da SUSE LINUX die Heimdal-Implementierung von Kerberos 5 benutzt, werden Sie in der Heimdal-Dokumentation bestimmt einige nützliche Informationen und Anleitungen finden; siehe Abschnitt 19.3.4. “Weitere Informationen über Kerberos”.