3.4. The KRB_SAFE Exchange (Der KRB_SAFE-Austausch)

Die KRB_SAFE-Nachricht KANN von Clients verwendet werden, die die Fähigkeit benötigen, Modifikationen von Nachrichten zu erkennen, die sie austauschen. Dies wird erreicht, indem eine verschlüsselte kollisionssichere Prüfsumme der Benutzerdaten und einiger Kontrollinformationen eingeschlossen wird. Die Prüfsumme ist mit einem Verschlüsselungsschlüssel verschlüsselt (normalerweise der zuletzt über Subkeys ausgehandelte Schlüssel oder der Session Key, wenn keine Verhandlung stattgefunden hat).

3.4.1. Generation of a KRB_SAFE Message (Erzeugung einer KRB_SAFE-Nachricht)

Wenn eine Anwendung eine KRB_SAFE-Nachricht senden möchte, sammelt sie ihre Daten und die entsprechenden Kontrollinformationen und berechnet eine Prüfsumme über ihnen. Der Prüfsummenalgorithmus sollte die verschlüsselte Prüfsumme sein, die zusammen mit dem für den Sub-Session- oder Session-Key verwendeten Kryptosystem vorgeschrieben ist. Die Prüfsumme wird mit dem Sub-Session-Key generiert, falls vorhanden, oder dem Session Key. Einige Implementierungen verwenden einen anderen Prüfsummenalgorithmus für die KRB_SAFE-Nachrichten, aber dies auf interoperable Weise zu tun ist nicht immer möglich.

Die Kontrollinformationen für die KRB_SAFE-Nachricht enthalten sowohl einen Zeitstempel als auch eine Sequenznummer. Der Designer einer Anwendung, die die KRB_SAFE-Nachricht verwendet, MUSS mindestens einen der beiden Mechanismen wählen. Diese Wahl SOLLTE auf den Bedürfnissen des Anwendungsprotokolls basieren.

Sequenznummern sind nützlich, wenn alle gesendeten Nachrichten von dem Peer empfangen werden. Verbindungsstatus ist derzeit erforderlich, um den Session Key zu pflegen, daher sollte die Pflege der nächsten Sequenznummer kein zusätzliches Problem darstellen.

Wenn erwartet wird, dass das Anwendungsprotokoll verlorene Nachrichten toleriert, ohne dass sie erneut gesendet werden, ist die Verwendung des Zeitstempels der geeignete Replay-Erkennungsmechanismus. Die Verwendung von Zeitstempeln ist auch der geeignete Mechanismus für Multicast-Protokolle, bei denen alle Peers einen gemeinsamen Sub-Session-Key teilen, aber einige Nachrichten an eine Teilmenge der Peers gesendet werden.

Nach Berechnung der Prüfsumme übermittelt der Client dann die Informationen und die Prüfsumme an den Empfänger im in Abschnitt 5.6.1 spezifizierten Nachrichtenformat.

3.4.2. Receipt of KRB_SAFE Message (Empfang der KRB_SAFE-Nachricht)

Wenn eine Anwendung eine KRB_SAFE-Nachricht empfängt, überprüft sie diese wie folgt. Wenn ein Fehler auftritt, wird ein Fehlercode zur Verwendung durch die Anwendung gemeldet.

