3.5. The KRB_PRIV Exchange (Der KRB_PRIV-Austausch)

Die Nachricht KRB_PRIV DARF von Clients verwendet werden, die Vertraulichkeit und die Fähigkeit benötigen, Veränderungen ausgetauschter Nachrichten zu erkennen. Sie erreicht dies, indem die Nachrichten verschlüsselt und Steuerinformationen 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 passenden Steuerinformationen (in Abschnitt 5.7.1 spezifiziert) und verschlüsselt sie unter einem Verschlüsselungsschlüssel (üblicherweise dem zuletzt über Subkeys ausgehandelten Schlüssel oder dem Session Key, wenn keine Aushandlung stattgefunden hat). Als Teil der Steuerinformationen MUSS der Client entweder einen Zeitstempel oder eine Sequenznummer (oder beides) verwenden; siehe die Erläuterungen in Abschnitt 3.4.1 zu Richtlinien, welches zu wählen ist. Nachdem Benutzerdaten und Steuerinformationen verschlüsselt sind, überträgt der Client den Chiffretext und bestimmte „Umschlag“-Informationen (envelope) an den Empfänger.

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

Wenn eine Anwendung eine KRB_PRIV-Nachricht empfängt, verifiziert sie sie wie folgt. Tritt ein Fehler auf, wird ein Fehlercode zur Verwendung durch die Anwendung gemeldet.

Die Nachricht wird zunächst geprüft, indem verifiziert wird, dass die Felder für Protokollversion und Typ zur aktuellen Version bzw. zu KRB_PRIV 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.

Die Absenderadresse MUSS in den Steuerinformationen enthalten sein; der Empfänger verifiziert, dass die vom Betriebssystem gemeldete Absenderadresse mit der Absenderadresse in der Nachricht übereinstimmt. Ist eine Empfängeradresse angegeben oder verlangt der Empfänger eine Adresse, MUSS eine der Adressen des Empfängers ebenfalls als Empfängeradresse in der Nachricht erscheinen. Wo eine Absender- oder Empfängeradresse wegen Network Address Translation (NAT) sonst nicht mit der Adresse in einer Nachricht übereinstimmen würde, DARF eine Anwendung so geschrieben sein, dass sie Adressen des Typs directional address (gerichtete Adresse) anstelle der tatsächlichen Netzwerkadresse verwendet.

Eine fehlgeschlagene Übereinstimmung in einem der beiden Fälle erzeugt einen Fehler KRB_AP_ERR_BADADDR. Zur Zusammenarbeit mit Network Address Translation DÜRFEN Implementierungen den in Abschnitt 7.1 definierten Typ directional address für die Absenderadresse verwenden und keine Empfängeradresse angeben.

Als Nächstes werden die Felder für Zeitstempel und Mikrosekunden (usec) und/oder die Sequenznummer geprüft. Werden Zeitstempel und usec erwartet, fehlen aber, oder sind sie vorhanden, aber nicht aktuell, wird der Fehler KRB_AP_ERR_SKEW erzeugt. Stimmen Servername sowie Clientname, Zeit und Mikrosekundenfelder aus dem Authenticator mit einem solchen kürzlich gesehenen Tupel überein, wird der Fehler KRB_AP_ERR_REPEAT erzeugt. Ist eine falsche Sequenznummer enthalten oder wird eine Sequenznummer erwartet, fehlt aber, wird der Fehler KRB_AP_ERR_BADORDER erzeugt. Sind weder Zeitstempel und usec noch eine Sequenznummer vorhanden, wird der Fehler KRB_AP_ERR_MODIFIED erzeugt.

Wenn alle Prüfungen erfolgreich sind, kann die Anwendung davon ausgehen, dass die Nachricht von ihrem Peer erzeugt und sicher übertragen wurde (ohne dass Dritte den unverschlüsselten Inhalt sehen).