1.1 The Kerberos Protocol (Kerberos プロトコル)

Kerberos は, オープンな (保護されていない) ネットワーク上で principals の識別情報を検証する手段を提供します (例: ワークステーションユーザーまたはネットワークサーバー)。これは, ホストオペレーティングシステムによるアサーションに依存せず, ホストアドレスに基づく信頼を置かず, ネットワーク上のすべてのホストの物理的セキュリティを必要とせず, ネットワーク上を移動するパケットが自由に読み取られ, 変更され, 挿入される可能性があるという前提の下で実現されます。Kerberos は, これらの条件下で, 従来型 (共有秘密鍵) 暗号化を使用して信頼できる第三者認証サービスとして認証を実行します。Kerberos への拡張 (この文書の範囲外) は, 認証プロトコルの特定のフェーズで公開鍵暗号化の使用を提供できます。そのような拡張は, 公開鍵認証局に登録されたユーザーの Kerberos 認証をサポートし, 必要な状況で公開鍵暗号化の特定の利点を提供します。

基本的な Kerberos 認証プロセスは次のように進行します: クライアントは, 特定のサーバーの "credentials (資格情報)" を認証サーバー (AS) に要求を送信します。AS は, クライアントの鍵で暗号化されたこれらの資格情報で応答します。資格情報は, サーバーの "ticket (チケット)" と一時的な暗号化鍵 (しばしば "session key (セッション鍵)" と呼ばれる) で構成されます。クライアントは, チケット (クライアントの識別情報とセッション鍵のコピーを含み, すべてサーバーの鍵で暗号化されている) をサーバーに送信します。セッション鍵 (現在クライアントとサーバーで共有されている) は, クライアントを認証するために使用され, オプションでサーバーを認証するためにも使用できます。また, 両者間のさらなる通信を暗号化するため, またはさらなる通信を暗号化するために使用される別個のサブセッション鍵を交換するために使用できます。多くのアプリケーションは, ストリームベースのネットワーク接続の開始時にのみ Kerberos の機能を使用することに注意してください。アプリケーションがデータストリームに対して暗号化または完全性保護を実行しない限り, 識別情報の検証は接続の開始にのみ適用され, 接続上の後続のメッセージが同じ principal から発信されることを保証しません。

基本プロトコルの実装は, 物理的に安全なホスト上で実行される1つ以上の認証サーバーで構成されます。認証サーバーは, principals (すなわち, ユーザーとサーバー) とその秘密鍵のデータベースを維持します。コードライブラリは暗号化を提供し, Kerberos プロトコルを実装します。トランザクションに認証を追加するために, 典型的なネットワークアプリケーションは, 直接または別の文書 [RFC4121] で説明されている Generic Security Services Application Programming Interface (GSS-API) を通じて Kerberos ライブラリへの呼び出しを追加します。これらの呼び出しにより, 認証を実現するために必要なメッセージの送信が行われます。

Kerberos プロトコルは, いくつかのサブプロトコル (または交換) で構成されています。クライアントが Kerberos サーバーに資格情報を要求できる基本的な方法は2つあります。最初のアプローチでは, クライアントは希望するサーバーのチケットの平文リクエストを AS に送信します。応答は, クライアントの秘密鍵で暗号化されて送信されます。通常, このリクエストは ticket-granting ticket (TGT) のためのものであり, これは後で ticket-granting server (TGS) と共に使用できます。2番目の方法では, クライアントは TGS にリクエストを送信します。クライアントは, Kerberos 認証を必要とする他のアプリケーションサーバーに接続しているかのように, TGT を使用して TGS に対して自身を認証します。応答は TGT のセッション鍵で暗号化されます。プロトコル仕様は AS と TGS を別個のサーバーとして記述していますが, 実際には単一の Kerberos サーバー内の異なるプロトコルエントリポイントとして実装されています。

取得された後, 資格情報はトランザクション内の principals の識別情報を検証するため, それらの間で交換されるメッセージの完全性を保証するため, またはメッセージのプライバシーを保持するために使用できます。アプリケーションは, 必要な保護を自由に選択できます。

トランザクション内の principals の識別情報を検証するために, クライアントはチケットをアプリケーションサーバーに送信します。チケットは "平文で" 送信されるため (その一部は暗号化されていますが, この暗号化はリプレイを阻止しません), 攻撃者によって傍受され再利用される可能性があるため, メッセージがチケットが発行された principal から発信されたことを証明するための追加情報が送信されます。この情報 (authenticator と呼ばれる) はセッション鍵で暗号化され, タイムスタンプを含みます。タイムスタンプは, メッセージが最近生成されたものであり, リプレイではないことを証明します。authenticator をセッション鍵で暗号化することで, セッション鍵を所有する当事者によって生成されたことが証明されます。要求する principal とサーバー以外の誰もセッション鍵を知らないため (ネットワーク上で平文で送信されることはありません), これはクライアントの識別情報を保証します。

principals 間で交換されるメッセージの完全性も, セッション鍵 (チケットで渡され, 資格情報に含まれる) を使用して保証できます。このアプローチは, リプレイ攻撃とメッセージストリーム変更攻撃の両方の検出を提供します。これは, クライアントのメッセージの衝突耐性チェックサム (他の場所ではハッシュまたはダイジェスト関数と呼ばれる) を生成して送信し, セッション鍵でキー付けすることによって実現されます。principals 間で交換されるメッセージのプライバシーと完全性は, チケットに含まれるセッション鍵または authenticator に含まれるサブセッション鍵を使用して渡されるデータを暗号化することによって保護できます。

上記の認証交換には, Kerberos データベースへの読み取り専用アクセスが必要です。ただし, 新しい principals を追加したり principal の鍵を変更したりする場合など, データベースのエントリを変更する必要がある場合があります。これは, クライアントと3番目の Kerberos サーバーである Kerberos Administration Server (KADM) 間のプロトコルを使用して行われます。Kerberos データベースの複数のコピーを維持するためのプロトコルもあります。これらのプロトコルのいずれもこの文書では説明されていません。

📊 翻訳品質チェック

📍 現在の進捗

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

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

📊 翻訳品質チェック​

📍 現在の進捗​

📊 翻訳品質チェック

📍 現在の進捗