3. Message Exchanges (メッセージ交換)

以下のセクションでは, ネットワーククライアントとサーバー間の相互作用と, それらの交換に含まれるメッセージについて説明します。

3.1. The Authentication Service Exchange (認証サービス交換)

概要

メッセージ方向	メッセージタイプ	セクション
1. Client to Kerberos	KRB_AS_REQ	5.4.1
2. Kerberos to client	KRB_AS_REP または KRB_ERROR	5.4.2 / 5.9.1

クライアントと Kerberos 認証サーバー間の Authentication Service (AS) Exchange は, クライアントが特定のサーバーの認証クレデンシャルを取得したいが現在クレデンシャルを保持していない場合にクライアントによって開始されます。基本的な形式では, クライアントの秘密鍵が暗号化と復号化に使用されます。この交換は通常, ログインセッションの開始時に使用され, Ticket-Granting Server のクレデンシャルを取得します。これは後でクライアントの秘密鍵をさらに使用せずに他のサーバーのクレデンシャルを取得するために使用されます (セクション 3.3 を参照)。この交換は, Ticket-Granting Service を介して仲介されるべきではなく, プリンシパルの秘密鍵の知識を必要とするサービス (パスワード変更サービスなど) のクレデンシャルを要求するためにも使用されます (パスワード変更サービスは, 要求者がユーザーの古いパスワードの知識を実証できない限り要求を拒否します。この知識を要求することで, 無人のセッションに近づいた誰かによる不正なパスワード変更を防ぎます)。

この交換それ自体は, ユーザーのアイデンティティの保証を提供しません。ローカルシステムにログオンするユーザーを認証するために, AS 交換で取得されたクレデンシャルは, まず TGS 交換でローカルサーバーのクレデンシャルを取得するために使用されることがあります。その後, それらのクレデンシャルは, Client/Server 交換の正常な完了を通じてローカルサーバーによって検証されなければなりません。

AS 交換は 2 つのメッセージで構成されます: クライアントから Kerberos への KRB_AS_REQ と, 返信の KRB_AS_REP または KRB_ERROR です。これらのメッセージの形式は, セクション 5.4.1, 5.4.2, および 5.9.1 で説明されています。

要求では, クライアントは (平文で) 自分自身のアイデンティティとクレデンシャルを要求しているサーバーのアイデンティティ, 要求しているクレデンシャルに関するその他の情報, およびランダムに生成された nonce を送信します。nonce はリプレイを検出し, 返信を一致する要求に関連付けるために使用できます。この nonce はクライアントによってランダムに生成され (MUST), 期待される返信の nonce と照合するために記憶されなければなりません。応答 KRB_AS_REP には, クライアントがサーバーに提示するチケットと, クライアントとサーバーによって共有されるセッションキーが含まれます。セッションキーと追加情報は, クライアントの秘密鍵で暗号化されます。KRB_AS_REP メッセージの暗号化された部分には, KRB_AS_REQ メッセージの nonce と一致しなければならない (MUST) nonce も含まれます。

事前認証がない場合, 認証サーバーは, クライアントが実際に要求で指定されたプリンシパルであるかどうかを知りません。同じであるかどうかを知らずまたは気にせずに単に返信を送信します。これは受け入れられます。なぜなら, 要求でアイデンティティが与えられたプリンシパル以外の誰も返信を使用できないからです。その重要な情報は, そのプリンシパルのキーで暗号化されています。ただし, 攻撃者は KRB_AS_REQ メッセージを送信して, プリンシパルのキーを攻撃するための既知の平文を取得できます。特にキーがパスワードに基づいている場合, これはセキュリティ上の問題を引き起こす可能性があります。したがって, 初期要求は, 初期交換に必要な可能性がある追加情報を渡すために使用できるオプションのフィールドをサポートします。このフィールドは, セクション 3.1.1 および 5.2.7 で説明されているように事前認証に使用されるべきです (SHOULD)。

さまざまなエラーが発生する可能性があります。これらは KRB_AS_REP 応答の代わりにエラー応答 (KRB_ERROR) で示されます。エラーメッセージは暗号化されていません。KRB_ERROR メッセージには, それが返信するメッセージに関連付けるために使用できる情報が含まれています。KRB_ERROR メッセージの内容は整合性保護されていません。そのため, クライアントはリプレイ, 捏造, または変更を検出できません。この問題の解決策は, プロトコルの将来のバージョンに含まれる予定です。

3.1.1. Generation of KRB_AS_REQ Message (KRB_AS_REQ メッセージの生成)

