3.3. The Ticket-Granting Service (TGS) Exchange (チケット付与サービス交換)

Summary (概要)

Message direction (メッセージ方向)	Message type (メッセージタイプ)	Section (セクション)
1. Client to Kerberos (クライアントから Kerberos へ)	KRB_TGS_REQ	5.4.1
2. Kerberos to client (Kerberos からクライアントへ)	KRB_TGS_REP または KRB_ERROR	5.4.2, 5.9.1

クライアントと Kerberos TGS 間の TGS 交換は, 特定のサーバー (リモートレルムに登録されている可能性がある) の認証クレデンシャルを取得しようとする場合, 既存のチケットを更新または検証しようとする場合, またはプロキシチケットを取得しようとする場合に, クライアントによって開始されます。最初のケースでは, クライアントは AS 交換を使用して Ticket-Granting Service のチケットをすでに取得していなければなりません (TGT は通常, クライアントが最初にシステムに認証するときに取得されます。たとえば, ユーザーがログインするときなど)。TGS 交換のメッセージ形式は, AS 交換のものとほぼ同じです。主な違いは, TGS 交換での暗号化と復号化がクライアントの鍵の下で行われないことです。代わりに, TGT または更新可能なチケットからのセッション鍵, または Authenticator からのサブセッション鍵が使用されます。すべてのアプリケーションサーバーの場合と同様に, 期限切れのチケットは TGS によって受け入れられないため, 更新可能なチケットまたは TGT が期限切れになると, クライアントは有効なチケットを取得するために別の交換を使用する必要があります。

TGS 交換は 2 つのメッセージで構成されます: クライアントから Kerberos Ticket-Granting Server への要求 (KRB_TGS_REQ) と, 応答 (KRB_TGS_REP または KRB_ERROR)。KRB_TGS_REQ メッセージには, クライアントを認証する情報とクレデンシャルの要求が含まれています。認証情報は, 認証ヘッダー (KRB_AP_REQ) で構成され, クライアントの以前に取得したチケット付与, 更新可能, または無効なチケットが含まれます。TGT およびプロキシのケースでは, 要求には次のうち 1 つ以上が含まれる場合があります (MAY): ネットワークアドレスのリスト, アプリケーションサーバーによる認可使用のためにチケットにシールされる型付き認可データのコレクション, または追加のチケット (その使用については後で説明します)。TGS 応答 (KRB_TGS_REP) には, 要求されたクレデンシャルが含まれ, TGT または更新可能なチケットからのセッション鍵で, または存在する場合は Authenticator からのサブセッション鍵で暗号化されます (認証ヘッダーの一部)。KRB_ERROR メッセージには, エラーコードと何が問題だったかを説明するテキストが含まれています。KRB_ERROR メッセージは暗号化されていません。KRB_TGS_REP メッセージには, リプレイを検出し, それが応答するメッセージと関連付けるために使用できる情報が含まれています。KRB_ERROR メッセージにも, それが応答するメッセージと関連付けるために使用できる情報が含まれています。セクション 3.1 で言及された KRB_ERROR メッセージの完全性保護に関する同じコメントが TGS 交換に適用されます。

3.3.1. [Generation of KRB_TGS_REQ Message (KRB_TGS_REQ メッセージの生成)]

チケット付与サービスに要求を送信する前に, クライアントは, アプリケーションサーバーがどのレルムに登録されていると考えられるかを決定しなければなりません (MUST)。これはいくつかの方法で達成できます。事前に知られている場合 (レルムはプリンシパル識別子の一部であるため), ネームサーバーに保存されている場合, または構成ファイルから取得される場合があります。使用されるレルムがネームサーバーから取得される場合, レルム名を提供するネームサービスが認証されていないと, スプーフィングされる危険があります。これにより, 侵害されたレルムの使用が生じ, アプリケーションサーバーからクライアントへの認証を侵害する攻撃者の能力がもたらされる可能性があります。

クライアントがサービスプリンシパル名とレルムを知っていて, 適切なレルムの TGT をまだ所有していない場合, 1 つを取得する必要があります。これは最初に, クライアントが TGT を所有する Kerberos サーバーから宛先レルムの TGT を要求することによって試みられます (KRB_TGS_REQ メッセージを再帰的に使用して)。Kerberos サーバーは, 希望するレルムの TGT を返す場合があり (MAY), その場合は続行できます。あるいは, Kerberos サーバーは, 希望するレルムに「より近い」レルムの TGT を返す場合があります (MAY) (クライアントのレルムと要求されたレルムサーバーのレルム間の標準的な階層パスに沿ってさらに進んだもの)。この場合, Kerberos サーバーの設定ミスにより, 結果として得られる認証パスにループが発生する可能性があることに注意してください。クライアントは, これを検出して回避するように注意する必要があります。

