以下の節においては、「ネットワーク クライアントとサーバー間の交換」および「それらの交換で行われるメッセージ」について説明します。
要約
メッセージの方向 メッセージのタイプ 掲載節 1. クライアントから Kerberos KRB_AS_REQ 5.4.1 2. Kerberos からクライアント KRB_AS_REP または
KRB_ERROR5.4.2
5.9.1
クライアントと Kerberos 認証サーバーの間の認証サービス（AS）交換は、通常、クライアントが特定のサーバーの認証信任状を取得したいが、信任状を持っていないときに開始されます。クライアントの秘密鍵は、暗号化と復号に使用されます。この交換は、一般的にはログイン セッションの開始時に、チケット交付サーバー用の信任状を取得するために使用されます。この信任状は、クライアントの秘密鍵をそれ以降要求することなく、他のサーバーの信任状を取得するために 後で使用されます (3.3 節参照)。この交換は、パスワード変更サービスのように、チケット交付サービスを仲介せず、プリンシパルの秘密鍵を要求するサービスの信任状を要求しなければならない場合にも使用します。(パスワード変更要求は、要求者が古いパスワード (ユーザの現在の秘密鍵) を提供するまで受領してはいけません。そうでないと、誰かが、ユーザがその場にいないセッションのところへ行き、別のユーザのパスワードを変更できてしまいます。）この交換自体は、ユーザの ID について、いかなる保証もしていません (ローカル システムにログインしているユーザを認証するには、AS 交換で取得した信任状を TGS 交換で最初に使用して、ローカル サーバーの信任状を取得します。それらの信任状は、クライアント／サーバー交換の正常な完了を通じてローカル サーバーによって検証されなければなりません)。
交換は、次の 2 つのメッセージで構成されています。クライアントから Kerberos への KRB_AS_REQ、および応答内の KRB_AS_REP または KRB_ERROR。これらのメッセージの形式については、5.4.1、5.4.2、および 5.9.1 節で説明しています。
要求では、クライアントは自分自身の ID と、信任状を要求しているサーバーの ID をクリアテキストで送信します。応答 KRB_AS_REP は、クライアントがサーバーに提出するチケットと、クライアントとサーバーが共有するセッション鍵を含んでいます。セッション鍵と詳細情報は、クライアントの秘密鍵で暗号化されています。KRB_AS_REP メッセージには、リプレイを検出するのに使用したり、応答対象のメッセージとの関連付けに使う情報が入っています。さまざまなエラーが発生する可能性がありますが、そのエラー メッセージは、 KRB_AS_REP 応答ではなく、エラー応答 (KRB_ERROR) で示されます。エラー メッセージは暗号化されません。KRB_ERROR メッセージにも、応答対象のメッセージとの関連付けを行う情報が入っています。KRB_ERROR メッセージは暗号化されていないため、リプレイや、リプレイの偽造メッセージは検出できません。
通常、認証サーバーには、クライアントが実際に要求で名前が指定されたプリンシパルであるかどうかは分りません。同一か否かに関わらず、単に応答を送信します。要求に指定されている ID のプリンシパルだけが応答を使用できるので、これで問題はありません。重要な情報は、そのプリンシパルの鍵で暗号化されています。初回の要求は、初回の交換で必要となるかもしれない詳細情報を渡す ために使用できるオプションのフィールドをサポートしています。このフィールドは、事前認証に使用することもできますが、現時点ではそのメカニズムは設定されていません。
クライアントは、初回の要求で複数のオプションを指定できます。これらのオプションとは、事前認証を実行するかどうか、要求したチケットを更新／代理／転送可能にするかどうか、先付け日付にするかどうか、または派生チケットを先付け日付にできるようにするどうか、要求したチケット満了日が更新不可能なチケットによって満足されない場合に、更新不可能なチケットの代わりに更新可能なチケットを受け付けるかどうかなどです (設定の制約による。第 4 節参照)。擬似コードについては、A.1 を参照してください。
クライアントは KRB_AS_REQ メッセージを準備し、それを KDC に送信します。
すべてが順調に進んだ場合、KRB_AS_REQ メッセージを処理することによって、クライアントがサーバーに提出するチケットが作成されます。チケットの形式については、5.3.1 節を参照してください。チケットの内容は、以下のようになっています。
認証サーバーは、KRB_AS_REQ で指定されているクライアントとサーバーのプリンシパルをデータベース内で検索し、それぞれの鍵を取り出します。要求された場合、サーバーは要求を事前認証します。事前認証検査が失敗した 場合、コード KDC_ERR_PREAUTH_FAILED のエラー メッセージが返されます。サーバーが要求した暗号化タイプに適応できない場合、コード KDC_ERR_ETYPE_NOSUPP のエラー メッセージが返されます。適応できる場合、「ランダムな」セッション鍵を生成します (この「ランダム」とは、過去のセッション鍵の情報に基づいても次のセッション鍵を予想できないことを意味します。擬似ランダム番号ジェネレータが暗号法プリンシパルに基づいている場合だけこれを実行できます。ランダムな物理現象の測定に基づいた、真のランダム番号ジェネレータを使用したほうがより望ましい結果が得られます。
要求で開始時刻を指定しなかった場合、または過去の時刻を指定した場合、チケットの開始時刻は認証サーバーの現在の時刻に設定されます。将来の時刻を指定したが、POSTDATED オプションを指定していない場合、エラー KDC_ERR_CANNOT_POSTDATE が返されます。そうでない場合、要求した開始時刻は、ローカル レルムのポリシーに照らして検査され (管理者は、このようなタイプ、または範囲の以後の日付のチケットを禁止することがあります)、それが許容できるものである場合、チケットの開始時刻は要求どおりに設定され、新しいチケットに INVALID フラグが設定されます。以後の日付のチケットは、開始時刻後に KDC に提出して、使用する前に有効にしなければなりません。
チケットの満了時刻は、以下のうちの最小値に設定されます。：
- KRB_AS_REQ メッセージで要求した満了時刻 (endtime)。
- チケットの開始時刻と、クライアント プリンシパルの許容最大有効期限の加算値 (認証サーバーのデータベースは、各プリンシパルのレコードにチケットの最大有効期限フィールドを含んでいます。第 4 章を参照のこと)。
- チケットの開始時刻と、サーバーのプリンシパルの最大許容有効期限の加算値。
- チケットの開始時刻と、ローカル レルムのポリシーによって設定されている最大許容有効期限の加算値。
要求した満了時刻から開始時刻 (上記で説明している) を減算した値がサイトで決定されている最小有効期限よりも小さい場合、コード KDC_ERR_NEVER_VALID のエラー メッセージが返されます。チケットの要求した満了時刻が上記で説明している値よりも大きくて、RENEWABLE-OK オプションを要求した場合、新しいチケットに RENEWABLE フラグが設定され、renew-till 値は RENEWABLE オプションを要求したときのように設定されます (フィールドとオプション名の詳細については、5.4.1 節で説明しています)。RENEWABLE オプションを要求したか、RENEWABLE-OK オプションを設定して更新可能なチケットを発行した場合、renew-till フィールドは以下のうちの最小値に設定されます。：
- 要求した値
- チケットの開始時刻と、プリンシパルのデータベース エントリの 2 つの更新可能最大有効期限の最小値を加算した値
- チケットの開始時刻と、ローカル レルムのポリシーによって設定された更新可能最大有効期限を加算した値
FORWARDABLE、MAY-POSTDATE、POSTDATED、PROXIABLE、または RENEWABLE オプションを要求して、ローカル レルムのポリシーがそれを許可した場合、新しいチケットのフラグ フィールドにそれらが設定されます。新しいチケットの日付が先付け日付になっている場合 (つまり、開始時刻が将来である場合)、INVALID フラグも設定されます。
上記のすべてが正常に行われた場合、サーバーは KRB_AS_REP メッセージを作成し (5.4.2 節参照)、要求内のアドレスを応答の caddr にコピーし、要求したあらゆる事前認証データを応答の padata に入れ、要求した暗号化方式を使用してクライアントのキー内の暗号文部分を暗号化し、それをクライアントに送信します。擬似コードについては A.2 を参照してください。
いくつかのエラーが発生することがあり、認証サーバーはクライアントに、error-code と e-text フィールドが適切な値に設定されたエラー メッセージ KRB_ERROR を返して応答します。エラー メッセージの内容と詳細については、5.9.1 節を参照してください。
応答メッセージのタイプが KRB_AS_REP の場合、クライアントは、応答のクリアテキスト部分の cname と crealm フィールドが要求と一致するかどうか検証します。padata フィールドが存在する場合、メッセージを復号するための秘密鍵を取り出すのに使用されます。クライアントは、秘密鍵を使用して応答の暗号化部分を復号し、暗号化部分の nonce が要求で提供された nonce と一致するかどうかを確認します (リプレイを検出するために)。また、応答と要求の sname と srealm が一致するかどうか、ホスト アドレス フィールドが正しいかどうかも確認します。その後、チケット、セッション鍵、開始時刻と満了時刻、あとで使用するための他の情報を保存します。応答の暗号化部分の key-expiration フィールドを検査して、迫っている鍵の満了日をユーザに通知します (これによって、クライアント プログラムはパスワードの変更などの対処方法を提案できます)。
KRB_AS_REP メッセージを正しく復号しただけでは、ユーザの ID を検証するためには十分ではありません。ユーザと攻撃者が協力すれば、正しい KDC から返された KRB_AS_REP 形式のメッセージでなくても、正しく復号できるメッセージを生成できます。ホストがユーザの ID を検証したい場合、ユーザにアプリケーション信任状を提出するように要求しなければなりません。このアプリケーション信任状は、安全に格納された秘密鍵を使って検証できます。それらの信任状が検証できれば、ユーザの ID は保証されます。
応答メッセージのタイプが KRB_ERROR の場合、クライアントはそれをエラーと解釈し、復元するのに必要なアプリケーション固有のあらゆるタスクを実行します。
要約
メッセージの方向 メッセージのタイプ 掲載節 1. クライアントからアプリケーション サーバー KRB_AP_REQ 5.5.1 2. [オプション] アプリケーション サーバーからクライアント KRB_AP_REP または
KRB_ERROR5.5.2
5.9.1
クライアント／サーバー認証 (CS) 交換は、ネットワーク アプリケーションによってクライアントをサーバーに認証させたり、サーバーをクライアントに認証させるために使用されます。クライアントは、事前に AS 交換または TGS 交換を使用してサーバーの信任状を取得している必要があります。
KRB_AP_REQ には、認証情報が入っています。これは、認証済みのトランザクションの最初のメッセージの一部分でなければなりません。これは、チケット、認証子、および追加の帳簿情報 (形式の詳細については 5.5.1 節を参照のこと) を含んでいます。チケットはネットワーク上を平文で渡されるため、チケット自体はクライアントを認証するのに十分なものではありません (チケットには暗号化されている部分と暗号化されていない部分があります。ここでいう「平文（クリアテキスト）」とは、暗号化技術を使用せずにあるメッセージからコピーして他のメッセージでリプレイできるユニット全体を示します)。このため、認証子が使用されます。認証子は、クライアントがチケットのセッション鍵を知っていて、それを使用する権利があることをサーバーに証明することでリプレイを防止します。KRB_AP_REQ メッセージは、「認証ヘッダー」とも呼ばれます。
サーバーに対して認証を実行したい場合、クライアントは、信任状キャッシュ、AS 交換、TGS 交換のいずれかの方法で、目的のサーバーのチケットとセッション鍵を取得します。クライアントは、保持しているあらゆるチケットを、それらが満了するまで再使用します。その後、クライアントは、システム時刻、その名前、またアプリケーション固有のチェックサム (任意)、KRB_SAFE または KRB_PRIV メッセージで使用する初回のシーケンス番号、この特定のセッションに固有なセッション鍵のネゴシエーションに使用するセッション サブ鍵、などから新しい認証子を構築します。認証子は再使用されず、サーバーにリプレイすると拒否されます (このため、重複するメッセージを伝送するような信頼性のないトランスポートをベースにしているアプリケーションは、正しくコーディングできなくなることに注意してください。このような場合、新しい認証子は再試行ごとに生成しなければなりません)。シーケンス番号を含める 場合、複数のメッセージが交換されたときでも使用中の他のシーケンス番号と競合しないように、シーケンス番号をランダムに選択する必要があります。
クライアントは、相互認証を要求することも、メッセージの ap-options フィールドに適切なフラグを設定して session-key ベースのチケットを使用することもできます。
認証子は、セッション鍵で暗号化されていて、チケットと組み合わせて KRB_AP_REQ メッセージを形成します。その後、このメッセージは、アプリケーション固有の追加情報とともに終端サーバーに送信されます。
認証は、サーバーの現在の時刻 (クロックは柔軟に同期していなければなりません)、認証子、およびチケットに基づいています。いくつかのエラーが発生する可能性があり、エラーが発生した 場合、サーバーはクライアントに KRB_ERROR メッセージで応答します。このメッセージは、プロトコルが「ロー (未処理)」形式を受け付けない場合、アプリケーション プロトコルでカプセル化されます。エラー メッセージの形式については、5.9.1 節を参照してください。
認証情報を検証するためのアルゴリズムは、以下のとおりです。メッセージ タイプが KRB_AP_REQ ではない場合、サーバーは KRB_AP_ERR_MSG_TYPE エラーを返します。KRB_AP_REQ の Ticket で示されている鍵のバージョンが、サーバーが使用できないものである場合（例えば、古いキーを示し、すでにサーバーが古い鍵のコピーを所有していない場合)、KRB_AP_ERR_BADKEYVER エラーが返されます。ap-options フィールドに USE-SESSION-KEY フラグが設定されている場合、チケットがサーバーの秘密鍵ではなく、サーバーのチケット交付チケットのセッション鍵で暗号化されていることを示します (これは、[6] で説明しているようにユーザ間の認証で使用されます)。サーバーは、複数のレルムにそれぞれ異なる鍵で登録できるため、KRB_AP_REQ のチケットの暗号化されていない部分の srealm フィールドを使用して、そのチケットを復号するのにサーバーが使用すべき秘密鍵を示します。サーバーがチケットを復号するための適切な鍵を持っていない場合、KRB_AP_ERR_NOKEY エラー コードが返されます。
チケットは、チケットが指定したバージョンのサーバーの鍵を使用して復号されます。復号ルーチンでチケットの修正が検出された場合 (各暗号化システムは、修正された暗号文を検出するための保護手段を提供していなければなりません。第 6 章参照)、KRB_AP_ERR_BAD_INTEGRITY エラーが返されます (暗号化と復号では異なる鍵が使用されるので検出できます)。
認証子は、復号されたチケットから取り出されたセッション鍵を使用して復号されます。復号したものに修正の形跡がある場合、KRB_AP_ERR_BAD_INTEGRITY エラーが返されます。チケットから取得したクライアントの名前とレルムは、認証子の同じフィールドと比較されます。それらが一致しない場合、KRB_AP_ERR_BADMATCH エラーが返されます (これらは一致しないことがあります。たとえば、認証子を暗号化する場合に、間違ったセッション鍵を使用すると一致しません)。チケット内にアドレスがある場合、それらの中に OS（オペレーティング システム）が報告したクライアントのアドレスと一致するものが検索されます。一致するものがない場合、または、サーバーはチケットのアドレスを主張しているがチケットにアドレスが存在しない場合、KRB_AP_ERR_BADADDR エラーが返されます。
認証子のローカル (サーバー) の時刻とクライアントの時刻が許容クロック誤差以上異なっている場合（例えば 5分）、KRB_AP_ERR_SKEW エラーが返されます。認証子のサーバー名、クライアント名、時刻、およびマイクロ秒のフィールドが、最近提出されたそれらの組み合わせと一致する場合、KRB_AP_ERR_REPEAT エラーが返されます (ここで行われる拒否は、同一のプリンシパルから同一のサーバーへの認証子に制限されています。同一のサーバー プリンシパルと通信している他のクライアント プリンシパルの認証子は、時刻とマイクロ秒のフィールドが他のクライアントの認証子と一致した場合でも拒否されません)。サーバーは、リプレイが試行されてもそれが必ず失敗するように、許容クロック誤差範囲内に提出された認証子をすべて記憶している必要があります。サーバーが、許容クロック誤差範囲内に提出されたあらゆる認証子の記録を失った場合、クロック誤差期間が経過するまですべての要求を拒否しなければなりません。これによって、失われた認証子、またはリプレイされた認証子は、許容クロック誤差範囲外になり、リプレイできなくなります (このようにしないと、攻撃者はネットワーク経由でサーバーに送信されたチケットと認証子を記録し、クライアントのホストを無効にして、無効化されたホストを装い、チケットと認証子をリプレイして認証を破壊します)。認証子にシーケンス番号が提供されている 場合、サーバーはそれを保存し、あとで KRB_SAFE や KRB_PRIV メッセージの処理で使用します。サブ鍵が存在する場合、サーバーは将来使用するためにそれを保存するか、KRB_AP_REP メッセージに返すサブ鍵を独自に選択するために使用します。サーバーは、ローカル (サーバー) 時刻からチケット内部の開始時刻を減算して、チケットの経過期間を計算します。開始時刻が、現在の時刻よりも許容クロック誤差以上以降になっている場合、またはチケットに INVALID フラグが設定されている場合、KRB_AP_ERR_TKT_NYV エラーが返されます。終了時刻が、現在の時刻よりも許容クロック誤差以上以前になっている場合、KRB_AP_ERR_TKT_EXPIRED エラーが返されます。
これらのすべての検査がエラーを伴わずに正常に完了した場合、サーバーは、チケットに指定されているプリンシパルの信任状をクライアントが所有していることを確証し、これによりクライアントはサーバーに認証されます。擬似コードについては 、A.10 を参照してください。
通常、クライアントの要求は認証情報と初回の要求を同一のメッセージに含め、サーバーは、明示的に KRB_AP_REQ に応答する必要はありません。ただし、相互認証 (クライアントをサーバーに認証させるだけではなく、サーバーをクライアントにも認証させる) を実行した場合、KRB_AP_REQ メッセージの ap-option フィールドには MUTUAL-REQUIRED が設定され、応答で KRB_AP_REP メッセージが要求されます。プロトコルが「ロー (未処理)」形式を受け付けない場合、エラー メッセージとともにこのメッセージはアプリケーション プロトコルでカプセル化されます。応答で使用するタイムスタンプとマイクロ秒フィールドは、クライアントのタイムスタンプとマイクロ秒フィールドでなければなりません (認証子で提供したように)。[注意： Kerberos v4 プロトコルにおいては、応答のタイムスタンプはクライアントのタイムスタンプに 1 を加算した値でした。v5 においては、この必要はありません。これは、v5 のメッセージは、適切な暗号化鍵の知識なしでは慎重にメッセージを組み合わせても応答を作成できないように構成されているためです (暗号化形式であっても)。] シーケンス番号を含める場合、上記の認証子と同様にランダムに選択する必要があります。サーバーが異なるサブ鍵をネゴシエーションしたい場合、サブ鍵を含めることもできます。KRB_AP_REP メッセージは、チケットから取り出したセッション鍵で暗号化されています。擬似コードについては A.11 を参照してください。
KRB_AP_REP メッセージが返された場合、クライアントはサーバーから取得した信任状のセッション鍵を使用して (KRB_AP_REP メッセージの暗号化では、認証子にサブセッション鍵が存在していてもそれは使用されません )メッセージを復号し、タイムスタンプとマイクロ秒のフィールドがサーバーに送信した認証子内のそれらの値と一致することを確認します。それらが一致すると、クライアントはサーバーが本物であることを確証します。シーケンス番号とサブ鍵 (存在する場合) は、あとで使用できるように保持されます。擬似コードについては A.12 を参照してください。
KRB_AP_REQ/KRB_AP_REP 交換が行われた後、クライアントとサーバーは、アプリケーションが使用できる暗号化鍵を共有します。KRB_PRIV、KRB_SAFE、または他のアプリケーション固有の使用方法で使用する「真のセッション鍵」が、KRB_AP_REP メッセージ内のサブ鍵と認証子に基づいてアプリケーションによって選択されます (プロトコルの実装は、セッション鍵とランダムな数値に基づいてサブ鍵を選択するルーチンを提供しようとし、ネゴシエーションした鍵が KRB_AP_REP メッセージで返されるように調整しようとします)。場合によっては、このセッション鍵はプロトコルで暗黙的に使用されます。そうでない場合、いくつかの代替鍵から使用するものを選択する必要があります。鍵をどのように使用 (たとえば、暗号化タイプ、またはチェックサム タイプの選択) するかのプロトコルのネゴシエーションについては、アプリケーション プログラマに委ねます。Kerberos プロトコルは、実装オプションに制約を課しません。
一方向認証交換と相互認証交換のどちらにおいても、ピアが適切な保証なしで守秘性の高い情報をお互いに送信しないように注意する必要があります。特に、プライバシーや 完全性が要求されるアプリケーションでは、サーバーからクライアントへの KRB_AP_REP または KRB_ERROR 応答を使用して、クライアントとサーバーの両方にそれらのピアの ID を確証させる必要があります。アプリケーション プロトコルがメッセージのプライバシー性を必要とする場合、KRB_PRIV メッセージ (3.5 節を参照) を使用できます。完全性を保証するには、KRB_SAFE メッセージ (3.4 節を参照) を使用できます。
3.3. チケット交付サービス (TGS) 交換 English
要約
メッセージの方向 メッセージのタイプ 掲載節 1. クライアントから Kerberos KRB_TGS_REQ 5.4.1 2. Kerberos からクライアント KRB_TGS_REP または
KRB_ERROR5.4.2
5.9.1
クライアントと Kerberos チケット交付サーバー間での TGS 交換は、クライアントが特定のサーバーの認証信任状の取得を希望する場合 (リモート レルムに登録されている可能性がある)、既存のチケットの更新や有効化を希望する場合、または代理チケットの取得を希望する場合にクライアントによって開始されます。最初する場合、クライアントは AS 交換を使用してチケット交付サービスのチケットをあらかじめ取得しておく必要があります (チケット交付チケットは、通常、ユーザがログインした場合など、クライアントがシステムに初めて認証されたときに取得します)。TGS 交換のメッセージ形式は、AS 交換のメッセージ形式とほとんど同じです。主な違いは、TGS 交換での暗号化と復号にクライアントの鍵が使われないことです。その代わり、チケット交付チケットまたは更新可能なチケットのセッション鍵、あるいは認証子のサブセッション鍵が使用されます。すべてのアプリケーション サーバーにおいて、満了したチケットは TGS によって受領されません。したがって、いったん更新可能なチケットや、チケット交付チケットが満了すると、クライアントは個別の交換を使用して有効なチケットを取得しなければなりません。
TGS 交換は、クライアントから Kerberos チケット交付サーバーへの要求 (KRB_TGS_REQ) と応答 (KRB_TGS_REP または KRB_ERROR) の 2 つのメッセージで構成されています。KRB_TGS_REQ メッセージは、クライアントと信任状の要求を認証する情報を含んでいます。認証情報は、認証ヘッダー (KRB_AP_REQ) で構成されていて、これにはクライアントが以前に取得したチケット交付チケット、更新可能なチケット、または無効なチケットが含まれています。チケット交付チケットと代理の場合、要求は次の 1 つまたは複数を含んでいます。ネットワーク アドレスのリスト、アプリケーション サーバーが認定の目的で使用する、チケットに封印する入力した認定データの集まり、または、追加のチケット (これの使用方法については、後述します)。TGS 応答 (KRB_TGS_REP) は、チケット交付チケットまたは更新可能なチケットのセッション鍵、あるいは認証子 (認証ヘッダーの一部分) のサブセッション鍵 (存在する場合) で暗号化した要求した信任状を含んでいます。KRB_ERROR メッセージは、エラー コードとその理由を示すテキストを含んでいます。KRB_ERROR メッセージは暗号化されていません。 KRB_TGS_REP メッセージは、リプレイの検出に使用できる情報と、応答メッセージに添付する情報を含んでいます。KRB_ERROR メッセージも、応答メッセージに添付するのに使用できる情報を含んでいますが、KRB_ERROR メッセージは暗号化されないため、リプレイを検出したり、それらのメッセージを組み立てることはできません。
チケット交付サービスに要求を送信する前に、クライアントは、「アプリケーション サーバーがどのレルムに登録されているか」を判断する必要があります。[注意： この判断はいくつかの方法で実行できます。サーバーが登録されているレルムは、あらかじめ分かっていたり (レルムはプリンシパル識別子の一部分であるため)、ネームサーバーに格納されていることがあります。現在、この情報は、設定ファイルから取得できます。使用するレルムがネームサーバーから取得される 場合、レルム名を提供しているネームサービスが認証されていないとスプーフィング (偽造) の危険性があります。これは、変更されているレルムを使用することとなり、結果として攻撃者がアプリケーション サーバーからクライアントへの認証を変更できるようになります]。クライアントが、適切なレルムのチケット交付チケットをあらかじめ持っていない場合、それを取得する必要があります。まず、ローカル Kerberos サーバーから送り先のレルムのチケット交付チケットを要求します (KRB_TGS_REQ メッセージを再帰的に使用して)。Kerberos サーバーが希望するレルムの TGT を返した場合、先に進むことができます。Kerberos サーバーが希望するレルムに「近い」レルム (標準の階層パスに沿った) の TGT を返した場合、返された TGT に指定されているレルム内の Kerberos サーバーでこの手順を繰り返す必要があります。どちらも返されない場合、より上位の階層のレルムの Kerberos サーバーでこの要求を再試行する必要があります。この要求自体、これらの指示を再帰的に適用して取得しなければならないより上位のレルムのチケット交付チケットを要求します。
クライアントがいったん適切なレルム用のチケット交付チケットを取得すると、クライアントはそのレルムの応対をする Kerberos サーバーを判断し、それに接続します。レルムが交換した秘密鍵が秘密になっていて、サービスが拒否されるのは不正な Kerberos サーバーの場合だけであれば、リストは設定ファイルまたはネットワーク サービスから取得できます。
AS 交換では、クライアントは KRB_TGS_REQ メッセージにいくつかのオプションを指定します。クライアントは KRB_TGS_REQ メッセージを準備し、認証ヘッダーを padata フィールドの要素として提供し、KRB_AS_REQ メッセージで使用されていたのと同じフィールドをいくつかのオプションのフィールド (アプリケーション サーバーと、いくつかのオプションが要求した追加のチケット用の enc-authorization-data フィールド) とともに含めます。
認証ヘッダーを準備する際に、クライアントは Kerberos サーバーからの応答が暗号化されるサブセッション鍵を選択できます (クライアントがサブセッション鍵を選択する場合、サブセッション鍵がランダムに選択されるように注意する必要があります。これには、ランダムな値を生成して、チケット 交付チケットからのセッション鍵で排他的論理和を計算する方法があります)。サブセッション鍵が指定されていない場合、チケット交付チケットのセッション鍵が使用されます。 enc-authorization-data が存在する場合、認証ヘッダーの認証部分からのサブセッション鍵 、またはチケット交付チケットからのサブセッション鍵で暗号化しなければなりません。
準備が完了すれば、メッセージは宛先のレルムから Kerberos サーバーに送信されます。擬似コードについては A.5 を参照してください。
KRB_TGS_REQ メッセージは、KRB_AS_REQ メッセージと同様に処理されますが、実行しなければならないたくさんのチェックがあります。まず、Kerberos サーバーは、添付されているチケットがどのサーバー用であるかを判断し、復号するための適切な鍵を選択しなければなりません。標準の KRB_TGS_REQ メッセージでは、これはチケット 交付サービス用であるため、TGS の鍵が使用されます。TGT が他のレルムによって発行された場合、適切なインターレルム鍵を使用する必要があります。添付されているチケットが現在のレルム用ではなく、現在のレルム内のアプリケーション サーバー用のチケット交付チケットの場合、要求で RENEW、VALIDATE、または PROXY オプションが指定されます。また、チケットが要求されたサーバーが、添付されているチケットで指定されているサーバーの場合、KDC は KDC が発行したサーバー用の鍵を使用して認証ヘッダー内のチケットを復号します。padata フィールドにチケットが見つからない場合、KDC_ERR_PADATA_TYPE_NOSUPP エラーが返されます。
添付されているチケットが復号されたら、ユーザが供給した認証子内のチェックサムを要求内容に対して検証しなければなりません。そして、チェックサムが一致しない場合 (エラー コード KRB_AP_ERR_MODIFIED)、またはチェックサムが鍵付きにされていなかったり耐衝突性がない場合 (エラー コード KRB_AP_ERR_INAPP_CKSUM) は、メッセージが拒否されます。チェックサムがサポートされていないタイプの場合、KDC_ERR_SUMTYPE_NOSUPP エラーが返されます。
authorization-data が存在する場合、それらは認証子のサブセッション鍵を使って復号されます。
いずれかの復号で完全性検査が失敗すると、KRB_AP_ERR_BAD_INTEGRITY エラーが返されます。
KRB_TGS_REP メッセージの形式は、タイプ フィールドが KRB_TGS_REP に設定されることを除いては KRB_AS_REP (KRB_KDC_REP) と同じです。詳細仕様については、5.4.2 節を参照してください。
応答には、要求したサーバー用のチケットが含まれます。Kerberos データベースは、要求したサーバー用のレコードを取り出すように要求されます (チケットが暗号化される鍵を含む)。要求がリモート レルム用のチケット交付チケット用で、要求したレルムと共有する鍵が存在しない場合、Kerberos サーバーは、要求したレルムにもっとも近い、鍵を共有するレルムを選択し、そのレルムを代わりに使用します。これは、KDC からの応答がクライアントが要求したサーバーと異なる唯一のケースです。
デフォルトでは、アドレス フィールド、クライアントの名前とレルム、転送したレルムのリスト、初回の認証時刻、満了時刻、および新しく発行されたチケットの認証データがチケット交付チケット (TGT) または更新可能なチケットからコピーされます。転送済みフィールドを更新する必要があるが、転送タイプがサポートされていない場合、KDC_ERR_TRTYPE_NOSUPP エラーが返されます。要求が終了時刻を指定している場合、新しいチケットの終了時刻が次のうちの最小値に設定されます。(a) その要求、(b) TGT の終了時刻、(c) TGT の開始時刻と、アプリケーション サーバーの最大有効期限とローカル レルムの最大有効期限のいずれか小さいほうを加算したもの (要求しているプリンシパルの最大有効期限は、TGT が発行されたときに適用されています)。新しいチケットが更新可能な場合、上記の終了値は次のいずれか小さい値で置きかえられます: (a) チケットの renew_till フィールドの値、(b) 新しいチケットの開始時刻と古いチケットの有効期限 (endtime から starttime を減算した値) を加算した値。
FORWARDED オプションを要求した場合、結果のチケットにはクライアントが指定したアドレスが含まれます。このオプションは TGT 内に FORWARDABLE フラグが設定されている場合だけ受領されます。PROXY オプションを指定した場合も同様で、結果のチケットにはクライアントが指定したアドレスが含まれます。これは、TGT 内に PROXIABLE フラグが設定されている場合だけ受領されます。PROXY オプションは、追加のチケット交付チケットの要求では受領されません。
要求開始時刻が指定されていない、または過去の時刻を示している場合、チケットの開始時刻は認証サーバーの現在の時刻に設定されます。将来の時刻を示しているが、TGT 内で POSTDATED オプションが指定されていなかったり、MAY-POSTDATE フラグが設定されていない場合、エラー KDC_ERR_CANNOT_POSTDATE が返されます。そうでない場合、チケット交付チケットに MAYPOSTDATE フラグが設定されていると、結果のチケットは先付け日付に変更され、要求した開始時刻はローカル レルムのポリシーに対して検査されます。可能であれば、チケットの開始時刻は要求どおりに設定され、INVALID フラグが設定されます。先付け日付に変更されたチケットは、開始時刻後に KDC に提出して有効化しなければなりません。ただし、新しく発行した以降の時刻のチケットの starttime、endtime、または renew-till 時刻が、チケット交付チケットの renew-till 時刻よりあとになることはありません。
>ENC-TKT-IN-SKEY オプションが指定されていて、要求に追加のチケットが含まれている場合、KDC は、追加のチケットの発行先であるサーバー用の鍵を使って追加のチケットを復号し、それがチケット交付チケットであることを検証します。要求に、要求するサーバーの名前が存在しない場合、追加のチケット内のクライアント名が使用されます。サーバーの名前が存在する場合、要求サーバーの名前は追加チケット内のクライアント名と比較され、異なる 場合その要求が拒否されます。要求が成功すると、新しいチケットが使用されるサーバーの鍵を使用する代わりに、発行された新しいチケットの暗号化には追加チケットのセッション鍵が使用されます (これによって、ユーザ間の認証 [6] を容易に実装できるようになります。この場合、秘密鍵は簡単に漏洩してしまうため、秘密のサーバー鍵を使用する代わりにチケット交付チケットのセッション鍵を使用します)。
認証ヘッダーの一部として KDC に提出したチケット内のサーバー名が、チケット交付サーバーの名前ではない場合、サーバーは KDC のレルム内に登録されます。RENEW オプションを要求すると、KDC は チケット内に RENEWABLE フラグが設定されていることと、renew_till 時刻が将来の時刻であることを検証します。VALIDATE オプションを要求した場合、KDC は過去の開始時刻をチェックし、INVALID フラグを設定します。PROXY オプションを要求した場合、KDC はチケット内に PROXIABLE フラグが設定されていることをチェックします。テストが成功すると、KDC は適切な新しいチケットを発行します。
チケット 交付 サーバーに要求を行うと、提出したチケットはキャンセルされたチケットのホットリストに対して必ずチェックされます。ホットリストは、一連の「疑いのあるチケット」の発行日を格納することで実装できます。提出したチケットにその範囲の authtime が設定されている場合、それは拒否されます。このようにして、盗難が報告されると、追加のチケット (更新したまたはその他の) を取得するのに盗み出されたチケット交付チケットまたは更新可能なチケットは使用できなくなります。盗難が報告される前に取得した正常なチケットは、引き続き通常の満了時刻まで有効になります (これらは KDC とのやり取りを必要としないため)。
KRB_TGS_REP メッセージ内の応答の暗号文部分は、認証子が存在する場合それのサブセッション鍵で暗号化され、存在しない場合チケット 交付 チケットのセッション鍵で暗号化されます。クライアントの秘密鍵では暗号化されません。さらに、クライアントの鍵の満了日と鍵バージョン番号フィールドは省略されます。これらの値はクライアントのデータベース レコードとともに格納され、これらのレコードは、チケッ ト交付チケットに基づいた要求を満足するためには不要であるからです。擬似コードについては、A.6 を参照してください。
認証ヘッダーの一部分として KDC に提出された TGT 内のサーバーの ID がチケット交付サービスのものであるが、TGT が他のレルムから発行されている場合、KDC はレルムと共有しているインターレルム鍵を検索し、その鍵を使ってチケットを復号します。チケットが有効な場合、KDC は AS 交換について説明している上記の節で概説している制約に基づいて要求を受領します。クライアント ID のレルム部分は、チケット交付チケットから取り出されます。チケット交付チケットを発行したレルムの名前は、発行するチケットの転送済みフィールドに追加されます。これを行うのに、チケット 交付チケットの転送フィールドを読み取り (順番どおりになっていないレルム名の設定として扱われる)、設定する新しいレルムを追加し、その符合化 (速記) 形式を構築して書き出します (既存の符号化の再編成を含みます)。
チケット交付サービスが、チケット交付サービス自身のレルム名を追加しないことに注意してください。チケット交付サービスは、その代わりに、直前のレルムの名前を追加します。これによって、悪意のある Kerberos サーバーがその Kerberos サーバー自身の名前を故意に省略することを防ぐことができます (ただし、他のレルム名を省略することはできます)。
ローカル レルム名とプリンシパルのレルム名は、どちらも転送フィールドに含めてはいけません。それらは、チケットのどこかに含まれていて、どちらもプリンシパルを認証するのに使われたことがわかっているからです。エンドポイントが含まれていないため、ローカル インターレルム認証と単一ホップ インターレルム認証のどちらの場合も、転送フィールドは空になります。
転送された各レルムの名前がこのフィールドに追加されるため、大変長くなる場合があります。このフィールドの長さを短縮するために、その内容は符合化されます。最初にサポートされた符合化方法が、通常のインターレルム コミュニケーションに合わせて最適化されます (ドメインまたは X.500 スタイルのレルム名を使用してレルムを階層的に配置します)。この符合化 (DOMAIN-X500-COMPRESS と呼ばれる) について、ここで説明します。
転送フィールド内のレルム名は、"," で区切られます。","、"\"、後続の "."、先頭のスペース (" ") は、特殊文字で、これらがレルム名の一部分である場合、それらの文字の前に "\" を付けて転送フィールドで引用する必要があります。
"." で終了しているレルム名は、以前のレルムに付加されると解釈されます。たとえば、EDU、MIT.EDU、ATHENA.MIT.EDU、WASHINGTON.EDU、および CS.WASHINGTON.EDU の通過を次のように符合化できます。
"EDU,MIT.,ATHENA.,WASHINGTON.EDU,CS.".
ATHENA.MIT.EDU または CS.WASHINGTON.EDU は終端で、 このフィールドには含まれず、次のようになります。
"EDU,MIT.,WASHINGTON.EDU"
"/" で開始しているレルム名は、以前のレルムに追加されると 解釈されます (追加のために、最初にリストされているレルムは、 ナル レルム ("") であると考えられます。)それだけで表す場合には、 スペース (" ") を前に付ける必要があります。たとえば、/COM/HP/APOLLO、 /COM/HP、/COM、および/COM/DEC の通過を次のように符合化できます。
"/COM,/HP,/APOLLO, /COM/DEC".
上記の例のように、/COM/HP/APOLLO および /COM/DEC が終端の場合、これらはこのフィールドには含まれず、これは次のようになります。
"/COM,/HP"
"," の前または後ろのナル サブフィールドは、以前のレルムと次のレルム間のすべてのレルムを通過したことを示します (ナル サブフィールドを解釈するためには、転送フィールド内のレルムの前にクライアントのレルムが付き、サーバーのレルムがその後ろに付くと考えられます)。このように "," は、クライアントとサーバー間のパス上のすべてのレルムを通過したことを示します。",EDU, /COM," は、クライアントのレルムから EDU (ドメイン スタイル階層) に至るすべてのレルムを通過し、/COM から X.500 スタイルのサーバーのレルム間のすべてを通過したことを意味します。1 つの階層の EDU レルムが、他の階層の /COM レルムとインターレルム鍵を直接共有する場合にこれが起こります。
KRB_TGS_REP をクライアントから受信した場合、これは前述の KRB_AS_REP 処理と同様に処理されます。主な違いとしては、応答の暗号文部分は、クライアントの秘密鍵ではなく、チケット交付チケットのセッション鍵を使用して復号しなければならないことです。擬似コードについては、A.7 を参照してください。
KRB_SAFE メッセージは、交換するメッセージの修正を検出できることを要求するクライアントが使用します。ユーザ データといくつかの制御情報の鍵付きにされた耐衝突性のあるチェックサムを含むことで、これを実行します。チェックサムは、暗号化鍵で鍵付きにされます(通常は、サブ鍵を使ってネゴシエートされた最後の鍵、またはネゴシエーションが行われなかった場合セッション鍵)。
アプリケーションが KRB_SAFE メッセージの送信を希望する場合、アプリケーションはそのデータと適切な制御情報を収集し、それらを通じてチェックサムを演算します。チェックサム アルゴリズムは、サブセッション鍵が存在する場合これによって生成され、存在しない場合セッション鍵で生成された、鍵付きにされた一方向ハッシュ関数の一種でなければなりません (6.4.5 節で示している RSA-MD5-DES チェックサム アルゴリズムや DES MAC など)。メッセージ内のチェックサム タイプを変更することで、異なるアルゴリズムを選択できます。鍵付けされていないチェックサムや、不一致に対する耐性のないチェックサムは、この場合には適していません。
KRB_SAFE メッセージの制御情報には、タイムスタンプとシーケンス番号が入っています。KRB_SAFE メッセージを使用してアプリケーションを設計する場合、この 2 つのメカニズムのいずれかを使用する必要があります。どちらを使用するかは、アプリケーション プロトコルの必要性に従って選択する必要があります。
シーケンス番号は、送信したすべてのメッセージを 1 つのピアが受信する場合に便利です。現在、セッション鍵を維持するには接続状態が常に必要であるため、次のシーケンス番号を維持する場合、追加の問題が提出されるべきではありません。
アプリケーション プロトコルが、紛失したメッセージを再送信せずにそれらを黙認する場合、タイムスタンプの使用は適切なリプレイ検出メカニズムとして機能します。タイムスタンプの使用は、ある ユーザが所有するすべてのピアが共通のサブセッション鍵を共有するが、いくつかのメッセージはピアのサブセットに送信されるマルチキャスト プロトコルにとっても適切なメカニズムです。
チェックサムの演算後、クライアントは情報とチェックサムを 5.6.1 節において説明しているメッセージ形式で受領者に伝送します。
アプリケーションは KRB_SAFE メッセージを受信すると、それを次のように検証します。エラーが発生した場合、アプリケーションが使用できるようにエラー コードが報告されます。
まずメッセージは、プロトコル バージョンとタイプ フィールドがそれぞれ現在のバージョンと KRB_SAFE と一致するかどうか検証されます。一致しない場合、KRB_AP_ERR_BADVERSION または KRB_AP_ERR_MSG_TYPE エラーが生成されます。
アプリケーションは、使用されるチェックサムが耐衝突性のある鍵付きにされたチェックサムであることを検証し、そうでない場合、KRB_AP_ERR_INAPP_CKSUM エラーを生成します。受領者は、OS（オペレーティング システム）が報告した送信者のアドレスが、メッセージ内の送信者のアドレスと一致することを検証し、受領者のアドレスが指定されていたり、受領者がアドレスを要求した場合、受領者のアドレスはメッセージ内の受領者のアドレスとして表示されます。どちらの場合も不一致が生じると KRB_AP_ERR_BADADDR エラーが生成されます。そしてタイムスタンプと usec か、シーケンス番号フィールド、またはその両方がチェックされます。タイムスタンプと usec が想定され、それらが存在しなかった場合、または存在するが現在ではない場合、KRB_AP_ERR_SKEW エラーが生成されます。認証子のサーバー名、クライアント名、時刻、およびマイクロ秒のフィールドが、最近提出されたそれらの組み合わせと一致する場合、KRB_AP_ERR_REPEAT エラーが返されます。不正なシーケンス番号が含まれていたり、シーケンス番号が想定されたが存在しない場合、KRB_AP_ERR_BADORDER エラーが生成されます。タイムスタンプと usec、またはシーケンス番号のどちらも存在しない場合、KRB_AP_ERR_MODIFIED エラーが生成されます。最後に、チェックサムはデータと制御情報を通して演算され、それが受信したチェックサムと一致しない場合、KRB_AP_ERR_MODIFIED エラーが生成されます。
すべてのチェックが成功すると、アプリケーションは、メッセージがピアによって生成され、伝送中に修正されていないことを保証します。
KRB_PRIV メッセージは、交換するメッセージの守秘性と修正の検出機能を必要とするクライアントが使用します。メッセージを暗号化し、制御情報を追加してこれを行います。
アプリケーションは、KRB_PRIV メッセージの送信を希望する場合、そのデータと適切な制御情報を収集し (5.7.1 節を参照)、暗号化鍵で暗号化します (通常は、サブ鍵を使ってネゴシエートされた最後の鍵、またはネゴシエーションが行われなかった 場合セッション鍵)。制御情報の一部分として、クライアントはタイムスタンプまたはシーケンス番号のどちらを使用するか選択しなければなりません (あるいはその両方)。どちらを使用するかのガイドラインについては、3.4.1 節 を参照してください。ユーザ データと制御情報が暗号化されると、クライアントは暗号文といくつかの「封筒」情報を受領者に伝送します。
アプリケーションは、KRB_PRIV メッセージを受信すると、それを次のように検証します。エラーが発生した場合、アプリケーションで使用できるエラー コードが報告されます。
まずメッセージは、プロトコル バージョンとタイプ フィールドがそれぞれ現在のバージョンと KRB_PRIV と一致するかどうか検証されます。一致しない場合、KRB_AP_ERR_BADVERSION または KRB_AP_ERR_MSG_TYPE エラーが生成されます。その後、アプリケーションは、暗号文を復号し、結果のプレーンテキストを生成します。復号が、データが修正されたことを示す場合、KRB_AP_ERR_BAD_INTEGRITY エラーが生成されます。受領者は、オペレーティング システムが報告した送信者のアドレスが、メッセージ内の送信者のアドレスと一致することを検証し、受領者のアドレスが指定されていたり、受領者がアドレスを要求した 場合、受領者のアドレスはメッセージ内の受領者のアドレスとして表示されます。どちらの場合も不一致が生じると KRB_AP_ERR_BADADDR エラーが生成されます。そしてタイムスタンプと usec か、シーケンス番号フィールド、またはその両方がチェックされます。タイムスタンプと usec が想定され、それらが存在しなかった場合、または存在するが現在ではない場合、KRB_AP_ERR_SKEW エラーが生成されます。認証子のサーバー名、クライアント名、時刻、およびマイクロ秒のフィールドが、最近提出されたそれらの組み合わせと一致する場合、KRB_AP_ERR_REPEAT エラーが返されます。不正なシーケンス番号が含まれていたり、シーケンス番号が想定されたが存在しない場合、KRB_AP_ERR_BADORDER エラーが生成されます。タイムスタンプと usec、またはシーケンス番号のどちらも存在しない場合、KRB_AP_ERR_MODIFIED エラーが生成されます。
すべてのチェックが成功すると、アプリケーションはメッセージがピアによって生成され、 (暗号化されていない内容を侵入者が見ることをできずに) 安全に伝送されたものと考えます。
KRB_CRED メッセージは、Kerberos 信任状をあるホストから他のホストに送信したいクライアントが使用します。チケットを、チケットに関連するセッション鍵と他の情報を含んでいる暗号化データとともに送信することでこれを実行できます。
アプリケーションは、KRB_CRED メッセージを送信しようする場合、まずリモート ホストに送信する信任状を (KRB_TGS 交換を使用して) 取得します。その後、そのようにして取得したチケットを使用して、KRB_CRED メッセージの暗号化部分に対応する KrbCredInfo シーケンスの鍵フィールド内の各チケットを使用するのに必要なセッション鍵を配置し、KRB_CRED を作成します。
各チケットに関連付けられている他の情報で KRB_TGS 交換中に取得したものも、KRB_CRED メッセージの暗号化部分にある対応する KrbCredInfo シーケンス内に配置されます。現在の時刻と、アプリケーションが特別に要求した場合には、nonce、s-address、および raddress フィールドが KRB_CRED メッセージの暗号化された部分に配置されます。その後、これは KRB_AP 交換により直前に得た暗号化鍵で暗号化されます (通常は、サブ鍵を使ってネゴシエートされた最後の鍵、またはネゴシエーションが行われなかった場合セッション鍵が使われます)。
アプリケーションは、KRB_CRED メッセージを受信した場合、それを検証します。エラーが発生すると、アプリケーションが使用できるようにエラー コードが報告されます。メッセージについては、「プロトコル バージョンとタイプ フィールドがそれぞれ現在のバージョンと KRB_CRED と一致するか否か」が検証されます。一致しない場合、KRB_AP_ERR_BADVERSION または KRB_AP_ERR_MSG_TYPE エラーが生成されます。その後、アプリケーションは、暗号文を復号し、結果の平文を生成します。復号の結果、データが修正されたことがわかった 場合、KRB_AP_ERR_BAD_INTEGRITY エラーが生成されます。存在する場合、または要求された場合、受領者は、OS（オペレーティング システム）の送信者のアドレスのレポートが、メッセージ内の送信者のアドレスと一致するかどうか検証します。そして、受領者のアドレスの 1つが、メッセージ内の受領者のアドレスにあることを検証します。どちらの場合も、一致しない場合 、KRB_AP_ERR_BADADDR エラーが生成されます。タイプスタンプと usec フィールド (要求された場合、nonce フィールドも) が次にチェックされます。タイムスタンプと usec が存在しなかった場合、あるいは、存在するが現在ではない場合、KRB_AP_ERR_SKEW エラーが生成されます。
すべてのチェックが成功すると、アプリケーションは、チケット キャッシュの新しいチケットを、セッション鍵や、対応する KRB_CRED メッセージの暗号化部分から得た KrbCredInfo シーケンスに入っている他の情報とともに保存します。