クライアントは, 初期要求でいくつかのオプションを指定できます。これらのオプションには, 事前認証が実行されるかどうか, 要求されたチケットが更新可能, プロキシ可能, または転送可能であるかどうか, ポストデートされるべきか派生チケットのポストデートを許可すべきか, および要求されたチケットの有効期限が更新不可能なチケットで満たせない場合に更新不可能なチケットの代わりに更新可能なチケットが受け入れられるかどうか (構成制約による) が含まれます。

クライアントは KRB_AS_REQ メッセージを準備し, KDC に送信します。

3.1.2. Receipt of KRB_AS_REQ Message (KRB_AS_REQ メッセージの受信)

すべてがうまくいけば, KRB_AS_REQ メッセージの処理により, クライアントがサーバーに提示するチケットが作成されます。チケットの形式はセクション 5.3 で説明されています。

Kerberos は UDP などの信頼性の低いトランスポート上で実行できるため, KDC は応答が失われた場合に備えて応答を再送信する準備ができていなければなりません (MUST)。KDC が最近正常に処理した要求と同一の要求を受信した場合, KDC はリプレイエラーではなく KRB_AS_REP メッセージで応答しなければなりません (MUST)。潜在的な攻撃者に与えられる暗号文を削減するために, KDC は要求が最初に処理された時に生成された同じ応答を送信してもよい (MAY) です。実際に使用されているトランスポートが信頼性がある場合でも, KDC はこのリプレイ動作に従わなければなりません (MUST)。

3.1.3. Generation of KRB_AS_REP Message (KRB_AS_REP メッセージの生成)

認証サーバーは, KRB_AS_REQ で指定されたクライアントとサーバーのプリンシパルをデータベースで検索し, それぞれのキーを抽出します。要求で指定された要求されたクライアントプリンシパルが KDC のプリンシパルデータベースに存在しないために未知である場合, KDC_ERR_C_PRINCIPAL_UNKNOWN のコードを持つエラーメッセージが返されます。

そうする必要がある場合, サーバーは要求を事前認証し, 事前認証チェックが失敗した場合, KDC_ERR_PREAUTH_FAILED のコードを持つエラーメッセージが返されます。事前認証が必要であるが要求に存在しない場合, KDC_ERR_PREAUTH_REQUIRED のコードを持つエラーメッセージが返され, METHOD-DATA オブジェクトが KRB-ERROR メッセージの e-data フィールドに格納され, どの事前認証メカニズムが受け入れられるかを指定します。通常, これには以下で説明する PA-ETYPE-INFO および/または PA-ETYPE-INFO2 要素が含まれます。サーバーがクライアントによって要求された暗号化タイプに対応できない場合, KDC_ERR_ETYPE_NOSUPP のコードを持つエラーメッセージが返されます。それ以外の場合, KDC は 'ランダムな' セッションキーを生成します。これは, とりわけ, 過去のセッションキーの知識に基づいて次のセッションキーを推測することが不可能であるべきであることを意味します。これは暗号化原理に基づいている場合は疑似乱数生成器で達成できますが, ランダムな物理現象の測定に基づくものなど, 真のランダム数生成器を使用することがより望ましいです。ランダム性の詳細な議論については [RFC4086] を参照してください。

AS 要求に応答して, Kerberos データベースにクライアント用に複数の暗号化キーが登録されている場合, AS 要求の etype フィールドが KDC によって使用され, クライアントに送信される KRB_AS_REP メッセージの暗号化された部分を保護するために使用される暗号化方法を選択します。etype リストに複数のサポートされている強力な暗号化タイプがある場合, KDC は暗号化キーが利用可能な最初の有効な強力な etype を使用すべきです (SHOULD)。

ユーザーのキーがパスワードまたはパスフレーズから生成される場合, [RFC3961] で指定されているように, 特定の暗号化キータイプの文字列からキーへの関数が使用されます。文字列からキーへの関数のソルト値と追加パラメータには, 事前認証データ (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, PA-ETYPE-INFO2 など) によって上書きされることがあるデフォルト値 (セクション 4 および暗号化メカニズム仕様でそれぞれ指定) があります。KDC は結果のキーのコピーのみを保存すると推定されるため, これらの値は, プリンシパルのキーを変更する場合を除いて, パスワードベースのキーでは変更されるべきではありません。

