3.2. The Client/Server Authentication Exchange (クライアント/サーバー認証交換)

Summary (概要)

Message direction (メッセージ方向)	Message type (メッセージタイプ)	Section (セクション)
Client to Application server (クライアントからアプリケーションサーバーへ)	KRB_AP_REQ	5.5.1
[optional] Application server to client ([オプション] アプリケーションサーバーからクライアントへ)	KRB_AP_REP または KRB_ERROR	5.5.2, 5.9.1

client/server authentication (CS) exchange (クライアント/サーバー認証交換) は, ネットワークアプリケーションがクライアントをサーバーに認証し, その逆も行うために使用されます。クライアントは, AS または TGS 交換を使用してサーバーのクレデンシャルをすでに取得していなければなりません (MUST)。

3.2.1. [The KRB_AP_REQ Message (KRB_AP_REQ メッセージ)]

KRB_AP_REQ には, 認証されたトランザクションの最初のメッセージの一部であるべき (SHOULD) 認証情報が含まれています。これには, チケット, 認証子, およびいくつかの追加の簿記情報が含まれています (正確な形式についてはセクション 5.5.1 を参照)。チケット自体はクライアントを認証するには不十分です。なぜなら, チケットはネットワーク上で平文で渡されるからです (チケットには暗号化された部分と暗号化されていない部分の両方が含まれているため, ここでの平文は, 暗号化スキルなしであるメッセージから別のメッセージにコピーしてリプレイできるユニット全体を指します)。認証子は, クライアントがチケットのセッション鍵を知っており, したがってチケットを使用する権利があることをサーバーに証明することによって, チケットの無効なリプレイを防ぐために使用されます。KRB_AP_REQ メッセージは, 他の場所では「authentication header (認証ヘッダー)」と呼ばれます。

3.2.2. [Generation of a KRB_AP_REQ Message (KRB_AP_REQ メッセージの生成)]

クライアントがサーバーへの認証を開始したい場合, (クレデンシャルキャッシュ, AS 交換, または TGS 交換のいずれかを通じて) 希望するサービスのチケットとセッション鍵を取得します。クライアントは, 有効期限が切れるまで保持しているチケットを再利用できます (MAY)。チケットを使用するために, クライアントは, システム時刻と自身の名前から, およびオプションでアプリケーション固有のチェックサム, KRB_SAFE または KRB_PRIV メッセージで使用される初期シーケンス番号, および/またはこの特定のセッションに固有のセッション鍵の交渉に使用されるセッションサブキーから, 新しい Authenticator を構築します。Authenticator は再利用してはならず (MUST NOT), サーバーにリプレイされた場合は拒否されるべきです (SHOULD)。これにより, 信頼性の低いトランスポートに基づくアプリケーションを正しくコーディングすることが困難になる可能性があることに注意してください。トランスポートが重複したメッセージを配信する可能性がある場合, 各再試行ごとに新しい認証子を生成しなければならない (MUST) か, またはアプリケーションサーバーが要求と応答を照合し, 検出された重複に応答して最初の応答をリプレイしなければなりません (MUST)。

シーケンス番号が含まれる場合, 多くのメッセージが交換された後でも, 使用中の他のシーケンス番号と衝突する可能性が低いように, ランダムに選択されるべきです (SHOULD)。

クライアントは, メッセージの ap-options フィールドに適切なフラグを設定することによって, 相互認証またはセッション鍵ベースのチケットの使用 (ユーザー間認証については, セクション 3.7 を参照) の要件を示すことができます (MAY)。

Authenticator はセッション鍵で暗号化され, チケットと組み合わされて KRB_AP_REQ メッセージを形成し, 追加のアプリケーション固有の情報とともにエンドサーバーに送信されます。

3.2.3. [Receipt of KRB_AP_REQ Message (KRB_AP_REQ メッセージの受信)]

