Ｋｅｒｂｅｒｏｓ（ケルベロス）入門 計算力学研究センター 技術開発部 桑村 潤 1 Kerberos の概要 1.1 Kerberos の歴史 Kerberos は オープンネットワークシステムのための認証プロトコルで、 マサチューセッツ工科大学(MIT:Massachusetts Institute of Technology)の アテナプロジェクト(Project Athena)で開発されました。 オープンネットワークシステムは、 デジタル社会(*5)、 サイバースペース などと呼ばれている領域で、ネットワークを介して コンピュータが相互に接続されて利用されているよ うな環境のことです。 アテナプロジェクトは1983年にMITが、 DEC(Digital Equipmet Corporation)と IBM(International Business Machines Corporation)と の共同研究として始めた、分散環境での計算システムの研究開発 プロジェクトで、サーバ-クライアント・モデルのウィンドウシス テムを代表する X Window System を開発したことでも有名です。 そのオープンで安全な分散システムの片翼となるのが認証システム です。 Kerberos は認証方式には、 1978年に R. Needham と M. Schroeder によって提唱された 鍵配布モデルに基づく「信頼のおける第三者機関による認証」 ("Trusted Third Party Authentication") の概念を採用し、 Miller と C. Neuman により設計されました。 Kerberos は 暗号プロトコルに 対称鍵方式の DES(Data Encryption Standard) を使用しました。 DES は米国商務省標準局(NBS:National Bureau of Standard)の 1973年の公募に対する IBM からの提案をもとに 1977 年に公布された対称鍵（共通鍵）ブロック暗号方式の データ暗号化標準プロトコルです。 アメリカ合州国政府により合州国およびカナダ 以外への国への持ち出しが規制されています。 合州国とカナダ国以外の国への持ち出しには 1994年までのCOCOMや 1996年からのワッセナー協定の規制により 合州国政府の許可が必要とされます。 そのような理由から、 Kerberos はバージョン4 になって MIT 以外にも公開されるようになりましたが、 アメリカ合州国とカナダ以外で自由に利用できるのは DES を取り除いた Bones と呼ばれるコードでした(*1)。 Bones は、piranha というプログラムを使って Kerberos の肉の部分にあたる DES を取り除いて、骨だけにしたものといわれています。 現在 MIT ではバージョン５の開発が行なわれています。 (最新リリースは Kerberos 5 Release 1.2.2) バージョン５とバージョン４との間のプロトコルに互換性はありませんが、 バージョン５をバージョン４のプロトコルで運用する設定は可能です。 バージョン５では DES 以外の暗号化プロトコルにも対応していますが、 アメリカ合州国とカナダ以外の国にはドキュメントのみ公開されています。 現在、アメリカ合州国とカナダ以外の国から入手できるのは Bones に オーストラリアでコーディングされた DES と同等の暗号化モジュールを付け加えた eBones というコードで、アメリカ合州国とカナダ以外の国からダウンロードすれば 利用が可能なようです(*2)。 スウェーデンのストックホルム王立研究所(KTH) では eBones に拡張を加えた KTH 版 Kerberos4(KTH-KRB)と Kerberos5のもう一つの実装である Heimdal を開発し 配布しています(*3)。 また、ヨーロッパ共同体ではSESAME というオープン・システムが ECMA(European Computer Manufacturers Association)で共同開発 されました(*4)。 古代ギリシャ神話で Kerberos は（ローマ神話では Cerberus）、 冥界の王（支配者）ハデスが飼う ３つの犬の頭、 １本の龍の尻尾、 背中にはあらゆる種類の蛇の頭 を持った冥界の門の番犬のことです。 ハリポタ版妖精幻獣事典による開設： http://www.harrypotterfan.net/quill/fairy/files/cerberos.html この犬の３つの頭は 認証、 承認、 監査 を象徴するそうです。 Kerberos には 認証の機能は当初の目的として実装されましたが(Kerberos4)、 後の２つは最新版のプロトコル(Kerberos5)になってから、 間接的に提供されるようになりました。 認証システムとは、話かけてきた人が本当にその本人なのか、あるい は、話かけようとしている人が本当にその本人なのかを証明するシス テムです。日常生活では、運転免許証の場合は顔写真で、クレジット カードの場合は署名で本人であることを証明しています。 -- (*1) ftp://athena-dist.mit.edu/pub/ATHENA/kerberos (*2) ftp://ftp.funet.fi/pub/unix/security/login/kerberos (*3) http://www.pdc.kth.se/kth-krb/ (*4) http://www.esat.kuleuven.ac.be/~vdwauver/sesame.html (*5) http://www.npa.go.jp/hightech/sec_repo/title.htm http://www.mpt.go.jp/policyreports/japanese/group/internet/ninshou/index.html 1.2 Kerberos に対する要求 Kerberos に求められたのは、 大学の学内（企業の部門内）のようなオープンなネットワークにおいて 情報の安全性を維持することでした。 大学や企業などで普及したイーサネットのような ブロードキャスト型のネットワーク上で、 クライアント／サーバモデルを採用した分散環境では、 ネットワークを流れる情報は、 容易に盗聴、改竄、偽造の対象となります。そうした状況下で 情報の安全性（セキュリティ）を維持するための暗号プロトコルです。 そして、Kerberos の設計にあたっては以下のような事柄が考慮されました。 o 一方向のみでなく双方向の認証の機能も備えること。通常はサーバに対す るクライアントの認証を行ない、クライアントの要求がある場合はサーバの 認証もおこなえるようにする。 o パスワードはユーザの認証が終れば消し去ること。クライアントがサーバ からサービスを受ける場合には認証を受けるためにパスワードがそのまま ネットワーク上を流れることのないようにする。 o 鍵を盗み出された場合にその鍵を用いて暗号が解読される危険を抑制する ために、暗号化に用いる鍵に寿命（有効期限）を設ける。 o ネットワークを流れるあらゆる情報を暗号化することを可能にすること。 o 暗号化ロジックをすべてのホストに組み込まずに済ませ、認証関係の情報 をデータベース化し集中管理するために、暗号化サーバを設けること。 o 認証はユーザがログインを行なう時のみとし、ユーザがそのことに気がつ かなくてもすむようにすること。 o このシステムを導入するのための労力を最低限に抑えること。 1.3 Kerberos の基本概念 Kerberos システムの構成は、 サーバへのチケットを含む証明書を発行する 鍵発行局(KDC: Key Distribution Center)と、 その KDC が管理（支配）する複数の クライアントと サーバを含む レルム(Realm)（王国、領域）からなります。 クライアント（ユーザとアプリケーション）と サーバ（アプリケーション）を総称して プリンシパル(Principals)（長(おさ？)、主体）と言います。 Kerbero で採用された「信頼のおける第3者機関による認証」の基本的な枠組は、 クライアントがサービスを利用したい場合、 クライアントは KDC にサービスを利用するための チケット（切符(ticket)）を求めて手に入れ、 KDC から授かったサービスを受けるためのチケットをサーバに提出し、 そのサービスを受けます。 ┌───┐ 　│ＫＤＣ│ └───┘ ↑ ｜(2) (1)│ ↓ ┌──────┐ (3) ┌────┐ │クライアント│──→│サービス│ └──────┘ └────┘ (1) サービスへのチケットを要求 (2) サービスへのチケット入手 (3) サービスへチケットの提出 このモデルでは次のような不都合が起こり得ます。 ここで、KDC から入手したサービスへのチケットが、 他者による流用を避けるために、 クライアントの秘密鍵で暗号化されているとすると、 クライアントはこのチケットを復号化するために 自分の秘密鍵を使うことになります。 もし、クライアントが別のサーバを使いたい場合は同様にして、 その別のサービスのためのチケットを復号化するために、 クライアントは再び自分の秘密鍵を使うこととなります。 クライアントはサービスが異なる毎にその秘密鍵を入力するのが不便なので、 便宜上その秘密鍵をキャッシュすることになります。 こうなると、そのクライアントの秘密鍵は漏洩し易くなり、 Kerberos システムの初期の目的を達成できなくなってしまいます。 そこで、取り入れられたのが TGT (Ticket-Granting Ticket) （発券許可証明書、チケット認可チケット）です。 まず、クライアントは 認証サーバ(AS: Authentication Server)から TGT を取得し、 次に、クライアントはその TGT を TGS(Ticket-Granting Server)（許可証明書発行サーバ）に提出して、 目的のサービスを利用するためのチケット（サーバ使用許可証）を取得し、 最後に、クライアントは このチケット（サーバ使用許可証）を目的のサービスへ提出して サービスを利用します。 この際、Kerberos システムでは KDC が、 AS としての役割と TGS としての役割と の２つの役割を果たします。 ┌──────────────────┐ │┌───┐ ＫＤＣ ┌───┐│ ││ ＡＳ │ │ＴＧＳ││ │└───┘ ,─→└───┘│ └─↑ ｜──────／──／ ────┘ (1)│ ｜(2) (3)／ ／(4) │ ↓ ＴＧＴ ／ ／ サービスチケット ┌──────┐←─' ┌───┐ │クライアント│────→│サーバ│ └──────┘ (5) └───┘ (1) ＴＧＴの要求 (2) ＴＧＴの入手 (3) ＴＧＴを提出してサービスチケットを要求 (4) サービスチケット入手 (5) サービスチケットを提出しサービスを要求 もし、クライアントが別のサービスも利用したい場合には、 既に AS から入手している TGT を再び TGS に提出し、 別のサービスを利用するためのチケットを入手することができます。 TGT はクライアントの秘密鍵から作られますが、 作る度に毎回異なり秘密鍵そのものではないので キャッシュして再利用しても比較的安全です。 TGT にはその利用期限が定められていて、 期限が切れるまでは何回も再利用ができます。 身近な例の紹介 ------------------------------------------------------------------------ この例は適当ではないかも知れませんが、たとえば身近な例でいうと、車や 家を購入するときには、契約に使う捺印の他に印鑑登録証明書が必要です。お 役所の登録窓口で印鑑登録をして印鑑登録証を発行してもらうと、車や家を購 入するために印鑑登録証明書が必要になったときにはその印鑑登録証を持って お役所の証明書発行窓口に行くと、その目的のために印鑑登録証明書を発行し てもらえます。そして、契約のために捺印をした書類と印鑑登録証明書を提出 します。 この例では、KDC（いわゆる信頼のおける第三者機関というもの）がお役所 というわけです。そして、印鑑登録証は TGT の役割を果たしているわけです。 ┌────────────────────┐ │┌────┐ お役所 ┌───────┐│ ││登録窓口│ │証明書発行窓口││ │└────┘ ,─→└───────┘│ └─ ↑ │ ───／──／ ────────┘ (1)│ │(2) ／(3) ／(4) │ ↓ ／ ／ ┌───┐←─' ┌───┐ │依頼人│────→│契約先│ └───┘ (5) └───┘ (1) 印鑑登録を行なう (2) 印鑑登録証の入手 (3) 印鑑登録証を提出して印鑑登録証明書を要求 (4) 印鑑登録証明書の入手 (5) 契約先に印鑑登録証明書を捺印と共に提出 ---------------------------------------------------------------------- 1.4 用語の整理 ユーザ: User。 プログラムあるいはサービスの利用者。 クライアント: Client。 ユーザのこと、あるいは、サーバ-クライアント・アプリケーション のクライアント側プログラム。利用者となるプリンシパル。 サーバ: Server。 サーバ-クライアント・アプリケーションのサーバ側プログラム。 ネットワーク クライアントにリソースを提供する特定のプリンシパル。 サービス: Service。 サービスプログラムあるいはその内容。 レルム: Realm。（王国） Kerberos の管理するネットワークの領域の単位を表す言葉。便宜上、 DNS（ドメインネームシステム）のドメインをレルムの単位として用い ることが多い。 プリンシパル: Principal。（長） そのレルムに参加する主体のことでクライアントとサーバの総称。 Kerberos システムから見ればどちらもクライアントとなるため、一般 的にいうところのサーバやクライアントと区別するための呼び方。 KDC: Key Distribution Center。（鍵発行局） 理論的にその機能によって AS と TGS とにわけられますが、物理的 には区別はなく同じ Kerberos サーバプログラムが処理を行う。 AS: Authentication Server。（認証サーバ） クライアントの要求を受けてクライアントの認証を行ない、そのクラ イアントに TGT を発行します。 TGT: Ticket Granting Ticket。（発券許可証明書） サーバ使用許可証を発行してもらうときに TGS に提示するチケット。 AS(KDC) から発行されます。 （チケット-認可・チケット） TGS: Ticket Granting Server。（許可証明書発行サーバ） クライアントの提出した TGT を調べてクライアントに対しサーバの 利用を認可し、サーバ使用許可証明書を発行します。 （チケット-認可・サーバ） DES: Data Encryption Standard。 対称鍵（共通鍵）ブロック暗号方式のデータ暗号化標準プロトコルで、 56 ビットの鍵長を持ち、 平文を 64 ビットのブロック長に分割し、 ブロック毎に多段階の排他的論理和で暗号化します。 秘密鍵(共有鍵): プリンシパルと KDC が共有する有効期限の長い暗号化鍵。システム 領域外で配布される。ユーザーのプリンシパルの場合は、秘密鍵はパ スワードから取り出される。 セッション鍵: Session Key 2つのプリンシパル間で使用される一時的な暗号化鍵。 チケット: Ticket クライアントが、サーバーへ自分自身を認証させるためのレコード。 クライアントの ID 、セッション鍵、タイムスタンプ、その他の情報 を含んでいて、サーバーの秘密鍵ですべて封印されている。新しい 認証子とともに提出したときだけ、クライアントが認証される。 2. Kerberos の実際 実際の Kerberos にはもともとの「信頼のおける第三者機関による認証」の モデルにタイムスタンプ（現在の日付と時刻）が付加されて、メッセージが盗 まれた場合のリプレイ攻撃に対しての予防をしています。 Kerberos はクライアントの名前とそのプライベート鍵とを含むデータベー スを持ちます。プライベート鍵は大きな値の数で Kerberos とクライアントの みが知り得ます。クライアントがユーザの場合、プライベート鍵はパスワード を暗号化して作ります。もちろん、Kerberos はそのプライベート鍵を知って いますので、そのユーザだけが復号化できるメッセージを作成することができ ます。また、Kerberos は一時的なプライベート鍵を作ることもできます。こ れをセッション鍵と呼び、二つのクライアントのみに渡され、二者間での通信 メッセージの暗号化に用いられます。 Kerberos は目的に合わせて三段階の保護を用意しています。第一段階は、 ネットワーク接続を確立するための最初の認証のみを行ないます。第二段階は、 各メッセージ毎に発信元が最初に認証された相手のネットワーク・アドレスか どうかを確かめます。第三段階は、メッセージ毎の認証の他にプライベート・ メッセージの暗号化を提供します。 2.1 Kerberos のソフトウェア群 アテナプロジェクトが提供するソフトウェアでは以下のモジュールの実装が されています。 o Kerberos アプリケーションライブラリ o 暗号化ライブラリ o データベースライブラリ o データベース管理プログラム o 管理サーバ o 認証サーバ o DB 伝搬ソフトウェア o ユーザプログラム o アプリケーション 2.2 Kerberos4 の暗号化モジュール Kerberos の暗号化には DES の CBC(Cipher Block Chaining)モードと、そ の拡張である PCBC(Propagating CBC) モードが選択できます。CBC モードで はエラーは現行のブロックのみにしか及びませんが、PCBC モードではエラー が全メッセージに及びます。暗号化のライブラリーは独立したモジュールです ので別の暗号プロトコルに置き換えることも可能です。もう一つ、置き換え可 能なモジュールはデータベース管理システムです。現状では ndbm（KTH版では バークレイdb や gdbm も可）を使っていますが、もともとは Ingres を使っ ていました。Kerberos のデータベースは直線的なもので、各レコードがプリ ンシパルの「名前」と「プライベート鍵」と「有効期限」とからなるものです。 その他の、本名や電話番号などのユーザー情報は Hesiod という別のネームサー バに保存します。こうして、ネットワークを流れても良い情報とそうでない情 報の管理を分けて行ないます。 2.3 Kerberos4 データベース Kerberos の様々なサーバはデータベース管理のためのツールとしてデータ ベースライブラリを使います。 管理サーバ（KDBM サーバ）はデータベースへのネットワーク越しの読み書 きを提供します。KDBM のクライアント側はネットワーク上のどこで走らせて もかまいませんが、KDBM のサーバ側は Kerberos のデータベースの存在する マシン上で走らせます。 認証サーバ（Kerberos サーバ）は、Kerberos データベースの読み出しのみ を行ないます。プリンシパルの認証とセッション鍵の生成を行ないます。この サーバは読み出ししか行ないませんので、マスター Kerberos データベースの 読み出し専用のコピーを置いてあるマシン上で走らせてかまいません。 データベース伝搬ソフトウェア(KPROP)は Kerberos データベースの重複化 を管理します。KPROP が管理するデータベースは、認証サーバが走る複数の異 なるマシン上に持つことが可能です。そして、それぞれのスレーブマシンは定 期的にマスターマシンからデータベースのアップデートを受けとります。 最後に、エンド-ユーザ・プログラムは、ユーザが Kerberos にログインし たり、Kerberos パスワードを変更したり、Kerberos のチケットを表示したり 破棄したりするためのものです。 2.4 Kerberos名 Kerberos の中ではユーザにもサーバにも名前（プリンシパル名）が付けら れます。認証サーバから見るとそれらは等価なものです。プリンシパル名は、 プライマリ名（名前）、インスタンス、それとレルムから成り、"名前.インス タンス@レルム" の様に表現されます。例えば、 joe@JK.JP joe.admin@JK.JP rlogin.venturis@ASTEA.JP のようなものです。 プライマリ名はユーザあるいはサービスの名前です。インスタンスはプライ マリ名の種類を区別します。一般ユーザにはインスタンスは付きませんが、ユー ザに付くインスタンス "root" あるいは "admin" がある場合は、そのユーザ が持つ特権を表します。アテナプロジェクトではサービスのインスタンスはそ れが実行されるマシンの名前です。Kerberos のチケットはそのプリンシパル 名に対応した一つのサーバでのみ有効で、同じサービス名であっても別のイン スタンス名のサーバを使う場合には別のチケットが必要となります。 3. Kerberos の動作 ここでは Kerberos の認証プロトコルについて説明しますが、次のような略 語を用います。 c → クライアント s → サーバ addr → クライアントのネットワークアドレス life → チケットの寿命 tgs,TGS → チケット-グランティング・サーバ AS → 認証サーバ KDBM → 管理サーバ Kx → x のプライベートキー Kx,y → x と y のセッションキー {abc}Kx → x のキーで暗号化された abc Tx,y → y を使うための x のチケット Ax → x の認証子 WS → ワークステーション（作業端末） ユーザがサービスを要求する時には、既にそのユーザの身元確認がなされて いなくてはなりません。これを行なうためにサーバからチケットがユーザに与 えられ、そのチケットはそのユーザに与えられたチケットで盗まれたものでな いことを証明します。 Kerberos を通しての認証には３つのフェーズがありま す。最初のフェーズは他のサービスにアクセスするための信任状を得ます。次 のフェーズでは指定のサービスを利用するための認証を要求します。最後のフェー ズはユーザがこれらの信任状を目的のサーバに提出します。 3.1 信任状(credentioals) Kerberos 認証モデルで使われる信任状には二つあります。一つはチケット (ticket)でもう一つは認証子(authenticator)です。これらはどちらもプライ ベート鍵による暗号化に基づいていますが、それぞれ別々の鍵を使って暗号化 されます。チケットは認証サーバと最終的なサーバとの間で、そのチケットが 発行された人の身元確認を安全に受渡しするのに使われます。すなわち、チケット はそのチケットを持つ人とチケットが発行された人とが同じ人であることを確 認するための情報も受け渡します。認証子はそれに付随して、そのクライアン トが提示しているチケットについて、そのチケットの所有者と発行された人と が同じであることが、いつ証明されたかといった情報を含みます。 チケットは一つのサーバと一つのクライアントにのみ有効です。チケットに はサーバの名前、クライアントの名前、クライアントのインターネットアドレ ス、タイムスタンプ、寿命、および、ランダムなセッション鍵を含みます。こ の情報はチケットが使われるサーバの鍵で暗号化されています。 {s, c, addr, timestamp, life, Ks,c}Ks = {Tc,s}Ks 一旦、チケットが発行されると、そのチケットの有効期限が切れるまで、記名 されたクライアントが記名されたサーバを使うために何度も利用できます。こ れは、チケットがサーバの鍵で暗号化されているため、ユーザがチケットの内 容の変更をすることを、心配することなく使っても安全だから可能なのです。 認証子はチケットとは異なり一回だけ使われます。ユーザが、サービスを受 けたい時に、その都度新しいものを生成します。このことは、クライアントが 自身で認証子を作り上げるので、何の問題もありません。認証子は、クライア ントの名前、ワークステーションのIPアドレス、および、ワークステーション の現行時刻を含みます。そして、認証子はチケットの内部にあるセッション鍵 で暗号化されます。 {c, addr, timestamp}Ks,c = {Ac}Ks,c 3.2 Kerberos を通した処理の流れ ここでは、最も単純な Kerberos システムを通した、処理の流れを示します。 ┌──── ケルベロス・サーバ──────┐ │ （KDC：鍵発行局） │ │ │ │ 認証サーバ │ │ ┌──┐ ┏━━┓ ┌───┐チケット-グランティング・サーバ │ │ AS ├──┨ＤＢ┠───┤ TGS │（許可証明書発行サーバ） │ └──┘ ┗━━┛ ,─→└───┘ │ └──↑ ｜ ───── ／─ ／ ────┘ (1)│ ｜(2) (3)／ ／(4) │ ↓ ／ ／ ┌──────┐←─' ┌───┐ │クライアント│────→│サーバ│アプリケーション・サーバ └──────┘ (5) └───┘ 　(1) c, tgs TGS からサーバ使用許可書を受けようとするクライアントは AS に対 してクライアント名とTGS名を知らせて、TGS に提出するための TGT を要求します。 (2) {Kc,tgs, {Tc,tgs}Ktgs}Kc AS は、クライアントが認証子を暗号化するためのクライアント-TGS 間のセッション鍵と TGS に提出する暗号化された TGT をまとめてク ライアントの鍵で暗号化し、クライアントに送おくります。 (注)Kerberos5では{Kc,tgs}Kc, {Tc,tgs}Ktgs AS は、クライアントが認証子を暗号化するためのクライアント-TGS 間のセッション鍵をクライアントの鍵で暗号化して、TGS の鍵で暗号 化された TGS に提出するためのチケットと共にクライアントに送り ます。 (3) {Ac}Kc,tgs, {Tc,tgs}Ktgs, s クライアントは、自分で生成した認証子を AS から送られてきたクラ イアント- TGS間のセッション鍵で暗号化したものと、TGS の鍵で暗 号化されて送られてきた TGS に提出するためのチケットと、利用し たいサービス名とを TGS に送り、サービス使用許可証を要求します。 (4) {Kc,s, {Tc,s}Ks}Kc,tgs TGS は、クライアント-サーバ間のセッション鍵とサーバの鍵で暗号 化されたサービス使用許可証とをクライアント-TGS間のセッション鍵 で暗号化して、クライアントに送ります。 (注)Kerberos5では {Kc,s}Kc,tgs, {Tc,s}Ks TGS は、クライアント-TGS間のセッション鍵で暗号化したクライアン ト-サーバ間のセッション鍵とサーバの鍵で暗号化されたサービス使 用許可証とをクライアントに送ります。 (5) {Ac}Kc,s, {Tc,s}Ks クライアントは自分で生成したた認証子を TGS から送られてきたク ライアント-サーバ間の鍵で暗号化し、サーバの鍵で暗号化されたま まのサービス使用許可証と共にサーバに送ります。 4. Kerberos レルムでの実際の作業 ここでは、実際に Kerberos を導入したシステム上でリモートホストのサー ビスプログラムを実行するときのユーザの立場での操作例を順を追って述べま す。Kerberos システムで実際に作業を行なうユーザは、 Kerberos による認 証がどのように行なわれているかについては、ほとんど意識する必要はありま せん。 なお、ここでの例で示したプリンシパルはあらかじめ Kerberos のデータベー スに登録されていなければなりません。登録の仕方はここでは述べませんが、 Kerberos データベース管理プログラムによって行ないます。Kerberos システ ムのインストールやコマンドの種類については、"Kerberos Installation Notes" が、また、データベースの管理やプリンシパルの登録の仕方などにつ いては "Kerberos Operation Notes" が参考になると思います。さらに、パッ ケージに附属のドキュメント類も参考になると思います。 4.1 Kerberos チケット(TGT)の入手 まずユーザは自分のワークステーションまで歩いて行き、そこにログインし ます。そして、kinit コマンドを実行して TGT を得ます。この間に前節の(1)〜 (2)の処理が起こります。得られたチケット(TGT)は klist コマンドで確認す ることが可能です。ここでは、ユーザが実際に kinit を実行するワークステー ションまで歩いて行くことが大切です。ネットワーク越しにログインした端末 で kinit コマンドを実行したのではユーザの秘密鍵が洩れてしまう恐れがあ ります。試しに、実際に自分の端末で TGT の入手をしてみます。 （Kerberos 化したシステムが標準システムと別の場所にあるシステム上で はコマンドやファイルのパスに気をつける必要があります。） 101 juk@earth ~> kinit eBones International (earth) Kerberos Initialization Kerberos name: juk Password: 102 juk@earth ~> klist Ticket file: /tmp/tkt10001 Principal: juk@ASTEA.JP Issued Expires Principal Apr 3 16:46:12 Apr 4 02:46:12 krbtgt.ASTEA.JP@ASTEA.JP 103 juk@earth ~> ここでは、ASTEA.JP というレルム名が使われています。 juk@ASTEA.JP はユーザのプリンシパル名で、kinit によって デフォ ルトの有効期限の 8時間後まで使える TGT が得られたことが分かります。こ の TGT のプリンシパル名が krbtgt.ASTEA.JP@ASTEA.JP と いうわけです。そして、この TGT が /tmp/tkt10001 というファイルにキャッ シュされています。tkt10001 の 10001 はログインしている UNIX システム上で のユーザIDです。 4.2 Kerberos 化されたコマンドの実行 TGT が手に入ると次は Kerberos 化されたコマンドを実行すのみです。前節 の(3)〜(5)の処理はユーザが使うクライアント-サーバ・アプリケーションの 中にプログラムされています。例えば、rlogin を使ってみます。この rlogin の実装では kerberos のログインに失敗した場合は通常のログインを試みます。 103 juk@earth ~> rlogin venturis *** Connection not encrypted! Communication may be eavesdropped. *** *** Use telnet or rlogin -x instead! *** Last login: Thu Apr 3 16:36:05 from earth Linux 2.0.29. venturis:~$ この rlogin の終了後、再び、klist でチケットのリストを見ると： venturis:~$ exit logout rlogin: connection closed. 104 juk@earth ~> klist Ticket file: /tmp/tkt10001 Principal: juk@ASTEA.JP Issued Expires Principal Apr 3 16:46:12 Apr 4 02:46:12 krbtgt.ASTEA.JP@ASTEA.JP Apr 3 17:02:49 Apr 4 02:47:49 rcmd.venturis@ASTEA.JP 105 juk@earth ~> 新たに rcmd.venturis@astea.jp というプリンシパルに対するチケッ トが加わっています。このチケットは rlogin を実行したことによって得られ たものです。そして、同じサービス（astea.jp というレルム内の venturis というインスタンスの rcmd という名前のプリンシパル）に対して はこのチケットが再利用可能です。 このアプリケーションに Kerberos を通すように変更する作業を Kerberos 化(Kerberization)と言います。この作業は、ユーザ認証のみに Kerberos を 通す場合は比較的簡単に行なうことができます。作業中に転送するデータ全て を暗号化したい場合は少し複雑です。 Kerberos 化の実装の方法についてユーザは全く気にする必要がありません。 ただし、通常ネットワークを通すデータ全てを暗号化して行ないたいときなど は実装によって、コマンド起動時のオプションの指定をするようになっている 場合が多いため、そのオプションを知る必要があります。たいていは、オンラ インマニュアルなどに記述されているはずです。たとえば、telnet のセッショ ン全てを暗号化して行ないたい時は "-x" オプションをつけて実行します。 例えばこんな具合です。 105 juk@earth ~> telnet -x venturis Encryption is verbose Trying 192.168.1.252... Connected to venturis.astea.jp. Escape character is '^]'. [ Trying mutual KERBEROS4 ... ] [ Kerberos V4 accepts you ] [ Kerberos V4 challenge successful ] [ Output is now encrypted with type DES_CFB64 ] [ Input is now decrypted with type DES_CFB64 ] Last login: Thu Apr 3 12:17:17 from earth Linux 2.0.29. You have new mail. venturis:~$ 4.3 Kerberos チケットの破棄 ユーザが作業を終わって端末から離れる前にチケットを全て破棄します。チ ケットは期限が切れるまでは再利用可能ですので、少しでも危険がないように することをお勧めします。チケットの破棄は kdestroy コマンドで行ないます。 kdestroy をした後、全てのチケットがなくなったことを klist コマンドで確 認できます。 106 juk@earth ~> kdestroy Tickets destroyed. 107 juk@earth ~> klist Ticket file: /tmp/tkt10001 klist: No ticket file (tf_util) 108 juk@earth ~> Kerberos チケットが破棄されても、最初のユーザ認証しか Kerberos を通さ ないアプリケーションを使っている場合はそのまま続けて利用可能です。チケッ ト破棄後は Kerberos 化されたコマンドはエラーを起こします。 109 juk@earth ~> rlogin venturis krcmd: No ticket file (tf_util) rsh: warning, using standard rsh: can't provide Kerberos auth data. rlogin: not installed setuid root, only root may use non kerberized rlogin 110 juk@earth ~> telnet venturis Trying 192.168.1.252... Connected to venturis.astea.jp. Escape character is '^]'. [ Trying mutual KERBEROS4 ... ] mk_req failed: No ticket file (tf_util) [ Trying KERBEROS4 ... ] mk_req failed: No ticket file (tf_util) *** Connection not encrypted! Communication may be eavesdropped. *** User not authenticated. Using plaintext username and password juk's Password: ここでは平文パスワードのプロンプトが表示されていますが、失敗したとき にパスワード認証やワンタイム・パスワード認証を使うかどうかは、サーバ起 動時のオプションによって指定できます。 4.4 Kerberos パスワードの変更 Kerberos のパスワードの変更は一般的な UNIX パスワードの変更と同じよ うにできます。コマンドが kpasswd に変わるだけです。ただし、大きな違い は、自分の Kerberos パスワードを一度変更すると、そのレルム内での自分 のパスワードが変更され、各マシン毎に変更する必要は無いということです。 NIS(Network Informatin System)をお使いになった経験のある方は yppasswd をご存知だと思いますが kpasswd でもそれと同じ効果を期待できます。 111 juk@earth ~> kpasswd Old password for juk: xxxxxxxx New Password for juk: XXXXXXXX Verifying New Password for juk: XXXXXXXX Password changed. 参考文献 "Kerberos: An Authentication Service for Open Network Systems" Jennifer G.Steiner, Clifford Neuman, Jeffrey I. Schiller 1988 "Kerberos Installation Notes " Bill Bryant, Jeffrey Schiller, John Kohl 1989 "Kerberos Operation Notes " Bill Bryant, John Kohl 1989 "The Evolution of the Kerberos Authentication Service" John T. Kohl 1991 EurOpen Conference, in Tromso, Norway 「UNIX セキュリティ 13章、18章」 Simon Garfinkel, Gene Spafford (アスキー) ISBN4-7561-0274-3 「ファイアウォール構築 インターネットセキュリティ」 D.Brent Champman, Elizabeth D. Zwicky (オライリージャパン) ISBN4-900900-03-6 「インターネットセキュリティ - システム管理者のためのリスクマネージメント」 Larry J. Hughes, Jr. (インプレス プレンティスホール) ISBN4-8443-4916-3 「オープンデザインNo.14 第4章 Kerberos」 稲村雄 (CQ出版) 「インターフェース 暗号システムの実践研究(1)〜(4)」 白田光有、斉藤泰一、盛合志帆 (CQ出版) 1997-01〜04 「ユニックスマガジン 暗号化システムの概要」 Mehrdad Foroozesh (アスキー) 1997-04 「ネットワークセキュリティ 9章、10章、11章」 Kaufman, Perlman, Speciner (プレンティスホール) 1997 ISBN-4-931356-98-2 「KERBEROS ネットワーク認証システム」 Brian Tung (ピアソンエデュケーション) 1999 ISBN4-89471-146-X MIT Kerberos Kerberos FAQ KTH-KRB Kerberos Notes for Japanese RFC1510和訳 モロンのKereberos ガイド by Brian Tang Kerberos5と今後の動向 Kerberosのための公開鍵サポート PK_INIT 公開鍵暗号方式を初期認証でサポートするために Kerberos を拡張する 修正パッケージです。 http://gost.isi.edu/info/pk_init/ ドラフトと参照実装はブライアン・タン(Brian Tung)らによる、ISI, DEC お よび CyberSafe での作業です。 SSLのKerberos認証オプション NetscapeのSSL 3.0(セキュアソケットレイヤ)は、IETF(Internet Engineering Task Force)のrfc2712.txt で述べられている Kerberos認証オプションをサポー トするように修正されました。 ftp://prospero.isi.edu/pub/ssl-krb The draft (presented at the IETF's Transport Layer Security (TLS) working group meeting, Dec. 1996) proposes the addition of new cipher suites to the TLS protocol (SSL 3.0) to support Kerberos-based authentication. Kerberos credentials are used to achieve mutual authentication and to establish a master secret which is subsequently used to secure client-server communication. Note: The reference implementation uses MIT's Kerberos V5 beta 6. ドラフトと参照実装は、CyberSafe Corporation の Ari Medvinsky と Matt Hur ら によるものです。 オーストラリア政府が企業と共同研究のために設立した分散システム技術セン ター(DSTC:Distributed Systems Technology Centre) では、分散環境におけ るセキュリティツールの開発を行っている。Workflow, CORBA, Java?, XML, Distributed Object Middleware, Internet Systems, Knowledge Management, Metadata, Collaborative Computing, GroupWare, Security そして Network infrastructure について世界水準の研究開発、トレーニング、コンサルティ ングサービスを行っている。 JAVA 用の暗号モジュールのクラスもそのなかで開発されている。 JCSI - Java Crypto and Security Implementation 標準仕様のセキュリティサービスの実装をJava Cryptographic Architecture (JCA) に準拠して行い、Java プラットホームで簡単に拡張できるようにして いる。 http://security.dstc.edu.au/projects/java/features.html JCSI には、KDC(例えば、Win2K)や GSSAPI(RFC 2853) との通信をアプリケー ションレベルのメッセージのやりとりで行う Kerberos5 のライブラリも含ま れている。 Windows 2000ではKerberosのSecurity Service Providerが実装されIEはそれ によってKerberos認証が可能となり、IISは仮想ディレクトリの設定でWindows NT認証の設定を行うことでKerberosの利用を行うことができる。 Netscape3 用にはKerberos4対応 kplugin というプラグインとApache のパッ チも存在していた。サーバは Apache-SSL にパッチを当てたもの。 http://www.monkey.org/~dugsong/krb-www/ CMU(カーネギメロン大学)の AndrewII では Kerberos Web サーバ/ブラウザ KWeb の研究開発を行った Minotaur(ミノタウル)プロジェクトがあった。 http://andrew2.andrew.cmu.edu/minotaur/ Kerberos対応の lpr に LPRng がありKerberos4,5に対応しているが、 KTH版ではコンパイルできなかった。 http://www.astart.com/LPRng/LPRng.html もうひとつ、rlpr をベースにした CWRUの cwrlpr もある。 プロクシとしてリモートプリンタの利用も可能。 http://socwww.cwru.edu/cwru_lpr/