1.2 Cross-Realm Operation (クロスレルム操作)

Kerberos プロトコルは, 組織の境界を越えて動作するように設計されています。ある組織のクライアントは, 別の組織のサーバーに認証できます。Kerberos サーバーを実行しようとする各組織は, 独自の "realm (レルム)" を確立します。クライアントが登録されているレルムの名前はクライアントの名前の一部であり, エンドサービスがリクエストを受け入れるかどうかを決定するために使用できます。

"inter-realm (レルム間)" 鍵を確立することにより, 2つのレルムの管理者は, ローカルレルムで認証されたクライアントが他のレルムのサーバーに対してその識別情報を証明できるようにすることができます。レルム間鍵の交換 (各方向に別個の鍵が使用される場合があります) により, 各レルムのチケット付与サービスが他のレルムの principal として登録されます。クライアントは, ローカルレルムからリモートレルムのチケット付与サービスの TGT を取得できます。その TGT が使用されると, リモートチケット付与サービスはレルム間鍵 (通常, 独自の通常の TGS 鍵とは異なります) を使用して TGT を復号化します。したがって, チケットがクライアント自身の TGS によって発行されたことが確実です。リモートチケット付与サービスによって発行されたチケットは, クライアントが別のレルムから認証されたことをエンドサービスに示します。

クロスレルム操作がなく, 適切な許可があれば, クライアントはリモートレルムに個別に名前を付けられた principal の登録を手配し, そのレルムのサービスと通常の交換を行うことができます。しかし, 少数のクライアントであっても, これは煩雑になり, ここで説明されているようなより自動的な方法が必要になります。

レルムは, 2つのレルムがレルム間鍵を共有している場合, またはローカルレルムがリモートレルムと通信する中間レルムとレルム間鍵を共有している場合, 別のレルムと通信していると言われます。認証パス (authentication path) は, あるレルムから別のレルムへの通信で経由される中間レルムのシーケンスです。

レルムは階層的に編成できます。各レルムは親との鍵を共有し, 各子との異なる鍵を共有します。レルム間鍵が2つのレルム間で直接共有されていない場合, 階層的な組織により認証パスを簡単に構築できます。階層的な組織が使用されない場合, レルム間の認証パスを構築するためにデータベースを参照する必要がある場合があります。

レルムは通常階層的ですが, 代替認証パスを通じてクロスレルム認証を実現するために中間レルムをバイパスできます。(これらは, 2つのレルム間の通信をより効率的にするために確立される場合があります。) エンドサービスが認証プロセスにどの程度の信頼を置くかを決定する際に, どのレルムが経由されたかを知ることが重要です。この決定を容易にするために, 各チケットのフィールドには, クライアントの認証に関与したレルムの名前が含まれています。

アプリケーションサーバーは, 最終的に認証を受け入れるか拒否するかについて責任を負い, 経由フィールド (transited field) をチェックすべきです (SHOULD)。アプリケーションサーバーは, アプリケーションサーバーのレルムの Key Distribution Center (KDC) に経由フィールドのチェックを依頼することを選択できます。アプリケーションサーバーの KDC は, この場合 TRANSITED-POLICY-CHECKED フラグを設定します。中間レルムの KDC は, 他のレルムの TGT を発行する際に経由フィールドをチェックすることもできますが, そうしないことが推奨されます。クライアントは, DISABLE-TRANSITED-CHECK フラグを設定することにより, KDC が経由フィールドをチェックしないように要求できます。KDC はこのフラグを尊重すべきです (SHOULD)。

📊 翻訳品質チェック

📍 現在の進捗

RFC 番号: 4120
対象言語: 🇯🇵 日本語
完了章節: index, 1-introduction, 1-1, 1-2
現在章節: 1-3
全体進捗: 4%

📊 翻訳品質チェック
📍 現在の進捗

📊 翻訳品質チェック​

📍 現在の進捗​

📊 翻訳品質チェック

📍 現在の進捗