3.3. The Ticket-Granting Service (TGS) Exchange (Der Ticket-Granting Service-Austausch)

Zusammenfassung

Nachrichtenrichtung	Nachrichtentyp	Abschnitt
1. Client zu Kerberos	`KRB_TGS_REQ`	5.4.1
2. Kerberos zu Client	`KRB_TGS_REP` oder `KRB_ERROR`	5.4.2, 5.9.1

Der TGS-Austausch zwischen einem Client und dem Kerberos TGS wird von einem Client initiiert, wenn er Authentifizierungs-Credentials für einen bestimmten Server erhalten möchte (der möglicherweise in einem entfernten Realm registriert ist), wenn er Credentials erneuern oder validieren möchte oder wenn er ein Proxy-Ticket erhalten möchte.

Wie beim AS-Austausch sendet der Client eine Anfrage an den Kerberos Ticket-Granting Service und erhält eine Antwort mit einem Ticket und einem Session Key oder mit einer Fehlermeldung. Der Haupt Unterschied besteht darin, dass der Client im TGS-Austausch bereits über ein TGT verfügt, das er zur Authentifizierung beim TGS verwendet.

3.3.1. Generation of KRB_TGS_REQ Message (Generierung der KRB_TGS_REQ-Nachricht)

Bevor eine Anforderung an den Ticket-Granting-Dienst gesendet wird, MUSS (MUST) der Client bestimmen, in welchem Bereich der Anwendungsserver vermutlich registriert ist. Dies kann auf mehrere Arten erfolgen. Es kann im Voraus bekannt sein (da der Bereich Teil der Prinzipalkennung ist), es kann in einem Namensserver gespeichert sein oder es kann aus einer Konfigurationsdatei abgerufen werden. Wenn der zu verwendende Bereich von einem Namensserver abgerufen wird, besteht die Gefahr des Spoofings, wenn der Nameservice, der den Bereichsnamen bereitstellt, nicht authentifiziert ist. Dies kann dazu führen, dass ein kompromittierter Bereich verwendet wird, was einem Angreifer die Möglichkeit gibt, die Authentifizierung des Anwendungsservers gegenüber dem Client zu kompromittieren.

Wenn der Client den Dienstprinzipalnamen und -bereich kennt und er noch kein TGT für den entsprechenden Bereich besitzt, muss eines beschafft werden. Dies wird zunächst versucht, indem ein TGT für den Zielbereich von einem Kerberos-Server angefordert wird, für den der Client ein TGT besitzt (durch rekursive Verwendung der KRB_TGS_REQ-Nachricht). Der Kerberos-Server KANN (MAY) ein TGT für den gewünschten Bereich zurückgeben, in diesem Fall kann fortgefahren werden. Alternativ KANN (MAY) der Kerberos-Server ein TGT für einen Bereich zurückgeben, der dem gewünschten Bereich "näher" ist (weiter entlang des standardmäßigen hierarchischen Pfads zwischen dem Bereich des Clients und dem Bereich des angeforderten Servers). Beachten Sie, dass in diesem Fall eine Fehlkonfiguration der Kerberos-Server Schleifen im resultierenden Authentifizierungspfad verursachen kann, die der Client sorgfältig erkennen und vermeiden sollte.

3.3.2. Receipt of KRB_TGS_REQ Message (Empfang der KRB_TGS_REQ-Nachricht)

Die KRB_TGS_REQ-Nachricht wird ähnlich wie die KRB_AS_REQ-Nachricht verarbeitet, aber es müssen viele zusätzliche Prüfungen durchgeführt werden. Zunächst MUSS (MUST) der Kerberos-Server bestimmen, für welchen Server das begleitende Ticket ist, und er MUSS (MUST) den entsprechenden Schlüssel auswählen, um es zu entschlüsseln. Für eine normale KRB_TGS_REQ-Nachricht ist es für den Ticket-Granting-Dienst bestimmt, und der Schlüssel des TGS wird verwendet. Wenn das TGT von einem anderen Bereich ausgestellt wurde, MUSS (MUST) der entsprechende bereichsübergreifende Schlüssel verwendet werden. Wenn (a) das begleitende Ticket kein TGT für den aktuellen Bereich ist, sondern für einen Anwendungsserver im aktuellen Bereich, (b) die Optionen RENEW, VALIDATE oder PROXY in der Anforderung angegeben sind und (c) der Server, für den ein Ticket angefordert wird, der im begleitenden Ticket genannte Server ist, dann entschlüsselt der KDC das Ticket im Authentifizierungsheader mit dem Schlüssel des Servers, für den es ausgestellt wurde. Wenn im padata-Feld kein Ticket gefunden werden kann, wird der Fehler KDC_ERR_PADATA_TYPE_NOSUPP zurückgegeben.

