Kerberos-Architektur und Ticket-Ablauf

Kerberos wurde am MIT in den 1980er-Jahren im Rahmen des Project Athena entwickelt, um eine sichere Netzwerkauthentifizierung für eine verteilte Computerumgebung bereitzustellen. Benannt nach dem dreiköpfigen Hund, der die Unterwelt bewacht, ermöglicht Kerberos die gegenseitige Authentifizierung zwischen Clients und Diensten mithilfe einer vertrauenswürdigen dritten Instanz: dem Key Distribution Center.

Das KDC besteht aus zwei logischen Komponenten: dem Authentication Service (AS) und dem Ticket Granting Service (TGS). In Microsoft Active Directory laufen beide auf dem Domain Controller. Der AS verarbeitet die erste Anmeldung und stellt Ticket Granting Tickets (TGTs) aus. Der TGS stellt Diensttickets für den Zugriff auf bestimmte Dienste aus.

Der Client beginnt die Authentifizierung, indem er eine AS-REQ an den Authentication Service sendet. Modernes Kerberos erfordert eine Präauthentifizierung: Der Client verschlüsselt einen Zeitstempel mit seinem Langzeitschlüssel (der aus dem Passwort abgeleitet wird), um nachzuweisen, dass er das Passwort kennt. Dadurch werden Offline-Wörterbuchangriffe auf ungeschützte AS-REQ-Nachrichten verhindert.

Der AS überprüft die Präauthentifizierungsdaten und antwortet mit einer AS-REP, die ein mit dem Langzeitschlüssel des krbtgt-Kontos verschlüsseltes Ticket Granting Ticket (TGT) sowie einen mit dem Langzeitschlüssel des Clients verschlüsselten Sitzungsschlüssel enthält. Der Client entschlüsselt nur den für ihn bestimmten Teil und erhält so den TGS-Sitzungsschlüssel.

Wenn der Client auf einen Dienst zugreifen möchte, sendet er eine TGS-REQ an den Ticket Granting Service. Diese enthält das TGT (als Identitätsnachweis) und einen mit dem TGS-Sitzungsschlüssel verschlüsselten Authenticator. Der TGS entschlüsselt das TGT mit dem krbtgt-Schlüssel, um die Identität des Clients zu überprüfen.

Der TGS antwortet mit einem mit dem Langzeitschlüssel des Zieldienstes verschlüsselten Dienstticket sowie einem neuen, für den Client verschlüsselten Sitzungsschlüssel. Der Client kann den Inhalt des Diensttickets nicht lesen, sondern nur den für ihn verschlüsselten Teil. Dieses Dienstticket weist die Identität des Clients gegenüber dem Dienst nach.

Der Client sendet eine AP-REQ an den Zieldienst. Diese enthält das Dienstticket und einen neuen, mit dem Dienstsitzungsschlüssel verschlüsselten Authenticator. Der Dienst entschlüsselt das Dienstticket mit seinem eigenen Langzeitschlüssel, überprüft den Authenticator und authentifiziert den Client. Das Passwort wird niemals an den Dienst gesendet.

Ein Kerberos-Realm ist eine administrative Domäne, die von einem einzelnen KDC verwaltet wird. Die Realm-übergreifende Authentifizierung wird durch Inter-Realm-Schlüssel eingerichtet, die von den KDCs verschiedener Realms gemeinsam verwendet werden. Wenn ein Client in Realm A auf einen Dienst in Realm B zugreift, stellt das KDC in Realm A ein Weiterleitungsticket aus, das der Client dem KDC von Realm B vorlegt.

Kerberos-Tickets haben eine konfigurierte Lebensdauer (für TGTs typischerweise 10 Stunden). Danach laufen sie ab und eine neue Authentifizierung ist erforderlich. TGTs können außerdem als erneuerbar konfiguriert werden. Dadurch kann der Client beim KDC ein neues TGT anfordern, ohne die Anmeldedaten erneut einzugeben, und zwar bis zu einer maximalen Erneuerungsdauer.

Kerberos verwendet zwei Arten von Schlüsseln. Langzeitschlüssel werden aus Kontopasswörtern abgeleitet und ausschließlich zur Verschlüsselung von Teilen der Authentifizierungsnachrichten verwendet. Sitzungsschlüssel werden für jeden Authentifizierungsaustausch neu ausgehandelt und für die eigentliche Kommunikationssitzung verwendet. Die Kompromittierung eines Sitzungsschlüssels legt den Langzeitschlüssel nicht offen.

Kerberos bietet gegenseitige Authentifizierung (Client und Dienst werden verifiziert), Schutz vor Wiedergabeangriffen (durch Zeitstempel und Authenticatoren) sowie Vorwärtsgeheimhaltung für einzelne Sitzungen. Das KDC gibt während des normalen Betriebs niemals Langzeitschlüssel preis. Die wichtigste Vertrauensannahme ist, dass das KDC selbst nicht kompromittiert wurde.

Kerberos verwendet ein KDC mit den Komponenten AS und TGS. Bei der Anmeldung wird ein TGT erstellt (AS-REQ/AS-REP). Für den Dienstzugriff wird das TGT gegen ein Dienstticket eingetauscht (TGS-REQ/TGS-REP). Das Dienstticket wird dem Zieldienst vorgelegt (AP-REQ). Nur das KDC und die jeweiligen Dienste können Tickets lesen. Realms ermöglichen die domänenübergreifende Authentifizierung durch Realm-übergreifendes Vertrauen.