AS サーバーが KRB-ERROR または AS-REP に事前認証データを含める場合, クライアントの AS-REQ の etype フィールドが少なくとも 1 つの "より新しい" 暗号化タイプをリストしている場合, PA-ETYPE-INFO ではなく PA-ETYPE-INFO2 を使用しなければなりません (MUST)。それ以外の場合 (クライアントの AS-REQ の etype フィールドが "より新しい" 暗号化タイプをリストしていない場合), PA-ETYPE-INFO2 と PA-ETYPE-INFO の両方を送信しなければなりません (MUST) (両方とも各 enctype のエントリを含む)。"より新しい" enctype は, この RFC の発行と同時またはそれ以降に最初に正式に指定された任意の enctype です。enctype DES, 3DES, または RC4 および [RFC1510] で定義されたものは "より新しい" enctype ではありません。

KDC に連絡せずにパスフレーズからユーザーのキーを確実に生成することはできません。代替ソルトまたはパラメータ値が必要かどうかがわからないためです。

KDC は, etype フィールドのメソッドのリストからランダムセッションキーのタイプを割り当てようとします。KDC は, 提供されたメソッドのリストと, アプリケーションサーバーの許容可能な暗号化メソッドを示す Kerberos データベースからの情報を使用して, 適切なタイプを選択します。KDC は, 弱いセッションキー暗号化タイプでチケットを発行しません。

要求された starttime が存在しない場合, 過去の時刻を示す場合, または KDC の許容可能なクロックスキューのウィンドウ内であり, POSTDATE オプションが指定されていない場合, チケットの starttime は認証サーバーの現在時刻に設定されます。許容可能なクロックスキューを超える将来の時刻を示しているが, POSTDATED オプションが指定されていない場合, KDC_ERR_CANNOT_POSTDATE エラーが返されます。それ以外の場合, 要求された starttime はローカルレルムのポリシーに対してチェックされます (管理者は特定のタイプまたは範囲のポストデートチケットを禁止することを決定するかもしれません)。チケットの starttime が許容可能である場合, 要求されたとおりに設定され, 新しいチケットに INVALID フラグが設定されます。ポストデートチケットは, starttime に到達した後に KDC に提示することによって使用前に検証されなければなりません (MUST)。

チケットの有効期限は, 要求された endtime と, ローカルポリシーによって決定された時刻 (レルムまたはプリンシパル固有の要素を使用する可能性があります) の早い方に設定されます。たとえば, 有効期限は以下の最も早い時刻に設定されてもよい (MAY) です:

KRB_AS_REQ メッセージで要求された有効期限 (endtime)。
チケットの starttime に, 認証サーバーのデータベースからのクライアントプリンシパルに関連付けられた最大許容ライフタイムを加えたもの。
チケットの starttime に, サーバープリンシパルに関連付けられた最大許容ライフタイムを加えたもの。
チケットの starttime に, ローカルレルムのポリシーによって設定された最大ライフタイムを加えたもの。

要求された有効期限から starttime を引いたもの (上記で決定されたとおり) がサイト決定の最小ライフタイムより短い場合, KDC_ERR_NEVER_VALID のコードを持つエラーメッセージが返されます。チケットの要求された有効期限が上記で決定されたものを超え, 'RENEWABLE-OK' オプションが要求された場合, 新しいチケットに 'RENEWABLE' フラグが設定され, renew-till 値は 'RENEWABLE' オプションが要求されたかのように設定されます (フィールドとオプション名はセクション 5.4.1 で完全に説明されています)。

RENEWABLE オプションが要求された場合, または RENEWABLE-OK オプションが設定されていて更新可能なチケットが発行される場合, renew-till フィールドは以下の最も早い時刻に設定されてもよい (MAY) です:

その要求された値。
チケットの starttime に, プリンシパルのデータベースエントリに関連付けられた 2 つの最大更新可能ライフタイムの最小値を加えたもの。
チケットの starttime に, ローカルレルムのポリシーによって設定された最大更新可能ライフタイムを加えたもの。

新しいチケットの flags フィールドには, 要求されていてローカルレルムのポリシーが許可する場合, 以下のオプションが設定されます: FORWARDABLE, MAY-POSTDATE, POSTDATED, PROXIABLE, RENEWABLE。新しいチケットがポストデートされている場合 (starttime が将来にある場合), その INVALID フラグも設定されます。

上記のすべてが成功した場合, サーバーは, サーバープリンシパルのキーに関連付けられた暗号化タイプを使用して, Kerberos データベースのサーバープリンシパルのレコードから抽出された暗号化キーを使用してチケットの暗号文部分を暗号化します。(この選択は要求の etype フィールドによって影響を受けません。) 次に, KRB_AS_REP メッセージをフォーマットし (セクション 5.4.2 を参照), 要求のアドレスを応答の caddr にコピーし, 必要な事前認証データを応答の padata に配置し, 要求の etype フィールドで要求された許容可能な暗号化メソッドを使用するか, または使用されている事前認証メカニズムによって指定されたキーでクライアントのキーを使用して暗号文部分を暗号化します。