Die Nachricht wird zunächst überprüft, indem verifiziert wird, dass die Protokollversions- und Typfelder mit der aktuellen Version bzw. KRB_SAFE übereinstimmen. Eine Nichtübereinstimmung erzeugt einen Fehler KRB_AP_ERR_BADVERSION oder KRB_AP_ERR_MSG_TYPE. Die Anwendung überprüft, dass die verwendete Prüfsumme eine kollisionssichere verschlüsselte Prüfsumme ist, die Schlüssel verwendet, die mit dem Sub-Session- oder Session-Key kompatibel sind (oder mit dem aus den Session- oder Sub-Session-Keys abgeleiteten Anwendungsschlüssel). Wenn nicht, wird ein Fehler KRB_AP_ERR_INAPP_CKSUM generiert. Die Adresse des Absenders MUSS in den Kontrollinformationen enthalten sein; der Empfänger überprüft, dass der Bericht des Betriebssystems über die Adresse des Absenders mit der Adresse des Absenders in der Nachricht übereinstimmt und (wenn eine Empfängeradresse angegeben ist oder der Empfänger eine Adresse benötigt), dass eine der Adressen des Empfängers als Empfängeradresse in der Nachricht erscheint. Um mit Netzwerkadressübersetzung zu arbeiten, KÖNNEN Absender den in Abschnitt 8.1 spezifizierten direktionalen Adresstyp für die Absenderadresse verwenden und keine Empfängeradressen einschließen. Eine fehlgeschlagene Übereinstimmung in beiden Fällen erzeugt einen Fehler KRB_AP_ERR_BADADDR. Dann werden die Zeitstempel- und usec- und/oder die Sequenznummernfelder überprüft. Wenn Zeitstempel und usec erwartet werden und nicht vorhanden sind, oder wenn sie vorhanden sind, aber nicht aktuell, wird der Fehler KRB_AP_ERR_SKEW generiert. Zeitstempel müssen nicht streng geordnet sein; sie müssen nur im Abweichungsfenster liegen. Wenn der Servername zusammen mit dem Client-Namen, der Zeit und den Mikrosekundenfeldern aus dem Authenticator mit kürzlich gesehenen (gesendeten oder empfangenen) solchen Tupeln übereinstimmt, wird der Fehler KRB_AP_ERR_REPEAT generiert. Wenn eine falsche Sequenznummer enthalten ist oder wenn eine Sequenznummer erwartet wird, aber nicht vorhanden ist, wird der Fehler KRB_AP_ERR_BADORDER generiert. Wenn weder ein Zeitstempel und usec noch eine Sequenznummer vorhanden ist, wird ein Fehler KRB_AP_ERR_MODIFIED generiert. Schließlich wird die Prüfsumme über die Daten und Kontrollinformationen berechnet, und wenn sie nicht mit der empfangenen Prüfsumme übereinstimmt, wird ein Fehler KRB_AP_ERR_MODIFIED generiert.

Wenn alle Prüfungen erfolgreich sind, kann die Anwendung sicher sein, dass die Nachricht von ihrem Peer generiert wurde und nicht während der Übertragung modifiziert wurde.

Implementierungen SOLLTEN jeden von ihnen implementierten Prüfsummenalgorithmus akzeptieren, der sowohl angemessene Sicherheit als auch mit dem Sub-Session- oder Session-Key kompatible Schlüssel hat. Unverschlüsselte oder nicht kollisionssichere Prüfsummen sind für diese Verwendung nicht geeignet.

3.5. The KRB_PRIV Exchange (Der KRB_PRIV-Austausch)

Die KRB_PRIV-Nachricht KANN von Clients verwendet werden, die Vertraulichkeit und die Fähigkeit benötigen, Modifikationen ausgetauschter Nachrichten zu erkennen. Dies wird erreicht, indem die Nachrichten verschlüsselt und Kontrollinformationen hinzugefügt werden.

3.5.1. Generation of a KRB_PRIV Message (Erzeugung einer KRB_PRIV-Nachricht)

Wenn eine Anwendung eine KRB_PRIV-Nachricht senden möchte, sammelt sie ihre Daten und die entsprechenden Kontrollinformationen (spezifiziert in Abschnitt 5.7.1) und verschlüsselt sie unter einem Verschlüsselungsschlüssel (normalerweise der zuletzt über Subkeys ausgehandelte Schlüssel oder der Session Key, wenn keine Verhandlung stattgefunden hat). Als Teil der Kontrollinformationen MUSS der Client wählen, entweder einen Zeitstempel oder eine Sequenznummer (oder beides) zu verwenden; siehe die Diskussion in Abschnitt 3.4.1 für Richtlinien, welche verwendet werden sollte. Nachdem die Benutzerdaten und Kontrollinformationen verschlüsselt sind, übermittelt der Client den Chiffretext und einige "Umschlag"-Informationen an den Empfänger.

3.5.2. Receipt of KRB_PRIV Message (Empfang der KRB_PRIV-Nachricht)

Wenn eine Anwendung eine KRB_PRIV-Nachricht empfängt, überprüft sie diese wie folgt. Wenn ein Fehler auftritt, wird ein Fehlercode zur Verwendung durch die Anwendung gemeldet.

