3.2. The Client/Server Authentication Exchange (Der Client/Server-Authentifizierungsaustausch)

Zusammenfassung

Nachrichtenrichtung	Nachrichtentyp	Abschnitt
Client zu Anwendungsserver	`KRB_AP_REQ`	5.5.1
[optional] Anwendungsserver zu Client	`KRB_AP_REP` oder `KRB_ERROR`	5.5.2, 5.9.1

Der Client/Server-Authentifizierungs-(CS-)Austausch wird von Netzwerkanwendungen verwendet, um den Client beim Server und umgekehrt zu authentifizieren. Der Client MUSS bereits Credentials für den Server unter Verwendung des AS- oder TGS-Austauschs erworben haben.

3.2.1. [The KRB_AP_REQ Message (Die KRB_AP_REQ-Nachricht)]

Die KRB_AP_REQ enthält Authentifizierungsinformationen, die Teil der ersten Nachricht in einer authentifizierten Transaktion sein SOLLTEN. Sie enthält ein Ticket, einen Authenticator und einige zusätzliche Buchhaltungsinformationen (siehe Abschnitt 5.5.1 für das genaue Format). Das Ticket allein ist unzureichend, um einen Client zu authentifizieren, da Tickets im Klartext über das Netzwerk übertragen werden (Tickets enthalten sowohl einen verschlüsselten als auch einen unverschlüsselten Teil, daher bezieht sich Klartext hier auf die gesamte Einheit, die von einer Nachricht kopiert und in einer anderen ohne kryptographische Fähigkeiten wiedergegeben werden kann). Der Authenticator wird verwendet, um ungültige Wiederholungen von Tickets zu verhindern, indem dem Server bewiesen wird, dass der Client den Session Key des Tickets kennt und somit berechtigt ist, das Ticket zu verwenden. Die KRB_AP_REQ-Nachricht wird an anderer Stelle als 'Authentifizierungsheader' bezeichnet.

3.2.2. [Generation of a KRB_AP_REQ Message (Generierung einer KRB_AP_REQ-Nachricht)]

Wenn ein Client die Authentifizierung bei einem Server initiieren möchte, erhält er (entweder durch einen Credentials-Cache, den AS-Austausch oder den TGS-Austausch) ein Ticket und einen Session Key für den gewünschten Dienst. Der Client KANN alle Tickets wiederverwenden, die er besitzt, bis sie ablaufen. Um ein Ticket zu verwenden, konstruiert der Client einen neuen Authenticator aus der Systemzeit und seinem Namen und optional aus einer anwendungsspezifischen Prüfsumme, einer initialen Sequenznummer, die in KRB_SAFE- oder KRB_PRIV-Nachrichten verwendet werden soll, und/oder einem Session-Subkey, der in Verhandlungen für einen Session Key verwendet werden soll, der für diese bestimmte Sitzung einzigartig ist. Authenticators DÜRFEN NICHT wiederverwendet werden und SOLLTEN abgelehnt werden, wenn sie zu einem Server wiedergegeben werden. Beachten Sie, dass dies es schwierig machen kann, Anwendungen basierend auf unzuverlässigen Transporten korrekt zu codieren. Wenn der Transport möglicherweise duplizierte Nachrichten liefert, MUSS entweder ein neuer Authenticator für jeden Wiederholungsversuch generiert werden, oder der Anwendungsserver MUSS Anfragen und Antworten abgleichen und die erste Antwort als Antwort auf ein erkanntes Duplikat wiedergeben.

Wenn eine Sequenznummer eingefügt werden soll, SOLLTE sie zufällig gewählt werden, so dass es auch nach vielen ausgetauschten Nachrichten unwahrscheinlich ist, dass sie mit anderen verwendeten Sequenznummern kollidiert.

Der Client KANN eine Anforderung für gegenseitige Authentifizierung oder die Verwendung eines auf Session-Key basierenden Tickets (für User-to-User-Authentifizierung, siehe Abschnitt 3.7) anzeigen, indem er das/die entsprechende(n) Flag(s) im ap-options-Feld der Nachricht setzt.

