Kerberos プロトコル v5 においては、様々なオプションをサポートしています。これらの中には、複数の暗号化とチェックサムの種類、転送フィールドの代替符号化スキーマ、事前認証のためのオプションのメカニズム、アドレスが指定されていないチケットの処理、相互認証のオプション、ユーザ間認証、代理チケット／転送チケット／未来の日付のチケット／更新チケットのサポート、レルム名の形式、認定データの処理等があります。
レルムの相互運用性を保証するために、すべての実装がサポートしている最少必要限度の構成を定義する必要があります。この最少必要限度の構成は、テクノロジーの進化とともに変更されることがあります。たとえば、将来、要求した暗号化やチェックサムのアルゴリズムが安全でないことが判明した場合には、それは置き換えられます。
この節においては、これらのオプションの最初の仕様を規定します。この方法で設定した実装は、Kerberos v5 仕様 1 (5.1) をサポートしているということができます。
暗号化方式とチェックサム方式
以下の暗号化方式とチェックサム メカニズムをサポートする必要があります。実装は、他のメカニズムをサポートすることもできます。ただし、追加したメカニズムは、それらをサポートしていることがわかっているプリンシパルと通信する場合だけ使用できます。暗号化方式 ： DES-CBC-MD5 チェックサム方式 ： CRC-32、DES-MAC、DES-MAC-K、DES-MD5
レルム名
すべての実装は、インターネット ドメインと X.500 スタイルの両方に含まれている階層的なレルムを理解している必要があります。不明なレルムのチケット グランティング チケットが要求された場合、KDC は、KDC のレルムと要求されたレルムの間にある中間レルムの名前を判断する必要があります。
転送フィールドの符号化
DOMAIN-X500-COMPRESS (3.3.3.1 節を参照) をサポートしていなければなりません。代替符号化方式をサポートすることもできますが、すべての中間レルムがその符号化方式をサポートしている場合だけ使用できます。
事前認証方式
TGS-REQ 方式をサポートしなければなりません。TGS-REQ 方式は、初回の要求では使用されません。クライアントは、PA-ENC-TIMESTAMP 方式をサポートしていなければなりませんが、それをデフォルトで使用できるようにするか否かは各レルムにおいて判断します。初回の要求で使用せず、PA-ENCTIMESTAMP が利用可能な方式であることを示すエラー KDC_ERR_PREAUTH_REQUIRED が返された場合、クライアントは PA-ENC-TIMESTAMP 事前認証方式を使用して初回の要求を再試行する必要があります。サーバーは、PA-ENC-TIMESTAMP 方式をサポートしている必要はありませんが、サポートしていない場合、要求内の PA-ENC-TIMESTAMP 事前認証の提出を無視する必要があります。
相互認証
相互認証 (KRB_AP_REP メッセージを使用した) をサポートしていなければなりません。
チケットのアドレスとフラグ
すべての KDC は、アドレスが含まれていないチケットを渡さなければなりません 。(例： チケット交付チケットにアドレスが含まれていない場合、KDC は派生チケットを返します。）ただし、レルムは、そのようなチケットを発行するかどうか独自のポリシーを設定できます。また、各アプリケーション サーバーは、それらを受けるかどうかの独自ポリシーを設定できます。デフォルトでは、サーバーはそれらを受領してはいけません。
代理チケットと転送チケットをサポートしていなければなりません。個別のレルムとアプリケーション サーバーは、それらのチケットを受領する状況に関して独自のポリシーを設定できます。
すべての実装は、更新可能なチケットと未来の日付のチケットを認識しなければなりません。ただし、それらを実際に実装している必要はありません。これらのオプションをサポートしていない場合、チケットの starttime と endtime はチケットの有効期限を示します。サーバーが未来の日付のチケットを復号化すると、すべての実装は未来の日付フラグが存在することを呼出し側のサーバーに見えるようにします。
ユーザー間の認証
実装は、ユーザー間の認証をサポートしていなければなりません (ENC-TKTIN-SKEY KDC オプションを使って)。ただし、プリンシパル単位またはレルム全体でそのような要求を拒否するかどうかは、各レルムがポリシーとして決定できます。
認定データ
実装は、登録されているサブフィールド タイプの定義の一部分でサブフィールドの使用が禁止されていない限り、チケット交付チケットのすべての認定データ サブフィールドをあらゆる派生チケットに渡さなければなりません (サブフィールドを渡すのが間違いであることはなく、登録されているサブフィールド タイプで現在 KDC での使用を禁止されているものはありません)。
実装は、チケットが使用されたときにサーバーが使用できるすべての認定データ サブフィールドの内容を作成しなければなりません。実装は、認定データ フィールドの内容をクライアントが指定できるようにする必要はありません。
以下は、推奨設定定数 ( 4.4 節を参照のこと) の一覧に基づいた KDC 実装の推奨値の一覧です。
最小有効期限
5 分 最大更新可能有効期限
1 週間 最大チケット有効期限
1 日 空のアドレス
認定データに適切な制限がある場合だけ 代理可能、その他 可能