Sobald das begleitende Ticket entschlüsselt wurde, MUSS (MUST) die vom Benutzer bereitgestellte Prüfsumme im Authenticator gegen den Inhalt der Anforderung verifiziert werden, und die Nachricht MUSS (MUST) abgelehnt werden, wenn die Prüfsummen nicht übereinstimmen (mit einem Fehlercode KRB_AP_ERR_MODIFIED) oder wenn die Prüfsumme nicht kollisionssicher ist (mit einem Fehlercode KRB_AP_ERR_INAPP_CKSUM). Wenn der Prüfsummentyp nicht unterstützt wird, wird der Fehler KDC_ERR_SUMTYPE_NOSUPP zurückgegeben. Wenn Autorisierungsdaten vorhanden sind, werden sie mit dem Unterschlüssel aus dem Authenticator entschlüsselt.

Wenn eine der Entschlüsselungen auf fehlgeschlagene Integritätsprüfungen hinweist, wird der Fehler KRB_AP_ERR_BAD_INTEGRITY zurückgegeben.

Wie in Abschnitt 3.1.2 beschrieben, MUSS (MUST) der KDC eine gültige KRB_TGS_REP-Nachricht senden, wenn er eine mit seiner zuletzt verarbeiteten KRB_TGS_REQ-Nachricht identische Nachricht erhält. Wenn jedoch der Authenticator eine Wiederholung ist, der Rest der Anforderung jedoch nicht identisch ist, SOLLTE (SHOULD) der KDC KRB_AP_ERR_REPEAT zurückgeben.

3.3.3. Generation of KRB_TGS_REP Message (Generierung der KRB_TGS_REP-Nachricht)

Die KRB_TGS_REP-Nachricht teilt ihr Format mit KRB_AS_REP (KRB_KDC_REP), aber ihr Typfeld ist auf KRB_TGS_REP gesetzt. Die detaillierte Spezifikation befindet sich in Abschnitt 5.4.2.

Die Antwort enthält entweder ein Ticket für den angeforderten Server oder ein Ticket für den Ticket-Granting-Server eines Zwischen-KDC, der kontaktiert werden soll, um das angeforderte Ticket zu erhalten. Die Kerberos-Datenbank wird abgefragt, um den Datensatz des entsprechenden Servers abzurufen (einschließlich des Schlüssels, der zum Verschlüsseln des Tickets verwendet wird). Wenn die Anforderung für ein TGT eines entfernten Bereichs ist und wenn kein Schlüssel mit dem angeforderten Bereich geteilt wird, wählt der Kerberos-Server den Bereich, der dem angeforderten Bereich am "nächsten" ist (mit dem er einen Schlüssel teilt) und verwendet diesen stattdessen. Dies ist der einzige Fall, in dem die Antwort des KDC für einen anderen Server als den vom Client angeforderten ist.

Standardmäßig werden die Adressfelder, der Clientname und -bereich, die Liste der transitierten Bereiche, die anfängliche Authentifizierungszeit, die Ablaufzeit und die Autorisierungsdaten des neu ausgestellten Tickets vom TGT oder erneuerbaren Ticket kopiert. Wenn das transited-Feld aktualisiert werden muss, der transited-Typ jedoch nicht unterstützt wird, wird der Fehler KDC_ERR_TRTYPE_NOSUPP zurückgegeben.

Wenn die Anforderung eine Endzeit angibt, wird die Endzeit des neuen Tickets auf das Minimum von gesetzt: (a) diese Anforderung, (b) die Endzeit des TGT und (c) die Startzeit des TGT plus dem Minimum der maximalen Lebensdauer des Anwendungsservers und der maximalen Lebensdauer des lokalen Bereichs (die maximale Lebensdauer des anfordernden Prinzipals wurde bereits bei der Ausstellung des TGT angewendet). Wenn das neue Ticket erneuert werden soll, wird die obige Endzeit durch das Minimum von ersetzt: (a) den Wert des renew_till-Felds des Tickets und (b) die Startzeit des neuen Tickets plus der Lebensdauer des alten Tickets (endtime-starttime).