Der Authenticator wird mit dem Session Key verschlüsselt und mit dem Ticket kombiniert, um die KRB_AP_REQ-Nachricht zu bilden, die dann an den End-Server zusammen mit allen zusätzlichen anwendungsspezifischen Informationen gesendet wird.

3.2.3. [Receipt of KRB_AP_REQ Message (Empfang der KRB_AP_REQ-Nachricht)]

Die Authentifizierung basiert auf der aktuellen Tageszeit des Servers (Uhren MÜSSEN lose synchronisiert sein), dem Authenticator und dem Ticket. Mehrere Fehler sind möglich. Wenn ein Fehler auftritt, wird vom Server erwartet, dass er dem Client mit einer KRB_ERROR-Nachricht antwortet. Diese Nachricht KANN im Anwendungsprotokoll eingekapselt werden, wenn ihre Rohform für das Protokoll nicht akzeptabel ist. Das Format von Fehlermeldungen ist in Abschnitt 5.9.1 beschrieben.

Der Algorithmus zur Überprüfung von Authentifizierungsinformationen ist wie folgt. Wenn der Nachrichtentyp nicht KRB_AP_REQ ist, gibt der Server den Fehler KRB_AP_ERR_MSG_TYPE zurück. Wenn die durch das Ticket in der KRB_AP_REQ angegebene Schlüsselversion nicht eine ist, die der Server verwenden kann (z.B. zeigt sie einen alten Schlüssel an, und der Server besitzt keine Kopie des alten Schlüssels mehr), wird der Fehler KRB_AP_ERR_BADKEYVER zurückgegeben. Wenn das Flag USE-SESSION-KEY im ap-options-Feld gesetzt ist, zeigt es dem Server an, dass User-to-User-Authentifizierung verwendet wird und dass das Ticket mit dem Session Key aus dem TGT des Servers verschlüsselt ist, anstatt mit dem geheimen Schlüssel des Servers. Siehe Abschnitt 3.7 für eine vollständigere Beschreibung der Auswirkung von User-to-User-Authentifizierung auf alle Nachrichten im Kerberos-Protokoll.

Da es möglich ist, dass der Server in mehreren Realms registriert ist, mit unterschiedlichen Schlüsseln in jedem, wird das Feld srealm im unverschlüsselten Teil des Tickets in der KRB_AP_REQ verwendet, um anzugeben, welchen geheimen Schlüssel der Server verwenden sollte, um dieses Ticket zu entschlüsseln. Der Fehlercode KRB_AP_ERR_NOKEY wird zurückgegeben, wenn der Server nicht den richtigen Schlüssel hat, um das Ticket zu entschlüsseln.

Das Ticket wird unter Verwendung der Version des Serverschlüssels entschlüsselt, die durch das Ticket spezifiziert ist. Wenn die Entschlüsselungsroutinen eine Modifikation des Tickets erkennen (jedes Verschlüsselungssystem MUSS Sicherheitsvorkehrungen zur Erkennung modifizierten Ciphertexts bereitstellen), wird der Fehler KRB_AP_ERR_BAD_INTEGRITY zurückgegeben (die Chancen sind gut, dass unterschiedliche Schlüssel zur Verschlüsselung und Entschlüsselung verwendet wurden).

Der Authenticator wird unter Verwendung des aus dem entschlüsselten Ticket extrahierten Session Keys entschlüsselt. Wenn die Entschlüsselung zeigt, dass er modifiziert wurde, wird der Fehler KRB_AP_ERR_BAD_INTEGRITY zurückgegeben. Der Name und das Realm des Clients aus dem Ticket werden mit den gleichen Feldern im Authenticator verglichen. Wenn sie nicht übereinstimmen, wird der Fehler KRB_AP_ERR_BADMATCH zurückgegeben; normalerweise wird dies durch einen Client-Fehler oder einen versuchten Angriff verursacht. Die Adressen im Ticket (falls vorhanden) werden dann nach einer Adresse durchsucht, die mit der vom Betriebssystem gemeldeten Adresse des Clients übereinstimmt. Wenn keine Übereinstimmung gefunden wird oder der Server auf Ticket-Adressen besteht, aber keine im Ticket vorhanden sind, wird der Fehler KRB_AP_ERR_BADADDR zurückgegeben. Wenn die lokale (Server-)Zeit und die Client-Zeit im Authenticator um mehr als die zulässige Uhrzeit-Skew (z.B. 5 Minuten) abweichen, wird der Fehler KRB_AP_ERR_SKEW zurückgegeben.