Kerberos サーバーが希望するレルムよりも「近い」レルムの TGT を返した場合, クライアントは, ローカルポリシー構成を使用して, 使用される認証パスが許容可能なものであることを検証できます (MAY)。あるいは, クライアントは, Kerberos サーバーに 1 つを選択させるのではなく, 独自の認証パスを選択することを選択できます (MAY)。いずれの場合も, Kerberos サーバーまたはクライアントのいずれかによって認証パスを選択または検証するために使用されるポリシーまたは構成情報は, 信頼できるソースから取得されなければなりません (MUST)。

クライアントが宛先レルムに「より近い」TGT を取得した場合, クライアントは, このチケットをキャッシュし, 「より近い」レルムのサービスとの将来の KRB-TGS 交換で再利用できます (MAY)。ただし, クライアントが別のチケットを取得する一環としてではなく, 初期 KDC から開始して「より近い」レルムの TGT を取得した場合, 「より近い」レルムへのより短いパスが使用される可能性があります。この短いパスは, より少ない中間 KDC が関与するチケットのセッション鍵を知ることになるため, 望ましい場合があります。このため, クライアントは, 将来チケットを使用するかどうかを決定する際に, 「より近い」チケットを取得する際に経由したレルムを信頼するかどうかを評価すべきです (SHOULD)。

クライアントが適切なレルムの TGT を取得すると, そのレルムにサービスを提供する Kerberos サーバーを決定し, そのうちの 1 つに連絡します。リストは, 構成ファイルまたはネットワークサービスを通じて取得されるか, またはレルムの名前から生成される場合があります (MAY)。レルムによって交換される秘密鍵が秘密に保たれている限り, 偽の Kerberos サーバーを使用すると, サービス拒否のみが発生します。

AS 交換と同様に, クライアントは KRB_TGS_REQ メッセージでいくつかのオプションを指定できます (MAY)。これらのオプションの 1 つは, ユーザー間認証に使用される ENC-TKT-IN-SKEY オプションです。ユーザー間認証の概要は, セクション 3.7 にあります。KRB_TGS_REQ メッセージを生成する際, このオプションは, クライアントが要求の追加チケットフィールドにアプリケーションサーバーから取得した TGT を含めており, KDC が, プリンシパルデータベースからのサーバー鍵の代わりに, この追加チケットからのセッション鍵を使用して, アプリケーションサーバーのチケットを暗号化すべき (SHOULD) ことを示します。

クライアントは, padata フィールドの要素として認証ヘッダーを提供し, KRB_AS_REQ メッセージで使用されるのと同じフィールドといくつかのオプションのフィールド (アプリケーションサーバー使用のための enc-authorization-data フィールドと一部のオプションで必要とされる追加チケット) を含めて, KRB_TGS_REQ メッセージを準備します。

認証ヘッダーを準備する際, クライアントは, Kerberos サーバーからの応答が暗号化されるサブセッション鍵を選択できます。クライアントがサブセッション鍵を選択する場合, 選択されたサブセッション鍵のランダム性を確保するように注意する必要があります。

サブセッション鍵が指定されていない場合, TGT からのセッション鍵が使用されます。enc-authorization-data が存在する場合, 認証ヘッダーの認証子部分からのサブセッション鍵 (存在する場合) で暗号化されなければならず (MUST), 存在しない場合は TGT からのセッション鍵を使用して暗号化されます。

準備が完了すると, メッセージは宛先レルムの Kerberos サーバーに送信されます。

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

