初出：「ファイアウォール＆ネットワークセキュリティ実践テクニック
〜すべてのPC UNIXユーザと際と管理者に贈る最強セキュリティガイド〜」,
技術評論社第２編集部編, 2000年11月, ISBN4-7741-1313-1,
(3.7 オープンネットワークのための認証システムKerberos／くわむら じゅん)
『オープンネットワーク 認証システム Kerberos4入門 (KTH-KRB)』
1. Kerberosとは
ギリシャ神話に出てくるKerberos（ケルベロス）は、冥界の王ハデスの番犬
で、無数の蛇の毛が生えた３つの犬の頭と龍の尻尾を持った生き物だそうです。
ああ恐ろしや。
ここで述べる Kerberos は、オープンなコンピュータネットワークのための
認証システムです。オープンなコンピュータネットワークは、デジタル社会と
かサイバースペースなどと呼ばれていて、ネットワークを介してコンピュータ
が相互に接続され、その中でいろいろなサービスを利用しているお互い知らな
い人同士が同時に存在するような世界です。認証システムとは、話かけてきた
人が本当にその本人なのか、あるいは、話かけようとしている相手が本当にそ
の人なのかを証明するシステムです。日常生活で、運転免許証は顔写真によっ
て、クレジットカードは署名によって、その持ち主が本人であることを証明し
ています。一般に、コンピュータにも認証システムがあり、ログイン（あるい
はログオン）しようとしているユーザが本当に当人あることを確かめます。最
近のコンピュータをお使いであれば、誰しもパスワード認証システムのお世話
になったことがあるはずです。
Kerberos は、MIT(マサチューセッツ工科大学) の Project Athena(アテネ・
プロジェクト) で開発されました。この、戦いの女神アテネの名を冠する分散
システムの研究開発プロジェクトは、X Window System を開発したことでも有
名です。分散環境でコンピュータのオープンで使用するコンピュータのマンマ
シン・インターフェースをX Window で研究する一方、分散環境の基となるコ
ンピュータネットワークでの安全確保（セキュリティ）の研究も Kerberos の
研究により行なっていたわけです。Kerberosも安定版(バージョン４)になって、
さらに多くの意見を採り入れるため、X Windowと同じように公開されましたが、
暗号モジュールが組み込まれていたため、数奇な運命をたどった後、我々の目
の前に現れることとなりました。それが、eBones というバージョンで、スウェー
デン王立技術研究所(KTH)でさらに改良が続けられ KTH-KRB という安定したバー
ジョンになっています。
現在、Kerberosの最新版はバージョン5で KerberosプロトコルのRFCとして
発行されています。しかしながらMITのKerberosは、米国政府の輸出規制のた
め米国、カナダ以外の国では自由には利用できません（米国政府の輸出許可が
必要です）。そんな中、KTHではKerberos5の国際化版Heimdalが開発されてい
ます。また、２０００年に商務省から規制緩和が発表されて以来、RedHat
Linux やMicrosoft Windows 2000 にも組み込まれるようになったため、今後
が楽しみです。
さて、組織で利用するコンピュータネットワークの安全性を考えた場合、ファ
イアウォールで外部のネットワークから切り離すことで十分なセキュリティと
なるかというと、一概にそうとはいえなくなってきています。組織内のコン
ピュータとネットワークの普及拡充に伴い、誰もが勝手にネットワークに自分
のコンピュータを繋ぐことができるとすると、そのネットワークを流れるパケッ
トを拾い見ることさえ可能であると十分に考えられます。こうした状況下で、
セキュリティ維持のためにはパスワードを流さず、しかも、使い勝手が悪くな
らないようなシステムの導入が望まれます。Kerberosを開発したMITのオープ
ンキャンパスはまさにこの問題に直面したわけです。コンピュータネットワー
ク上での安全性と可用性とを同時に充たすためには、分散環境向けでしかもシ
ングル・サインオンをサポートするようなネットワーク認証システムが必要と
なります。Kerberosはこのトレードオフの関係にある要求を解決するための一
つの手段となり得ます。もちろん、Kerberos だけですべてが解決するわけでは
なく、他のセキュリティツールとの併用によってより安全で使いやすい環境を
構築することが可能になるはずです。たとえば、KTH-KRB はファイアウォール
を工夫することができます。
Kerberos認証はファイアウォール越しのネットワークにも対応できるように
なっている他、ダイアルアップのネットワークからの接続にも利用でき、リモー
トからのサーバ・メンテナンスなどにも役に立ちます。特に複数のサーバのメ
ンテナンスにはシングル・サインオンはとても重宝します。
1.1 Kerberos の歴史
アテネ・プロジェクトは、1983年にMITが、DEC(Digital Equipmet
Corporation)と IBM(International Business Machines Corporation)との共
同研究として始めた、分散環境での計算システムの研究開発プロジェクトでし
た。サーバ／クライアント・モデルのウィンドウシステムを代表する X
Window System を開発したことでも有名です。そのオープンな分散システムで
セキュリティという片翼を担うのがとなるのがKerberos認証システムだったわ
けです。
Kerberosの認証方式には、1978年に R. M. Needham と M. D. Schroeder に
よって提唱された鍵配布モデルに基づく「信頼のおける第三者機関による認証」
("Trusted Third Party Authentication") の概念を採用し、S. P. Millerと
B. Clifford Neumanにより設計されました。
Kerberosは、もともと暗号プロトコルに対称鍵方式の DES(Data Encryption
Standard) を使用しました。DES はアメリカ合州国（米国）商務省標準局
(NBS:National Bureau of Standard)の1973年の公募に対する IBM からの提案
をもとに 1977 年に公布された対称鍵（共通鍵）ブロック暗号方式のデータ暗
号化標準プロトコルですが、米国政府は（1994年までのCOCOMや1996年からの
ワッセナー協定の規制により）輸出規制の対象としていたため米国およびカナ
ダ以外の国への持ち出しが規制されていました。合州国とカナダ国以外の国へ
の持ち出しには米国政府の許可が必要とされます。このような理由から、バー
ジョン4 になってMIT 以外にも公開されたKerberosを、米国とカナダ以外で自
由に利用できるようになっのは 1989年ころ、DES を取り除いた Bones と呼ば
れるコードとなってからでした。Bonesという名前は、DESをKerberosの肉
に例えて、piranha（ピラニア）というプログラムに食わせて、骨だけにした
といういわれだそうです。
1990年以降、米国とカナダ以外の国から入手できるのは Bonesにオーストラ
リアでコーディングされた国際版DES暗号化モジュールを付け加えたeBonesと
いうコードで、米国とカナダ以外の国からダウンローすドすれば利用が可能で
したが、スウェーデンのストックホルム王立研究所(KTH:The Royal Institute
of Technology in Stockholm, Sweden) では 1995年ころより eBonesに拡張を
加えたKTH版Kerberos4(KTH-KRB)の開発をはじめました。KTH では KTH_KRB4
を様々なマシンに移植し維持管理しています。管理コマンドの追加や拡張が行
なわれ、MIT のKerberos4 よりもさらに利用しやすいものとなっています。
Kerberos4 の暗号モジュールに使われていた 56ビットDESは、1999年ころ
DES チャレンジというコンテストにおいて、数万台のコンピュータ使った国際
的プロジェクトチームにより数ヶ月がかりで解読されました。簡単には解読で
きないにしろ、Kerberos4 もそろそろ万全とは言えなくなる日が近づいてきて
いるかもしれません。その点、1993年に RFC1510 として発行されたKerberos5
のプロトコルは、RFC1509 の暗号化モジュールを選べる GSSAPI(Generic
Security Service Application Programing Interface) （RFC1964）を採用し
ています。
ヨーロッパ共同体（EU）でも、Kerberos5と同じGSSAPI対応のSESAME (a
Secure European System for Applications in a Multi-vendor Environmet)
というオープン・システムがECMA(European Computer Manufacturers
Association) の下で共同開発されました。商用化されたものとしては、
OpenMasterというシステムなどが有名です。現在、KTHでもKerberos5の国際化
版であるHeimdalの開発が行なわれています。Heimdalの開発は着々と進んでい
るようですので正式版のリリースが待ちこがれます。
現在、MITからリリースされている最新版の Kerberos5 は米国とカナダの国
内では自由に利用できるのですが、それ以外の国にはドキュメントのみの公開
で、プログラムを入手するには米国政府の許可が必要なため、ほとんど手に入
れることは不可能と考えられていました。しかしながら、西暦2000年に米国商
務省から規制緩和政策が発表されたので状況は変わってきているようです。
実際、RedHat Linuxにはバージョン 6.x のころから、Kerberos5 がバンドル
されるようになっていますし、また、Microsoft Windows 2000 のプロトコル
スタックにも Kerberos5 が組み込まれるようになりました。
--
1.2 Kerberosの特徴
もともと、Kerberosを開発したMITでは、オープンな大学のネットワーク内
での学生によるいたずらを防ぐことがその開発の大きなきっかけでもありまし
た。米国では、企業や大学など組織内のセキュリティ維持のためにKerberosを
利用することがよくあります。セキュリティの基本は認証ですが、ネットワー
クセキュリティでは、その認証に用いるパスワードを流さないか、流すとして
もそのままではなく暗号化することが基本です。もともと、オープンなネット
ワーク上の分散環境でのセキュリティのために開発されたものですから、
Kerberosは 外部からの侵入にも強いわけです。
Kerberos は認証システムです。コンピュータにログインしようとするとき、
一般的には個々のコンピュータで管理されるパスワードでの認証が行なわれま
すが、Kerberosではそれを一括管理する認証局のようなものを持つのが特徴で
す。Kerberos認証システムでは、一度認証をしてしまえば、その認証局の管理
する領域内ではサービスを提供するコピュータが複数あってもすべてのサービ
スを受けられることも特徴です。一度の認証でその領域内では全てのサービス
を利用できますが、この仕組みのことを指してシングル・サインオンと呼ばて
います。
この仕組みをもう少し詳しく説明してみます。一度、認証を行なったクライ
アントはチケット認可チケット(TGT: Ticket Granting Ticket)という期限付
きの切符を手に入れ、それ以降期限が切れるまで何度も使用できます。目的の
サービスを利用する際は、パスワードのかわりにTGTを使って、サービス毎に
必要なサービスチケットを手に入れます。サービスチケットにはサービスを利
用するために必要な鍵が含まれていて、実際にサービスを受ける際に使います。
サービスチケットの有効期限もTGT に従います。通常、Kerberosのチケットは
ディスク上に保存されます。これを他の誰かに再利用されることを防ぐために、
TGTという概念が生まれ、実際にサービスを受けるために利用するセッション
鍵はその都度発行されることで、再利用の可能性を最小限に止めています。
ネットワーク認証システムということは、ワープロや表計算のように単体で
動くプログラムに実装されることはあまりなく、クライアント／サーバ型のネッ
トワーク経由で利用されるアプリケーションの認証のために実装されることが
よくあります。アプリケーションにKerberosを実装することをケルベロス化と
いいます。認証と暗号化とは別のことで、ケルベロス化のレベルによっては、
セッションの暗号化もサポートさせられます。Kerberosの暗号化セッションで
はアプリケーションレベルでコンピュータ間のやりとりをすべて暗号化します。
Kerberosの実装はアプリケーション毎に必要となりますので、すべてのアプリ
ケーションでKerberos認証が使えるわけではありません。
ケルベロス化にはレベルがあると書きましたが、最初の第１レベルではクラ
イアントの認証のみで、次の第２レベルではサーバの証明も行うことができ
（相互認証）、さらに第３レベルではセッションの暗号化も可能です。ケルベ
ロス化の度合はアプリケーションやそのバージョン版によってちがいます。
KTH版Kerberosには、 Telnet, FTP, POP などの実装がありますが、それとは
別に、Windows版 の KTelnet クライアントセット(Telnet,FTP,KPOPProxy) も
配布されています。KTH版のTelnetはセッションの暗号化もサポートしていま
す。また、PostgreSQLやSSHのように Kerberos 認証をサポートしていて、構
成オプションによって利用可能となるアプリケーションもあります。
Kerberosでの認証の仕組みは一見複雑ですが、そのすべてはアプリケーショ
ンに実装されていますので、それを利用するユーザ(クライアント) はその仕
組みの大枠さえ知っていれば、一度パスワードを入力して一定の時間内はその
領域内のサービスを自由に受けることができます。すなわち、最初に一度パス
ワードを入力してチケット(TGT)を入手すれば、そのTGTの期限が切れるまで、
認証局の管理する領域のサービスを受けるための認証を自動的に受けられます。
Kerberos ではこの管理領域のことをレルム(Realm)と言います。また、
Kerberos では、サービスを提供するアプリケーションサーバとそのサービス
を受けるクライアントのことをまとめてプリンシパル(Principal)と呼んでい
ます。いずれも、Kerberos サーバから見るとクライアントとなるからです。
Kerberos では、「信頼のおける第三者機関(Trusted Third Party)」による
認証モデルを基本としていて、その第三者機関すなわち認証局の働きをするサー
バを鍵発行局 (KDC: Key Distribution Center)と呼んでいます。KDCは実質上、
認証サーバ(AS: Authentication Server)とチケット認可サーバ (TGS: Ticket
Granting Server)とからなります。ここで言う、サーバとは Kerberos のサー
ビスを提供するプログラムのことですので、どこかの機関が認証サービスを提
供しているということではありません。セキュリティの確保を完全にして、自
分でKDC となるサーバを設置して走らせれば良いのです。実際、商用の
Kerberos認証サービスというのは聞いたことがありませんが、グループを組織
して実験的に共同でレルムを構成することは可能かもしれません。
Kerberosのレルムは便宜上DNS(ドメインネームシステム)のドメインにあわ
せてインストールされることが一般的ですが、実際は複数のドメインや個々の
ホストを一つのレルムとして登録することも可能です。たとえば、東京の本社
と大阪の支社とで別々のドメインを利用していたとしても、同一のKerberosの
レルムとして扱うことができます。また、別々のレルムであったとしても、
Kerberosはレルムを越えて認証を行う、クロス=レルム認証機能を持っていま
す。一つのレルムに Kerberos の KDC は一つ以上必要ですが、安全のために
スレーブサーバを複数用意することもできます。
Kerberosの開発において求められたことは、大学の学内（企業の部門内）の
ようなオープンなネットワークにおいて情報の安全性を維持することでした。
大学や企業などで普及したイーサネットのようなブロードキャスト型のネット
ワーク上で、クライアント／サーバモデルを採用した分散環境では、ネットワー
クを流れる情報は、容易に盗聴、改竄、偽造の対象となります。そうした状況
下で情報のセキュリティを維持するための暗号プロトコルが必要であったわけ
です。このため、Kerberosは以下のような事柄を考慮の上設計されました。
o 一方向のみでなく双方向の認証の機能も備えること。通常はサーバに対す
るクライアントの認証を行ない、クライアントの要求がある場合はサーバの
認証もおこなえるようにする。
o パスワードはユーザの認証が終れば消し去ること。クライアントがサーバ
からサービスを受ける場合には認証を受けるためにパスワードがそのまま
ネットワーク上を流れることのないようにする。
o 鍵を盗み出された場合にその鍵を用いて暗号が解読される危険を抑制する
ために、暗号化に用いる鍵に寿命（有効期限）を設ける。
o ネットワークを流れるあらゆる情報を暗号化することを可能にすること。
o 暗号化ロジックをすべてのホストに組み込まずに済ませ、認証関係の情報
をデータベース化し集中管理するために、暗号化サーバを設けること。
o 認証はユーザがログインを行なうときのみとし、ユーザがそのことに気が
つかなくてもすむようにすること。
o このシステムを導入するのための労力を最低限に抑えること。
Kerberosの設計要求において注目すべき点は、高度なセキュリティのみなら
ず、ユーザの使い勝手、管理の容易さを求めていたことです。このように相反
する要求を一つのシステムにまとめあげるというこのは、並大抵のことではな
かったはずです。その結果、多少の導入コストが伴うのは仕方のないことかも
しれません。Kerberosに手間がかかるということがKerberosのハードルを高く
した一つの理由でもありますが、Kerberosの基本をおさえて、ある程度の理解
があればそれほど難しいことではありません。
古代ギリシャ神話で Kerberos は（ローマ神話ではCerberus）、冥界の門の
番犬のことですが、冥界の王（支配者）ハデスは、プルートとも呼ばれ富の象
徴ともいわれます。その富を守るのがKerberosというわけしょうか。この犬の
３つの頭は、認証・承認・監査を象徴するそうです。Kerberosには認証機能は
当初の目的として実装されていましたが(Kerberos4)、後の２つは最新版のプ
ロトコル(Kerberos5)になってから、間接的に提供されるようになりました。
KTHで開発されている国際版のKerberos5は、Heimdal（ヘイムダル）という
名前で、北欧神話に出てくる Heimdal は見張りの神様のことで、まさに、そ
の役割にぴったりの名前というわけです。最後に、Loki（ロキ）と相打ちとな
る物語があります。
1.3 Kerberos の基本概念
Kerberos 認証システムの構成は、サーバへのチケットを含む証明書を発行
する鍵発行局(KDC: Key Distribution Center)と、そのKDCが管理（支配）す
る複数のクライアントおよびサーバを含むレルム(Realm)（王国、領域の意味）
からなります。Kerberosではクライアント（ユーザとクライアントアプリケー
ション）とサーバ（サーバアプリケーション）を総称してプリンシパル
(Principals)（長、主体の意味）と言います（図）。
+--- Realm ---------------------------------------+
| |
| |
| |
| |
| /Principal\ /Principal \ |
| \(User) / \(Application Server)/ |
| |
+-------------------------------------------------+
図 Kerberosのレルム
Kerberos で採用された「信頼のおける第三者機関による認証」の基本的な
枠組は、クライアントがあるサービスを利用したい場合、クライアントは KDC
にサービスを利用するためのチケット(ticket)を要求して、チケットを手に入
れ、KDC から授かったサービスを受けるためのチケットをサーバに提出し、そ
のサービスを受けます（図）。
------------------------------------------------
┌───┐
│ＫＤＣ│
└───┘
↑ ｜(2)
(1)│ ↓
┌──────┐ (3) ┌────┐
│クライアント│──→│サービス│
└──────┘ └────┘
(1) サービスへのチケットを要求
(2) サービスへのチケット入手
(3) サービスへチケットの提出
------------------------------------------------
図 第三者機関による認証の基本
しかし、このモデルでは次のような不都合が起こり得ます。
o ここで、KDC から入手したサービスへのチケットが、他者による流用を避
けるために、クライアントの秘密鍵で暗号化されているとすると、クライ
アントはこのチケットを復号化するために自分の秘密鍵を使うことになり
ます。
o もし、クライアントが別のサーバを使いたい場合は同様にして、その別の
サービスのためのチケットを復号化するために、クライアントは再び自分
の秘密鍵を使うこととなります。
o クライアントはサービスが異なる毎にその秘密鍵を入力するのが不便なの
で、便宜上その秘密鍵をキャッシュすることになります。こうなると、そ
のクライアントの秘密鍵は漏洩し易くなり、Kerberos システムの初期の
目的を達成できなくなってしまいます。
そこで、取り入れられたのが TGT:Ticket-Granting Ticket（チケット認可
チケット）です。
まず、クライアントは認証サーバ(AS: Authentication Server)に要求して
(1)、認証サーバから TGT を取得し(2)、次に、クライアントはその TGT を
TGS(Ticket-Granting Server)（チケット認可サーバ）に提出して(3)、目的の
サービスを利用するためのチケット（サーバ使用許可証）を取得し(4)、最後
に、クライアントはこのチケット（サーバ使用許可証）を目的のサービスへ提
出してサービスを利用します(5)。
この際、Kerberos システムでは KDC が AS としての役割と TGS としての
役割との２つの役割を果たします。
--------------------------------------------------
┌──────────────────┐
│┌───┐ ＫＤＣ ┌───┐│
││ ＡＳ │ │ＴＧＳ││
│└───┘ ,─→└───┘│
└─↑ ｜──────／──／ ────┘
(1)│ ｜(2) (3)／ ／(4)
│ ↓ ＴＧＴ ／ ／ サービスチケット
┌──────┐←─' ┌───┐
│クライアント│────→│サーバ│
└──────┘ (5) └───┘
(1) ＴＧＴの要求
(2) ＴＧＴの入手
(3) ＴＧＴを提出してサービスチケットを要求
(4) サービスチケット入手
(5) サービスチケットを提出しサービスを要求
--------------------------------------------------
図 第三者機関による安全な認証
もし、クライアントが続けて別のサービスも利用したい場合には、既に AS
から入手している TGT を再び TGS に提出し(3)、別のサービスを利用するた
めのチケットを入手することができます(4)。 TGT はクライアントの秘密鍵か
ら作られますが、作る度に毎回異なり秘密鍵そのものではないのでキャッシュ
して再利用しても比較的安全でなわけです。さらに、 TGT にはその利用期限
が定められていて、期限が切れるまでは何回も再利用ができます。
コラム：日本人に身近な第三者機関による認証システムの例
------------------------------------------------------------------------
コンピュータやネットワークの仕組みに疎遠な人にもわかるような身近な例
を捜してみたのですが、一番似ていると思われるのは印鑑登録証明書（いわゆ
る印鑑証明）でした。たとえば、車や家を購入するときには、契約に使う捺印
の他に印鑑登録証明書が必要です。この印鑑登録証明書を取得するための手順
がTGTを介したKerberosの証明書の取得に似ていることに気がつきました。
この手順をみてみましょう。まず、お役所の登録窓口で印鑑登録をして印鑑
登録証を発行してもらういます。すると、車や家を購入するために印鑑登録証
明書が必要になったときには、その都度、印鑑登録証を持ってお役所の証明書
発行窓口へ行けば、目的のための印鑑登録証明書を発行してもらえます。そし
て、発行してもらった印鑑登録証明書を契約のために捺印をした書類と一緒に
提出します。
この例では、KDC（いわゆる信頼のおける第三者機関というもの）がお役所
というわけです。そして、印鑑登録証は TGT の役割を果たしているわけです。
┌────────────────────┐
│┌────┐ お役所 ┌───────┐│
││登録窓口│ │証明書発行窓口││
│└────┘ ,─→└───────┘│
└─ ↑ │ ───／──／ ────────┘
(1)│ │(2) ／(3) ／(4)
│ ↓ ／ ／
┌───┐←─' ┌───┐
│依頼人│────→│契約先│
└───┘ (5) └───┘
(1) 印鑑登録を行なう
(2) 印鑑登録証の入手
(3) 印鑑登録証を提出して印鑑登録証明書を要求
(4) 印鑑登録証明書の入手
(5) 契約先に印鑑登録証明書と捺印した書類を提出
----------------------------------------------------------------------
コラム： 用語の整理
----------------------------------------------------------------------
Kerberosではギリシャ神話にちなんだ、特異な言い回しがあるため、具体的
な説明に入る前にここでもう一度、用語を整理をしておきます。
ユーザ: 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 ビットのブロック長に分割し、
ブロック毎に多段階の排他的論理和で暗号化する。
共有鍵: Shared Key
プリンシパルと KDC が共有する有効期限の長い暗号化鍵。システム
領域外で配布される。ユーザーのプリンシパルの場合は、秘密鍵はパ
スワードから取り出される。秘密鍵(Secret Key)という呼び方は、
混乱のもとなので行なわない。特に日本語では、公開鍵システムの
プライベート鍵のことを秘密鍵と呼ぶので紛らわしい。
セッション鍵: Session Key。
クライアント（ユーザ）とサーバ（アプリケーション）2つのプリン
シパルの間で使用される一時的な暗号化鍵。
チケット: Ticket。
クライアントが、サーバーへ自分自身を認証させるためのレコード。
クライアントの ID 、セッション鍵、タイムスタンプ、その他の情報
を含んでいて、サーバーの秘密鍵ですべて封印されている。新しい
認証子とともに提出したときだけ、クライアントが認証される。
----------------------------------------------------------------------
2. Kerberosの仕組み
Kerberos は、「信頼のおける第三者機関による認証」のモデルを採用して
いますが、さらに、タイムスタンプ（現在の日付と時刻）を付加することによっ
て、メッセージが盗まれた場合のリプレイ攻撃に対する予防も考慮しています。
ここでは 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 を通しての認証には３つのフェーズがあ
ります。最初、１番目のフェーズは他のサービスにアクセスするための信任状
を得ます。次、２番目のフェーズでは指定のサービスを利用するための認証を
要求します。最後、３番目のフェーズはユーザがこれらの信任状を目的のサー
バに提出します。これでユーザの認証は終り、ユーザは目的のサービスを受け
られるようになります。
2.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
2.2 Kerberos を通した処理の流れ
では、順を追って Kerberos 認証の処理の流れをみてゆきましょう。ここで
は、Kerberos4 システムを通した最も単純な処理の流れを示します。
---------------------------------------------------------------------------
┌──── ケルベロス・サーバ──────┐
│ （KDC：鍵発行局） │
│ │
│ 認証サーバ │
│ ┌──┐ ┏━━┓ ┌───┐チケット-グランティング・サーバ
│ │ AS ├──┨ＤＢ┠───┤ TGS │（許可証明書発行サーバ）
│ └──┘ ┗━━┛ ,─→└───┘ │
└──↑ ｜ ───── ／─ ／ ────┘
(1)│ ｜(2) (3)／ ／(4)
│ ↓ ／ ／
┌──────┐←─' ┌───┐
│クライアント│────→│サーバ│アプリケーション・サーバ
└──────┘ (5) └───┘
(1) c, tgs
(2) {Kc:tgs, {Tc:tgs}Ktgs}Kc
(3) {Ac}Kc:tgs, {Tc:tgs}Ktgs, s
(4) {Kc:s, {Tc:s}Ks}Kc:tgs
(5) {Ac}Kc:s, {Tc:s}Ks
(1) c, tgs
.--------,
| c, tgs |
`--------'
(2) {Kc:tgs, {Tc:tgs}Ktgs}Kc
+-----------------------+
| +--------+ |
| Kc:tgs, | Tc:tgs Ktgs Kc
| +--------+ |
+-----------------------+
(3) {Ac}Kc:tgs, {Tc:tgs}Ktgs, s
.-------------------------------,
| +----+ +--------+ |
| | Ac Kc:tgs, | Tc:tgs Ktgs, s |
| +----+ +--------+ |
`-------------------------------'
(4) {Kc:s, {Tc:s}Ks}Kc:tgs
+-----------------+
| +------+ |
| Kc:s, | Tc:s Ks Kc:tgs
| +------+ |
+-----------------+
(5) {Ac}Kc:s, {Tc:s}Ks
.----------------------,
| +----+ +------+ |
| | Ac Kc:s, | Tc:s Ks |
| +----+ +------+ |
`----------------------'
---------------------------------------------------------------------------
図 Kerberos 認証処理の流れ
以下、図 のやりとりで受け渡されるデータについて順番に説明します。
まず、クライアントは使いたいサービスの存在するレルムの TGT を自分の
所属するレルムの KDC に要求し手に入れます。
(1) c, tgs
TGS からサーバ使用許可書を受けようとするクライアントは、
クライアント名とTGS名をASに知らせて、TGS に提出するための TGT
を要求します。
(2) {Kc:tgs, {Tc:tgs}Ktgs}Kc
AS は、クライアントが認証子を暗号化するためのクライアント-TGS
間のセッション鍵とTGSに提出する暗号化されたTGTをまとめてク
ライアントの鍵で暗号化し、クライアントに送おくります。
(注)Kerberos5では{Kc:tgs}Kc, {Tc:tgs}Ktgs
AS は、クライアントが認証子を暗号化するためのクライアント-TGS
間のセッション鍵をクライアントの鍵で暗号化して、TGS の鍵で暗号
化された TGS に提出するためのチケットと共にクライアントに送り
ます。
次に、クライアントはあらかじめ手に入れた TGT を利用したいレルムの
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 から送られてきたク
ライアント-サーバ間の鍵で暗号化し、サーバの鍵で暗号化されたま
まのサービス使用許可証と共にサーバに送ります。
3. Kerberos の実際
実際の Kerberos は、クライアントの名前と共有鍵（KDCとクライアントの
みが知っている）を含むデータベース（KDB: Kerberos DataBase）を持ちます。
共有鍵は大きな値の数で Kerberos とクライアントのみが知っています。クラ
イアントがユーザの場合、共有鍵はパスワードを暗号化して作ります。もちろ
ん、Kerberos はその共有鍵を知っていますので、そのユーザだけが復号化で
きるメッセージを作成することができます。また、Kerberos は一時的な共有
鍵を作ることもできます。これをセッション鍵と呼び、二つのクライアントの
みに渡され、二者間での通信メッセージの暗号化に用いられます。
Kerberos は目的に合わせて３段階の保護を用意しています。第１段階は、
ネットワーク接続を確立するための最初の認証のみを行ないます。第２段階は、
各メッセージ毎に発信元が最初に認証された相手のネットワーク・アドレスか
どうかを確かめます。第３段階は、さらにプライベート・メッセージの暗号化
を提供します。
ここでは、Kerberosの基本機能を持ち比較的理解し易いことから、KTH-KRB
（MITのKerberos4から派生したeBonesを元に開発された）を材料に話を進めま
す。
3.1 Kerberos のソフトウェア群
Kerberos4の配布版には以下のモジュールの実装がされています。
o Kerberosアプリケーション、データベース、暗号化などのライブラリ
o データベース管理プログラム
o 管理サーバ
o 認証サーバ
o DB 伝搬ソフトウェア
o ユーザプログラム
o アプリケーション
以下、KTH-KRB の配布版に実際に含まれるプログラムについて簡単に説明します。
(1) Kerberosアプリケーション、データベース、暗号化などのライブラリ
libacl ACL(Access Control List) ライブラリ
libdes DES(Data Encryption Standard) ライブラリ
libkafs AFS(Andrew File System)ライブラリ
libkadm 管理用インターフェースライブラリ
libkdb Kerberosデータベース・インターフェースライブラリ
libkrb Kerberos ライブラリ
libotp OTP(One Time Password) 関連ライブラリ
(2) マスターデータベース(KDB)管理プログラム
kdb_init
Kerberos マスターデータベースを初期化します。Kerberos レルム名
と Kerberos マスターパスワードの入力を促します。
kstash
マスターパスワードをファイル /.k に保存し(stash)、これにより
マスターサーバマシーンは、不慮のリブートの際に Kerberos サーバ
を自動的にリスタートできます。
kdb_edit
マスターデータベースを修正するための低レベルツール。
kdb_destroy
マスターデータベースを削除します。
kdb_util
マスターデータベースをアスキーファイルにダンプするために使えま
す。また、アスキーファイルからマスターデータベースにロードする
ためにも使えます。これを利用して、マスターデータベースを編集で
きます。
ext_srvtab
ホスト依存の srvtab ファイルを作るために、マスターデータベース
から情報を抽出します。そのファイルはホストの Kerberos 化した
サービスの Kerberos 鍵を格納します。こういったサービスは、
その認証過程で srvtab ファイルからその鍵を捜します。
kadmin
リモートからKerberosデータベースの情報を操作する
ksrvutil
リモートからKerberosデータベースの情報にアクセスし、
ローカルのsrvtabをつくり出す
(3) 管理サーバ
kadmind
管理サーバは、マスターデータベースへの変更を行なえます。
(4) 認証サーバ
kerberos
Kerberos サーバ(KDC)です。このプログラムは、クライアントの鍵
やサービスの暗号鍵を管理するマスターデータベースに対して読み
出し専用のアクセスをしてクライアントが要求するチケットを配布
します。
(5) DB 伝搬ソフトウェア
kpropd
(6) ユーザプログラム
kinit
ユーザにユーザ名と Kerberos パスワードの入力を促し、そして、
KerberosのTGTをあてがいます。
kauth
kinit の拡張で、リモートコンピュータにチケットをあてがうこと
が可能です。
kdestroy
有効な切符を破棄します。ユーザはワークステーションからログオフ
する前に kdestroy をするべきです。
klist
ユーザに有効な切符を表示します。
ksrvtgt
パスワードの代わりにサーバの秘密鍵を使って、 5分間有効な発券
許可証をを取得します。シェルスクリプトとその他のバッチ機能の
中で使うために最初に行ないます。
login, su
ログイン認証や、スイッチユーザにKerberosを用いるための
コマンドです。
(7) アプリケーション
ネットワークコマンド
クライアント サーバ
---------------+--------
telnet telnetd
ftp ftpd
BSDネットワークプログラム
クライアント サーバ
---------------+--------
rlogin klogind
rsh kshd
rcp
KPOP メール
クライアント サーバ
---------------+--------
push poper
暗号化Xセッション
クライアント サーバ
---------------+--------
kx kxd
rxterm
rxtelnet
xnlock
暗号化IPトンネル（トンネルデバイスが必要）
クライアント サーバ
---------------+--------
kip kipd
One Time Password（使い捨てパスワード）関連コマンド
otp
otpprint
この他に、AFS(Andrew File System)のサポートや、機種依存ですが、
PAM(Pluggable Authentication Module)があります。
3.2 Kerberos4 の暗号化モジュール
Kerberos4 の暗号化には DES の CBC(Cipher Block Chaining)モードと、そ
の拡張である PCBC(Propagating CBC) モードが選択できます。CBC モードで
はエラーは現行のブロックのみにしか及びませんが、PCBC モードではエラー
が全メッセージに及びます。暗号化のライブラリーは独立したモジュールです
ので別の暗号プロトコルに置き換えることもプログラミングで可能です。もう
一つ、置き換え可能なモジュールはデータベース管理システムです。データベー
ス管理システムにはバークレイdb や gdbmが使えます（MIT版はndbm、もとも
とは Ingres）。Kerberos のデータベースは直線的なもので、各レコードはプ
リンシパルの「名前」と「共有鍵」と「有効期限」とからなります。その他の、
本名や電話番号などのユーザー情報は Hesiod という別のネームサーバを使う
と保存できます。こうして、ネットワークを流れても良い情報とそうでない情
報の管理を分けて行ないます。
3.3 Kerberos4 データベース
Kerberos の各サーバはデータベース管理のためのツールとしてデータ
ベースライブラリを使います。
管理サーバ kadmind はデータベースへのネットワーク越しの読み書きを提
供します。管理クライアント(kadmin)はネットワーク上のどこで走らせてもか
まいませんが、kadmind は Kerberos のマスターデータベースが存在するマシ
ン上で走らせます。
認証サーバ kerberos は、Kerberos データベースの読み出しのみを行ない
ます。プリンシパルの認証とセッション鍵の生成を行ないます。このサーバは
読み出しのみを行いますので、マスター Kerberos データベースを複製して読
み出し専用に置いてあるスレーブマシン上で走らせてもかまいません。
Kerberos データベースのスレーブサーバへの複製は、データベース伝搬プ
ログラム kprop が行ないます。スレーブサーバ上で kpropd を走らせること
により、複数のマシン上で認証サーバを走らせることが可能です。それぞれの
スレーブマシンで走る kpropd は、定期的にマスターマシンの kprop から送
られてくるデータベースのアップデートを受けとり自分のデータベースに反映
させます。
3.4 ユーザプログラム
最後に、エンド-ユーザ・プログラムは、ユーザが Kerberos にログインし
たり、Kerberos パスワードを変更したり、Kerberos のチケットを表示したり
破棄したりするためのものです。ユーザがパスワードを変更するには、
kpassword コマンドを使います。kpassword での変更はマスターデータベース
に反映され、以後、ユーザは新しいパスワードを使うことができます。
3.5 Kerberos名について
Kerberos の世界ではユーザにもアプリケーションサーバにも名前（プリン
シパル名）が付けられます。そして、認証サーバから見るとそれらは等価なも
のです。プリンシパル名は、プライマリ名（名前）、インスタンス、それとレ
ルムから成り、"プライマリ名.インスタンス@レルム" のように表現されます。
プライマリ名はユーザあるいはサービスの名前です。インスタンスはプライマ
リ名の種類を区別します。一般ユーザにはインスタンスは付きませんが、ユー
ザに "root" あるいは "admin" がインスタンスとして付く場合、インスタン
スはそのユーザが持つ特権を表します。また、サービス場合は、インスタンス
はそのサービスが実行されるマシンのホスト名となります。Kerberos のチケッ
トは、それに含まれるプリンシパル名に対応した一つのサーバでのみ有効で、
同じサービス名であっても別のインスタンス名のサーバを使う場合には別のチ
ケットが必要となります。（Kerberos5では "プライマリ名/インスタンス@レ
ルム" になります。）
例えば、
jaco@YOKOHAMA.JP
jaco.admin@YOKOHAMA.JP
rcmd.pluto@YOKOHAMA.JP
のようなプリンシパルが考えられます。最初の２つはjacoという名前のユーザ
プリンシパルで、２つめは admin というインスタンスが付いていて管理用に
使います。３つ目はサービスプリンシパルで、plutoという名前のサーバに用
意された rcmd というサービスです。（KTH版Kerberos4では、rcmdという名前
のサービスには rlogin やrsh、telnet などが含まれます。）
4. Kerberosの導入
ここでは、Kerberosの導入方法について、KTH-KRBのインストールと設定を
例に説明します。Kerberosの導入には、KDCとアプリケーションサーバとクラ
イアントのそれぞれについて、インストールと設定が必要です。また、
Kerberosを導入する際には、その領域内ではすべての認証をパスワードを流さ
ないものに置き換えるなければ、意味を持ちません。極端なことをいえば、領
域すべてをケルベロス化する必要があるということになります。
Kerberosの導入にあたって、何よりも忘れてならないことは、KDCに利用す
るマシンには完璧なセキュリティを施さなければならないということです。と
いうのも、KDC にはそのレルムのプリンシパルすべての鍵が保存されているか
らです。言い替えると、KDC が破られるとそのレルムのセキュリティは全くな
くなってしまうということです。認証局の使命の重さはここにあるわけです。
次に、すべてのマシンの時刻を合わせることです。Kerberosを利用するプリン
シパルのマシンは KDC との時刻差を最大でも５分以内（デフォルト）にしな
ければサービスを受けることはできません。NTPシステムを導入するか、定期
的にコマンド(netdate や rdate)を走らせて、KDCの時刻と同期を取るように
します。
4.1 KTH-KRBのインストール
それでは、ソースコードからのインストールについて説明します。ここでは、
最も単純なインストールの仕方について述べますので、詳しくは附属の文書や
Webページ(http://www.pdc.kth.se/kth-krb/) の情報を参照してください。こ
こでは、説明にコマンド行の例を'%' や '#' で始まる行にて示しますが、'#'
は特に root 特権で実行すべきコマンド行であることを示しています。また、
サブコマンドで入力の必要なところは '' をその印として記してあります。
まず、KTH-KRB をFTPサイトよりダウンロードします。オリジナル FTP サイ
ト(ftp://ftp.pdc.kth.se/pub/krb/src/)から、最新版のソースコードのアー
カイブをダウンロードします。現在(2001-09-02)の最新版は、
krb4-1.0.9.tar.gz です。
% wget ftp://ftp.pdc.kth.se/pub/krb/src/krb4-1.0.9.tar.gz
次に、アーカイブを展開し、構成とメイクを行ないます。構成のときに利用
するデータベース管理ライブラリを選択したりできますが、詳しくは
`./configure --help` コマンドや附属の文書を参照してください。（Linuxの
配布キットによっては、"--without-berkeley-db" を付けて構成し、バークレ
イDBを使わないで GDBM を利用した方が良い場合もあります。）
% tar xvfz krb4-1.0.9.tar.gz
% cd krb4-1.0.9/
% ./configure
% make
そして、KDCやアプリケーションサーバをインストールするマシンではそのま
ま、インストールします。
% su -
# make install
デフォルトでは、以下のようなディレクトリ構成で、/usr/athena/ の下にイ
ンストールされます。
/usr/athena/
+
|-include/
|-lib/
|-bin/
|-libexec/
|-man/
|-info/
|-etc/
`-sbin/
クライアントマシンでも、同じようにインストールを行なえますが、サーバプ
ログラムはインストールしないで、クライアントプログラムだけをインストー
ルしたい場合はトラベルキットを作成して、それをインストールすることもで
きます。
% make travelkit
トラベルキットには、kauth,klist,telnet,ftp,kx,rxtelnet が含まれていま
す。トラベルキットのインストールは次のようにインストール先のディレクト
リパス（ここでは、/usr/athena/bin/）を指定して行ないます。
% tar xvf travelkit.tar -C /usr/athena/bin/
以後の説明においても、KTH-KRBのデフォルトのインストール先を仮定して行
ないます。
4.2 KDCの設定
KDCの設定を行なう前に、まず、レルム名を決めます。習慣では、ドメイン
ネームシステムのドメイン名をそのまま大文字にして使うことになっています。
たとえば、ドメインが yokohama.jp であった場合は、YOKOHAMA.JP にします。
ここでは、便宜上 YOKOHAMA.JP という名前のレルムで KDC を設定することに
します。
(1) プログラムのインストール
繰り返しますが、KDCを開け渡してしまうと、そのKDCが管理するレルム全体
を開け渡してしまうことになります。それゆえ、KDCとするマシンには万全の
セキュリティが必要です。できれば、Kerberos以外のサービスは走らせるべき
ではありません。また、KDCに使うマシンにはそれ自身の信頼性も必要です。
KDC が働かなければ、スレーブサーバを設置していない限り、ケルベロス化さ
れたサービスは利用できなくなってしまいます。Kerberosサーバのインストー
ルや設定に際して、安全な経路が確保されない限りはネットワーク越しではな
く、直接マシンのコンソールからログインして行なうようにしましょう。
ここでは、YOKOHAMA.JPというレルムのKDCをkdc.yokohama.jpというホスト
名のマシンにインストールすることにします。プログラムのインストールにつ
いては前節を参照して下さい。
(2) 構成ファイルのインストール
プログラムのインストールができたら、次は、レルムを構成します。レルム
の構成には、krb.confとkrb.realmsという２つの重要なファイルがあり、通常、
/etc ディレクトリに配置します。/etc/krb.confでローカルレルムの名前の定
義とKerberosサーバの指定をし、 /etc/krb.realmsでレルムに所属するホスト
名を指定します。
ここでは、例として、kdc.yokohama.jpをKDCとし、yokohama.jp ドメインの
すべてのホストをこのレルムに属するホストとして定義することにします。
krb.conf は、
--
YOKOHAMA.JP
YOKOHAMA.JP kdc.yokohama.jp admin server
--
のように記述します。１行目がローカルレルムの名前で、その次の行からは二
次的なローカルレルムやKerberosサーバやデータベース管理サーバを定義でき
ます。ここでは、kdc.yokohama.jpがKDCで、'admin server'という記述で、
Kerberosデータベース(KDB)の管理サーバであることも示します。KDB管理サー
バプログラムはkadmindという名前で、パスワードの変更のときなどにデータ
ベースの更新を行ないます。
krb.realmsは、
--
kdc.yokohama.jp YOKOHAMA.JP
.yokohama.jp YOKOHAMA.JP
--
のようにホスト名とレルムを記述しますが、'.'から始まる行はそのサブドメ
インのホストすべてを意味します。ここでは、yokohama.jpのドメインを持つ
ホストはすべてYOKOHAMA.JPというレルムにあることを示しています。
(3)サービスポートの追加
KerberosサーバとKDB管理サーバとが利用するポートを/etc/servicesに加え
ます。KTH-KRBソースツリーのetcディレクトリにはservices.appendという名
前で追加するサービスポートの雛型がデフォルトの番号で用意されています。
--
#
# $Id: services.append,v 1.13 1999/07/06 13:08:02 assar Exp $
#
# Kerberos services
#
kerberos-sec 88/udp # Kerberos secondary port UDP
kerberos-sec 88/tcp # Kerberos secondary port TCP
kpasswd 464/udp # password changing
kpasswd 464/tdp # password changing
klogin 543/tcp # Kerberos authenticated rlogin
kshell 544/tcp krcmd # and remote shell
ekshell 545/tcp # Kerberos encrypted remote shell -kfall
ekshell2 2106/tcp # What U of Colorado @ Boulder uses?
kerberos-adm 749/udp # v5 kadmin
kerberos-adm 749/tcp # v5 kadmin
kerberos-iv 750/udp kerberos kdc # Kerberos authentication--udp
kerberos-iv 750/tcp kerberos kdc # Kerberos authentication--tcp
kerberos_master 751/udp # v4 kadmin
kerberos_master 751/tcp # v4 kadmin
krb_prop 754/tcp hprop # Kerberos slave propagation
kpop 1109/tcp # Pop with Kerberos
eklogin 2105/tcp # Kerberos encrypted rlogin
rkinit 2108/tcp # Kerberos remote kinit
kx 2111/tcp # X over kerberos
kip 2112/tcp # IP over kerberos
kauth 2120/tcp # Remote kauth
--
なお、/etc/servicesファイルにポートの記述が見つからない場合はデフォルトの
ポートが使われるようになっています。
(4) Kerberosサーバの設定
Kerberosデータベースを初期化する前に、まず、/usr/athena/binと
/usr/athena/sbinにコマンドパスを通しておきます。それから、データベー
スを保存するためのディレクトリ/var/kerberosを作り、データベースの初期
化コマンドkdb_init を実行し、レルム（ここではデフォルトのまま）とマス
ターパスワードを入力します。
--
# mkdir /var/kerberos
# kdb_init
Realm name [default YOKOHAMA.JP ]:
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter Kerberos master password: xxxxxxxxx
Verifying password -
Enter Kerberos master password: xxxxxxxxx
--
マスターパスワードはKerberosデータベースの暗号化とランダム鍵を生成す
るために使われ、kerberosサーバを起動するときにも必要となりますが、
kstash コマンドでマスターパスワードを使ってディスク上にキャッシュして
おくとその必要もなくなります。
--
# kstash
Enter Kerberos master password: xxxxxxxxx
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Wrote master key to /.k
--
スタッシュファイルは、/.k という名前で保存され、以後、kerberos起動時
に鍵は自動的に読み出されます。
初期化されたデータベースには、Kerberosサーバへの認証に使う鍵、パスワー
ドの変更に使う鍵、デフォルトの有効期限、マスター鍵など最小限必要なプリ
ンシパルが登録されています。
(5) 管理ユーザの登録
Kerberosデータベースの初期化を済ませたら、次にkdb_editを使って、管理
ユーザのプリンシパルを登録します。ここでは、jaco.admin を登録してみま
す。kdb_edit を "-n" オプション起動すると、スタッシュファイルから鍵を
取り出すので、マスターパスワードを入力する必要がありません。
--
# kdb_edit -n
Opening database...
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
Principal name: jaco
Instance: admin
, Create [y] ?
Principal: jaco, Instance: admin, kdc_key_ver: 1
New Password: xxxxxxxxx
Verifying password -
New Password: xxxxxxxxx
Principal's new key version = 1
Expiration date (yyyy-mm-dd) [ 2006-09-01 ] ?
Max ticket lifetime (*5 minutes) [ 2 ] ?
Attributes [ 0 ] ?
Edit O.K.
Principal name:
--
ひととおり項目に入力がされると、再び "Principal name: " がプロンプト
に現れたとき、何も打たないで入力だけすると kdb_edit プログラムは終了し
ます。（ここでは、"Max ticket lifetime (*5 minutes) [ 2 ]" のように 2
がデフォルトとなっていますが、インスタンスがない場合は 255 がデフォル
トとして表示されます。）
(6) Kerberosサーバ(KDC)の起動
さて、いよいよKerberosサーバの起動です。
--
# /usr/athena/libexec/kerberos &
Kerberos server starting
Sleep forever on error
Log file is /var/log/kerberos.log
Current Kerberos master key version is 1.
Master key entered. BEWARE!
Current Kerberos master key version is 1
Local realm: YOKOHAMA.JP
--
Kerberosサーバを起動したら、前に追加したプリンシパルが使えることを確認
しておきます。kinitコマンドでTGTを取得し、それをklistコマンドで確認し
ます。
--
# kinit
eBones International (krb)
Kerberos Initialization
Kerberos name: jaco.admin
Password:
# klist
Ticket file: /tmp/tkt0
Principal: jaco.admin@YOKOHAMA.JP
Issued Expires Principal
Sep 2 23:14:58 Sep 2 23:24:58 krbtgt.YOKOHAMA.JP@YOKOHAMA.JP
--
(7) 管理サーバの起動
Kerberos管理サーバ kadmind によって、リモートから安全にKerberosデー
タベース（KDB）を操作できます。kadmind は一連のアクセスコントロールリ
スト（ACL）をもとにKDBへのアクセス権を判断します。ACLファイルは、
/var/kerberosディレクトリにあってKDBアクセスの種類により、
admin_acl.add, admin_acl.get, admin_acl.mod, admin_acl.del の４つのファ
イルにわかれています。ここでは、それぞれのACLファイルに管理ユーザプリ
ンシパルを登録しておきます。
--
echo "jaco.admin@YOKOHAMA.JP" >> /var/kerberos/admin_acl.add
echo "jaco.admin@YOKOHAMA.JP" >> /var/kerberos/admin_acl.get
echo "jaco.admin@YOKOHAMA.JP" >> /var/kerberos/admin_acl.mod
echo "jaco.admin@YOKOHAMA.JP" >> /var/kerberos/admin_acl.del
--
ACLファイルの登録を終えたら、管理サーバを起動します。
--
# /usr/athena/libexec/kadmind &
KADM Server KADM0.0A initializing
Please do not use 'kill -9' to kill this job, use a
regular kill instead
Current Kerberos master key version is 1.
Master key entered. BEWARE!
--
管理サーバを起動したら、kadminコマンドを使ってユーザをデータベースに登
録できることを確認しておきます。
--
# kadmin -p jaco.admin -m
kadmin: add jaco
jaco.admin@YOKOHAMA.JP's Password: xxxxxxxxx
Maximum ticket lifetime? (162) [4+07:34:45]
Attributes? [0x00]
Expiration date (enter yyyy-mm-dd) ? [2003-09-02]
Password for jaco:XXXXXXXX
Verifying password - Password for jaco:XXXXXXXX
jaco added to database.
--
続けてユーザプリンシパルが登録されているのを確認してkadminを抜けます。
--
kadmin: get jaco
Principal: jaco
Max ticket life: 162 (4+07:34:45)
Expiration date: 2003-09-02 14:35:58
Attributes: 0
Modification date: 2001-09-02 23:36:20
Modifier: jaco.admin
Key version: 1
kadmin: q
--
(7) サーバ起動を自動化
最後に、KDCとKDB管理サーバの起動を自動化します。起動スクリプトはそれ
ぞれのシステムによって記述の仕方や配備の仕方が異なりますが、参考までに
Plamo Linuxでの設定例を揚げておきます。
Plamo LinuxはかつてのSlackware Linuxの名残があります。次のような実行
可能なスクリプトを /etc/rc.d/rc.krb4 という名前で作っておき、
--
#!/bin/sh -f
#
# HISTORY
# Creation: 1997-04-10
# Auther: JuK
#
#
KERBEROS=/usr/athena/libexec/kerberos
krbdaemon="kerberos(Kerberos 4 KDC)"
KADMIND=/usr/athena/libexec/kadmind
kdmdaemon="kadmind(Kerberos DB admin. daemon)"
krbpid=`ps ax | grep $KERBEROS | grep -v grep | sed -e 's/^ *//' -e 's/ .*//' `
kdmpid=`ps ax | grep $KADMIND | grep -v grep | sed -e 's/^ *//' -e 's/ .*//' `
#
# start or stop kerberos (KDC)
# start or stop kadmind (Kerberos DB admin. daemon)
#
case $1 in
'start')
if [ -x $KERBEROS ]; then
if [ "X$krbpid" = "X" ]; then
$KERBEROS &
echo "$0: $krbdaemon started."
krbpid=`ps ax | grep $KERBEROS | grep -v grep | sed -e 's/^ *//' -e 's/ .*//' `
echo "$0: Proccess ID = $krbpid"
else
echo "$0: $krbdaemon is ALREADY running(PID = $krbpid)."
fi
else
echo "$0: $KERBEROS does NOT exist."
exit 1
fi
if [ -x $KADMIND ]; then
if [ "X$kdmpid" = "X" ]; then
$KADMIND &
echo "$0: $kdmdaemon started."
kdmpid=`ps ax | grep $KADMIND | grep -v grep | sed -e 's/^ *//' -e 's/ .*//' `
echo "$0: Proccess ID = $kdmpid"
else
echo "$0: $kdmdaemon is ALREADY running(PID = $kdmpid)."
fi
else
echo "$0: $KADMIND does NOT exist."
exit 1
fi
;;
'stop')
if [ -x $KERBEROS ]; then
if [ "X$krbpid" != "X" ]; then
/bin/kill $krbpid
echo "$0: $krbdaemon has been killed."
else
echo "$0: $krbdaemon is NOT running."
fi
fi
if [ -x $KADMIND ]; then
if [ "X$kdmpid" != "X" ]; then
/bin/kill $kdmpid
echo "$0: $kdmdaemon has been killed."
else
echo "$0: $kdmdaemon is NOT running."
fi
fi
;;
*)
echo "usage: $0 {start|stop}"
# check kerberos
if [ "X$krbpid" != "X" ]; then
echo "$0: $krbdaemon is ALREADY running(PID = $krbpid)."
else
echo "$0: $krbdaemon is NOT running."
fi
# check kadmind
if [ "X$kdmpid" != "X" ]; then
echo "$0: $kdmdaemon is ALREADY running(PID = $kdmpid)."
else
echo "$0: $kdmdaemon is NOT running."
fi
exit 1
;;
esac
exit 0
--
そして、/etc/rc.localに次のような数行を追加します。
--
if [ -x /etc/rc.d/rc.krb4 ]; then
/etc/rc.d/rc.krb4 start
fi
--
4.3 アプリケーションサーバの設定
KTH-KRBには、rshd,rlogind,telnetd,ftpd,popperなどのサービスがありま
す。KDCの設定と同じように、Kerberosをインストールした後に/etc/krb.conf
と/etc/krb.realmsを設定し、/etc/services にサービスを加えます。それか
ら、ソースツリーの etc/inetd.conf.changes を参考に /etc/inetd.conf を
編集します。etc/inetd.conf.changes は次のような内容です。
--
#
# $Id: inetd.conf.changes.in,v 1.14 1999/11/10 14:21:07 joda Exp $
#
# Turn off vanilla rshd and rlogind with an informational message.
# If you really want this security problem remove the '-v' option!
shell stream tcp nowait root /usr/athena/libexec/rshd rshd -l -L -v
login stream tcp nowait root /usr/athena/libexec/rlogind rlogind -l -v
#
# Kerberos rsh
kshell stream tcp nowait root /usr/athena/libexec/rshd rshd -L -k
ekshell stream tcp nowait root /usr/athena/libexec/rshd rshd -L -k -x
ekshell2 stream tcp nowait root /usr/athena/libexec/rshd rshd -L -k -x
#
# Kerberos rlogin
klogin stream tcp nowait root /usr/athena/libexec/rlogind rlogind -k
eklogin stream tcp nowait root /usr/athena/libexec/rlogind rlogind -k -x
#
# Kerberized telnet and ftp, consider adding '-a user' to
# disallow cleartext passwords to both telnetd and ftpd.
telnet stream tcp nowait root /usr/athena/libexec/telnetd telnetd -a none
ftp stream tcp nowait root /usr/athena/libexec/ftpd ftpd -l -a none
#
# Kerberized POP. Server principal is pop.hostname, *not* rcmd.hostname!
#kpop stream tcp nowait root /usr/athena/libexec/popper popper -k
#
# Old POP3 with passwords in clear (not recommended, uses cleartext passwords)
#pop3 stream tcp nowait root /usr/athena/libexec/popper popper
#
# Kauthd, support for putting tickets on other machines in a secure fashion.
kauth stream tcp nowait root /usr/athena/libexec/kauthd kauthd
#
# Encrypted X connections
kx stream tcp nowait root /usr/athena/libexec/kxd kxd
--
このサンプルでは、telnetdとftpdとに "-a none" オプションがあって匿名ロ
グインや平文パスワードも許しているのですが、Kerberos認証だけにしたけれ
ば、"-a none"の代わりに"-a user"をオプションにします。
サービスの登録で忘れてならないことはサービス鍵の保存です。すべてのユー
ザがKDCに登録されたパスワードの鍵を持っているのと同じように、すべての
サービスもKDCと鍵を共有する必要があることです。このサービス鍵はアプリ
ケーションサーバ上では /etc/srvtab という名前のファイルに保存します。
この作業はksrvutilコマンドで行なえます。ここでは、アプリケーションサー
バのホスト名をplutoとして、rcmd.plutoというプリンシパルのサービス鍵を
設置する例を示します。
--
# ksrvutil -p jaco.admin get
Name [rcmd]:
Instance [pluto]:
Realm [YOKOHAMA.JP]:
Is this correct? (y,n) [y]
Add more keys? (y,n) [n]
Password for jaco.admin@YOKOHAMA.JP:
Added rcmd.pluto@YOKOHAMA.JP
Old keyfile in /etc/srvtab.old.
--
これだけの操作で、サービスプリンシパルのKerberosデータベースへの登録と
サービスキーファイルの取得更新が行なわれます。
よく使われるサービスプリンシパルとそれを使うプログラムを以下に示しま
す。
rcmd.ホスト名
rsh, rcp, rlogin, telnet, ftp, kauth, su
rcmd.kerberos
kprop
pop.ホスト名
popper, movemail, push
sample.ホスト名
sample_server, simple_server
changepw,kerberos
kadmin, kpasswd
krbtgt.レルム
kerberos
4.4 クライアントの設定
rsh,rlogin,telnet,ftp,pushなどのクライアントアプリケーションのインス
トールと設定もKDCの設定と同じように、Kerberosをインストールした後に
/etc/krb.confと/etc/krb.realmsを設定し、/etc/services にサービスを加え
ます。管理ツールが不要でクライアントプログラムだけあればよいのなら、
ftp://ftp.pdc.kth.se/pub/krb/binaries/ に用意されたトラベルキットをイ
ンストールして利用することも可能です。以下のバイナリーコードの用意があ
ります。なお、インストールが終ったら、Kerberosのユーザコマンドがインス
トールされている場所へコマンドパスを通すことを忘れないようにしましょう。
--
alpha-dec-osf3.2
alpha-dec-osf4.0
f301-fujitsu-uxpv4.1
hppa-hp-nextstep3.3
hppa1.1-hp-hpux10.10
hppa1.1-hp-hpux9.05
i386-pc-openbsd2.3
i386-pc-openbsd2.4
i386-sun-solaris2.5
i386-unknown-bsdi1.1
i386-unknown-bsdi2.0
i386-unknown-linux1.3
i386-unknown-linux2.0
i386-unknown-linux2.2
i386-unknown-netbsd1.2
i386-unknown-netbsd1.3
i386-unknown-unknown
i386-unknown-winnt4.0
j90-cray-unicos9.0
mips-dec-ultrix4.4
mips-sgi-irix4.0.5
mips-sgi-irix5.3
mips-sgi-irix6.2
mips-sgi-irix6.3
mips-sgi-irix6.5
powerpc-apple-darwin1.2
powerpc-ibm-aix4.2
rs6000-ibm-aix3.2.5
rs6000-ibm-aix4.1
rs6000-ibm-aix4.3
sparc-sun-linux2.0
sparc-sun-solaris2.4
sparc-sun-solaris2.5
sparc-sun-solaris2.6
sparc-sun-sunos4.1
t3e-cray-unicosmk2.0
--
4.5 Windows版クライアントの設定
Windows95/98/NT/2000で稼働するKerberosのクライアントKTelnetが
http://www.stacken.kth.se/~thn/ktelnet/にあります。KTW32.EXE という名
前のファイルをダウンロードして実行するとインストーラが立ち上がります。
インストーラの指示に従ってインストールをすることができます。このプログ
ラムキットには、Telnet,FTP,KPOPProxy,および、チケットマネージャが含ま
れています（図 ktelnet-progs.gif）。
KTelnetでの設定は、各プログラムのメニューバーから
[Connection]->[Propaties]を選ぶとプロパティの設定ダイアログがポップアッ
プして、krb.configとkrb.realmsの設定を行なうことができます。
図 krbconfig.gifのように、設定表示のボックスで右のマウスボタンをクリック
するとメニューが出てきますので、[Add ...]を選ぶとひとつづつ追加ができ、
[Import] を選ぶと（あらかじめ用意しておけば良い）、既に存在するファイ
ルから読み込むこともできます。
KTelnetの設定で注意するべきなのはKPOPProxyの設定です。このプログラム
は名前のとおり、KPOPクライアントというわけではなく、プロキシサーバです。
何でも使えます。たとえば、Outlookではメニューバーより、[ツール]->[アカ
ウント]->[メール]で設定を[追加]するか[プロパティ] で編集し、[サーバ]の
設定を図outlook-setting.gif のようにすることで、KPOPProxyが代わりに
KPOPサーバ（ここでは、mx.yokohama.jp）へアクセスしてくれるようになりま
す。
5. Kerberosレルムでの作業例
ここでは、実際に Kerberos を導入したシステム上でリモートホストのサー
ビスプログラムを実行するときのユーザの立場での操作例を順を追って説明し
ます。Kerberos システムで実際に作業を行なうユーザは、 Kerberos による
認証がどのように行なわれているかについては、ほとんど意識する必要はあり
ません。ただ、チケット(TGT)持っていればそのレルムのサービスを受けられ
るということだけは覚えておいてください。
ここでは、earthというホストにログインしているユーザが、plutoというホ
ストのrcmdという名前で登録されたサービス(rlogin,telnet)を利用すること
を例に説明を行なってゆきます。
5.1 Kerberos チケット(TGT)の入手
まずユーザは自分のワークステーションのコンソールからログインします。
そして、kinit コマンド（あるいは、kauthコマンド）を実行してTGTを得ます。
得られたチケット(TGT)は klist コマンドで確認することが可能です。ここで
は、ユーザが実際にkinitを実行するワークステーションのコンソールの前ま
で歩いて行くことが大切です。ネットワーク越しにログインした端末から
kinit コマンドを実行したのではユーザ鍵が洩れてしまうおそれがあります。
試しに、実際に自分の端末でTGTの入手をしてみます。（Kerberos化したシス
テムが標準システムとは別の場所にあるシステム上ではコマンドやファイルの
パスに気をつける必要があります。）
--
% kinit
eBones International (earth)
Kerberos Initialization
Kerberos name: jaco
Password: xxxxxxxx
% klist
Ticket file: /tmp/tkt10001
Principal: jaco@YOKOHAMA.JP
Issued Expires Principal
Sep 3 16:46:12 Sep 4 02:46:12 krbtgt.YOKOHAMA.JP@YOKOHAMA.JP
--
ここでは、YOKOHAMA.JPというレルム名が使われています。
jaco@YOKOHAMA.JPはユーザのプリンシパル名で、kinitによって デフォルトの
有効期限の8時間後まで使えるTGTが得られたことが分かります。この TGT の
プリンシパル名がkrbtgt.YOKOHAMA.JP@YOKOHAMA.JPというわけです。そして、
このTGTが/tmp/tkt10001というファイルにキャッシュされています。tkt10001
の 10001 はログインしている UNIX システム上でのユーザIDです。
5.2 Kerberos 化されたコマンドの実行
TGTが手に入ると次はKerberos化されたコマンドを実行すのみです。前節の
(3)〜(5)の処理はユーザが使うクライアント-サーバ・アプリケーションの中
にプログラムされています。例えば、rloginを使ってみます。このrlogin の
実装ではkerberosのログインに失敗した場合は通常のログインを試みます。
--
% rlogin pluto
*** Connection not encrypted! Communication may be eavesdropped. ***
*** Use telnet or rlogin -x instead! ***
Last login: Thu Sep 3 16:36:05 from earth
Linux 2.0.29.
pluto:~$
--
このrloginセッションの終了後、再び、klist でチケットのリストを見ると：
--
pluto:~$ exit
logout
rlogin: connection closed.
% klist
Ticket file: /tmp/tkt10001
Principal: jaco@YOKOHAMA.JP
Issued Expires Principal
Sep 3 16:46:12 Sep 4 02:46:12 krbtgt.YOKOHAMA.JP@YOKOHAMA.JP
Sep 3 17:02:49 Sep 4 02:47:49 rcmd.pluto@YOKOHAMA.JP
--
新たに rcmd.pluto@YOKOHAMA.JPというプリンシパルに対するチケットが加わっ
ています。このチケットは rlogin を実行したことによって得られたものです。
そして、同じサービス（YOKOHAMA.JPというレルム内のpluto というインスタ
ンスの rcmd という名前のプリンシパル）に対してはこのチケットが再利用可
能です。
Kerberos化の方法についてユーザは全く気にする必要がありません。ただし、
通常ネットワークを経由するデータの全てを暗号化して行ないたいときなどは、
実装によってコマンド起動時のオプションの指定をするようになっている場合
が多いため、そのオプションを知る必要があります。たいていは、オンライン
マニュアルなどに記述されているはずです。たとえば、telnet のセッション
全てを暗号化して行ないたい時は "-x" オプションをつけて実行します。
例えばこんな具合に暗号化されているという意味のメッセージが出ます。
--
% telnet -x pluto
Encryption is verbose
Trying 192.168.1.252...
Connected to pluto.yokohama.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 Sep 3 12:17:17 from earth
Linux 2.0.29.
You have new mail.
pluto:~$
--
5.3 Kerberos チケットの破棄
ユーザは、作業を終わって端末から離れる前にチケットを全て破棄します。
チケットは期限が切れるまでは再利用可能ですので、少しでも危険がないよう
にすることをお勧めします。チケットの破棄は kdestroy コマンドで行ないま
す。kdestroy をした後、全てのチケットがなくなったことを klist コマンド
で確認できます。
--
% kdestroy
Tickets destroyed.
% klist
Ticket file: /tmp/tkt10001
klist: No ticket file (tf_util)
--
Kerberosチケットが破棄されても、最初にだけKerberos認証が必要なアプリケー
ションを使っている場合は、そのままセッションを続けて利用できます。チケッ
ト破棄後はKerberos認証を必要とするコマンドはエラーを起こします。
--
% rlogin pluto
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
% telnet pluto
Trying 192.168.1.252...
Connected to pluto.yokohama.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
jaco's Password:
--
ここでは平文パスワードのプロンプトが表示されていますが、失敗したとき
にパスワード認証やワンタイム・パスワード認証を使うかどうかは、サーバ起
動時のオプションの指定によって違ってきます。
5.4 Kerberos パスワードの変更
Kerberos のパスワードの変更は一般的な UNIX パスワードの変更と同じよ
うにできます。コマンドが kpasswd に変わるだけです。ただし、大きな違い
は、自分の Kerberos パスワードを一度変更すると、そのレルム内での自分の
パスワードが変更され、各マシン毎に変更する必要は無いということです。
NIS(Network Informatin System)をお使いになった経験のある方は yppasswd
をご存知だと思いますが kpasswd でもそれと同じ効果を期待できます。
--
% kpasswd
Old password for jaco: xxxxxxxx
New Password for jaco: XXXXXXXX
Verifying New Password for jaco: XXXXXXXX
Password changed.
--
6. Kerberosの今後
既に述べたように、MITの配布するKerberosの最新版はバージョン５となっ
ています。Kerberos5は、プロトコルとしてRFCから発行されているだけでなく、
さらに新しい機能を追加しつつあります。その一つが、PK_INITという公開鍵
暗号方式を初期認証でサポートするためにKerberos を拡張する修正パッケー
ジで、http://gost.isi.edu/info/pk_init/ から情報を得られます（残念なが
らパッチのソースは手にはりません）。
KTHではHeimdalが国際版Kerberos5として開発中です。現在はまだベータ版
ですが、GSSAPI のサポート、OpenLDAP のサポート、Windows 2000との認証、
PAMなど試してみたい機能もいろいろあり今後が楽しみです。RedHat Linux に
も Kerberos5 が含まれていて、(2002年01月現在)国内でも実際に稼働報告が
されてます。
オーストラリアの分散システム技術センター(DSTC:Distributed Systems
Technology Centre)では、分散環境におけるセキュリティツールの開発を行っ
ています。ここでは、JCSI:Java Crypto and Security Implementationという
JAVA用の暗号モジュールクラスの開発が行なわれています。
(http://security.dstc.edu.au/projects/java/features.html) すでに、
PostgreSQL,CVS,Samba,SSH,fetchmail,LPRngなどではKerberos 認証がサポー
トされていて、メイク前の構成オプションで指定可能になっています。今後、
Kerberosを利用できる開発言語が増えることで、Kerberosを利用できるアプリ
ケーションも増えてくることも期待できそうです。
最後に、日本ではKerberosの知名度が低いのが少し残念ですが、最近、（株）
シンク・ラボが日本語のメーリングリスト(KRB-JP ML)を立ち上げてくれまし
た。Kerberosについてなんでもかまいませんので、情報や経験をお持ちの方は
し是非参加して意見交換などいたしましょう。MLへの参加は、
http://www.sync-labo.co.jp/ の「Kerberos認証」というページからたどれま
す。また、拙作のWebページも http://www.rccm.co.jp/~juk/krb/にあります。
少しでも皆様のお役に立てれば幸いです。
参考文献
"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
参照URI
MIT Kerberos http://web.mit.edu/kerberos/www/
Kerberos FAQ http://www.ov.com/misc/krb-faq.html
KTH-KRB http://www.pdc.kth.se/kth-krb/
KTH Heimdal http://www.pdc.kth.se/heimdal/
KTH KTelnet http://www.pdc.kth.se/~thn/ktelnet/
The Moron's Guide to Kerberos
http://www.isi.edu/gost/brian/security/kerberos.html
Kerberos Notes for Japanese http://www.rccm.co.jp/~juk/krb/
RFC1510和訳 http://www.ipa.go.jp/SECURITY/rfc/RFC1510-00JA.html
SESAME https://www.cosic.esat.kuleuven.ac.be/sesame/
MSのKerberos http://www.microsoft.com/windows2000/techinfo/howitworks/security/kerberos.asp
ftp://athena-dist.mit.edu/pub/ATHENA/kerberos
ftp://ftp.funet.fi/pub/unix/security/login/kerberos
http://www.npa.go.jp/hightech/sec_repo/title.htm
http://www.mpt.go.jp/policyreports/japanese/group/internet/ninshou/index.html
米国商務省規制緩和アナウンス
http://204.193.246.62/public.nsf/docs/60D6B47456BB389F852568640078B6C0
CalNet Kerberos Implementation Report
http://wssg.berkeley.edu/public/Reports/WSSG_Kerberos_Implementation_Report.html
KTelnetでの設定は、各プログラムのメニューバーから
[Connection]->[Propaties]を選ぶとプロパティの設定ダイアログがポップアッ
プして、krb.configとkrb.realmsの設定を行なうことができます。