Wenn das Feld ctime im Ticket innerhalb des zulässigen Uhrzeit-Skew-Zeitraums liegt, überprüft der Server, ob die gleiche Kombination aus ctime, cusec und cname aus dem Authenticator kürzlich in einer vorherigen Anfrage präsentiert wurde. Wenn dies der Fall ist, ist es wahrscheinlich, dass diese Anfrage eine Wiederholung durch einen Angreifer ist, und der Fehler KRB_AP_ERR_REPEAT SOLLTE zurückgegeben werden. Der Server MUSS jeden derartigen Authenticator für mindestens die Dauer des akzeptablen Uhrzeit-Skew erkennen können. Implementierungen KÖNNEN verwenden, was auch immer für eine lokale Politik angemessen ist, um das zulässige Zeitfenster zu begrenzen, in dem eine Anfrage (und Antwort) unter Verwendung eines bestimmten Authenticators verarbeitet wird. Ein Server KANN einen Cache ausschließlich für Authentifizierungsanfragen für einen kurzen Zeitraum verwenden und nachfolgende Authentifizierungen mit dem gleichen Authenticator während dieses kurzen Zeitraums nach Ablauf der anfänglichen Anfrage ablehnen.

Wenn das starttime-Feld im Ticket in der Zukunft liegt, wird der Fehler KRB_AP_ERR_TKT_NYV zurückgegeben. Wenn das Flag INVALID im Ticket gesetzt ist, wird der Fehler KRB_AP_ERR_TKT_INVALID zurückgegeben.

Wenn alle Überprüfungen erfolgreich sind, gilt der Server als authentifiziert für den Client. Wenn gegenseitige Authentifizierung angefordert wurde, sendet der Server eine Antwort-Nachricht an den Client. Das Format dieser Antwort ist in Abschnitt 3.2.4 beschrieben.

3.2.4. [Generation of a KRB_AP_REP Message (Generierung einer KRB_AP_REP-Nachricht)]

Typischerweise wird die Anfrage eines Clients sowohl die Authentifizierungsinformationen als auch seine anfängliche Anfrage in derselben Nachricht enthalten, und der Server muss nicht explizit auf die KRB_AP_REQ antworten. Wenn jedoch gegenseitige Authentifizierung (Authentifizierung nicht nur des Clients beim Server, sondern auch des Servers beim Client) durchgeführt wird, wird die KRB_AP_REQ-Nachricht MUTUAL-REQUIRED in ihrem ap-options-Feld gesetzt haben, und eine KRB_AP_REP-Nachricht ist als Antwort erforderlich. Wie bei der Fehlermeldung KANN diese Nachricht im Anwendungsprotokoll eingekapselt werden, wenn ihre "Roh"-Form für das Protokoll der Anwendung nicht akzeptabel ist. Das Timestamp- und Mikrosekunden-Feld, das in der Antwort verwendet wird, MUSS der Timestamp und das Mikrosekunden-Feld des Clients sein (wie im Authenticator bereitgestellt). Wenn eine Sequenznummer eingefügt werden soll, SOLLTE sie zufällig gewählt werden, wie oben für den Authenticator beschrieben. Ein Subkey KANN eingefügt werden, wenn der Server einen anderen Subkey aushandeln möchte. Die KRB_AP_REP-Nachricht wird mit dem aus dem Ticket extrahierten Session Key verschlüsselt.

Beachten Sie, dass im Kerberos Version 4-Protokoll der Timestamp in der Antwort der Timestamp des Clients plus eins war. Dies ist in Version 5 nicht notwendig, weil Version 5-Nachrichten so formatiert sind, dass es nicht möglich ist, die Antwort durch umsichtige Nachrichtenchirurgie (selbst in verschlüsselter Form) ohne Kenntnis der entsprechenden Verschlüsselungsschlüssel zu erstellen.