Wenn die FORWARDED-Option angefordert wurde, enthält das resultierende Ticket die vom Client angegebenen Adressen. Diese Option wird nur akzeptiert, wenn das FORWARDABLE-Flag im TGT gesetzt ist. Die PROXY-Option ist ähnlich; das resultierende Ticket enthält die vom Client angegebenen Adressen. Sie wird nur akzeptiert, wenn das PROXIABLE-Flag im TGT gesetzt ist. Die PROXY-Option wird in Anforderungen für zusätzliche TGTs nicht akzeptiert.

Wenn die angeforderte Startzeit nicht vorhanden ist, eine Zeit in der Vergangenheit anzeigt oder innerhalb des vom KDC akzeptablen Uhrenabweichungsfensters liegt und die POSTDATE-Option nicht angegeben ist, wird die Startzeit des Tickets auf die aktuelle Zeit des Authentifizierungsservers gesetzt. Wenn sie eine zukünftige Zeit jenseits der akzeptablen Uhrenabweichung anzeigt, aber die POSTDATED-Option nicht angegeben ist oder das MAY-POSTDATE-Flag nicht im TGT gesetzt ist, wird der Fehler KDC_ERR_CANNOT_POSTDATE zurückgegeben. Andernfalls wird, wenn das TGT das MAY-POSTDATE-Flag gesetzt hat, das resultierende Ticket nachdatiert, und die angeforderte Startzeit wird gemäß der Richtlinie des lokalen Bereichs überprüft. Wenn akzeptabel, wird die Startzeit des Tickets wie angefordert gesetzt, und das INVALID-Flag wird gesetzt. Nachdatierte Tickets MÜSSEN (MUST) vor der Verwendung validiert werden, indem sie dem KDC nach Erreichen der Startzeit präsentiert werden. In jedem Fall dürfen jedoch die Startzeit, Endzeit oder renew-till-Zeit des neu ausgestellten nachdatierten Tickets die renew-till-Zeit des TGT nicht überschreiten.

Wenn die ENC-TKT-IN-SKEY-Option angegeben wurde und ein zusätzliches Ticket in der Anforderung enthalten ist, zeigt dies an, dass der Client die Benutzer-zu-Benutzer-Authentifizierung verwendet, um seine Identität gegenüber einem Server nachzuweisen, der keinen Zugriff auf einen persistenten Schlüssel hat. Abschnitt 3.7 beschreibt die Auswirkungen dieser Option auf das gesamte Kerberos-Protokoll. Bei der Generierung der KRB_TGS_REP-Nachricht weist diese Option in der KRB_TGS_REQ-Nachricht den KDC an, das zusätzliche Ticket mit dem Schlüssel des Servers zu entschlüsseln, der das zusätzliche Ticket ausgestellt hat, und zu verifizieren, dass es ein TGT ist. Wenn der Name des angeforderten Servers in der Anforderung fehlt, wird der Name des Clients aus dem zusätzlichen Ticket verwendet. Andernfalls wird der Name des angeforderten Servers mit dem Namen des Clients im zusätzlichen Ticket verglichen. Wenn sie unterschiedlich sind, wird die Anforderung abgelehnt. Wenn die Anforderung erfolgreich ist, wird der Sitzungsschlüssel aus dem zusätzlichen Ticket verwendet, um das ausgestellte neue Ticket zu verschlüsseln, anstatt den Schlüssel des Servers zu verwenden, den das neue Ticket verwenden würde.

Wenn (a) der Servername im Ticket, das dem KDC als Teil des Authentifizierungsheaders präsentiert wird, nicht der Name des TGS selbst ist, (b) der Server im Bereich des KDC registriert ist und (c) die RENEW-Option angefordert wurde, verifiziert der KDC, dass das RENEWABLE-Flag im Ticket gesetzt ist, das INVALID-Flag im Ticket nicht gesetzt ist und die renew_till-Zeit noch in der Zukunft liegt. Wenn die VALIDATE-Option angefordert wurde, überprüft der KDC, ob die Startzeit vergangen ist und das INVALID-Flag gesetzt ist. Wenn die PROXY-Option angefordert wurde, überprüft der KDC, ob das PROXIABLE-Flag im Ticket gesetzt ist. Wenn die Tests erfolgreich sind und das Ticket die im nächsten Abschnitt beschriebene Hotlist-Prüfung besteht, stellt der KDC das entsprechende neue Ticket aus.

