2. Ticket Flag Uses and Requests (チケットフラグの使用と要求)

各 Kerberos チケットには, そのチケットの属性を示すために使用されるフラグのセットが含まれています。ほとんどのフラグは, チケットが取得される時にクライアントによって要求されることがあります。いくつかは必要に応じて Kerberos サーバーによって自動的にオンまたはオフになります。以下のセクションでは, さまざまなフラグが何を意味するかを説明し, それらを使用する理由の例を示します。INVALID フラグを除いて, クライアントは認識されないチケットフラグを無視しなければなりません (MUST)。KDC は認識されない KDC オプションを無視しなければなりません (MUST)。RFC 1510 の一部の実装は未知の KDC オプションを拒否することが知られているため, RFC 1510 以降に追加されたオプションを含めて送信された要求が拒否された場合, クライアントは新しい KDC オプションなしで要求を再送信する必要があるかもしれません。新しい KDC は未知のオプションを無視するため, クライアントは KDC によって返されたチケットが自分のニーズを満たすことを確認しなければなりません (MUST)。

オプションが理解されなかったために尊重されなかったのか, 構成またはポリシーによって拒否されたのかを判断することは, 一般的に不可能であることに注意してください。Kerberos プロトコルに新しいオプションを追加する場合, 設計者はその区別がオプションにとって重要かどうかを考慮すべきです。重要である場合, KDC がオプションが理解されたが拒否されたことを示す表示を返すメカニズムをオプションの仕様で提供する必要があります。多くの場合, そのような場合, メカニズムはエラーまたは理由を返すことができるように十分に広範である必要があります。

2.1. Initial, Pre-authenticated, and Hardware-Authenticated Tickets (初期チケット, 事前認証チケット, ハードウェア認証チケット)

INITIAL フラグは, チケットが TGT に基づいて発行されたのではなく, AS プロトコルを使用して発行されたことを示します。クライアントの秘密鍵の実証された知識を要求したいアプリケーションサーバー (例えば, パスワード変更プログラム) は, 受け入れるチケットにこのフラグが設定されていることを主張でき, したがってクライアントのキーが最近認証サーバーに提示されたことを保証できます。

PRE-AUTHENT および HW-AUTHENT フラグは, 現在のチケットが直接発行されたか (その場合 INITIAL も設定されます) または TGT に基づいて発行されたか (その場合 INITIAL フラグはクリアされますが, PRE-AUTHENT および HW-AUTHENT フラグは TGT から継承されます) に関係なく, 初期認証に関する追加情報を提供します。

2.2. Invalid Tickets (無効なチケット)

INVALID フラグは, チケットが無効であることを示します。アプリケーションサーバーは, このフラグが設定されているチケットを拒否しなければなりません (MUST)。ポストデートチケットはこの形式で発行されます。無効なチケットは, 使用前に KDC によって検証されなければなりません (MUST)。これは, VALIDATE オプションを指定した TGS 要求で KDC に提示することによって行われます。KDC は, 開始時刻が経過した後にのみチケットを検証します。検証が必要なのは, 開始時刻前に盗まれたポストデートチケットを (ホットリストメカニズムを通じて) 永久に無効にできるようにするためです (セクション 3.3.3.1 を参照)。

2.3. Renewable Tickets (更新可能なチケット)

アプリケーションは, 長期間有効なチケットを保持することを望むかもしれません。ただし, これは同様に長期間クレデンシャルを潜在的な盗難にさらす可能性があり, 盗まれたクレデンシャルはチケットの有効期限まで有効です。単に短期間のチケットを使用して定期的に新しいものを取得するには, クライアントが秘密鍵に長期間アクセスする必要があり, さらに大きなリスクがあります。更新可能なチケットは, 盗難の結果を軽減するために使用できます。更新可能なチケットには 2 つの "有効期限" があります: 1 つ目はチケットの現在のインスタンスが期限切れになる時刻で, 2 つ目は個々の有効期限の最新の許容値です。アプリケーションクライアントは, 定期的に (つまり, 期限が切れる前に) KDC 要求で RENEW オプションを設定して, 更新可能なチケットを KDC に提示しなければなりません。KDC は, 新しいセッションキーと後の有効期限を持つ新しいチケットを発行します。チケットの他のすべてのフィールドは, 更新プロセスによって変更されません。最新の許容有効期限が到来すると, チケットは永久に期限切れになります。各更新時に, KDC は前回の更新以降にチケットが盗難として報告されたかどうかを判断するためにホットリストを参照してもよい (MAY) です。盗まれたチケットの更新を拒否するため, 盗まれたチケットの使用可能な寿命は短縮されます。

