Kerberos-Terminologie

Im folgenden Abschnitt werden die Kerberos-Begriffe und die dazugehörigen Definitionen aufgeführt. Diese Begriffe werden in der gesamten Kerberos-Dokumentation verwendet. Zum Nachvollziehen der Kerberos-Konzepte bedarf es eines grundlegenden Verständnisses dieser Begriffe.

Kerberos-spezifische Terminologie

Zur Verwaltung von KDCs müssen Sie die in diesem Abschnitt aufgeführten Begriffe verstehen.

Das Key Distribution Center oder KDC ist die für die Ausstellung von Berechtigungsnachweisen verantwortliche Komponente von Kerberos. Diese Berechtigungsnachweise werden anhand von in der KDC-Datenbank gespeicherten Informationen erstellt. Jeder Bereich benötigt mindestens zwei KDCs: ein Master- und wenigstens ein Slave-KDC. Alle KDCs generieren Berechtigungsnachweise, aber nur das Master-KDC kann Änderungen an der KDC-Datenbank verarbeiten.

Eine Stash-Datei enthält den Master-Schlüssel für das KDC. Dieser Schlüssel wird verwendet, wenn ein Server zur automatischen Authentifizierung des KDC vor dem Starten der Befehle kadmind und krb5kdc neu gestartet wird. Da diese Datei den Master-Schlüssel enthält, sollten die Datei und die zugehörigen Backups dauerhaft gesichert sein. Die Datei wird mit Leseberechtigungen für root erstellt. Ändern Sie die Berechtigungen nicht, damit die Datei dauerhaft gesichert bleibt. Wenn die Datei beeinträchtigt wird, könnte der Schlüssel zum Zugriff auf die KDC-Datenbank oder zum Ändern selbiger verwendet werden.

Authentifizierungsspezifische Terminologie

Das Verständnis des Authentifizierungsprozesses erfordert die Kenntnis der in diesem Abschnitt aufgeführten Begriffe. Programmierer und Systemadministratoren sollten mit diesen Begriffen vertraut sein.

Ein Client ist die auf einer Workstation eines Benutzers ausgeführte Software. Die auf dem Client ausgeführte Kerberos-Software erstellt sämtliche Anforderungen während dieses Vorgangs. Demnach ist es wichtig, zwischen den Aktionen dieser Software und denen des Benutzers zu unterscheiden.

Die Begriffe server und service werden häufig synonym verwendet. Genauer gesagt definiert der Begriff Server das physische System, auf dem die Kerberos-Software ausgeführt wird. Der Begriff Service bezieht sich dagegen auf eine bestimmte Funktion, die auf einem Server unterstützt wird (zum Beispiel ftp oder nfs). In der Dokumentation wird häufig von Servern als Teil eines Service gesprochen, aber diese Definition ist hinsichtlich der tatsächlichen Bedeutung der Begriffe sehr vage. Daher bezieht sich der Begriff server auf das physische System. Der Begriff service bezieht sich dagegen auf die Software.

Das Kerberos-Produkt verwendet zwei Typen von Schlüsseln. Bei einem Schlüsseltyp handelt es sich um einen Schlüssel, der vom Passwort abgeleitet wird. Dieser Schlüssel wird an jedes Benutzer-Hauptelement übergeben und ist nur dem Benutzer und dem KDC bekannt. Der andere vom Kerberos-Produkt verwendete Schlüsseltyp ist ein zufallsverteilter Schlüssel, der keinem Passwort zugewiesen ist und somit nicht für die Verwendung durch Benutzer-Hauptelemente geeignet ist. Zufallsverteilte Schlüssel werden üblicherweise für Service-Hauptelemente mit Einträgen in einer Schlüsseltabelle sowie für vom KDC generierte Sitzungsschlüssel verwendet. Service-Hauptelemente können zufallsverteilte Schlüssel verwenden, da der Service auf den Schlüssel in der Schlüsseltabelle zugreifen kann, wodurch er nicht interaktiv ausgeführt werden kann. Sitzungsschlüssel werden vom KDC generiert (und von Client und Service gemeinsam genutzt), um sichere Transaktionen zwischen einem Client und einem Service zu ermöglichen.

Ein Ticket ist ein Informationspaket, das zur sicheren Übergabe der Identität eines Benutzers an einen Server oder Service verwendet wird. Ein Ticket ist nur für einen einzigen Client und einen bestimmten Service auf einem spezifischen Server gültig. Ein Ticket enthält Folgendes:

• Hauptelementnamen des Service

• Hauptelementnamen des Benutzers

• IP-Adresse des Hosts des Benutzers

• Zeitstempel

• Wert, der die Lebensdauer des Tickets definiert

• Kopie des Sitzungsschlüssels