Die Nachricht wird zunächst überprüft, indem verifiziert wird, dass die Protokollversions- und Typfelder mit der aktuellen Version bzw. KRB_PRIV übereinstimmen. Eine Nichtübereinstimmung erzeugt einen Fehler KRB_AP_ERR_BADVERSION oder KRB_AP_ERR_MSG_TYPE. Die Anwendung entschlüsselt dann den Chiffretext und verarbeitet den resultierenden Klartext. Wenn die Entschlüsselung zeigt, dass die Daten modifiziert wurden, wird ein Fehler KRB_AP_ERR_BAD_INTEGRITY generiert.

Die Adresse des Absenders MUSS in den Kontrollinformationen enthalten sein; der Empfänger überprüft, dass der Bericht des Betriebssystems über die Adresse des Absenders mit der Adresse des Absenders in der Nachricht übereinstimmt. Wenn eine Empfängeradresse angegeben ist oder der Empfänger eine Adresse benötigt, MUSS auch eine der Adressen des Empfängers als Empfängeradresse in der Nachricht erscheinen. Wenn eine Absender- oder Empfängeradresse aufgrund von Netzwerkadressübersetzung möglicherweise nicht mit der Adresse in einer Nachricht übereinstimmt, KANN eine Anwendung geschrieben werden, um Adressen des direktionalen Adresstyps anstelle der tatsächlichen Netzwerkadresse zu verwenden.

Eine fehlgeschlagene Übereinstimmung in beiden Fällen erzeugt einen Fehler KRB_AP_ERR_BADADDR. Um mit Netzwerkadressübersetzung zu arbeiten, KÖNNEN Implementierungen den in Abschnitt 7.1 definierten direktionalen Adresstyp für die Absenderadresse verwenden und keine Empfängeradresse einschließen.

Als nächstes werden die Zeitstempel- und usec- und/oder die Sequenznummernfelder überprüft. Wenn Zeitstempel und usec erwartet werden und nicht vorhanden sind, oder wenn sie vorhanden sind, aber nicht aktuell, wird der Fehler KRB_AP_ERR_SKEW generiert. Wenn der Servername zusammen mit dem Client-Namen, der Zeit und den Mikrosekundenfeldern aus dem Authenticator mit kürzlich gesehenen Tupeln übereinstimmt, wird der Fehler KRB_AP_ERR_REPEAT generiert. Wenn eine falsche Sequenznummer enthalten ist oder wenn eine Sequenznummer erwartet wird, aber nicht vorhanden ist, wird der Fehler KRB_AP_ERR_BADORDER generiert. Wenn weder ein Zeitstempel und usec noch eine Sequenznummer vorhanden ist, wird ein Fehler KRB_AP_ERR_MODIFIED generiert.

Wenn alle Prüfungen erfolgreich sind, kann die Anwendung annehmen, dass die Nachricht von ihrem Peer generiert wurde und sicher übermittelt wurde (ohne dass Eindringlinge den unverschlüsselten Inhalt gesehen haben).

3.6. The KRB_CRED Exchange (Der KRB_CRED-Austausch)

Die KRB_CRED-Nachricht KANN von Clients verwendet werden, die die Fähigkeit benötigen, Kerberos-Credentials von einem Host zu einem anderen zu senden. Dies wird erreicht, indem die Tickets zusammen mit verschlüsselten Daten gesendet werden, die die Session Keys und andere mit den Tickets verbundene Informationen enthalten.

3.6.1. Generation of a KRB_CRED Message (Erzeugung einer KRB_CRED-Nachricht)

Wenn eine Anwendung eine KRB_CRED-Nachricht senden möchte, erhält sie zunächst (unter Verwendung des KRB_TGS-Austauschs) Credentials, die an den entfernten Host gesendet werden sollen. Sie konstruiert dann eine KRB_CRED-Nachricht unter Verwendung des oder der so erhaltenen Tickets und platziert den Session Key, der zur Verwendung jedes Tickets benötigt wird, im Schlüsselfeld der entsprechenden KrbCredInfo-Sequenz des verschlüsselten Teils der KRB_CRED-Nachricht.

