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

Summary (概要)

Message direction (メッセージ方向)	Message type (メッセージタイプ)	Section (セクション)
1. Client to Kerberos (クライアントから Kerberos へ)	KRB_AS_REQ	5.4.1
2. Kerberos to client (Kerberos からクライアントへ)	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] で指定されているように, 特定の暗号化鍵タイプの文字列から鍵への関数が使用されます。文字列から鍵への関数の salt 値と追加パラメータには, 事前認証データ (PA-PW-SALT, PA-AFS3-SALT, PA-ETYPE-INFO, PA-ETYPE-INFO2 など) によってオーバーライドされる場合があるデフォルト値 (それぞれセクション 4 および暗号化メカニズム仕様で指定) があります。KDC は結果の鍵のコピーのみを保存すると推定されるため, これらの値は, プリンシパルの鍵を変更する場合を除いて, パスワードベースの鍵に対して変更されるべきではありません。

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

パスフレーズが与えられてユーザーの鍵を確実に生成することは, KDC に連絡せずには不可能です。代替の salt またはパラメータ値が必要かどうかがわからないためです。

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

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

チケットの有効期限は, 要求された終了時刻と, おそらくレルムまたはプリンシパル固有の要因を使用して, ローカルポリシーによって決定される時刻のうち早い方に設定されます。たとえば, 有効期限は以下の最も早いものに設定される場合があります (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 メッセージの生成)]

いくつかのエラーが発生する可能性があり, 認証サーバーは, error-code および e-text フィールドを適切な値に設定して, エラーメッセージ KRB_ERROR をクライアントに返すことによって応答します。エラーメッセージの内容と詳細は, セクション 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 メッセージの検証時 (KRB_AS_REQ メッセージで送信された nonce に対して返された nonce をチェックすることによって), クライアントは, 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 の場合, クライアントはそれをエラーとして解釈し, 回復に必要なアプリケーション固有のタスクを実行します。