1. Introduction (はじめに)

この文書は, Kerberos ネットワーク認証システム (Kerberos network authentication system) が基づいている概念とモデルを説明します。また, Kerberos プロトコルのバージョン 5 を規定します。ほとんどの設計上の決定の背後にある動機, 目標, 仮定, および根拠は簡潔に扱われており, それらは IEEE communications で入手可能な論文 [NT94] およびそれ以前の Athena Technical Plan の Kerberos 部分 [MNSS87] でより完全に説明されています。

この文書は, エンドユーザー, システム管理者, またはアプリケーション開発者に Kerberos を説明することを意図したものではありません。Kerberos システムのバージョン 5 を説明する上位レベルの論文 [NT94] およびバージョン 4 を文書化したもの [SNS88] は他の場所で入手可能です。

Kerberos モデルは, 一部は Needham and Schroeder の信頼できる第三者認証プロトコル [NS78] と, Denning and Sacco によって提案された修正 [DS81] に基づいています。Kerberos バージョン 1 から 4 の元の設計と実装は, Project Athena の 2 人の元スタッフメンバーである Digital Equipment Corporation の Steve Miller と Clifford Neuman (現在は University of Southern California の Information Sciences Institute に所属), Project Athena の Technical Director である Jerome Saltzer, および MIT Campus Network Manager である Jeffrey Schiller の仕事でした。Project Athena の他の多くのメンバーも Kerberos の作業に貢献しています。

この文書で説明されている Kerberos プロトコルのバージョン 5 は, バージョン 4 では利用できない機能に対する新しい要件と要望のために進化しました。バージョン 5 の設計は, コミュニティからの多くの入力を得て Clifford Neuman と John Kohl によって主導されました。MIT リファレンス実装の開発は, MIT で John Kohl と Theodore Ts'o によって主導され, 他の多くの人々からの支援と貢献されたコードがありました。RFC 1510 が発行されて以来, 多くの個人がプロトコルへの拡張と改訂を提案しています。この文書はこれらの提案の一部を反映しています。そのような変更が重要な努力を伴った場合, 文書は提案者の貢献を引用しています。

Kerberos のバージョン 4 とバージョン 5 の両方のリファレンス実装は公開されており, 商用実装が開発され広く使用されています。バージョン 4 と 5 の違いの詳細は [KNT94] で見つけることができます。

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は, [RFC2119] で説明されているように解釈されるものとします。

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

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

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

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

Kerberos プロトコルは, いくつかのサブプロトコル (またはエクスチェンジ) で構成されています。クライアントが Kerberos サーバーにクレデンシャルを要求できる 2 つの基本的な方法があります。最初のアプローチでは, クライアントは希望するサーバーのチケットを AS にクリアテキストの要求を送信します。返信はクライアントの秘密鍵で暗号化されて送信されます。通常, この要求はチケット付与チケット (Ticket-Granting Ticket, TGT) のためのもので, これは後でチケット付与サーバー (Ticket-Granting Server, TGS) と共に使用できます。2 番目の方法では, クライアントは TGS に要求を送信します。クライアントは, Kerberos 認証を必要とする他のアプリケーションサーバーに接続する場合と同じ方法で, TGT を使用して TGS に対して自身を認証します。返信は TGT からのセッションキーで暗号化されます。プロトコル仕様は AS と TGS を別個のサーバーとして説明していますが, 実際には単一の Kerberos サーバー内の異なるプロトコルエントリポイントとして実装されています。

クレデンシャルが取得されると, トランザクション内のプリンシパルのアイデンティティを検証するため, それらの間で交換されるメッセージの整合性を保証するため, またはメッセージのプライバシーを保持するために使用されることがあります。アプリケーションは, 必要な保護を自由に選択できます。

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

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

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

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

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

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

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

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

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

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

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

1.3. Choosing a Principal with Which to Communicate (通信するプリンシパルの選択)