Alle dieser Daten werden im Serviceschlüssel des Servers verschlüsselt. Denken Sie daran, dass das KDC das Ticket eingebettet in einem Berechtigungsnachweis ausstellt, wie nachfolgend beschrieben. Nach der Ausstellung eines Tickets kann dieses solange wiederverwendet werden, bis es abläuft.

Ein Berechtigungsnachweis ist ein Paket von Informationen, das ein Ticket und einen passenden Sitzungsschlüssel enthält. Der Berechtigungsnachweis wird mit dem Schlüssel des anfordernden Hauptelements verschlüsselt. Üblicherweise generiert das KDC einen Berechtigungsnachweis als Antwort auf eine Ticketanforderung von einem Client.

Bei einem Authentifizierer handelt es sich um vom Server zur Authentifizierung des Benutzer-Hauptelements des Clients verwendete Informationen. Ein Authentifizierer schließt den Hauptelementnamen des Benutzers, einen Zeitstempel und weitere Daten mit ein. Im Unterschied zu einem Ticket kann ein Authentifizierer nur einmal verwendet werden. Dies geschieht normalerweise, wenn Zugriff auf einen Service angefordert wird. Ein Authentifizierer wird unter Verwendung des von Client und Server gemeinsam genutzten Sitzungsschlüssels verschlüsselt. Üblicherweise erstellt der Client den Authentifizierer und versendet ihn mit dem Ticket des Servers oder des Service, um den Server bzw. Service zu authentifizieren.

Typen von Tickets

Tickets haben Eigenschaften, die deren Verwendungsweise festlegen. Diese Eigenschaften werden dem Ticket bei der Erstellung zugewiesen. Sie können jedoch später geändert werden. So kann ein Ticket beispielsweise von einem weiterleitbaren zu einem weitergeleiteten Ticket geändert werden. Sie können die Eigenschaften eines Tickets mit dem Befehl klist anzeigen. Weitere Informationen finden Sie unter Anzeigen von Kerberos-Tickets.

Tickets können durch mindestens einen der folgenden Begriffe beschrieben werden:

Weiterleitbar/weitergeleitet

Ein weiterleitbares Ticket kann von einem Host an einen anderen gesendet werden, ohne dass sich ein Client erneut authentifizieren muss. Beispiel: Wenn der Benutzer david ein weiterleitbares Ticket abruft, während er sich am Rechner von jennifer befindet, kann er sich bei seinem eigenen Rechner anmelden, ohne dafür ein neues Ticket zu benötigen (und sich somit erneut authentifizieren zu müssen). Ein Beispiel für ein weiterleitbares Ticket finden Sie unter Beispiel 26-1.

Anfänglich

Ein anfängliches Ticket ist ein Ticket, das direkt und nicht auf Basis eines Ticket-gewährenden Tickets ausgestellt wird. Für einige Services, wie zum Beispiel Anwendungen zum Ändern von Passwörtern, kann es erforderlich sein, dass Tickets als anfängliche Tickets gekennzeichnet werden, um sicherzustellen, dass der Client Kenntnisse über den Geheimschlüssel unter Beweis stellen kann. Ein anfängliches Ticket gibt an, dass der Client sich kürzlich selbst authentifiziert hat, anstatt ein Ticket-gewährendes Ticket zu verwenden, das möglicherweise schon seit längerer Zeit vorhanden ist.

Ungültig

Bei einem ungültigen Ticket handelt es sich um ein nachdatiertes Ticket, das noch nicht verwendet werden kann. Ein ungültiges Ticket wird solange von einem Anwendungsserver abgewiesen, bis es validiert wird. Dazu muss ein Ticket nach Ablauf seiner Startzeit vom Client in einer Anforderung für einen Ticket-gewährenden Service an den KDC gesendet werden, wobei das Flag VALIDATE festgelegt sein muss.

Nachdatierbar/nachdatiert

Ein nachdatiertes Ticket ist ein Ticket, das erst eine bestimmte Zeit nach seiner Erstellung gültig wird. Ein solches Ticket eignet sich beispielsweise für Batch-Jobs, die spät nachts ausgeführt werden sollen, da das Ticket im Falle eines Diebstahls nicht verwendet werden kann, bis der Batch-Job ausgeführt werden muss. Wenn ein nachdatiertes Ticket ausgestellt wird, wird es als ungültig ausgestellt und bleibt dies auch solange, bis seine Startzeit abgelaufen ist und der Client die Validierung durch das KDC anfordert. Ein nachdatiertes Ticket ist normalerweise bis zur Ablaufzeit des Ticket-gewährenden Tickets gültig. Wenn das Ticket jedoch als erneuerbar gekennzeichnet wird, wird seine Lebensdauer normalerweise so festgelegt, dass sie der vollen Lebensdauer des Ticket-gewährenden Tickets entspricht.