KRB_TGS_REQ メッセージは, KRB_AS_REQ メッセージと同様の方法で処理されますが, 実行する必要がある追加のチェックが多数あります。まず, Kerberos サーバーは, 添付のチケットがどのサーバーのものであるかを決定しなければならず (MUST), それを復号化するための適切な鍵を選択しなければなりません (MUST)。通常の KRB_TGS_REQ メッセージの場合, それはチケット付与サービスのためのものであり, TGS の鍵が使用されます。TGT が別のレルムによって発行された場合, 適切なレルム間鍵が使用されなければなりません (MUST)。(a) 添付のチケットが現在のレルムの TGT ではなく, 現在のレルムのアプリケーションサーバーのためのものであり, (b) 要求で RENEW, VALIDATE, または PROXY オプションが指定されており, (c) チケットが要求されているサーバーが添付のチケットで指定されたサーバーである場合, KDC は, それが発行されたサーバーの鍵を使用して認証ヘッダーのチケットを復号化します。padata フィールドにチケットが見つからない場合, KDC_ERR_PADATA_TYPE_NOSUPP エラーが返されます。

添付のチケットが復号化されると, Authenticator 内のユーザー提供のチェックサムが要求の内容に対して検証されなければならず (MUST), チェックサムが一致しない場合 (エラーコード KRB_AP_ERR_MODIFIED で), またはチェックサムが衝突防止ではない場合 (エラーコード KRB_AP_ERR_INAPP_CKSUM で) メッセージは拒否されなければなりません (MUST)。チェックサムタイプがサポートされていない場合, KDC_ERR_SUMTYPE_NOSUPP エラーが返されます。authorization-data が存在する場合, Authenticator からのサブセッション鍵を使用して復号化されます。

復号化のいずれかが完全性チェックの失敗を示す場合, KRB_AP_ERR_BAD_INTEGRITY エラーが返されます。

セクション 3.1.2 で説明したように, KDC が最近処理したものと同一の KRB_TGS_REQ メッセージを受信した場合, 有効な KRB_TGS_REP メッセージを送信しなければなりません (MUST)。ただし, 認証子がリプレイであるが, 要求の残りの部分が同一でない場合, KDC は KRB_AP_ERR_REPEAT を返すべきです (SHOULD)。

3.3.3. [Generation of KRB_TGS_REP Message (KRB_TGS_REP メッセージの生成)]

KRB_TGS_REP メッセージは, KRB_AS_REP (KRB_KDC_REP) と形式を共有しますが, type フィールドが KRB_TGS_REP に設定されています。詳細な仕様はセクション 5.4.2 にあります。

応答には, 要求されたサーバーのチケット, または要求されたチケットを取得するために連絡される中間 KDC のチケット付与サーバーのチケットが含まれます。Kerberos データベースがクエリされて, 適切なサーバーのレコード (チケットが暗号化される鍵を含む) が取得されます。要求がリモートレルムの TGT のためのものであり, 要求されたレルムと鍵が共有されていない場合, Kerberos サーバーは, 要求されたレルムに「最も近い」, 鍵を共有するレルムを選択し, 代わりにそのレルムを使用します。これは, KDC の応答がクライアントによって要求されたものとは異なるサーバーのためになる唯一のケースです。

デフォルトでは, アドレスフィールド, クライアントの名前とレルム, 経由されたレルムのリスト, 初期認証の時刻, 有効期限, および新しく発行されたチケットの認可データは, TGT または更新可能なチケットからコピーされます。経由フィールドを更新する必要があるが, 経由タイプがサポートされていない場合, KDC_ERR_TRTYPE_NOSUPP エラーが返されます。

要求が endtime を指定する場合, 新しいチケットの endtime は, (a) その要求, (b) TGT からの endtime, および (c) TGT の starttime と, アプリケーションサーバーの最大ライフタイムとローカルレルムの最大ライフタイムの最小値の合計のうち, 最小値に設定されます (要求しているプリンシパルの最大ライフタイムは, TGT が発行されたときにすでに適用されています)。新しいチケットが更新である場合, 上記の endtime は, (a) チケットの renew_till フィールドの値と (b) 新しいチケットの starttime と古いチケットのライフ (endtime-starttime) の合計のうち, 最小値に置き換えられます。

FORWARDED オプションが要求されている場合, 結果のチケットには, クライアントによって指定されたアドレスが含まれます。このオプションは, TGT に FORWARDABLE フラグが設定されている場合にのみ受け入れられます。PROXY オプションも同様です。結果のチケットには, クライアントによって指定されたアドレスが含まれます。これは, TGT の PROXIABLE フラグが設定されている場合にのみ受け入れられます。PROXY オプションは, 追加の TGT の要求では受け入れられません。