認証は, サーバーの現在の時刻 (クロックは緩く同期されていなければなりません (MUST)), 認証子, およびチケットに基づいています。いくつかのエラーが発生する可能性があります。エラーが発生した場合, サーバーは KRB_ERROR メッセージでクライアントに応答することが期待されます。このメッセージは, その生の形式がプロトコルに許容されない場合, アプリケーションプロトコルにカプセル化される場合があります (MAY)。エラーメッセージの形式は, セクション 5.9.1 で説明されています。

認証情報を検証するアルゴリズムは次のとおりです。メッセージタイプが KRB_AP_REQ でない場合, サーバーは KRB_AP_ERR_MSG_TYPE エラーを返します。KRB_AP_REQ の Ticket によって示される鍵バージョンがサーバーが使用できるものでない場合 (例: 古い鍵を示しており, サーバーがもはや古い鍵のコピーを所有していない), KRB_AP_ERR_BADKEYVER エラーが返されます。ap-options フィールドに USE-SESSION-KEY フラグが設定されている場合, サーバーに対して, ユーザー間認証が使用中であり, チケットがサーバーの秘密鍵ではなく, サーバーの TGT のセッション鍵で暗号化されていることを示します。Kerberos プロトコルのすべてのメッセージに対するユーザー間認証の効果のより完全な説明については, セクション 3.7 を参照してください。

サーバーは複数のレルムに登録されている可能性があり, それぞれに異なる鍵があるため, KRB_AP_REQ のチケットの暗号化されていない部分の srealm フィールドを使用して, サーバーがそのチケットを復号化するためにどの秘密鍵を使用すべきかを指定します。サーバーがチケットを解読するための適切な鍵を持っていない場合, KRB_AP_ERR_NOKEY エラーコードが返されます。

チケットは, チケットで指定されたサーバーの鍵のバージョンを使用して復号化されます。復号化ルーチンがチケットの変更を検出した場合 (各暗号化システムは, 変更された暗号文を検出するためのセーフガードを提供しなければなりません (MUST)), KRB_AP_ERR_BAD_INTEGRITY エラーが返されます (暗号化と復号化に異なる鍵が使用された可能性が高いです)。

認証子は, 復号化されたチケットから抽出されたセッション鍵を使用して復号化されます。復号化が変更されたことを示す場合, KRB_AP_ERR_BAD_INTEGRITY エラーが返されます。チケットからのクライアントの名前とレルムが, 認証子の同じフィールドと比較されます。一致しない場合, KRB_AP_ERR_BADMATCH エラーが返されます。通常, これはクライアントエラーまたは攻撃の試みによって引き起こされます。チケット内のアドレス (存在する場合) は, クライアントのオペレーティングシステムから報告されたアドレスと一致するアドレスを検索されます。一致が見つからない場合, またはサーバーがチケットアドレスを主張するがチケットにアドレスが存在しない場合, KRB_AP_ERR_BADADDR エラーが返されます。ローカル (サーバー) 時刻と認証子のクライアント時刻が許容可能なクロックスキュー (例: 5 分) よりも大きく異なる場合, KRB_AP_ERR_SKEW エラーが返されます。

アプリケーションサーバーがリプレイから保護するための独自の適切な手段を提供しない限り (たとえば, 認証後にサーバーによって開始されるチャレンジレスポンスシーケンス, またはサーバー生成の暗号化サブキーの使用), サーバーは, 許容可能なクロックスキュー内に提示された認証子を記憶するために, リプレイキャッシュを利用しなければなりません (MUST)。このキャッシュを排除する前に, アプリケーションプロトコルと実装の慎重な分析が推奨されます。リプレイキャッシュは, 少なくともサーバー名と, 最近見られた認証子からのクライアント名, 時刻, およびマイクロ秒フィールドを保存し, 一致するタプルが見つかった場合, KRB_AP_ERR_REPEAT エラーが返されます。ここでの拒否は, 同じプリンシパルから同じサーバーへの認証子に制限されることに注意してください。同じサーバープリンシパルと通信する他のクライアントプリンシパルは, 時刻とマイクロ秒フィールドがたまたま他のクライアントの認証子と一致しても, 認証子が拒否されるべきではありません。

