メインコンテンツまでスキップ

5. セキュリティに関する考察

本節では、チケットの使用に関連するセキュリティ問題について述べます。チケットは、攻撃者による改ざんや盗聴を防ぐために認証および暗号化されなければなりません。これが注意深く行われない場合、以下で説明するいくつかの攻撃が可能になります。

実装は、チケットの処理が以下で説明するサービス拒否 (denial of service) の可能性を増加させないように注意を払うべきです。

5.1. セッションの無効化​

TLS 仕様は、エラーが発生したときに TLS セッションを無効化することを要求しています。[CSSC] は、これのセキュリティ上の影響について詳細に論じています。この論文の分析では、セッションの無効化の失敗はセキュリティ上のリスクをもたらしません。これは、TLS ハンドシェイクがセッションの鍵を導出するために不可逆な関数を使用するため、あるセッションに関する情報がマスターシークレットまたは別のセッションを攻撃するための利点を与えないからです。セッション無効化スキームが使用される場合、実装は、攻撃者が選択したセッションを無効化できないようにするために、その内容をセッションの無効化に使用する前にチケットの完全性を検証すべきです。

5.2. 盗まれたチケット​

盗聴者または中間者 (man-in-the-middle) はチケットを入手し、それを使用してサーバーとのセッションを確立しようと試みる可能性があります。しかし、チケットは暗号化されており、攻撃者は秘密鍵を知らないため、盗まれたチケットは攻撃者がセッションを再開する助けにはなりません。TLS サーバーは、攻撃者がブルートフォース機構を使用してチケットの内容を入手することを防ぐために、チケットに強力な暗号化と完全性保護を使用しなければなりません (MUST)。

5.3. 偽造されたチケット​

悪意のあるユーザーは、セッションを再開したり、その有効期間を延長したり、別のユーザーになりすましたり、追加の権限を取得したりするために、チケットを偽造または改変することができます。チケットが鍵付き HMAC-SHA-256 のような強力な完全性保護アルゴリズムを使用して保護されている場合、この攻撃は不可能です。

5.4. サービス拒否攻撃​

推奨されるチケット形式で定義された key_name フィールドは、サーバーが自身が発行していないチケットを効率的に拒否するのに役立ちます。しかし、攻撃者は、検証のために TLS サーバーに送信する多数のチケットを保存または生成することができます。サービス拒否の可能性を最小限に抑えるために、チケットの検証は軽量であるべきです (例えば、効率的な対称鍵暗号アルゴリズムを使用するなど)。

5.5. チケット保護鍵の管理​

チケットを保護するために使用される鍵の管理についての完全な説明は、本文書の範囲外です。推奨される (RECOMMENDED) 実践の一覧を以下に示します。

  • 鍵は、[RFC4086] のランダム性に関する推奨事項に従って安全に生成すべきです。

  • 鍵および暗号保護アルゴリズムは、少なくとも 128 ビットの強度であるべきです。一部の暗号スイートやアプリケーションは、128 ビットを超える強度の暗号保護を必要とする場合があります。

  • 鍵は、チケットの生成および検証以外のいかなる目的にも使用されるべきではありません。

  • 鍵は定期的に変更すべきです。

  • 鍵は、チケット形式または暗号保護アルゴリズムが変更された場合に変更すべきです。

5.6. チケットの有効期間​

TLS サーバーはチケットの有効期間を制御します。サーバーは、自身が展開されている環境の運用上およびセキュリティ上の要件に基づいて、許容される有効期間を決定します。チケットの有効期間は、[RFC4346] で推奨されている 24 時間の有効期間より長くてもよいです。TLS クライアントにはチケットの有効期間のヒントが与えられる場合があります。チケットの有効期間は指定されない場合があるため、クライアントは、いつチケットを破棄するかを決定する独自のローカルポリシーを持ちます。

5.7. 代替のチケット形式および配布スキーム​

本文書で定義されたチケット形式または配布スキームが使用されない場合、ソリューションのセキュリティを分析する際に細心の注意を払わなければなりません。特に、秘密鍵などの機密情報がクライアントに転送される場合、攻撃者が鍵を入手または改変することを防ぐために、安全な通信を使用して行われなければなりません (MUST)。また、チケットは、システムのセキュリティの侵害を防ぐために、強力な暗号技術によってその完全性と機密性が保護されなければなりません (MUST)。

5.8. アイデンティティのプライバシー、匿名性、および非リンク性​

本文書は、ユーザー関連情報などの内容の漏洩を避けるために、チケットの内容が機密性保護されることを義務付けています。そのため、本文書は、チケット内で運ばれる潜在的に機密性の高い情報の開示を防ぎます。

チケットを取得するために使用された最初のハンドシェイク交換は、TLS の特性に基づくクライアントのアイデンティティの機密性を提供しない場合があります。別の関連するセキュリティ上の脅威は、経路上の (on-path) 攻撃者が、同じチケットが使用される複数の TLS ハンドシェイクを観察し、それによってそれらが同じ通信エンドポイントに属すると結論付けることができることです。本文書で説明するチケット機構を使用するアプリケーション設計者は、非リンク性 (unlinkability) [ANON] が必ずしも提供されるわけではないことを考慮すべきです。

これらの話題についての完全な議論は本文書の範囲外ですが、以前のハンドシェイクによって安全なトンネルが確立された後に発生する TLS 再ネゴシエーションハンドシェイクを使用してチケットを発行することが可能であることに注意すべきです。これは、一部の環境において、いくつかのプライバシーおよび非リンク性の問題に対処するのに役立つ場合があります。