3.1.4. Generation of KRB_ERROR Message (KRB_ERROR メッセージの生成)

いくつかのエラーが発生する可能性があり, Authentication Server はエラーメッセージ KRB_ERROR をクライアントに返すことによって応答します。error-code および e-text フィールドは適切な値に設定されます。エラーメッセージの内容と詳細はセクション 5.9.1 で説明されています。

3.1.5. Receipt of KRB_AS_REP Message (KRB_AS_REP メッセージの受信)

返信メッセージタイプが KRB_AS_REP である場合, クライアントは返信の平文部分の cname および crealm フィールドが要求したものと一致することを検証します。padata フィールドが存在する場合, それらは暗号化された部分を復号化するための適切な秘密鍵を導出するために使用されることがあります。

クライアントは秘密鍵を使用して応答の暗号化された部分を復号化し, 暗号化された部分の nonce が要求で提供した nonce と一致することを検証します (リプレイを検出するため)。また, 応答の sname および srealm が要求のものと一致する (またはそれ以外の期待される値である) こと, およびホストアドレスフィールドも正しいことを検証します。その後, チケット, セッションキー, 開始時刻と有効期限, およびその他の情報を後で使用するために保存します。応答の暗号化された部分からの last-req フィールド (および廃止された key-expiration フィールド) は, ユーザーに差し迫ったキーの有効期限を通知するためにチェックされてもよい (MAY) です。これにより, クライアントプログラムはパスワード変更などの是正措置を提案できます。

KRB_AS_REP メッセージの検証時 (返された nonce を KRB_AS_REQ メッセージで送信されたものと照合することによって), クライアントは KDC の現在時刻が返信の暗号化された部分の authtime フィールドから読み取られたものであることを知ります。クライアントは, オプションでこの値を使用して, authtime 値とローカルクロック間の差 (オフセット) をチケットと共に記録することによって, 後続のメッセージでクロック同期を行うことができます。このオフセットは, 同じユーザーがメッセージを生成する際にシステムクロックから読み取った時刻を調整するために使用できます [DGT96]。

この技術は, システムクロックを直接変更する代わりにクロックスキューを調整する際に使用されなければなりません (MUST)。なぜなら, KDC の返信は秘密鍵が使用されたユーザーにのみ認証されており, システムまたはワークステーションには認証されていないためです。クロックが調整された場合, ワークステーションにログインするユーザーと共謀する攻撃者がパスワードに同意し, ワークステーションによって信頼される KDC から発信されていなくても正しく検証される KDC 返信をもたらす可能性があります。

KRB_AS_REP メッセージの適切な復号化は, ホストがユーザーのアイデンティティを検証するのに十分ではありません。ユーザーと攻撃者は協力して, 適切に復号化されるが適切な KDC からのものではない KRB_AS_REP 形式のメッセージを生成できます。ホストがユーザーのアイデンティティを検証したい場合, ユーザーに, ホストの安全に保存された秘密鍵を使用して検証できるアプリケーションクレデンシャルを提示することを要求しなければなりません (MUST)。それらのクレデンシャルが検証できる場合, ユーザーのアイデンティティを保証できます。

3.1.6. Receipt of KRB_ERROR Message (KRB_ERROR メッセージの受信)

返信メッセージタイプが KRB_ERROR である場合, クライアントはそれをエラーとして解釈し, 回復に必要なアプリケーション固有のタスクを実行します。

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

概要

メッセージ方向	メッセージタイプ	セクション
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 認証 (CS) 交換は, クライアントをサーバーに認証し, その逆を行うためにネットワークアプリケーションによって使用されます。クライアントは, 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) です。チケットを使用するために, クライアントはシステム時刻と自分の名前から新しい Authenticator を構築し, オプションでアプリケーション固有のチェックサム, KRB_SAFE または KRB_PRIV メッセージで使用される初期シーケンス番号, および/またはこの特定のセッションに固有のセッションキーのネゴシエーションで使用されるセッションサブキーから構築します。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 からのセッションキーで暗号化されていることを示します。すべてのメッセージに対するユーザー間認証の影響のより完全な説明については, セクション 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 エラーが返されます。それ以外の場合, 現在時刻が end time より許容可能なクロックスキューを超えて後である場合, 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 つの方法は次のとおりです。