サーバーが許容可能なクロックスキュー内に提示された認証子を追跡できなくなった場合, クロックスキュー間隔が経過するまで, すべての要求を拒否しなければなりません (MUST)。これにより, 失われたまたはリプレイされた認証子が許容可能なクロックスキューの外に落ち, 正常にリプレイできなくなることが保証されます。これが行われなかった場合, 攻撃者は, ネットワーク上でサーバーに送信されたチケットと認証子を記録し, サーバーが最近見られた認証子を追跡できなくなる原因となったイベントの後にそれらをリプレイすることによって, 認証を破壊できます。

実装上の注意: クライアントがマイクロ秒フィールドを含む同じタイムスタンプで KDC に複数の要求を生成した場合, 受信した最初の要求以外のすべてがリプレイとして拒否されます。これは, たとえば, クライアントのクロックの解像度が粗すぎる場合に発生する可能性があります。クライアント実装は, タイムスタンプが再利用されないようにすべきです (SHOULD)。おそらく, クロックが複数の要求に対して同じ時刻を返した場合に, タイムスタンプのマイクロ秒フィールドをインクリメントすることによって。

複数のサーバー (たとえば, 1 台のマシン上の異なるサービス, または複数のマシンに実装された単一のサービス) がサービスプリンシパルを共有する場合 (一般的には推奨しませんが, 一部のケースで使用されることを認識しています), それらはこのリプレイキャッシュを共有しなければならない (MUST) か, またはアプリケーションプロトコルがそれの必要性を排除するように設計されなければなりません (MUST)。これはすべてのサービスに適用されることに注意してください。アプリケーションプロトコルのいずれかにリプレイ保護が組み込まれていない場合, そのようなサービスで使用される認証子は, 前者が共通のリプレイキャッシュに認証子情報を記録しない場合, 後で同じサービスプリンシパルを持つがリプレイ保護がない別のサービスにリプレイされる可能性があります。

認証子でシーケンス番号が提供されている場合, サーバーは, KRB_SAFE および/または KRB_PRIV メッセージの処理で後で使用するためにそれを保存します。サブキーが存在する場合, サーバーは後で使用するために保存するか, または KRB_AP_REP メッセージで返されるサブキーの独自の選択を生成するのに役立つために使用します。

サーバーは, チケットの経過時間を計算します: ローカル (サーバー) 時刻から Ticket 内の starttime を引いた値。starttime が許容可能なクロックスキューよりも現在の時刻よりも遅い場合, またはチケットに INVALID フラグが設定されている場合, KRB_AP_ERR_TKT_NYV エラーが返されます。それ以外の場合, 現在の時刻が終了時刻よりも許容可能なクロックスキューよりも遅い場合, KRB_AP_ERR_TKT_EXPIRED エラーが返されます。

これらすべてのチェックがエラーなしで成功した場合, サーバーは, クライアントがチケットで指定されたプリンシパルのクレデンシャルを所有しており, したがって, クライアントがサーバーに認証されたことが保証されます。

これらのチェックに合格しても, 指定されたプリンシパルの認証のみが提供されます。指定されたサービスを使用する認可を意味するものではありません。アプリケーションは, ユーザーの認証された名前, 要求された操作, .k5login または .k5users ファイルに含まれるものなどのローカルアクセス制御情報, および場合によっては別個の分散認可サービスに基づいて, 別個の認可決定を行わなければなりません (MUST)。

3.2.4. [Generation of a KRB_AP_REP Message (KRB_AP_REP メッセージの生成)]

