4. 推奨されるチケット構造

本節では、チケットの推奨される形式と保護方法について説明します。チケットはクライアントにとって不透明 (opaque) であるため、その構造は相互運用性の懸念の対象にはならず、実装はこの形式から逸脱してもよいことに注意してください。実装がこの形式から逸脱する場合、実装はセキュリティ上の懸念を真剣に受け止めなければなりません。クライアントは、チケットが本文書に準拠していると仮定してチケットを検査してはなりません (MUST NOT)。

サーバーは 2 つの異なる鍵を使用します。1 つは暗号ブロック連鎖 (CBC) モード [CBC] の暗号化における Advanced Encryption Standard (AES) [AES] 用の 128 ビット鍵で、もう 1 つは HMAC-SHA-256 [RFC4634] 用の 256 ビット鍵です。

チケットは次のように構成されます。

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

ここで、key_name はチケットを保護するために使用される特定の鍵の集合を識別する役割を果たします。これにより、サーバーは自身が発行したチケットを容易に認識できます。key_name は、サーバー間での衝突を避けるためにランダムに生成すべきです。1 つの可能性は、サーバーが起動するたびに新しいランダム鍵と key_name を生成することです。

encrypted_state 内の実際の状態情報は、指定された IV を使用して CBC モードの 128 ビット AES で暗号化されます。メッセージ認証コード (MAC) は、key_name (16 オクテット) および IV (16 オクテット) に続けて、encrypted_state フィールドの長さ (2 オクテット) とその内容 (可変長) に対して HMAC-SHA-256 を使用して計算されます。

   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;

StatePlaintext 構造は、master_secret を含む TLS セッション状態を格納します。この構造内の timestamp により、TLS サーバーはチケットを失効させることができます。TLS が提供する認証および鍵交換プロトコルを網羅するために、ClientIdentity 構造には、初期交換で使用されたクライアントの認証タイプが含まれます (ClientAuthenticationType を参照)。TLS サーバーに認証および認可について同じ能力を提供するために、公開鍵ベースの認証の場合には証明書リストが含まれます。したがって、TLS サーバーはこれらの証明書内のさまざまな属性を検査できます。特定の実装は、この情報の一部または追加情報を格納することを選択する場合があります。Kerberos [RFC2712] などの他の認証機構は、異なるクライアント識別データを必要とします。他の TLS 拡張は、StatePlaintext 構造に追加データを含めることを必要とする場合があります。