Kerberos プロトコルは, (セクション 1.6 の仮定に従って) 通信する相手が, 主張されたアイデンティティ (プリンシパル名) を使用して KDC に登録されたものと同じエンティティであることを検証する手段を提供します。そのアイデンティティが通信しようとしているエンティティに対応するかどうかを判断することは依然として必要です。

適切なデータが事前に交換されている場合, アプリケーションは, アプリケーションプロトコル仕様, ユーザーによって提供された情報, および構成ファイルに基づいてこの判断を構文的に実行できます。たとえば, telnet サーバーのサーバープリンシパル名 (レルムを含む) は, ユーザーが指定したホスト名 (telnet コマンドラインから), アプリケーションプロトコル仕様で指定された "host/" プレフィックス, および指定されたホスト名のドメイン部分とローカル Kerberos レルムデータベースからの情報から構文的に導出された Kerberos レルムへのマッピングから導出される可能性があります。

信頼できる第三者に依存してこの判断を行うこともできますが, 第三者から取得したデータが第三者サーバー上に常駐している間と送信される時に適切に整合性保護されている場合に限ります。したがって, たとえば, 保護されていない DNS レコードに依存してホストエイリアスをサーバーのプライマリ名にマップし, プライマリ名を連絡しようとしている当事者として受け入れるべきではありません。攻撃者がマッピングを変更して当事者になりすますことができるためです。

Kerberos の実装および Kerberos に基づくプロトコルは, サービスプリンシパル名のホスト名コンポーネントを正規化するために安全でない DNS クエリを使用してはなりません (MUST NOT) (つまり, 通信する相手のプリンシパル名のホスト部分を決定するために, ある名前を別の名前にマップするために安全でない DNS クエリを使用してはなりません)。安全な名前サービスのない環境では, アプリケーション作成者は, 名前をセキュリティメカニズムに渡す前に, 非修飾ホスト名に静的に構成されたドメイン名を追加してもよい (MAY) ですが, それ以上のことはすべきではありません。安全な名前サービス機能が利用可能な場合, ホスト名の正規化のために信頼されるかもしれませんが, クライアントによるそのような正規化は KDC 実装によって要求されるべきではありません (SHOULD NOT)。

実装に関する注意: 多くの現在の実装は, セキュリティ問題を引き起こすにもかかわらず, しばしば DNS を使用して提供されたサービス名のある程度の正規化を行います。ただし, サービス名が小文字に折りたたまれるかどうか, または逆引き解決が使用されるかどうかについて, 実装間で一貫性はありません。相互運用性とセキュリティを最大化するために, アプリケーションは, 他の変更や正規化を実行せずにユーザーが入力した名前を小文字に折りたたんだ結果の名前をセキュリティメカニズムに提供すべきです (SHOULD)。

1.4. Authorization (認可)

認証サービスとして, Kerberos はネットワーク上のプリンシパルのアイデンティティを検証する手段を提供します。認証は通常, 認可のプロセスの最初のステップとして主に有用です。認可は, クライアントがサービスを使用できるかどうか, クライアントがアクセスを許可されているオブジェクト, および各オブジェクトに対して許可されているアクセスのタイプを決定します。Kerberos は, それ自体では認可を提供しません。サービスのクライアントチケットの所有は, そのサービスへのクライアントの認証のみを提供し, 別個の認可手順がない場合, アプリケーションはそれをそのサービスの使用を認可するものとみなすべきではありません。

別個の認可方法は, アプリケーション固有のアクセス制御機能として実装されてもよく (MAY), アプリケーションサーバー上のファイル, プロキシに基づくものなど別個に発行された認可クレデンシャル [Neu93], または他の認可サービスを利用できます。別個に認証された認可クレデンシャルは, KDC が発行した認可データ要素によってカプセル化されている場合, チケットの認可データに埋め込まれてもよい (MAY) です。

アプリケーションは, (変更された Kerberos サーバーによるものであっても) Kerberos サーバーによるサービスチケットの単なる発行を, サービスを使用する権限を付与するものとして受け入れるべきではありません。そのようなアプリケーションは, アプリケーション認証の他のオプションが提供されている環境, または他の KDC と相互運用する場合に, この認可チェックのバイパスに対して脆弱になる可能性があるためです。