Der Chiffretextteil der Antwort in der KRB_TGS_REP-Nachricht ist im Unterschlüssel aus dem Authenticator (falls vorhanden) oder im Sitzungsschlüssel aus dem TGT verschlüsselt. Er wird nicht mit dem Schlüssel des Clients verschlüsselt. Darüber hinaus werden die Felder für das Ablaufdatum des Clientschlüssels und die Schlüsselversionsnummer weggelassen, da diese Werte zusammen mit dem Datensatz des Clients in der Datenbank gespeichert sind und dieser Datensatz nicht benötigt wird, um eine auf TGT basierende Anforderung zu erfüllen.

3.3.3.1. Checking for Revoked Tickets (Prüfung auf widerrufene Tickets)

Immer wenn eine Anforderung an den Ticket-Granting-Server gestellt wird, wird das präsentierte Ticket gegen eine Hotlist widerrufener Tickets überprüft. Diese Hotlist kann durch Speichern von Zeitstempelbereichen "verdächtiger Tickets" implementiert werden; wenn die authtime des präsentierten Tickets in diesen Bereich fällt, wird es abgelehnt. Auf diese Weise kann ein gestohlenes TGT oder erneuerbares Ticket, sobald der Diebstahl dem KDC des Bereichs gemeldet wurde, in dem sich der Server befindet, nicht mehr zum Erhalt zusätzlicher Tickets (Erneuerungen oder andere) verwendet werden. Alle normalen Tickets, die vor der Meldung des Diebstahls erhalten wurden, bleiben gültig (da Tickets keine Interaktion mit dem KDC erfordern), jedoch nur bis zu ihrer normalen Ablaufzeit. Wenn ein TGT für die bereichsübergreifende Authentifizierung ausgestellt wurde, ist die Verwendung des bereichsübergreifenden TGT nicht betroffen, es sei denn, die Hotlist wird an die KDCs der Bereiche weitergegeben, die solche bereichsübergreifenden Tickets ausstellen.

3.3.3.2. Encoding the Transited Field (Codierung des transited-Felds)

Wenn die Identität des Servers im TGT, das dem KDC als Teil des Authentifizierungsheaders präsentiert wird, die Identität des Ticket-Granting-Dienstes ist, das TGT jedoch von einem anderen Bereich ausgestellt wurde, sucht der KDC den mit diesem Bereich geteilten bereichsübergreifenden Schlüssel und verwendet diesen Schlüssel zum Entschlüsseln des Tickets. Wenn das Ticket gültig ist, wird der KDC der Anforderung nachkommen, jedoch unter Beachtung der Einschränkungen, die in den Abschnitten beschrieben sind, die den AS-Austausch beschreiben. Der Bereichsteil der Clientidentität wird aus dem TGT entnommen. Wenn der Name des Bereichs, der das TGT ausgestellt hat, nicht der Bereich des Client-Prinzipals ist, wird er dem transited-Feld des auszustellenden Tickets hinzugefügt. Dies geschieht durch Lesen des transited-Felds aus dem TGT (und Behandlung als ungeordnete Menge von Bereichsnamen), Hinzufügen des neuen Bereichs zur Menge und anschließendes Konstruieren und Ausschreiben seiner codierten (Kurzschrift-)Form (was eine Neuanordnung der vorhandenen Codierung beinhalten kann).

Beachten Sie, dass der Ticket-Granting-Dienst den Namen seines eigenen Bereichs nicht hinzufügt. Stattdessen ist es seine Verantwortung, den Namen des vorherigen Bereichs hinzuzufügen. Dies verhindert, dass ein böswilliger Kerberos-Server seinen eigenen Namen absichtlich weglässt (er kann jedoch die Namen anderer Bereiche weglassen).

Der Name des lokalen Bereichs und des Prinzipal-Bereichs sind beide nicht im transited-Feld enthalten. Sie erscheinen an anderer Stelle im Ticket, und es ist bekannt, dass beide an der Authentifizierung des Prinzipals beteiligt waren. Da die Endpunkte nicht eingeschlossen sind, führen sowohl die lokale als auch die einstufige bereichsübergreifende Authentifizierung zu einem leeren transited-Feld.

Da dieses Feld den Namen jedes transitierten Bereichs hinzufügt, kann es sehr lang werden. Um die Länge dieses Felds zu reduzieren, wird sein codiertes Format verwendet (beschrieben im Rest von Abschnitt 3.3.3.2).