4. Recommended Ticket Construction

This section describes a recommended format and protection for the ticket. Note that the ticket is opaque to the client, so the structure is not subject to interoperability concerns, and implementations may diverge from this format. If implementations do diverge from this format, they must take security concerns seriously. Clients MUST NOT examine the ticket under the assumption that it complies with this document.

The server uses two different keys: one 128-bit key for Advanced Encryption Standard (AES) [AES] in Cipher Block Chaining (CBC) mode [CBC] encryption and one 256-bit key for HMAC-SHA-256 [RFC4634].

The ticket is structured as follows:

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

Here, key_name serves to identify a particular set of keys used to protect the ticket. It enables the server to easily recognize tickets it has issued. The key_name should be randomly generated to avoid collisions between servers. One possibility is to generate new random keys and key_name every time the server is started.

The actual state information in encrypted_state is encrypted using 128-bit AES in CBC mode with the given IV. The Message Authentication Code (MAC) is calculated using HMAC-SHA-256 over key_name (16 octets) and IV (16 octets), followed by the length of the encrypted_state field (2 octets) and its contents (variable length).

   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;

The structure StatePlaintext stores the TLS session state including the master_secret. The timestamp within this structure allows the TLS server to expire tickets. To cover the authentication and key exchange protocols provided by TLS, the ClientIdentity structure contains the authentication type of the client used in the initial exchange (see ClientAuthenticationType). To offer the TLS server with the same capabilities for authentication and authorization, a certificate list is included in case of public-key-based authentication. The TLS server is therefore able to inspect a number of different attributes within these certificates. A specific implementation might choose to store a subset of this information or additional information. Other authentication mechanisms, such as Kerberos [RFC2712], would require different client identity data. Other TLS extensions may require the inclusion of additional data in the StatePlaintext structure.