4. Construction de ticket recommandée

Cette section décrit un format et une protection recommandés pour le ticket. Notez que le ticket est opaque pour le client, de sorte que la structure n'est pas soumise à des préoccupations d'interopérabilité, et que les implémentations peuvent s'écarter de ce format. Si des implémentations s'écartent effectivement de ce format, elles doivent prendre les considérations de sécurité au sérieux. Les clients NE DOIVENT PAS (MUST NOT) examiner le ticket en supposant qu'il est conforme à ce document.

Le serveur utilise deux clés différentes : une clé de 128 bits pour le chiffrement Advanced Encryption Standard (AES) [AES] en mode Cipher Block Chaining (CBC) [CBC] et une clé de 256 bits pour HMAC-SHA-256 [RFC4634].

Le ticket est structuré comme suit :

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

Ici, key_name sert à identifier un ensemble particulier de clés utilisé pour protéger le ticket. Il permet au serveur de reconnaître facilement les tickets qu'il a émis. Le key_name devrait être généré aléatoirement afin d'éviter les collisions entre serveurs. Une possibilité consiste à générer de nouvelles clés aléatoires et un nouveau key_name chaque fois que le serveur est démarré.

Les informations d'état proprement dites dans encrypted_state sont chiffrées à l'aide d'AES 128 bits en mode CBC avec l'IV donné. Le code d'authentification de message (Message Authentication Code, MAC) est calculé à l'aide de HMAC-SHA-256 sur key_name (16 octets) et l'IV (16 octets), suivis de la longueur du champ encrypted_state (2 octets) et de son contenu (longueur variable).

   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 structure StatePlaintext stocke l'état de session TLS, y compris le master_secret. L'horodatage (timestamp) au sein de cette structure permet au serveur TLS de faire expirer les tickets. Pour couvrir les protocoles d'authentification et d'échange de clés fournis par TLS, la structure ClientIdentity contient le type d'authentification du client utilisé lors de l'échange initial (voir ClientAuthenticationType). Afin d'offrir au serveur TLS les mêmes capacités d'authentification et d'autorisation, une liste de certificats est incluse en cas d'authentification à base de clé publique. Le serveur TLS est donc en mesure d'inspecter un certain nombre d'attributs différents au sein de ces certificats. Une implémentation particulière peut choisir de stocker un sous-ensemble de ces informations ou des informations supplémentaires. D'autres mécanismes d'authentification, tels que Kerberos [RFC2712], exigeraient des données d'identité de client différentes. D'autres extensions TLS peuvent exiger l'inclusion de données supplémentaires dans la structure StatePlaintext.