1.5. Extending Kerberos without Breaking Interoperability (相互運用性を損なわない Kerberos の拡張)

展開された Kerberos 実装のベースが成長するにつれて, Kerberos の拡張はより重要になります。残念ながら, 既存の Kerberos プロトコルへのいくつかの拡張は, 一部の実装による特定の拡張性オプションの扱いに関する不確実性のために相互運用性の問題を引き起こします。このセクションには, 将来の実装が相互運用性を維持できるようにするガイドラインが含まれています。

Kerberos は, プロトコルの拡張性のための一般的なメカニズムを提供します。一部のプロトコルメッセージには型付きホール (typed holes) が含まれています。これは, オクテット文字列とそのオクテット文字列の解釈方法を定義する整数を含むサブメッセージです。整数型は一元的に登録されていますが, ベンダー拡張と IETF を通じて標準化された拡張の両方に使用できます。

この文書では, "拡張 (extension)" という言葉は, プロトコルメッセージ内の既存の型付きホールに挿入する新しい型を定義することによる拡張を指します。テキストが明示的に示さない限り, ASN.1 型への新しいフィールドの追加による拡張を指すものではありません。

1.5.1. Compatibility with RFC 1510 (RFC 1510 との互換性)

既存の Kerberos メッセージフォーマットは, ASN.1 型にフィールドを追加することによって容易に拡張できないことに注意してください。追加のフィールドを送信すると, しばしばエラー表示なしでメッセージ全体が破棄されます。この仕様の将来のバージョンでは, 相互運用性の問題を引き起こすことなく ASN.1 フィールドを追加できるようにするガイドラインが提供されます。

その間, 未知のメッセージ拡張を受信する Kerberos のすべての新規または変更された実装は, 拡張のエンコーディングを保持すべきです (SHOULD) が, その存在を無視してください。受信者は, 拡張が存在するという理由だけで要求を拒否してはなりません (MUST NOT)。

このルールには 1 つの例外があります。未知の認可データ要素タイプが, AP-REQ 内または AP-REQ に含まれるチケット内のいずれかで, チケット付与サービス以外のサーバーによって受信された場合, 認証は失敗しなければなりません (MUST)。認可データの主な用途の 1 つは, チケットの使用を制限することです。サービスが制限がそのサービスに適用されるかどうかを判断できない場合, チケットがそのサービスに使用できる場合にセキュリティ上の弱点が生じる可能性があります。オプションの認可要素は, AD-IF-RELEVANT 要素に囲まれるべきです (SHOULD)。

チケット付与サービスは, 未知の認可データ型を無視しなければなりませんが (MUST), それらのデータ型が MANDATORY-FOR-KDC 要素に埋め込まれている場合を除いて, 派生チケットに伝播します。その場合, 要求は拒否されます。この動作は適切です。なぜなら, チケット付与サービスが未知の認可データ型を理解することを要求すると, アプリケーションがこれらの制限を使用する前に, 新しいアプリケーションレベルの制限を理解するために KDC ソフトウェアをアップグレードする必要があり, チケットの使用を制限するメカニズムとしての認可データの有用性が低下するためです。チケットが発行されるサービスが認可データを検証するため, セキュリティ上の問題は発生しません。

実装に関する注意: 多くの RFC 1510 実装は, 未知の認可データ要素を無視します。これらの実装に依存して認可データ制限を尊重させることは, セキュリティ上の弱点を引き起こす可能性があります。

1.5.2. Sending Extensible Messages (拡張可能なメッセージの送信)

古い実装が, 使用される拡張を理解していなくても, 送信されたメッセージを理解できるようにするために注意を払う必要があります。送信者が拡張がサポートされていることを知らない限り, 拡張はコアメッセージまたは以前に定義された拡張のセマンティクスを変更できません。