Proxyfähig/Proxy

Gelegentlich ist es für ein Hauptelement erforderlich, einem Service die Ausführung eines Vorgangs in dessen Namen zu ermöglichen. Der Hauptelementname des Proxys muss bei der Erstellung des Tickets angegeben werden. Die Oracle Solaris-Version unterstützt keine proxyfähigen oder Proxy-Tickets.

Ein proxyfähiges Ticket ähnelt einem weiterleitbaren Ticket, mit der Ausnahme, dass es nur für einen einzigen Service gültig ist, während ein weiterleitbares Ticket dem Service die vollständige Verwendung der Identität des Clients gewährleistet. Ein weiterleitbares Ticket kann daher als eine Art "Super-Proxy" angesehen werden.

Erneuerbar

Da Tickets mit besonders hoher Lebensdauer ein Sicherheitsrisiko darstellen, können Tickets als erneuerbar festgelegt werden. Ein erneuerbares Ticket hat zwei Ablaufzeiten: die Zeit, zu der die aktuelle Instanz des Tickets abläuft, und die maximale Lebensdauer für jedes Ticket, die eine Woche beträgt. Wenn ein Client ein Ticket weiterhin verwenden möchte, erneuert er es vor Ende der ersten Ablaufzeit. Beispiel: Ein Ticket kann für eine Stunde gültig sein, während alle Tickets eine maximale Lebensdauer von 10 Stunden aufweisen. Wenn der Client das Ticket für mehr als eine Stunde behalten möchte, muss er es innerhalb dieser Stunde erneuern. Erreicht ein Ticket die maximale Lebensdauer für Tickets von 10 Stunden, läuft es automatisch ab und kann nicht erneuert werden.

Informationen zum Anzeigen der Attribute von Tickets finden Sie unter Anzeigen von Kerberos-Tickets.

Lebensdauer von Tickets

Jedes Mal, wenn ein Hauptelement ein Ticket abruft, wird für die Lebensdauer des Tickets der kleinste der folgenden Lebensdauerwerte festgelegt (dies gilt auch für Ticket-gewährende Tickets):

• Der von der Option -l von kinit angegebene Lebensdauerwert, wenn das Ticket mit kinit abgerufen wird. Standardmäßig verwendete kinit den maximalen Lebensdauerwert.

• Der in der Datei kdc.conf angegebene maximale Lebensdauerwert (max_life )

• Der maximale Lebensdauerwert, der in der Kerberos-Datenbank für das Service-Hauptelement angegeben ist, das das Ticket bereitstellt. Bei kinit lautet das Service-Hauptelement krbtgt/realm.

• Der maximale Lebensdauerwert, der in der Kerberos-Datenbank für das Benutzer-Hauptelement angegeben ist, das das Ticket anfordert

Abbildung 27-1 zeigt, wie die Lebensdauer eines TGT (Ticket-gewährendes Ticket) bestimmt wird und woher die vier Lebensdauerwerte stammen. Zwar bezieht sich diese Abbildung explizit auf die Bestimmung der Lebensdauer eines TGT; der Vorgang beim Abrufen eines Tickets durch ein beliebiges Hauptelement ist jedoch fast der gleiche. Die einzigen Unterschiede liegen darin, dass kinit keinen Lebensdauerwert angibt, und das Service-Hauptelement, welches das Ticket bereitstellt, einen maximalen Lebensdauerwert angibt (anstelle des Hauptelements krbtgt/ realm).

Abbildung 27-1 Bestimmung der Lebensdauer eines TGT

Die erneuerbare Ticket-Lebensdauer wird ebenfalls aus dem Minimum von vier verschiedenen Werten bestimmt, jedoch werden in diesem Fall folgende erneuerbare Lebensdauerwerte verwendet:

• Der von der Option -r von kinit verwendete erneuerbare Lebensdauerwert, wenn das Ticket mit kinit abgerufen oder erneuert wird

• Der in der Datei kdc.conf angegebene maximale erneuerbare Lebensdauerwert (max_renewable_life )

• Der erneuerbare Wert für die maximale Lebensdauer, der in der Kerberos-Datenbank für das Service-Hauptelement angegeben ist, das das Ticket bereitstellt. Bei kinit lautet das Service-Hauptelement krbtgt/realm.

• Der erneuerbare Wert für die maximale Lebensdauer, der in der Kerberos-Datenbank für das Benutzer-Hauptelement angegeben ist, das das Ticket anfordert

Kerberos-Hauptelementnamen

Jedes Ticket wird durch einen Hauptelementnamen identifiziert. Der Hauptelementname kann einen Benutzer oder einen Service identifizieren. Im Folgenden sind Beispiele für verschiedene Hauptelementnamen aufgeführt.

Tabelle 27-4 Beispiele für Kerberos-Hauptelementnamen