チケットの RENEWABLE フラグは, 通常チケット付与サービスによってのみ解釈されます (以下のセクション 3.3 で説明)。通常, アプリケーションサーバーによって無視できます。ただし, 特に慎重なアプリケーションサーバーは, 更新可能なチケットを許可しないことがあります (MAY)。

更新可能なチケットがその有効期限までに更新されない場合, KDC はチケットを更新しません。RENEWABLE フラグはデフォルトでリセットされますが, クライアントは KRB_AS_REQ メッセージで RENEWABLE オプションを設定することによって設定を要求してもよい (MAY) です。設定されている場合, チケットの renew-till フィールドには, チケットが更新できなくなる時刻が含まれます。

2.4. Postdated Tickets (ポストデートチケット)

アプリケーションは, 後で使用するためのチケットを取得する必要がある場合があります。たとえば, バッチ送信システムは, 送信されたジョブが実行される時に有効なチケットを必要とします。ただし, チケットが使用可能になるまで長時間待つと, 盗難にさらされる期間が長くなります。

ポストデートチケットは, 将来の時刻に有効になるように発行できます。チケットが有効になる前に盗まれた場合, クライアントはチケットを無効にするよう KDC に通知できます (ホットリストメカニズムを使用)。そのため, チケットが検証される時 (上記のセクション 2.2 の INVALID フラグを参照), KDC はチケットがホットリストに載っているかどうかを確認し, 載っている場合は検証を拒否します。

チケットがポストデートされる場合, POSTDATED フラグが設定されます。ポストデートチケットは通常, INVALID フラグも設定された状態で発行され, 開始時刻が経過した後に検証されなければなりません。これは, クライアントが自分のクレデンシャルを安全に保管できるようにし, チケットが実際に使用される直前にのみ検証するようにするためです。ポストデートチケットを受け入れるアプリケーションサーバーは, INVALID フラグがクリアされていることを確認しなければなりません。これは, チケットが KDC によって検証されたことを保証します。

2.5. Proxiable and Proxy Tickets (プロキシ可能チケットとプロキシチケット)

ときどき, プリンシパルは別のプリンシパルに操作を実行させたい場合があります。たとえば, ユーザーは印刷サーバーにファイルサーバーからファイルにアクセスして印刷させたい場合があります。プロキシを許可する 1 つの方法は, ユーザーが自分のクレデンシャルを印刷サーバーに与えることです。ただし, これには問題があります: これらのクレデンシャルは無期限に保存され, 他の目的に使用される可能性があります。(これらの問題は, ファイルサーバーへのアクセスを制限する認可データを使用することで緩和できます。)

別のアプローチでは, ユーザーは印刷サーバー用の TGT を KDC に要求し, 印刷サーバーに渡します。ただし, 印刷サーバーは実際には自分自身のチケットを取得しているため, ユーザーの代わりにファイルサーバーに対して認証できません (つまり, ファイルサーバーは要求がユーザーからではなく印刷サーバーからのものであると見なします)。

プロキシメカニズムは, これらの問題のいくつかを解決します。チケットが PROXIABLE フラグで発行されている場合, プリンシパルはそのチケットを使用して別のプリンシパル用のプロキシチケットを取得できます。プロキシチケットは, 元のプリンシパルのアイデンティティを持ちますが, 異なるネットワークアドレス (プロキシが実行される場所のアドレス) を持つ TGT です。したがって, プロキシは元のプリンシパルの名前で操作を実行できますが, 特定の場所からのみです。プロキシチケットには PROXY フラグが設定されます。

プロキシチケットは, 元のプリンシパルが明示的に要求した場合にのみ発行されます。クライアントは, KRB_AS_REQ または KRB_TGS_REQ メッセージで ALLOW-POSTDATE オプションを設定することによって, チケットが PROXIABLE フラグで発行されることを要求できます。

アプリケーションサーバーは, PROXY フラグが設定されたチケットを拒否する選択をしてもよい (MAY) です。サーバーは, プロキシが使用されていることを知りたい場合もあります (たとえば, ログに記録するため)。

2.6. Forwardable Tickets (転送可能なチケット)

