Kerberos は、オープンで(保護されていないネットワーク上において、プリンシパル（ユーザやサーバー）の身元を確認する手段を提供します。これは、ホストの OS（オペレーティングシステム）による認証に頼ることなく、また、ホスト アドレスに信頼をおくことなく、ネットワーク上の全てのホストの物理的なセキュリティも要求せずに、ネットワーク上を流れるパケットが自由に読み取り、修正および挿入 できるという仮定に基づいて実現されています。 (ただし、多くのアプリケー ションは、ストリームベースのネットワーク接続の開始時だけ Kerberos の機能を使用し、そのような接続を破壊する「ハイジャッカー」がいないと想定しています。そのような使用では、含まれているホスト アドレスを 暗黙的に信頼していることになります。）Kerberos は、共有秘密鍵のような一般的な暗号化方式を使用して、信頼のおける第三者機関の条件下で認証を行います (共有秘密鍵 - 「秘密」と「プライベート」という語句は、しばしば同じ意味で使われますが、我々は、「秘密」を 2人、またはそれ以上が共有できると考えています。つまり、共有 DES 鍵は秘密鍵です。それに対して、所有者だけが知っている情報を「プライベート」といいます。したがって、パブリックな鍵暗号法には、パブリック鍵とプライベート鍵が存在します)。認証プロセスは、次のように行われます。： クライアントは、AS（(認証サーバー）に特定のサーバーへの「信任状（credentials）」を要求します。AS は、これらの信任状をクライアントの鍵で暗号化して応答します。信任状は、1) サーバー用のチケットと 2) 一時的な暗号鍵 (「セッション鍵」とも呼ばれる) によって構成されています。クライアントは、チケット (サーバーの鍵で暗号化された、クライアントの ID とセッション鍵のコピーを含む) をサーバーに転送します。これらのセッション鍵 (この時点でクライアントとサーバーで共有されている) は、クライアントを認証するために使用されます。また、サーバーを認証するために使用することもできます。さらに、2つの主体間の通信内容を暗号化するのに使用したり、通信内容を暗号化するのに使用する独立したサブセッション鍵を交換するためにも使用できます。
実装は、物理的に安全なホスト上で実行されている 1つまたは複数の認証サーバーで構成されます。認証サーバーは、プリンシパルのデータベース (ユーザとサーバー) とそれらの秘密鍵を維持します。コード ライブラリは、暗号を提供し、Kerberos プロトコルを実装します。トランザクションに認証を追加するために、一般的なネットワーク アプリケーションは Kerberos ライブラリに 1つまたは 2つのコールを追加します。これによって、認証を実現するために必要なメッセージが転送されます。
Kerberos プロトコルは、いくつかのサブプロトコル (または交換) によって構成されています。クライアントが Kerberos サーバーに信任状を要求する方法には、2つの方法があります。1 番目の方法において、クライアントは、希望するサーバー用のチケットの平文の要求を AS に送信します。応答は、クライアントの秘密鍵で暗号化されて送信されます。通常、この要求は、TGT（チケット交付チケット）用のもので、これは、後で TGT（チケット 交付サーバー）において使用することができます。2番目の方法において、クライアントは、TGS に要求を送信します。そして、クライアントは、Kerberos の信任状を要求する他のアプリケーション サーバーと連絡を取るのと同じ方法で TGS に TGT を送信します。応答は、TGT のセッション鍵で暗号化されます。
任状は、いったん取得すれば、トランザクション内のプリンシパルの ID の検証、それらの間で交換されるメッセージのインテグリティ（完全性）の保証、またはメッセージのプライバシーを保護するために使用できます。アプリケーションは、必要なあらゆる保護を選択できます。
トランザクション内のプリンシパルの ID を検証するために、クライアントは、サーバーにチケットを転送します。チケットは「クリアな状態」で送信 されるため、(部分的には暗号化されていますが、この暗号化はリプレイを妨害しません) 攻撃者によって横取りされ再利用される可能性があるので追加情報が送信されます。この情報は、チケットが発行されたプリンシパルによって作成されたメッセージであることを証明します。この情報は 、認証子と呼ばれ、セッション鍵によって暗号化され、タイムスタンプを含んでいます。タイムスタンプは、メッセージが最近生成されたもので、リプレイ (真似) ではないことを保証します。要求しているプリンシパルとサーバー以外は誰もセッション鍵 (これは、クリアな状態ではネットワーク上を送信されません) を知らないため、これによってクライアントの ID が保証されます。
プリンシパル間のメッセージ交換のインテグリティ（完全性）は、セッション鍵 (チケットで渡され、信任状に含まれている) を使っても保証できます。これを使えば、 リプレイ攻撃とメッセージ ストリーム修正攻撃の両方を検出できます。 これは、セッション鍵で鍵付きにされたクライアントのメッセージの 耐衝突性チェックサム (ハッシュ機能、またはダイジェスト機能とも呼ばれる) を生成し、転送することで実現できます。プリンシパル間で交換された メッセージのプライバシーとのインテグリティは、チケットで渡された信任状に 含まれていたセッション鍵を使用し、渡すデータを暗号化することで 保護できます。
上記の認証交換を行うには、Kerberos データベースへの読み取り専用アクセス権が必要です。ただし、新しいプリンシパルを追加する場合やプリンシパルの鍵を変更する場合など、場合によってはデータベース内の エントリを修正する必要があります。これは、クライアントと 3番目の Kerberos サーバーである Kerberos 管理サーバー (KADM： Kerberos Administration Server) 間のプロトコルを使用して行います。管理プロトコルについては、この文書では説明していません。Kerberos データベースの複数のコピーを維持するプロトコルもありますが、これは 実装の詳細として考えることができ、異なるデータベーステクノロジを サポートする場合に異なることがあります。
Kerberos プロトコルは、組織間の壁を越えて動作するように設計されています。ある組織のクライアントは、他の組織のサーバーに認証できます。Kerberos サーバーを実行したい各組織は、独自の 「レルム」を確立します。クライアントが登録されているレルムのレルム名は、クライアント名の一部で、終端サービスは要求を引き受けるか否かを決定するためにこれを使用できます。「レルム間」鍵を確立することにより、2 つのレルムの管理者は、ローカル レルムで認証されているクライアントがその認証を遠隔から使えるように許可できます。（(適切なパーミッションを使えば、クライアントは リモートレルム内の独立した名前のプリンシパルの登録を調整でき、 そのレルムのサービスと通常の交換を行うことができます。ただし、クライアント数が少ないとこれは厄介になり、ここで説明するより自動化 された方法が必要になります。）レルム間鍵の交換 (各方向には独立した鍵が使用されます) は、各レルムのチケット交付サービスを他のレルム内のプリンシパルとして登録します。その後、クライアントは、そのローカルのレルムから、リモート レルムの チケット交付サービス用のチケット交付チケットを 取得できるようになります。そのチケット交付チケットが使用されると、リモートのチケット交付サービスは、 レルム間鍵 (通常、独自の TGS 鍵とは異なる) を使用してチケット- グランティング チケットを解読し、それがクライアントの独自の TGS によって発行されたことを確証します。リモートのチケット交付サービスによって発行されたチケットは、クライアントが他のレルムで認証されたことを終端サービスに示します。
2つのレルムがレルム間鍵を共有するか、またはローカル レルムがリモート レルムと通信する中間レルムとレルム間鍵を共有する場合、レルムは他のレルムと通信していることになります。認証パスは、レルム間で通信する場合に転送される一連の中間レルムです。
一般的に、レルムは階層的に編成されています。各レルムは、親と鍵を共有し、各子供と別の鍵を共有します。レルム間鍵が 2つのレルムによって直接共有されていない場合、階層的な編成によって 容易に認証パスを作成できます。階層的な編成を使用していない場合、 レルムの間の認証パスを作成するにはデータベースを参照する必要があります。
一般的にレルムは階層的ですが、代替の認証パス経由でクロスレルム認証を 行う場合、中間レルムは、迂回されることがあります (これらは、2 つのレルム間の通信をより効率的にするために確立されています)。認証プロセスの信頼性を決定するのに、どのレルムが転送されたかを知っておくことは、終端サービスにとって重要です。この決定が容易に行えるように、各チケット内 のフィールドにはクライアントの認証に関係したレルムの名前が含まれています。
Kerberos が正常に機能するためには、いくつかの環境要件があります。
- Kerberos は、「サービス妨害」攻撃には対処できません。これらのプロトコルには、侵入者によって、アプリケーションが正規の認証ステップを実行するのを妨害できる余地があります。そのような攻撃の検出と対処は、管理者とユーザーが行うのが最も適しています (これらの攻撃は、特別な障害ではなく「正常な」システム障害モードのように見えることがあります)。
- プリンシパルは、それらの秘密鍵を秘密にしておかなければなりません。プリンシパルの鍵を盗んだ侵入者は、そのプリンシパルを装ったり、合法的なプリンシパルに対するサーバーになりすまします。
- Kerberos は、「パスワード推測」攻撃には対処できません。ユーザーが簡単なパスワードを使用している場合、攻撃者は解読を繰り返してオフライン ディクショナリ攻撃し、ディクショナリから連続したエントリを取り出し、ユーザーのパスワードから取り出した鍵によって暗号化されているメッセージを取得します。
- ネットワーク上の各ホストのクロックは、他のホストの時刻と「柔軟に (ゆるく) 同期」しているはずです。この同期は、アプリケーション サーバーがリプレイ検出を実行するときに記録の必要性を削減するために使用されます。「柔軟さ」 (ゆるさ) の度合いはサーバーごとに設定できます。ネットワーク上でクロックが同期されている場合、クロック同期プロトコル自体もネットワーク攻撃者から守る必要があります。
- プリンシパル識別子は、短期間では再利用されません。一般的なモードのアクセス制御は、アクセス制御リスト（(ACL）を使用して特定のプリンシパルに許可を与えます。削除したプリンシパルの古い ACL エントリが残っている状態でプリンシパル識別子を再利用すると、新しいプリンシパルは古い ACL エントリで指定されている権利を引き継ぎます。プリンシパル識別子を再利用しなければ、不注意なアクセスの危険性はありません。
本書を通して使われている用語を、次に示します。
認証 要求されたプリンシパルの ID を検証すること。
認証ヘッダー 認証プロセスの一部としてサーバーに提出されるチケットと認証子を含んでいるレコード。
認証パス レルム間で通信しているときに、認証プロセスで転送される一連の中間レルム。
認証子 クライアントとサーバーだけが知っているセッション鍵を使用して最近生成されたことを示す情報を含んでいるレコード。
認定 クライアントがサービスを使用しても良いかどうか、またクライアントがアクセスを許可されているのは どのオブジェクトかを決定するプロセス。また、 それぞれに許可されているアクセスのタイプも決定される。
ケイパビリティ オブジェクトまたはサービスにアクセスするための送信許可を与えるトークン。Kerberos では、認定データ フィールドの内容によりその使用が制限されているチケット。このチケットには、ネットワーク アドレスが含まれていないため、セッション鍵と一緒でなければチケットは使えない。
暗号文 暗号化機能の出力形式。平文は、暗号化により暗号文に変換されます。
クライアント ユーザーの代わりにネットワーク サービスを利用するプロセス。あるサーバーが他のサーバーのクライアントになっていることもあります (例えば、プリント サーバーがファイル サーバーのクライアントになっている場合など)。
信任状 チケットと、秘密のセッション鍵。認証交換においてチケットを使用するのに必要。
KDC 鍵配布センター。チケットおよび一時的なセッション鍵を供給するネットワーク サービス。または、そのサービスのインスタンス、あるいはそれが実行されるホスト。KDC は初回のチケット要求とチケット交付チケット要求の両方を処理します。初回のチケットを処理する部分は、認証サーバー (またはサービス) とも呼ばれ ます。チケット-グランティング チケットを処理する部分は、チケット譲渡サーバー（またはサービス）と呼ばれます。
Kerberos ギリシャ神話に登場する 3 つの頭を持った冥界の番犬のことで、Athena プロジェクトの認証サービス、そのサービスが使用するプロトコル、または認証サービスを実装するためのコードに与えられた名前。
平文 暗号化機能の入力形式、または、解読機能の出力形式。解読とは暗号文を平文に変換することです。
プリンシパル ネットワーク通信に関係する、固有な名前のクライアント インスタンスまたはサーバー インスタンス。
プリンシパル識別子 各プリンシパルを個別に識別するための名前。
封印 複数のフィールドが入っているレコードを暗号化すること。 ただし暗号化の方法として、暗号化鍵を知らなければ各フィールドを個別に変更できないか、または変更したら改ざんの形跡が必ず残るようにしなければならない。
秘密鍵 プリンシパルと KDC が共有する有効期限の長い暗号化鍵。システム領域外で配布される。ユーザーのプリンシパルの場合、秘密鍵はパスワードから取り出される。
サーバー ネットワーク クライアントにリソースを提供する特定のプリンシパル。
サービス ネットワーク クライアントに提供されるリソース。通常は、複数のサーバーから提供される (たとえば、リモート ファイル サービス)。
セッション鍵 2 つのプリンシパル間で使用される一時的な暗号化鍵で、有効期限は単一のログイン「セッション」中に制限されている。
サブセッション鍵 2 つのプリンシパル間で使用される一時的な暗号化鍵で、プリンシパルがセッション鍵を使用して選択／交換する。有効期限は、1 回の交換時間中に制限されている。
チケット クライアントが、サーバーに自分自身を認証させるためのレコード。クライアントの ID 、セッション鍵、タイムスタンプ、および他の情報を含んでいて、サーバーの秘密鍵ですべて封印されている。新しい認証子とともに提出したときだけ、クライアントが認証される。