ケルベロス認証
プロトコル概要
Kerberos サーバーを運用したい組織は、独自の 「レルム」を構築する。レルムに属するマシンやサービスはプリンシパルと呼ばれる。レルムにはKDC（key distribution center、直訳：鍵配送センター）と呼ばれる権限者が存在する。KDCはAS（Authentication Server、直訳：認証サーバ）というサーバとTGS（Ticket Granting Server、意訳：チケット発行許諾サーバ）というサーバがある。
ユーザがレルムにログインする際には、まず自身の持つクライアント端末からID/パスワードなどで認証を受け、認証が受理されたらクライアント端末はこのパスワードを利用して秘密鍵Kを生成する。クライアントはユーザのIDを平文でASに送り、ASはユーザのIDを自身のデータベースに問い合わせる事でユーザの秘密鍵Kを得る。
次にASはTGT（ticket-granting ticket、意訳：チケット発行許諾チケット）と、クライアント/TGSセッション鍵とをKで共通鍵暗号化してクライアント端末に送る。TGTはユーザがTGSから「チケット」というデータを受け取るための、いわば大本となるチケットであり、クライアント/TGSセッション鍵はTGSからチケットを受け取る際に用いるセッション鍵である。ASはTGSにもTGTとクライアント/TGSセッション鍵とを渡しておく。なお共通鍵暗号としては（バージョン4においては56bitDES暗号）を用いる。
その後ユーザがレルム内にあるプリンシパルAが提供しているサービスを利用したくなったら、ユーザのクライアント端末はTGTをAのサービスを使いたい旨とともにTGSに送る。この際の通信はクライアント/TGSセッション鍵で共通鍵暗号化しておく。TGSはTGTの正当性を確認し、チケットという、Aのサービスを利用する許可証をクライアント端末に送り、さらにAとの通信で用いるセッション鍵もクライアント端末に送る。
チケットに記載された有効期限内にチケットを（セッション鍵で暗号化して）プリンシパルAに送れば、クライアント端末はAの提供するサービスを利用できる。
以上のようにKerberosでは、ユーザがID/パスワードを使うのは最初にASから認証を受ける時だけ、以後はTGTを使って（TGSから）認証を受ける。このようにID/パスワードの利用を最小限に抑える事で、Kerberosではパスワードの漏洩を防いでいる。
またクライアント端末がプリンシパルAのサービスを使うためにAから認証を受ける際には、ASから受け取ったTGTを直接プリンシパルAに送信する事はしていない。その代わりに一旦権限者であるTGSにTGTを送ることで認証を受けてから、Aへのアクセスのみに利用できるチケットを発行してもらい、このチケットをAに送信する事でAの認証を受け、サービスを利用する。このような方法を取るのは、TGTを直接Aに送ってしまうと、AがTGTを使ってユーザになりすまして別のプリンシパルBのサービスを利用する事ができてしまうからである。
歴史
1980年代のマサチューセッツ工科大学 (MIT) にて研究プロジェクトとして始まった。MITのAthenaプロジェクトでは開始当初からクライアントサーバモデルを想定して設計されており、そのネットワーク認証のためにKerberosプロトコルが開発された。この認証システムは、経路上での盗聴を防ぐために、認証サーバとその他のコンピュータとの間の認証のやりとりを暗号化している。
Kerberosバージョン3まではテストのために開発され、MIT内部でのみ使われた。そして、1989年1月24日に初めてMIT外部にKerberosバージョン4として公開される。Kerberosはいくつかのベンダーに採用されることとなった。
Kerberosバージョン4はDESを用いていたため、アメリカ政府の暗号化ソフトウェアに対する輸出規制に引っかかり、アメリカ国外の組織はMITから合法的にソフトウェアをダウンロードすることはできなかった。そのため、MITの開発チームは、Kerberosのソフトウェアから暗号化のコードをすべて取り除き、骨格だけにした「Bones」を作成した。オーストラリアのエリック・ヤングがこのBonesに独自のDES実装を追加した「eBones」を開発したことで、アメリカ国外でも合法的にKerberosバージョン4を使うことができるようになった。
その後、Kerberosバージョン4に機能を追加し、セキュリティの強化を行ったバージョン5が開発される。Kerberosバージョン5のプロトコルはRFC 1510で文書化されている。