4. Empfohlene Ticket-Konstruktion

Dieser Abschnitt beschreibt einen empfohlenen Ticket-Konstruktionsmechanismus. Implementierungen werden ermutigt, die Sicherheitsimplikationen des von ihnen gewählten Ticket-Konstruktionsmechanismus sorgfältig zu berücksichtigen. Tickets MÜSSEN authentifiziert und verschlüsselt werden, um Modifikation und Abhören durch einen Angreifer zu verhindern. Mehrere geeignete Cipher-Suites umfassen: AES-128-CBC mit HMAC-SHA-256, AES-256-CBC mit HMAC-SHA-256, AES-128-GCM, AES-256-GCM und jede andere starke Cipher-Suite, die Authentifizierung und Verschlüsselung bietet.

Der Server verwendet einen Verschlüsselungsschlüssel zum Ver- und Entschlüsseln des Tickets. Dieser Schlüssel ist nur dem Server bekannt. Der Server verwendet auch einen separaten Schlüssel zur Berechnung einer Integritätsprüfung für das Ticket. Eine empfohlene Konstruktion wird unten beschrieben.

struct {
    opaque key_name[16];
    opaque iv[16];
    opaque encrypted_state&lt;0..2^16-1>;
    opaque mac[32];
} ticket;

key_name: Dieses Feld identifiziert den Verschlüsselungsschlüssel, der zum Verschlüsseln des Tickets verwendet wurde. Es wird empfohlen, diesen Wert zufällig zu machen und häufig zu ändern.

iv: Dieses Feld enthält den Initialisierungsvektor (IV) für den verschlüsselten Zustand. Der IV MUSS für jedes Ticket zufällig generiert werden.

encrypted_state: Dieses Feld enthält den verschlüsselten Sitzungszustand. Der Zustand umfasst das Master-Secret der Sitzung, die Cipher-Suite, die Komprimierungsmethode und alle anderen Informationen, die der Server zur Wiederaufnahme der Sitzung benötigt.

mac: Dieses Feld enthält einen Message Authentication Code (MAC), der das gesamte Ticket abdeckt, einschließlich der Felder key_name, iv und encrypted_state.