3.6. The KRB_CRED Exchange (Der KRB_CRED-Austausch)

Die Nachricht KRB_CRED DARF von Clients verwendet werden, die Kerberos-Credentials von einem Host zu einem anderen senden müssen. Sie erreicht dies, indem die Tickets zusammen mit verschlüsselten Daten gesendet werden, die die Session Keys und sonstige 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, beschafft sie zunächst (über den KRB_TGS-Austausch) die Credentials, die an den entfernten Host gesendet werden sollen. Anschließend konstruiert sie eine KRB_CRED-Nachricht unter Verwendung des so bezogenen Tickets bzw. der Tickets und legt den zum jeweiligen Ticket benötigten Session Key in das Feld key der entsprechenden KrbCredInfo-Sequenz des verschlüsselten Teils der KRB_CRED-Nachricht.

Weitere Informationen, die mit jedem Ticket verbunden sind und während des KRB_TGS-Austauschs bezogen wurden, werden ebenfalls in die entsprechende KrbCredInfo-Sequenz im verschlüsselten Teil der KRB_CRED-Nachricht gelegt. Die aktuelle Zeit sowie, falls die Anwendung dies ausdrücklich verlangt, die Felder nonce, s-address und r-address werden in den verschlüsselten Teil der KRB_CRED-Nachricht gelegt, der anschließend unter einem im KRB_AP-Austausch zuvor ausgetauschten Verschlüsselungsschlüssel verschlüsselt wird (üblicherweise dem zuletzt über Subkeys ausgehandelten Schlüssel oder dem Session Key, wenn keine Aushandlung stattgefunden hat).

Implementierungshinweis: Beim Aufbau einer KRB_CRED-Nachricht zur Einbettung in ein GSSAPI-Initial-Context-Token verschlüsselt die MIT-Implementierung von Kerberos die KRB_CRED-Nachricht nicht, wenn der Session Key ein DES- oder Triple-DES-Schlüssel ist. Zur Interoperabilität mit MIT verschlüsselt die Microsoft-Implementierung die KRB_CRED in einem GSSAPI-Token nicht, wenn ein DES-Session-Key verwendet wird. Ab Version 1.2.5 kann MIT Kerberos verschlüsselte oder unverschlüsselte KRB_CRED-Tokens im GSSAPI-Austausch empfangen und dekodieren. Die Heimdal-Implementierung von Kerberos kann ebenfalls verschlüsselte oder 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 darstellt.

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

Wenn eine Anwendung eine KRB_CRED-Nachricht empfängt, verifiziert sie sie. Tritt ein Fehler auf, wird ein Fehlercode zur Verwendung durch die Anwendung gemeldet. Die Nachricht wird verifiziert, indem geprüft wird, dass die Felder für Protokollversion und Typ zur aktuellen Version bzw. zu KRB_CRED passen. Eine Abweichung erzeugt einen Fehler KRB_AP_ERR_BADVERSION oder KRB_AP_ERR_MSG_TYPE. Die Anwendung entschlüsselt anschließend den Chiffretext und verarbeitet den resultierenden Klartext. Zeigt die Entschlüsselung, dass die Daten verändert wurden, wird ein Fehler KRB_AP_ERR_BAD_INTEGRITY erzeugt.

Ist eine Prüfung vorgesehen oder erforderlich, DARF der Empfänger verifizieren, dass die vom Betriebssystem gemeldete Absenderadresse mit der Absenderadresse in der Nachricht übereinstimmt und dass eine der Adressen des Empfängers als Empfängeradresse in der Nachricht erscheint. Die Adressprüfung bietet keinen zusätzlichen Schutz, da die Adresse, falls vorhanden, bereits in der KRB_AP_REQ-Nachricht geprüft wurde und ein Angreifer keinen Nutzen davon hat, eine KRB_CRED-Nachricht an ihren Ursprung zurückzuspiegeln. Daher DARF der Empfänger die Adresse ignorieren, selbst wenn sie vorhanden ist, um in Umgebungen mit Network Address Translation (NAT) besser zu funktionieren. Eine fehlgeschlagene Übereinstimmung in einem der beiden Fälle erzeugt einen Fehler KRB_AP_ERR_BADADDR. Empfänger DÜRFEN die Adressprüfung überspringen, da eine KRB_CRED-Nachricht im Allgemeinen nicht an den Ursprung zurückreflektiert werden kann. Als Nächstes werden die Felder für Zeitstempel und usec (und das Feld nonce, falls erforderlich) geprüft. Fehlen Zeitstempel und usec, oder sind sie vorhanden, aber nicht aktuell, wird der Fehler KRB_AP_ERR_SKEW erzeugt.

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