要求された starttime が存在しない場合, 過去の時刻を示す場合, または KDC の許容可能なクロックスキューのウィンドウ内にあり, POSTDATE オプションが指定されていない場合, チケットの starttime は認証サーバーの現在の時刻に設定されます。許容可能なクロックスキューを超えた将来の時刻を示すが, POSTDATED オプションが指定されていないか, TGT に MAY-POSTDATE フラグが設定されていない場合, エラー KDC_ERR_CANNOT_POSTDATE が返されます。それ以外の場合, TGT に MAY-POSTDATE フラグが設定されている場合, 結果のチケットは日付指定され, 要求された starttime はローカルレルムのポリシーに対してチェックされます。許容される場合, チケットの starttime は要求どおりに設定され, INVALID フラグが設定されます。日付指定チケットは, starttime に到達した後に KDC に提示して検証してから使用しなければなりません (MUST)。ただし, どのような場合でも, 新しく発行された日付指定チケットの starttime, endtime, または renew-till 時刻が TGT の renew-till 時刻を超えることはありません。

ENC-TKT-IN-SKEY オプションが指定されていて, 追加のチケットが要求に含まれている場合, クライアントが, 永続的な鍵にアクセスできないサーバーに対してその身元を証明するために, ユーザー間認証を使用していることを示します。セクション 3.7 では, このオプションが Kerberos プロトコル全体に及ぼす影響について説明しています。KRB_TGS_REP メッセージを生成する際, KRB_TGS_REQ メッセージのこのオプションは, KDC に, 追加のチケットが発行されたサーバーの鍵を使用して追加のチケットを復号化し, それが TGT であることを検証するように指示します。要求されたサーバーの名前が要求から欠落している場合, 追加のチケットのクライアントの名前が使用されます。それ以外の場合, 要求されたサーバーの名前が追加のチケットのクライアントの名前と比較されます。異なる場合, 要求は拒否されます。要求が成功した場合, 追加のチケットからのセッション鍵が, 新しいチケットが使用されるサーバーの鍵を使用する代わりに, 発行される新しいチケットを暗号化するために使用されます。

(a) 認証ヘッダーの一部として KDC に提示されたチケット内のサーバーの名前が TGS 自体のものではなく, (b) サーバーが KDC のレルムに登録されており, (c) RENEW オプションが要求されている場合, KDC は, チケットに RENEWABLE フラグが設定されていること, チケットに INVALID フラグが設定されていないこと, および renew_till 時刻がまだ将来であることを検証します。VALIDATE オプションが要求されている場合, KDC は, starttime が経過し, INVALID フラグが設定されていることをチェックします。PROXY オプションが要求されている場合, KDC は, チケットに PROXIABLE フラグが設定されていることをチェックします。テストが成功し, チケットが次のセクションで説明するホットリストチェックに合格した場合, KDC は適切な新しいチケットを発行します。

KRB_TGS_REP メッセージの応答の暗号文部分は, 存在する場合は Authenticator からのサブセッション鍵で, または TGT からのセッション鍵で暗号化されます。クライアントの秘密鍵を使用して暗号化されません。さらに, クライアントの鍵の有効期限と鍵バージョン番号フィールドは省略されます。これらの値はクライアントのデータベースレコードとともに保存されており, TGT に基づく要求を満たすためにそのレコードは必要ないためです。

3.3.3.1. [Checking for Revoked Tickets (取り消されたチケットのチケットのチェック)]

チケット付与サーバーに要求が行われるたびに, 提示されたチケットは, キャンセルされたチケットのホットリストに対してチェックされます。このホットリストは, 「疑わしいチケット」の発行タイムスタンプの範囲を保存することによって実装される場合があります。提示されたチケットがその範囲内の authtime を持っている場合, それは拒否されます。この方法で, 盗まれた TGT または更新可能なチケットは, 盗難がサーバーが存在するレルムの KDC に報告されると, 追加のチケット (更新またはその他) を取得するために使用できなくなります。盗難が報告される前に取得された通常のチケットは引き続き有効です (チケットは KDC との対話を必要としないため) が, 通常の有効期限までのみです。クロスレルム認証のために TGT が発行されている場合, クロスレルム TGT の使用は, ホットリストがそのようなクロスレルムチケットが発行されたレルムの KDC に伝播されない限り, 影響を受けません。

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

KRB_TGS_REP が受信されると, AS 交換の場合と同様に処理されますが, チケットとセッション鍵は, 元のチケット付与チケットのセッション鍵, または存在する場合は認証子から選択されたサブセッション鍵を使用して, TGS 応答の暗号化部分から抽出されます。