転送可能なチケットは, プロキシ可能なチケットと似ていますが, いくつかの重要な違いがあります。プロキシ可能なチケットが特定のアドレスからの特定の操作に制限されることを意図している場合, 転送可能なチケットは, プリンシパルが別のホスト上の新しい TGT を取得し, 新しいホストで直接作業することを許可します。

チケットが FORWARDABLE フラグで発行されている場合, ユーザーは新しい TGT を異なるネットワークアドレスで要求できます。新しい TGT は元のユーザーのアイデンティティを持ちますが, 新しいネットワークアドレスを持ちます。転送されたチケットには FORWARDED フラグが設定されます。

転送可能なチケットは, 元のプリンシパルが明示的に要求した場合にのみ発行されます。クライアントは, KRB_AS_REQ または KRB_TGS_REQ メッセージで FORWARDABLE オプションを設定することによって, チケットが FORWARDABLE フラグで発行されることを要求できます。

アプリケーションサーバーは, FORWARDED フラグが設定されたチケットを拒否する選択をしてもよい (MAY) です。サーバーは, 転送が使用されていることを知りたい場合もあります (たとえば, ログに記録するため)。

2.7. Transited Policy Checking (通過ポリシーチェック)

クロスレルム認証では, チケットの transited フィールドに, クライアントのレルムとサーバーのレルム間の認証パスが記録されます。アプリケーションサーバーは, この情報を使用して, 認証を受け入れるかどうかを決定できます。

アプリケーションサーバーは, transited フィールドのチェックを KDC に依存してもよい (MAY) です。KDC が transited フィールドをチェックした場合, チケットに TRANSITED-POLICY-CHECKED フラグが設定されます。アプリケーションサーバーは, このフラグが設定されている場合, transited フィールドを自分でチェックする必要がないかもしれません。

ただし, アプリケーションサーバーには最終的な責任があり, 自分で transited フィールドをチェックすることを選択してもよい (MAY) です。

クライアントは, KDC 要求で DISABLE-TRANSITED-CHECK フラグを設定することによって, KDC が transited フィールドをチェックしないように要求できます。KDC はこの要求を尊重すべきです (SHOULD)。この場合, TRANSITED-POLICY-CHECKED フラグは設定されず, アプリケーションサーバーは transited フィールドを自分でチェックする責任があります。

2.8. OK as Delegate (委任として OK)

OK-AS-DELEGATE フラグは, サーバーがクライアントの委任されたクレデンシャルを受け入れることが安全であることを KDC が示すために使用されます。これは通常, サーバーのセキュリティポリシーに基づいて設定されます。

クライアントは, このフラグを使用して, 自分のクレデンシャルをサーバーに委任するかどうかを決定できます。フラグが設定されていない場合, クライアントはクレデンシャルを委任すべきではありません (SHOULD NOT)。

2.9. Other KDC Options (その他の KDC オプション)

2.9.1. Renewable-OK (更新可能 OK)

RENEWABLE-OK オプションは, クライアントが要求された有効期限を持つチケットを取得できない場合に, より短い有効期限を持つ更新可能なチケットを受け入れることを示します。

クライアントが長い有効期限を持つチケットを要求し, KDC がポリシーのためにそれを発行できない場合, KDC は RENEWABLE-OK オプションが設定されているかどうかを確認します。設定されている場合, KDC はより短い有効期限を持つ更新可能なチケットを発行できます。

2.9.2. ENC-TKT-IN-SKEY

ENC-TKT-IN-SKEY オプションは, ユーザー間認証 (user-to-user authentication) をサポートするために使用されます。このオプションが設定されている場合, KDC は要求されたサーバーの長期的なキーではなく, 要求に含まれるセッションキーでチケットを暗号化します。

これにより, サーバーが長期的な秘密鍵を持っていない場合でも, 2 つのクライアントが相互に認証できます。

2.9.3. Passwordless Hardware Authentication (パスワードレスハードウェア認証)

一部のシステムでは, ユーザーはパスワードを入力する代わりにハードウェアトークン (スマートカードなど) を使用して認証できます。この場合, KDC は HW-AUTHENT フラグを設定してチケットを発行できます。

このフラグは, 認証がハードウェアトークンを使用して実行されたことを示します。アプリケーションサーバーは, この情報を使用して, より高いセキュリティレベルを要求する操作を許可するかどうかを決定できます。