たとえば, KDC-REP の暗号化された部分を復号化するために必要なキー情報を含む拡張は, 受信者が拡張をサポートすることが知られている状況でのみ使用できます。したがって, そのような拡張を設計する際には, 受信者が送信者に拡張のサポートを通知する方法を提供することが重要です。たとえば, KDC-REP 応答キーを変更する拡張の場合, クライアントは AS-REQ シーケンスに padata 要素を含めることによって拡張のサポートを示すことができます。KDC は, この padata 要素が AS-REQ に存在する場合にのみ拡張を使用すべきです。ポリシーが拡張の使用を要求する場合でも, 受信者がサポートしていない可能性がある時に拡張を使用するよりも, 拡張が必要であることを示すエラーを返す方が良いです。相互運用しない実装のデバッグは, エラーが返される場合の方が簡単です。

1.6. Environmental Assumptions (環境上の仮定)

Kerberos は, 正しく機能できる環境に関していくつかの仮定を課しています。これには以下が含まれます:

"サービス拒否 (Denial of service)" 攻撃は Kerberos では解決されません。侵入者がアプリケーションが適切な認証ステップに参加するのを妨げることができるプロトコル内の場所があります。そのような攻撃の検出と解決 (その一部はシステムの珍しくない "通常の" 障害モードのように見える可能性があります) は, 通常, 人間の管理者とユーザーに任せるのが最善です。
プリンシパルは秘密鍵を秘密にしておかなければなりません (MUST)。侵入者が何らかの方法でプリンシパルのキーを盗んだ場合, そのプリンシパルになりすますことができるか, または正当なプリンシパルに対して任意のサーバーになりすますことができます。
"パスワード推測 (Password guessing)" 攻撃は Kerberos では解決されません。ユーザーが貧弱なパスワードを選択した場合, 攻撃者がユーザーのパスワードから導出されたキーで暗号化されたメッセージを取得し, 辞書からの連続するエントリで繰り返し復号化を試みることによって, オフライン辞書攻撃を成功裏に実行することが可能です。
ネットワーク上の各ホストは, 他のホストの時刻に "緩く同期された" 時計を持っていなければなりません (MUST)。この同期は, リプレイ検出を行う際のアプリケーションサーバーの帳簿管理のニーズを減らすために使用されます。"緩さ" の程度はサーバーごとに構成できますが, 通常は 5 分程度です。時計がネットワーク経由で同期されている場合, 時計同期プロトコル自体がネットワーク攻撃者から保護されなければなりません (MUST)。
プリンシパル識別子は短期的には再利用されません。典型的なアクセス制御モードは, アクセス制御リスト (Access Control Lists, ACLs) を使用して特定のプリンシパルに権限を付与します。削除されたプリンシパルの古い ACL エントリが残っていてプリンシパル識別子が再利用された場合, 新しいプリンシパルは古い ACL エントリで指定された権利を継承します。プリンシパル識別子を再利用しないことにより, 不注意によるアクセスの危険が除去されます。

1.7. Glossary of Terms (用語集)

以下は, この文書全体で使用される用語のリストです。

Authentication (認証) : プリンシパルの主張されたアイデンティティを検証すること。

Authentication header (認証ヘッダー) : 認証プロセスの一部としてサーバーに提示される Ticket と Authenticator を含むレコード。

Authentication path (認証パス) : あるレルムから別のレルムへの通信時に認証プロセスで通過される中間レルムのシーケンス。

Authenticator (認証子) : クライアントとサーバーのみが知っているセッションキーを使用して最近生成されたことを示すことができる情報を含むレコード。

Authorization (認可) : クライアントがサービスを使用できるかどうか, クライアントがアクセスを許可されているオブジェクト, および各オブジェクトに対して許可されているアクセスのタイプを決定するプロセス。

Capability (ケーパビリティ) : 保持者にオブジェクトまたはサービスへのアクセス許可を付与するトークン。Kerberos では, これは認可データフィールドの内容によって使用が制限されているが, ネットワークアドレスがリストされていないチケットと, チケットを使用するために必要なセッションキーの組み合わせである可能性があります。

Ciphertext (暗号文) : 暗号化関数の出力。暗号化は平文を暗号文に変換します。

