Kerberos サーバーは、認証するプリンシパルのプリンシパル識別子と秘密鍵を含んでいるデータベースにアクセスできなければなりません (Kerberos サーバーの実装は、データベースとサーバーを同じマシン上に組み合わせる必要はありません。保存されている要素が許可されていない団体への開示とそれらによる修正から保護されている場合、プリンシパルのデータベースをネットワークのネーム サービスなどに保存できます。ただし、この方法では、システム管理と脅威分析が比較的複雑になるため、あまりお薦めしません。
データベース要素には、少なくとも以下のフィールドが入っている必要があります。
フィールド 値 name プリンシパルの識別子 key プリンシパルの秘密鍵 p_kvno プリンシパルの鍵のバージョン max_life チケットの最大有効期限 max_renewable_life 更新可能なチケットの最大合計有効期限
名前フィールドは、プリンシパルの識別子を符合化したものです。鍵フィールドは、暗号化鍵を含んでいます。この鍵は、プリンシパルの秘密鍵です(この鍵は、データベースが漏洩し、マスター鍵が漏洩していない場合に保護できるように、Kerberos の「マスター鍵」に格納する前に暗号化できます。その場合、使用するマスター鍵のバージョンを示すフィールドを追加しなければなりません。これについては以下を参照のこと)。p_kvno フィールドには、プリンシパルの秘密鍵のバージョン番号が入っています。max_life フィールドには、このプリンシパル用に発行されたあらゆるチケットの許容最大有効期限 (endtime から starttime を減算した値) が入っています。max_renewable_life フィールドには、このプリンシパル用に発行されたあらゆる更新可能なチケットの許容最大合計有効期限が入っています (特定のチケットの有効期限を決定するのに、これらの有効期限がどのように使用されるかについては、3.1 を参照してください)。
レルム名だけが異なるプリンシパル レコードどうしを判別できる機能がデータベースにある限りは、KDC サービスを 1台のサーバーで複数のレルムに提供できます。
アプリケーション サーバーの鍵が (古い鍵が外部に漏れたためではなく) 定期的に変更されている場合、その鍵を使って発行されたすべてのチケットの有効期間が満了するまで、サーバーは古い鍵を保管する必要があります。このため、1つのプリンシパルに対して複数の鍵が有効になることもあります。プリンシパル鍵で暗号化された暗号文は、受領者が 復号により適切な鍵を見つけられるように、暗号化に使われた鍵のバージョンが常にタグ付けされています。
1 つのプリンシパルに対し複数の鍵が有効な場合、プリンシパルは Kerberos データベースに 2 つ以上のレコードがあります。鍵と、鍵のバージョン番号は、レコードによって異なります (それ以外のフィールドは、同じ場合もあれば異なる場合もあります)。Kerberos がチケットを発行する場合、または初回の認証要求に応答する場合、暗号化には常に最新の鍵 (Kerberos サーバーが知っている) が使用されます。この鍵は、最新の (もっともバージョン番号が大きい) 鍵です。
Athena プロジェクトの KDC 実装は、データベース内で追加フィールドを使用します。
フィールド 値 値 K_kvno Kerberos の鍵バージョン expiration エントリの満了日 attributes 属性のビット フィールド mod_date 最後に行われた修正のタイムスタンプ mod_name プリンシパルの識別子の修正
K_kvno フィールドは、プリンシパルの秘密鍵を暗号化するのに使用する Kerberos のマスター鍵の鍵バージョンを示します。
エントリの満了日が過ぎると、KDC はプリンシパルとして、またはプリンシパル用にチケットを取得しようとするあらゆるクライアントにエラーを返します (データベースは、2 つの満了日が必要な場合があります。1 つはプリンシパル用で、もう 1つは、プリンシパルの現在の鍵用です。これにより、パスワードのエイジングが、プリンシパルの満了日と独立して機能するようにできます。ただし、応答の領域が制限されているため、KDC は鍵の満了日とプリンシパルの満了日を key_exp という 1 つの値に組み合わせる必要があります。この key_exp は、ユーザに管理の実行を促すヒントとして使用されます)。
属性フィールドは、プリンシパルを含む操作を統括するのに使用するビットフィールドです。このフィールドは、ユーザの登録処理とともに使用したり (Athena プロジェクトでは、現在これをシステム全体のデータベース サービスである Moira [7] で制御したユーザ登録処理で使用しています)、プリンシパルの鍵で使用される「文字列から鍵」の変換アルゴリズムを識別するのに便利です (これが便利である理由については、5.4.2 の padata フィールドの説明を参照してください)。他のビットは (各ビットごとに)、プリンシパルの鍵を使用して暗号化されたチケットにおいて、特定のチケット オプションが使用できないことを示します。たとえば先付け日付のチケット、転送可能チケット、TGT 認証に基づいたチケット、更新可能なチケット、代理可能チケット、プリンシパルがサーバーであるチケットなどの発行を禁止します。
mod_date フィールドには、エントリの最終修正時刻が入っており、mod_name フィールドはエントリを最後に修正したプリンシパルの名前を含んでいます。
KDC によっては、特定のプリンシパルが前回要求を作成した時刻を維持したい場合があります。維持される情報には、最後の要求の時刻、チケット交付チケットを要求した最後の時刻、チケット 交付チケットを使用した最後の時刻、または他の時刻などがあります。この情報は、last-req フィールドを使用して、その後ユーザに返すことができます (5.2 を参照のこと)。
頻繁に変更されながら、維持が可能な他の情報は、各鍵を使用して発行されたチケットの最終有効期間満了時刻です。このフィールドは、重要なチケットの継続使用を許可するため、古い鍵がいつまで有効かを示すのに使用します。
KDC の実装は、管理者がポリシーを決定し、強化できるように、以下の設定可能な定数またはオプションがなければなりません。
- サポートされている最小有効期限 (KDC_ERR_NEVER_VALID エラーを返すかどうかを決定するのに使用)。この定数は、一周して KDC へ戻ってくるまでの時間、暗号化／複合化時間、クライアントとターゲット サーバーの処理時間、および最小有効有効期限の適切な見込み値を示します。
- チケットの最大許容合計 (更新可能) 有効期限 (renew_till から starttime を減算した値)
- チケットの最大許容有効期限 (endtime から starttime を減算した値)
- アドレス フィールドが空のチケットの発行を許可するかどうか (要求がいくつかの authorization_data を指定している場合だけ、それらのチケットが発行されることを指定できることを含む)
- 代理可能チケット、転送可能チケット、更新可能なチケット、または先付け日付が付けられるチケットが発行できるかどうか。