3.1. The Authentication Service Exchange (認証サービス交換)
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 メッセージの内容は完全性保護されていません。そのため, クライアントはリプレイ, 捏造, または変更を検出できません。この問題の解決策は, プロトコルの将来のバージョンに含まれます。