Andere Informationen, die mit jedem Ticket verbunden sind und während des KRB_TGS-Austauschs erhalten wurden, werden ebenfalls in der entsprechenden KrbCredInfo-Sequenz im verschlüsselten Teil der KRB_CRED-Nachricht platziert. Die aktuelle Zeit und, wenn sie von der Anwendung speziell benötigt werden, die Felder nonce, s-address und r-address werden im verschlüsselten Teil der KRB_CRED-Nachricht platziert, der dann unter einem zuvor im KRB_AP-Austausch ausgetauschten Verschlüsselungsschlüssel verschlüsselt wird (normalerweise der zuletzt über Subkeys ausgehandelte Schlüssel oder der Session Key, wenn keine Verhandlung stattgefunden hat).

Implementierungshinweis: Bei der Konstruktion einer KRB_CRED-Nachricht zur Aufnahme in ein GSSAPI-Initial-Context-Token wird die MIT-Implementierung von Kerberos die KRB_CRED-Nachricht nicht verschlüsseln, wenn der Session Key ein DES- oder Triple-DES-Schlüssel ist. Für Interoperabilität mit MIT wird die Microsoft-Implementierung die KRB_CRED in einem GSSAPI-Token nicht verschlüsseln, wenn sie einen DES-Session-Key verwendet. Ab Version 1.2.5 kann MIT Kerberos sowohl verschlüsselte als auch unverschlüsselte KRB_CRED-Tokens im GSSAPI-Austausch empfangen und dekodieren. Die Heimdal-Implementierung von Kerberos kann auch sowohl verschlüsselte als auch unverschlüsselte KRB_CRED-Nachrichten akzeptieren. Da die KRB_CRED-Nachricht in einem GSSAPI-Token im Authenticator verschlüsselt ist, stellt das MIT-Verhalten kein Sicherheitsproblem dar, obwohl es eine Verletzung der Kerberos-Spezifikation ist.

3.6.2. Receipt of KRB_CRED Message (Empfang der KRB_CRED-Nachricht)

Wenn eine Anwendung eine KRB_CRED-Nachricht empfängt, überprüft sie diese. Wenn ein Fehler auftritt, wird ein Fehlercode zur Verwendung durch die Anwendung gemeldet. Die Nachricht wird überprüft, indem geprüft wird, dass die Protokollversions- und Typfelder mit der aktuellen Version bzw. KRB_CRED übereinstimmen. Eine Nichtübereinstimmung erzeugt einen Fehler KRB_AP_ERR_BADVERSION oder KRB_AP_ERR_MSG_TYPE. Die Anwendung entschlüsselt dann den Chiffretext und verarbeitet den resultierenden Klartext. Wenn die Entschlüsselung zeigt, dass die Daten modifiziert wurden, wird ein Fehler KRB_AP_ERR_BAD_INTEGRITY generiert.

Falls vorhanden oder erforderlich, KANN der Empfänger überprüfen, dass der Bericht des Betriebssystems über die Adresse des Absenders mit der Adresse des Absenders in der Nachricht übereinstimmt und dass eine der Adressen des Empfängers als Empfängeradresse in der Nachricht erscheint. Die Adressprüfung bietet keine zusätzliche Sicherheit, da die Adresse, falls vorhanden, bereits in der KRB_AP_REQ-Nachricht überprüft wurde und es keinen Vorteil für einen Angreifer gibt, eine KRB_CRED-Nachricht an ihren Urheber zurückzusenden. Daher KANN der Empfänger die Adresse ignorieren, selbst wenn sie vorhanden ist, um besser in Network Address Translation (NAT)-Umgebungen zu funktionieren. Eine fehlgeschlagene Übereinstimmung in beiden Fällen erzeugt einen Fehler KRB_AP_ERR_BADADDR. Empfänger KÖNNEN die Adressprüfung überspringen, da die KRB_CRED-Nachricht im Allgemeinen nicht an den Urheber zurückgesendet werden kann. Die Zeitstempel- und usec-Felder (und das nonce-Feld, falls erforderlich) werden als nächstes überprüft. Wenn der Zeitstempel und usec nicht vorhanden sind oder wenn sie vorhanden sind, aber nicht aktuell, wird der Fehler KRB_AP_ERR_SKEW generiert.

