• 検索結果がありません。

対称鍵による認証

ドキュメント内 「本人認証の現状に関する調査報告書」 (ページ 87-91)

3 認証技術の標準化動向

3.1. ネットワーク認証プロトコル及び API 標準

3.1.4 対称鍵による認証

(2) ASからクライアントへの返答(KRB_REP)

ASはクライアントとTGSが共有するセッション鍵を作成し、TGSへ渡すチ ケットをTGSとKDCが共有する対称鍵で暗号化し(これがTGTとなる)、そ れら全てをまとめてKDCとクライアント間で共有している対称鍵で暗号化し てクライアントへ返す。

TGTの中にはクライアントのIDとクライアントとTGSが共有するセッシ ョン鍵が入っている。

エラーが発生した場合はKRB_REPの代わりにKRB_ERRORを返す

(3) クライアントからTGSへの要求(KRB_TGS_REQ、KRB_TGS_REP) クライアントはTGTをTGSに提出する。

TGSはKDCとTGSが共有している対称鍵でTGTを複合化し、クライアン トのIDとセッション鍵を取り出す。そして、クライアントが要求するサーバ ーと通信するためのチケットを作成する。(TGSはクライアントとサーバーが 共有するセッション鍵を作成し、サーバーへ渡すチケットをサーバーとKDC が共有する対称鍵で暗号化し(これがチケットとなる)、それら全てをまとめて KDCとクライアント間で共有している対称鍵で暗号化してクライアントへ返 す。チケットの中にはクライアントのIDとクライアントとサーバーが共有す るセッション鍵が入っている。

(4) クライアント/サーバー通信開始(KRB_AP_REQ、KRB_AP_REP) 目的のサーバーと通信するためのチケットを取得したクライアントはサーバ ーとの通信が可能になる。

クライアントが違うサーバーと通信を行いたい場合はTGSにその要求を出 す。TGTが有効である限り、ASとやりとりを行う必要はない。

Kerberos環境での注意点。

クライアントがサーバーへ送るチケットは攻撃者によって盗まれて再利用さ れることを防ぐために追加情報としてタイムスタンプを含んだ暗号化したデー タを送る。この情報は 、認証子と呼ばれる。このため、Kerberosに参加する 各ホストは時間の同期を取る必要がある。

クライアントとTGS間でのTGT交換は、クライアントが目的サーバーのチ ケット取得を希望する場合のほかに、既存のチケットの更新や有効化、代理チ ケット取得の場合、実施される。

Kerberosデータベース

Kerberosサーバーは、認証するプリンシパルのプリンシパル識別子と対称鍵

を含んでいるデータベースを持つ。表 3-2に示す。

表  3‑ 2    Ker ber os   DB 

フィールド  値 

name  プリンシパルの識別子  key  プリンシパルの対称鍵 

p_kvno  プリンシパルの鍵のバージョン 

max_life チケットの最大有効期限

max_renewable_life 新可能なチケットの最大合計有効期限

鍵が定期的に変更されている場合、その鍵を使って発行されたすべてのチケ ットの有効期間が満了するまで、サーバーは古い鍵を保管する。このため、1 つのプリンシパルに対して複数の鍵が有効になることもある。

以下は追加フィールド。表 3-3 Kerberos DB追加フィールドに示す。

表  3‑ 3    Ker ber os   DB 追加フィールド 

フィールド  値 

K_kvno  Kerberos の鍵バージョン 

expiration  エントリの満了日 

attributes  属性のビット フィールド 

mod_date 最後に行われた修正のタイムスタンプ

mod_name プリンシパルの識別子の修正

K_kvnoフィールドは、プリンシパルの対称鍵を暗号化するために使用する

Kerberosのマスター鍵の鍵バージョンを示す。

Expirationはエントリの満了日で、これを過ぎると、KDCはプリンシパル

として、又はプリンシパル用にチケットを取得しようとするあらゆるクライア ントにエラーを返す 。

attributesフィールドは、プリンシパルを含む操作を統括するのに使用する

ビットフィールド。

mod_date フィールドには、エントリの最終修正時刻が入っている。

mod_name フィールドはエントリを最後に修正したプリンシパルの名前が

入っている。

3.1.4.2 Kerberos V5 GSSAPI メカニズム(RFC1964)

Kerberos V5 GSSAPIメカニズム(The Kerberos Version 5 GSS-API Mechanism)は、3.1.4.1で述べたKerberos V5のメカニズムをGSS-APIの フレームワークで利用する方法を定めている。

GSS-APIは3.1.1.2で述べたように通信アプリケーション間の安全なメッセ

ージ交換に使用されされる汎用的なセキュリティのAPIを定めたものである。

この仕様は、Kerberos V5をGSS-APIのもとで利用するためのプロトコル、

手続、規定を定める。

このRFC1964ではKerberos V5をセキュリティ機構に採用した場合の、ピ ア間でメッセージを交換するための各トークン形式、名前形式、パラメータに 関する定義がされている。

また、ここでは、相互運用性のためのプロトコルの要素を定義しているので、

RFC1509のGSS-API C言語バインド(Generic Security Service Application Program Interface: C-bindings)には依存しない汎用的な仕様となっている。

トークンはGSS-APIピア間で交換するプロトコルのフォーマットを定めた ものである。トークンにはセッションを確立する際のセキュリティ・コンテク スト管理と、セッションが確立した後のメッセージ毎の保護がある。この仕様

はKerberosのKDCとのチケットの授受に関するものではなく、エンドポイン

トであるクライアント/サーバー間の認証やメッセージの保護に関する仕様の みを定めたものである。

本仕様で定めるトークンには「コンテクスト確立トークン」、「メッセージ毎 のトークン」、「コンテクスト終了トークン」がある。

・コンテクスト確立トークン

ここでは初期トークンとしてイニシエータとターゲット間での要求・応答 のトークン仕様であるチケットや鍵の暗号部分のフォーマットを定め、その 要 求 GSS-API 呼 出 し gss_init_sec_context( )と 応 答 GSS=API 呼 出 し gss_accept_contxt( )で用いる。

・メッセージ毎のトークン

メッセージの認証のためのGSS-API呼出しgss_getMIC( )と検証のための gss_veryfyMIC( )で用いるトークン仕様を定める。ここでは Kerberos セッ ション鍵と鍵配布のための秘匿鍵などを扱うフォーマットを定める。ピア間 の認証(1方向、双方向)にこのトークンが用いられる。

またメッセージの秘匿のためのGSS-API呼出しgss_rap( )、復号のための GSS-API呼出しgss_unwrap( )呼出しのためのトークン仕様も定める。

・コンテクスト終了トークン

セッションの終了を行うための GSS-API 呼出し gss_delete_context( )お よび確認の呼出しgss_process_context( )のためのトークン仕様も定める。

Kerberos v5 GSS-APIはKerberosの巧妙で複雑な認証やデータ秘匿のメカ ニズムを汎用的なAPIで抽象化し、クライアント/サーバーでのアプリケーシ ョン間で、セッションの認証やメッセージの秘匿の標準的な手段を与える。

3.1.5 公開鍵による認証

ドキュメント内 「本人認証の現状に関する調査報告書」 (ページ 87-91)