通常, クライアントの要求には, 認証情報と初期要求の両方が同じメッセージに含まれ, サーバーは KRB_AP_REQ に明示的に応答する必要はありません。ただし, 相互認証 (クライアントからサーバーへの認証だけでなく, サーバーからクライアントへの認証も実行する) が実行されている場合, KRB_AP_REQ メッセージの ap-options フィールドに MUTUAL-REQUIRED が設定されており, 応答として KRB_AP_REP メッセージが必要です。エラーメッセージと同様に, このメッセージは, その「生の」形式がアプリケーションのプロトコルに許容されない場合, アプリケーションプロトコルにカプセル化される場合があります (MAY)。応答で使用されるタイムスタンプとマイクロ秒フィールドは, クライアントのタイムスタンプとマイクロ秒フィールド (認証子で提供された) でなければなりません (MUST)。シーケンス番号が含まれる場合, 認証子について上記で説明したようにランダムに選択されるべきです (SHOULD)。サーバーが異なるサブキーを交渉することを希望する場合, サブキーが含まれる場合があります (MAY)。KRB_AP_REP メッセージは, チケットから抽出されたセッション鍵で暗号化されます。

Kerberos バージョン 4 プロトコルでは, 応答のタイムスタンプはクライアントのタイムスタンプに 1 を加えたものであったことに注意してください。これは, バージョン 5 では必要ありません。なぜなら, バージョン 5 のメッセージは, 適切な暗号化鍵の知識なしに (暗号化された形式であっても) 慎重なメッセージ手術によって応答を作成することが不可能な方法でフォーマットされているからです。

3.2.5. [Receipt of KRB_AP_REP Message (KRB_AP_REP メッセージの受信)]

KRB_AP_REP メッセージが返された場合, クライアントは, サーバーのために取得したクレデンシャルからのセッション鍵を使用してメッセージを復号化し, タイムスタンプとマイクロ秒フィールドがサーバーに送信した Authenticator のものと一致することを検証します。一致する場合, クライアントは, サーバーが真正であることを保証されます。シーケンス番号とサブキー (存在する場合) は, 後で使用するために保持されます。(KRB_AP_REP メッセージを暗号化するために, サブセッション鍵は, Authentication に存在していても使用されないことに注意してください。)

3.2.6. [Using the Encryption Key (暗号化鍵の使用)]

KRB_AP_REQ/KRB_AP_REP 交換が発生した後, クライアントとサーバーは, アプリケーションで使用できる暗号化鍵を共有します。場合によっては, このセッション鍵の使用がプロトコルで暗黙的です。他の場合では, 使用方法はいくつかの代替案から選択する必要があります。アプリケーションは, チケットからのセッション鍵と KRB_AP_REP メッセージおよび認証子のサブキーに基づいて, KRB_PRIV, KRB_SAFE, またはその他のアプリケーション固有の使用に使用される実際の暗号化鍵を選択できます (MAY)。プロトコルの実装は, セッション鍵と乱数に基づいてサブキーを選択し, KRB_AP_REP メッセージで返される交渉された鍵を生成するルーチンを提供する場合があります (MAY)。

クライアントでの乱数生成の失敗の影響を軽減するために, アプリケーションが後続の使用のために導出する鍵には, チケットで運ばれる KDC 生成のセッション鍵から導出された完全な鍵エントロピーを含めることを強く推奨します。鍵の使用方法 (たとえば, 暗号化またはチェックサムタイプの選択) のプロトコル交渉は, アプリケーションプログラマーに任せます。Kerberos プロトコルは実装オプションを制約しませんが, これがどのように行われるかの例が続きます。

アプリケーションが後続の完全性とプライバシー保護に使用される鍵を交渉することを選択する 1 つの方法は, クライアントが認証子のサブキーフィールドで鍵を提案することです。サーバーは, クライアントによって提案された鍵を入力として使用して鍵を選択し, アプリケーション応答のサブキーフィールドで新しいサブキーを返すことができます。この鍵は, 後続の通信に使用できます。

一方向および相互認証交換の両方で, ピアは後続の通信でどの鍵を使用するかを交渉できます。KRB_PRIV および KRB_SAFE メッセージは, チケットから交換されたセッション鍵またはサブセッション鍵で保護できます。KRB_AP_REQ および KRB_AP_REP メッセージで交渉されたサブセッション鍵の優先使用が推奨されます。