各 Kerberos チケットは、チケットのさまざまな属性を示す一連のフラグが入っています。クライアントは、チケットを取得すれば、ほとんどのフラグを要求できます。フラグのいくつかは、Kerberos サーバーにより、要求に合わせ自動的にオン／オフが切り換えられます。以降の節においては、これらのフラグの意味と、そのフラグを使用する理由を例をあげて説明します。
「INITIAL フラグ」は、そのチケットが AS プロトコルを使って発行されたものであり、チケット交付チケットに基づいて発行されたものではないことを示します。クライアントの秘密鍵の情報を要求したいアプリケーション サーバー(例： パスワード変更プログラム)は、受け取るすべてのチケットにこのフラグが設定されるように要求できます。これによって、クライアントの鍵がアプリケーション クライアントに最近提出されたことを確証できます。PRE-AUTHENT と HW-AUTHENT フラグは、現在のチケットが直接発行されたか (この場合、INITIAL が設定される)、またはチケット交付チケットによって発行されたかにかかわらず (この場合、INITIAL フラグは設定されないが、チケット交付チケットから PRE-AUTHENT と HW-AUTHENT フラグが転送される)、初回の認証についての詳細情報を示します。
「INVALID フラグ」は、チケットが無効であることを示します。アプリケーション サーバーは、このフラグ セットを持っているチケットを拒否しなければなりません。通常、先付け日付のチケットは、この形式で発行されます。無効のチケットは、使用する前に KDC で有効にしなければなりません。有効にするには、TGS 要求で VALIDATE オプションを指定して、チケットを KDC に提出します。KDC は、チケットの starttime 以降にそれを有効化します。この有効化は、starttime 以前に盗まれた、先付け日付のチケットを (ホットリスト メカニズムによって) 永久的に無効にするために必要です。
アプリケーションによっては、長期間有効なチケットが必要な場合があります。しかし、チケットが長期間有効だと、信任状はその期間中、盗難の危険性にさらされることになります。盗まれた信任状も、有効期限が切れるまで有効 であるからです。有効期限の短いチケットを使い、新しいチケットを定期的に取得するには、クライアントが秘密鍵に長期間アクセスできる必要がありますが、これではさらにリスクが大きくなります。そこで、更新可能なチケットを使用すること により、盗難の危険性を減らすことができます。更新可能なチケットには、2 つの「満了時刻」があります。
1 番目の満了時刻は、チケットの現在のインスタンスが満了する時刻で、2番目の満了時刻は、各満了時刻の許容最終時刻です。アプリケーション クライアントは、KDC 要求の RENEW オプションをセットして、更新可能なチケットを KDC に定期的に (例えば、チケットが満了する前に) 提出しなければなりません。KDC は、新しいセッション鍵と満了時刻がそれ以降になっている新しいチケットを発行します。更新プロセスにおいては、それ以外のフィールドは、一切修正されません。許容最終時刻になると、チケットは 、永久的に満了します。各更新時に、KDC はホットリストを参照して、最後に更新が行われてから盗難が報告されているか否かを判断できます。KDC は盗まれたチケットを更新することはしないので、盗まれたチケットの有効期限が短縮されます。
通常、チケットの「RENEWABLE フラグ」は、チケット交付サービスのみが解釈し (3.3 節参照)、通常 、アプリケーション サーバーは、これを無視できます。ただし、特に慎重なアプリケーション サーバーは、更新可能なチケットを拒否することがあります。
更新可能なチケットが満了時刻までに更新されない場合、KDC はチケットを更新しません。「RENEWABLE フラグ」は、デフォルトではリセットされますが、クライアントは、RENEWABLE オプションを設定した KRB_AS_REQ メッセージを設定することにより、「RENEWABLE フラグ」を設定するように要求できます。「RENEWABLE フラグ」が設定されると、チケットの renew-till フィールドにはチケットの更新限度時間(それ以降は更新が不可能になる時間) が設定されます。
アプリケーションでよっては、(現在すぐではなく) かなり時間が経ってから使用するためのチケットが必要になることがあります。たとえば、バッチ実行システムには、バッチ ジョブ開始時刻に有効なチケットが必要です。しかし、バッチ キューに有効なチケットを入れておくことは危険です。チケットが長期間オンラインの状態になり、盗難の危険性が高くなるためです。先付け日付のチケットを使用すれば、ジョブ開始時刻に KDC からこれらのチケットを取得し、KDC が要求を出して有効化するまでそれらを「休止」状態にしておくことができます。その間にチケットの盗難が報告された場合、KDC は、チケットを有効化することを拒否するので、盗難は失敗に終わります。
通常、チケットの「MAY-POSTDATE フラグ」は、チケット交付サービスだけが解釈します。アプリケーション サーバーは、これを無視できます。提出したチケットに基づいて先付け日付のチケットを発行するには、チケット交付チケットにこのフラグを設定しなければなりません。これはデフォルトでリセットされますが、ALLOW-POSTDATE オプションを設定した KRB_AS_REQ メッセージで設定するように要求できます。このフラグによって、クライアントは先付け日付のチケット交付チケットを取得できなくなります。先付け日付のチケット交付チケットは、KRB_AS_REQ メッセージで先付け日付のチケットを要求した場合だけ取得できます。先付け日付のチケットの有効期間 (endtime から starttime を減算した値) は、RENEWABLE オプションも設定しない限り、要求を行った時点のチケット交付チケットの残りの有効期間になります。RENEWABLE オプションも設定した場合は、チケット交付チケットの全有効期間になります。KDC は先付け日付を制限できます。
「POSTDATED フラグ」は、チケットが先付け日付になっていることを示します。アプリケーション サーバーは、チケットの authtime フィールドをチェックして、オリジナルの認証の発行日を確認できます。サービスによっては、先付け日付のチケットを拒否する場合もあります。また、オリジナルの認証の発行日以降、特定期間内にだけ受け付けるサービスもあります。KDC は、POSTDATED チケットを発行する際、それに INVALID マークを付けます。アプリケーション クライアントは、使用する前にチケットを KDC に提出し、有効にしなければなりません。
場合によっては、プリンシパルの代わりにサービスが操作を実行できるように許可する必要があります。サービスは、クライアントのID を、ある特定の目的で利用できなければなりません。プリンシパルは、サービスにプロキシを与えることで、ある特定の目的でサービスがプリンシパルの ID を利用できるように許可できます。
通常、チケットの「PROXIABLE フラグ」は、チケット交付サービスのみが解釈します。アプリケーション サーバーは、これを無視できます。PROXIABLE フラグを設定すると、このチケットに基づいた異なるネットワーク アドレスの新しいチケット (チケット交付チケットは不可) を発行してもよいことがチケット交付サーバーに伝えられます。このフラグはデフォルトで設定されます。
このフラグは、クライアントの代わりにリモート要求を実行するためのプロキシを、サーバーに渡すことを許可します。たとえば、プリント サービス クライアントは、印刷要求を実行するため、特定のファイル サーバー上のクライアントのファイルにアクセスするためのプロキシをプリントサーバに与えることができます。
盗まれた信任状を使用しにくくするため、Kerberos チケットは、チケットに明確に記載されたネットワーク アドレスから渡された場合だけ有効になります (ネットワーク アドレスを指定せずにチケットを要求したり発行することもできますが、お勧めできません)。このため、プロキシを与えようとしているクライアントは、プロキシを与えるサービスのネットワーク アドレスで有効な新しいチケットを要求しなければなりません。
PROXY フラグは、TGS が代理チケットを発行する際にチケットに設定されます。アプリケーション サーバーは、監査記録を提供するために、このフラグをチェックしてプロキシを提出したエージェントに追加の認証を要求できます。
認証転送は、クライアントの ID をすべて使用できる権利がサービスに与えられるプロキシの例です。これを使用する例としては、ユーザーが遠隔システムにログインして、ログインがローカルから行われたように、そのシステムで認証を動作させたい場合です。
通常、チケットの「FORWARDABLE フラグ」は、チケット交付サービスのみが解釈します。アプリケーション サーバーはこれを無視できます。「FORWARDABLE フラグ」は、チケット交付チケットが異なるネットワーク アドレスでも発行できること以外は、「PROXIABLE フラグ」と同様に解釈されます。このフラグは、デフォルトではリセットされますが、初回のチケット交付チケットを要求する際に、AS 要求で FORWARDABLE オプションを設定すれば、このフラグを設定するように要求できます。
このフラグを使えば、ユーザーに再びパスワードを入力することを要求せずに、認証を転送できるようになります。フラグが設定されていない場合、認証転送は許可されていません。ただし、ユーザーが要求したネットワーク アドレスと AS 交換を行っていて、パスワードを入力すれば同じ結果が得られます。
「FORWARDED フラグ」は、クライアントが「FORWARDABLE フラグ」が設定されたチケットを提出し、それを設定することを要求した場合 (FORWARDED KDC オプションを指定して新しいチケットの一連のアドレスを提供する) に TGS によって設定されます。またこのフラグは、FORWARDED フラグが設定されたチケットに基づいて発行されたすべてのチケットに設定されます。アプリケーション サーバーによっては、FORWARDED チケットと非 FORWARDED チケットを異なる方法で処理する必要がある場合があります。
クライアントの KDC 要求に設定できる追加オプションは、2つあります。1つは、RENEWABLE-OK オプションです。これは、要求した有効期限のチケットが他の方法で提供されない場合、クライアントが更新可能なチケットを受け入れることを示します。要求した有効期限のチケットが提供されない場合、KDC は、renew-till の値が要求した endtime の値に等しい更新可能なチケットを発行します。renew-till フィールドの値は、サイトで決定されている制限値、または個別のプリンシパルやサーバーの制限によって調整できます。
もう 1つのオプションは、ENC-TKT-IN-SKEY オプションで、これはチケット交付サービスのみが受領します。このオプションは、終端サーバー用に発行すべきチケットは、要求とともに提供した追加のチケット交付チケットのセッション鍵で暗号化する必要があることを示します。詳細については 、3.3.3 節を参照してください。