Wenn alle Prüfungen erfolgreich sind, speichert die Anwendung jedes der neuen Tickets in ihrem Credentials-Cache zusammen mit dem Session Key und anderen Informationen in der entsprechenden KrbCredInfo-Sequenz aus dem verschlüsselten Teil der KRB_CRED-Nachricht.

3.7. User-to-User Authentication Exchanges (Benutzer-zu-Benutzer-Authentifizierungsaustausch)

Benutzer-zu-Benutzer-Authentifizierung bietet eine Methode zur Durchführung der Authentifizierung, wenn der Verifizierer keinen Zugriff auf einen langfristigen Service-Schlüssel hat. Dies könnte der Fall sein, wenn ein Server (z.B. ein Fensterserver) als Benutzer auf einer Workstation ausgeführt wird. In solchen Fällen hat der Server möglicherweise Zugriff auf das TGT, das erhalten wurde, als sich der Benutzer an der Workstation anmeldete, aber da der Server als unprivilegierter Benutzer läuft, hat er möglicherweise keinen Zugriff auf Systemschlüssel. Ähnliche Situationen können beim Ausführen von Peer-to-Peer-Anwendungen auftreten.

Zusammenfassung

Nachrichtenrichtung	Nachrichtentyp	Abschnitte
0. Nachricht vom Anwendungsserver	Nicht spezifiziert
1. Client zu Kerberos	`KRB_TGS_REQ`	3.3 & 5.4.1
2. Kerberos zu Client	`KRB_TGS_REP` oder `KRB_ERROR`	3.3 & 5.4.2, 5.9.1
3. Client zu Anwendungsserver	`KRB_AP_REQ`	3.2 & 5.5.1

Um dieses Problem anzugehen, erlaubt das Kerberos-Protokoll dem Client anzufordern, dass das vom KDC ausgestellte Ticket mit einem Session Key aus einem TGT verschlüsselt wird, das der Partei ausgestellt wurde, die die Authentifizierung überprüfen wird. Dieses TGT muss vom Verifizierer durch einen Austausch außerhalb des Kerberos-Protokolls erhalten werden, normalerweise als Teil des Anwendungsprotokolls. Diese Nachricht wird in der obigen Zusammenfassung als Nachricht 0 dargestellt. Beachten Sie, dass das TGT, da es mit dem geheimen Schlüssel des KDC verschlüsselt ist, nicht ohne Besitz des entsprechenden geheimen Schlüssels zur Authentifizierung verwendet werden kann. Darüber hinaus erlaubt die Bereitstellung einer Kopie des TGT des Verifizierers keine Identitätsvorfälschung des Verifizierers, da der Verifizierer den entsprechenden geheimen Schlüssel nicht offenlegt.

Nachricht 0 in der obigen Tabelle stellt eine anwendungsspezifische Verhandlung zwischen Client und Server dar, am Ende derer beide bestimmt haben, dass sie Benutzer-zu-Benutzer-Authentifizierung verwenden werden, und der Client das TGT des Servers erhalten hat.

Als nächstes schließt der Client das TGT des Servers als zusätzliches Ticket in seine KRB_TGS_REQ-Anfrage an das KDC ein (Nachricht 1 in der obigen Tabelle) und gibt die Option ENC-TKT-IN-SKEY in seiner Anfrage an.

Wenn gemäß den Anweisungen in Abschnitt 3.3.3 validiert, wird das an den Client zurückgegebene Anwendungsticket (Nachricht 2 in der obigen Tabelle) mit dem Session Key aus dem zusätzlichen Ticket verschlüsselt, und der Client wird dies beachten, wenn er das Anwendungsticket verwendet oder speichert.

Beim Kontaktieren des Servers unter Verwendung eines für Benutzer-zu-Benutzer-Authentifizierung erhaltenen Tickets (Nachricht 3 in der obigen Tabelle) MUSS der Client das Flag USE-SESSION-KEY im ap-options-Feld angeben. Dies teilt dem Anwendungsserver mit, den mit seinem TGT verbundenen Session Key zu verwenden, um das im Anwendungsauftrag bereitgestellte Server-Ticket zu entschlüsseln.