4. Empfohlene Ticket-Konstruktion

Dieser Abschnitt beschreibt ein empfohlenes Format und einen empfohlenen Schutz für das Ticket. Beachten Sie, dass das Ticket für den Client undurchsichtig (opaque) ist, sodass die Struktur keinen Interoperabilitätsbedenken unterliegt und Implementierungen von diesem Format abweichen können. Wenn Implementierungen von diesem Format abweichen, müssen sie Sicherheitsbedenken ernst nehmen. Clients DÜRFEN NICHT (MUST NOT) das Ticket unter der Annahme untersuchen, dass es diesem Dokument entspricht.

Der Server verwendet zwei verschiedene Schlüssel: einen 128-Bit-Schlüssel für die Verschlüsselung mit dem Advanced Encryption Standard (AES) [AES] im Cipher Block Chaining (CBC)-Modus [CBC] und einen 256-Bit-Schlüssel für HMAC-SHA-256 [RFC4634].

Das Ticket ist wie folgt strukturiert:

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

Hier dient key_name dazu, eine bestimmte Gruppe von Schlüsseln zu identifizieren, die zum Schutz des Tickets verwendet wird. Er ermöglicht es dem Server, Tickets, die er ausgegeben hat, leicht zu erkennen. Der key_name sollte zufällig erzeugt werden, um Kollisionen zwischen Servern zu vermeiden. Eine Möglichkeit besteht darin, jedes Mal, wenn der Server gestartet wird, neue zufällige Schlüssel und einen neuen key_name zu erzeugen.

Die tatsächlichen Zustandsinformationen in encrypted_state werden mit 128-Bit-AES im CBC-Modus mit dem angegebenen IV verschlüsselt. Der Message Authentication Code (MAC) wird unter Verwendung von HMAC-SHA-256 über key_name (16 Oktette) und IV (16 Oktette) berechnet, gefolgt von der Länge des Feldes encrypted_state (2 Oktette) und dessen Inhalt (variable Länge).

   struct {
       ProtocolVersion protocol_version;
       CipherSuite cipher_suite;
       CompressionMethod compression_method;
       opaque master_secret[48];
       ClientIdentity client_identity;
       uint32 timestamp;
   } StatePlaintext;

   enum {
      anonymous(0),
      certificate_based(1),
      psk(2)
  } ClientAuthenticationType;

   struct {
       ClientAuthenticationType client_authentication_type;
       select (ClientAuthenticationType) {
           case anonymous: struct {};
           case certificate_based:
               ASN.1Cert certificate_list<0..2^24-1>;
           case psk:
               opaque psk_identity<0..2^16-1>;   /* from [RFC4279] */
       };
    } ClientIdentity;

Die Struktur StatePlaintext speichert den TLS-Sitzungszustand einschließlich des master_secret. Der Zeitstempel innerhalb dieser Struktur ermöglicht es dem TLS-Server, Tickets ablaufen zu lassen. Um die von TLS bereitgestellten Authentifizierungs- und Schlüsselaustauschprotokolle abzudecken, enthält die Struktur ClientIdentity den Authentifizierungstyp des Clients, der im ursprünglichen Austausch verwendet wurde (siehe ClientAuthenticationType). Um dem TLS-Server dieselben Fähigkeiten für Authentifizierung und Autorisierung zu bieten, wird im Fall von Authentifizierung auf Basis öffentlicher Schlüssel eine Zertifikatsliste aufgenommen. Der TLS-Server ist daher in der Lage, eine Reihe verschiedener Attribute innerhalb dieser Zertifikate zu prüfen. Eine bestimmte Implementierung könnte sich dafür entscheiden, eine Teilmenge dieser Informationen oder zusätzliche Informationen zu speichern. Andere Authentifizierungsmechanismen wie Kerberos [RFC2712] würden andere Client-Identitätsdaten erfordern. Andere TLS-Erweiterungen können die Aufnahme zusätzlicher Daten in die Struktur StatePlaintext erfordern.