3.2.5. [Receipt of KRB_AP_REP Message (Empfang der KRB_AP_REP-Nachricht)]

Wenn eine KRB_AP_REP-Nachricht zurückgegeben wird, verwendet der Client den Session Key aus den für den Server erhaltenen Credentials, um die Nachricht zu entschlüsseln, und überprüft, dass die Timestamp- und Mikrosekunden-Felder mit denen im Authenticator übereinstimmen, den er an den Server gesendet hat. Wenn sie übereinstimmen, ist der Client sicher, dass der Server echt ist. Die Sequenznummer und der Subkey (falls vorhanden) werden für die spätere Verwendung aufbewahrt. (Beachten Sie, dass zum Verschlüsseln der KRB_AP_REP-Nachricht der Sub-Session-Key nicht verwendet wird, selbst wenn er in der Authentifizierung vorhanden ist.)

3.2.6. [Using the Encryption Key (Verwendung des Verschlüsselungsschlüssels)]

Nach dem KRB_AP_REQ/KRB_AP_REP-Austausch teilen sich Client und Server einen Verschlüsselungsschlüssel, der von der Anwendung verwendet werden kann. In einigen Fällen wird die Verwendung dieses Session Keys im Protokoll implizit sein; in anderen muss die Verwendungsmethode aus mehreren Alternativen gewählt werden. Die Anwendung KANN den tatsächlichen Verschlüsselungsschlüssel wählen, der für KRB_PRIV, KRB_SAFE oder andere anwendungsspezifische Verwendungen verwendet werden soll, basierend auf dem Session Key aus dem Ticket und Subkeys in der KRB_AP_REP-Nachricht und dem Authenticator. Implementierungen des Protokolls KÖNNEN Routinen bereitstellen, um Subkeys basierend auf Session Keys und Zufallszahlen zu wählen und um einen ausgehandelten Schlüssel zu generieren, der in der KRB_AP_REP-Nachricht zurückgegeben werden soll.

Um die Auswirkung von Fehlern bei der Zufallszahlengenerierung auf den Client zu mildern, wird dringend empfohlen, dass jeder von einer Anwendung für die nachfolgende Verwendung abgeleitete Schlüssel die vollständige Schlüsselentropie enthält, die aus dem vom KDC generierten Session Key abgeleitet wird, der im Ticket getragen wird. Wir überlassen die Protokollverhandlungen darüber, wie der Schlüssel zu verwenden ist (z.B. zur Auswahl eines Verschlüsselungs- oder Prüfsummentyps), dem Anwendungsprogrammierer. Das Kerberos-Protokoll schränkt die Implementierungsoptionen nicht ein, aber ein Beispiel dafür, wie dies geschehen könnte, folgt.

Eine Möglichkeit, wie eine Anwendung wählen kann, einen Schlüssel auszuhandeln, der für den nachfolgenden Integritäts- und Datenschutzschutz verwendet werden soll, besteht darin, dass der Client einen Schlüssel im Subkey-Feld des Authenticators vorschlägt. Der Server kann dann einen Schlüssel unter Verwendung des vom Client vorgeschlagenen Schlüssels als Eingabe wählen und den neuen Subkey im Subkey-Feld der Anwendungsantwort zurückgeben. Dieser Schlüssel könnte dann für die nachfolgende Kommunikation verwendet werden.

Bei sowohl den Einweg- als auch den gegenseitigen Authentifizierungsaustauschen sollten die Peers darauf achten, einander keine sensiblen Informationen ohne ordnungsgemäße Zusicherungen zu senden. Insbesondere Anwendungen, die Datenschutz oder Integrität erfordern, SOLLTEN die KRB_AP_REP-Antwort vom Server zum Client verwenden, um sowohl Client als auch Server die Identität ihres Peers zu versichern. Wenn ein Anwendungsprotokoll Datenschutz seiner Nachrichten erfordert, kann es die KRB_PRIV-Nachricht verwenden (Abschnitt 3.5). Die KRB_SAFE-Nachricht (Abschnitt 3.4) kann verwendet werden, um Integrität sicherzustellen.