4. Costruzione raccomandata del ticket

Questa sezione descrive un formato e una protezione raccomandati per il ticket. Si noti che il ticket è opaco per il client, quindi la struttura non è soggetta a problemi di interoperabilità e le implementazioni possono discostarsi da questo formato. Se le implementazioni si discostano da questo formato, devono prendere sul serio le considerazioni sulla sicurezza. I client NON DEVONO (MUST NOT) esaminare il ticket presupponendo che sia conforme al presente documento.

Il server usa due chiavi diverse: una chiave a 128 bit per la cifratura Advanced Encryption Standard (AES) [AES] in modalità Cipher Block Chaining (CBC) [CBC] e una chiave a 256 bit per HMAC-SHA-256 [RFC4634].

Il ticket è strutturato come segue:

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

Qui, key_name serve a identificare un particolare insieme di chiavi usato per proteggere il ticket. Consente al server di riconoscere facilmente i ticket che ha emesso. Il key_name dovrebbe essere generato in modo casuale per evitare collisioni tra server. Una possibilità è generare nuove chiavi casuali e un nuovo key_name ogni volta che il server viene avviato.

Le informazioni di stato effettive in encrypted_state sono cifrate usando AES a 128 bit in modalità CBC con l'IV dato. Il Message Authentication Code (MAC) è calcolato usando HMAC-SHA-256 su key_name (16 ottetti) e IV (16 ottetti), seguiti dalla lunghezza del campo encrypted_state (2 ottetti) e dal suo contenuto (lunghezza variabile).

   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;

La struttura StatePlaintext memorizza lo stato della sessione TLS, incluso il master_secret. Il timestamp all'interno di questa struttura consente al server TLS di far scadere i ticket. Per coprire i protocolli di autenticazione e di scambio di chiavi forniti da TLS, la struttura ClientIdentity contiene il tipo di autenticazione del client usato nello scambio iniziale (vedere ClientAuthenticationType). Per offrire al server TLS le stesse capacità di autenticazione e autorizzazione, nel caso di autenticazione basata su chiave pubblica è inclusa una lista di certificati. Il server TLS è quindi in grado di ispezionare una serie di attributi diversi all'interno di questi certificati. Un'implementazione specifica potrebbe scegliere di memorizzare un sottoinsieme di queste informazioni o informazioni aggiuntive. Altri meccanismi di autenticazione, come Kerberos [RFC2712], richiederebbero dati di identità del client diversi. Altre estensioni TLS possono richiedere l'inclusione di dati aggiuntivi nella struttura StatePlaintext.