Client (クライアント) : ユーザーに代わってネットワークサービスを利用するプロセス。場合によっては, Server 自体が他のサーバーの Client である可能性があることに注意してください (例えば, プリントサーバーはファイルサーバーの Client である可能性があります)。

Credentials (クレデンシャル) : チケットと, 認証交換でそのチケットを正常に使用するために必要な秘密セッションキー。

Encryption Type (etype) (暗号化タイプ) : 暗号化されたデータに関連付けられている場合, 暗号化タイプはデータの暗号化に使用されたアルゴリズムを識別し, データを復号化するための適切なアルゴリズムを選択するために使用されます。暗号化タイプタグは, 当事者間のデータの暗号化に使用されることが望ましい, サポートされている, 優先される, または許可されているアルゴリズムを列挙するために他のメッセージで通信されます。この優先順位は, ローカル情報とポリシーと組み合わされて, 使用するアルゴリズムを選択します。

KDC : Key Distribution Center (鍵配布センター)。チケットと一時的なセッションキーを提供するネットワークサービス, またはそのサービスのインスタンスまたはそれが実行されているホスト。KDC は初期チケットとチケット付与チケットの両方の要求にサービスを提供します。初期チケット部分は, Authentication Server (または service) と呼ばれることがあります。チケット付与チケット部分は, Ticket-Granting Server (または service) と呼ばれることがあります。

Kerberos : Project Athena の認証サービス, そのサービスで使用されるプロトコル, または認証サービスを実装するために使用されるコードに付けられた名前。この名前は, ハデスを守る三つ頭の犬から採用されています。

Key Version Number (kvno) (キーバージョン番号) : プリンシパルに関連付けられた長期的なキーが時間の経過とともに変化する場合に, どのキーが暗号化に使用されたかを識別する暗号化されたデータに関連付けられたタグ。これは新しいキーへの移行中に使用され, メッセージを復号化する当事者がデータが古いキーで暗号化されたのか新しいキーで暗号化されたのかを判断できるようにします。

Plaintext (平文) : 暗号化関数への入力または復号化関数の出力。復号化は暗号文を平文に変換します。

Principal (プリンシパル) : ネットワーク通信に参加する名前付きクライアントまたはサーバーエンティティであり, 正規と見なされる 1 つの名前を持ちます。

Principal identifier (プリンシパル識別子) : 各異なるプリンシパルを一意に識別するために使用される正規名。

Seal (シール) : 暗号化キーの知識なしに, またはタンパリングの証拠を残さずに, フィールドを個別に置き換えることができないように, 複数のフィールドを含むレコードを暗号化すること。

Secret key (秘密鍵) : プリンシパルと KDC によって共有され, システムの境界外で配布され, 長い寿命を持つ暗号化キー。人間のユーザーのプリンシパルの場合, 秘密鍵はパスワードから導出されてもよい (MAY) です。

Server (サーバー) : ネットワーククライアントにリソースを提供する特定のプリンシパル。サーバーは Application Server と呼ばれることもあります。

Service (サービス) : ネットワーククライアントに提供されるリソース。多くの場合, 複数のサーバーによって提供されます (例えば, リモートファイルサービス)。

Session key (セッションキー) : 2 つのプリンシパル間で使用される一時的な暗号化キーであり, 単一のログイン "セッション" の期間に制限された寿命を持ちます。Kerberos システムでは, セッションキーは KDC によって生成されます。セッションキーは, 次に説明するサブセッションキーとは異なります。

Sub-session key (サブセッションキー) : 2 つのプリンシパル間で使用される一時的な暗号化キーであり, セッションキーを使用してプリンシパルによって選択および交換され, 単一のアソシエーションの期間に制限された寿命を持ちます。サブセッションキーは subkey とも呼ばれます。

Ticket (チケット) : クライアントがサーバーに対して自身を認証するのを助けるレコード。クライアントのアイデンティティ, セッションキー, タイムスタンプ, およびその他の情報を含み, すべてサーバーの秘密鍵を使用してシールされています。新しい Authenticator と一緒に提示された場合にのみ, クライアントを認証するのに役立ちます。