Kerberos

読み：けるべろす　／　英語表記：Kerberos

セキュリティ

信頼された第三者が発行するチケットと共通鍵暗号を使い、利用者やサービスの身元を確認するネットワーク認証プロトコルである。一度のログインを複数のサービスの認証につなげるシングルサインオンを実現できる。

イマシルちゃんの解説

社内のファイルサーバや業務システムを使うたびに、同じパスワードを入力するのは大変だね。
Kerberosは、本人確認を担当するサーバが発行したチケットを使って本人を確認する認証プロトコルだよ。
最初に本人確認を済ませると、その結果を使って利用先ごとのチケットを受け取れるんだ。
利用先のサーバにはパスワードを渡さず、チケットと「その本人が今アクセスしている」と確認できる情報を送るよ。
これなら各サービスにパスワードを預けずに、何度も入力する手間を減らせるんだ。

より深い解説

認証を共有するための登場者

Kerberosは、クライアントと利用先サーバが信頼する認証機関を置く方式である。各サービスが利用者のパスワードを個別に確認する代わりに、認証機関が発行した情報を検証する。WindowsのActive Directory Domain Servicesではドメインコントローラーがこの役割を担う。Kerberos自体はWindows専用の方式ではない。

中心となる認証機関をKDC（Key Distribution Center：鍵配布センター）と呼ぶ。その内部には最初の認証を担当するAS（Authentication Service）と、利用先ごとのチケットを発行するTGS（Ticket-Granting Service）がある。二つの役割を、必ず別々の物理サーバに置くという意味ではない。

登場者	持っている情報と役割
クライアント	利用者の認証を行い、受け取ったチケットと通信に使う鍵を保存する
鍵配布センター	利用者やサービスの登録情報と鍵を管理し、認証とチケット発行を行う
利用先サーバ	自分のサービス用の鍵を使ってチケットを検証し、接続してきた利用者を確認する

認証で分かるのは「誰として接続しているか」である。その人にファイルの更新を許すかは認可の仕事であり、アクセス制御リストなどの規則も必要になる。三者の関係とWindowsでの実装はMicrosoftの概要資料で確認できる。

チケットを二段階に分ける理由

最初の認証で受け取るのはTGT（Ticket-Granting Ticket：チケット発行用チケット）である。これは通常のファイルサーバへ直接提示するものではない。利用先のサービスチケットを発行してもらうために使う。

例えばファイル共有と社内Webサイトの両方を利用するとき、クライアントは同じ発行用チケットを使って、それぞれの利用先に対応するサービスチケットを取得する。このため最初の認証結果を使い回せる一方、あるサービス用のチケットを別のサービスへそのまま提示しても認証には使えない。

この仕組みを支える鍵には、継続して管理する長期鍵と、一時的に共有するセッション鍵がある。利用者は認証機関との間に長期鍵を持ち、各サービスも認証機関と自分用の長期鍵を共有する。認証機関はその関係を使って、クライアントと利用先が同じ一時的な鍵を安全に持てるようにする。

チケットの暗号化された部分には本人情報や有効期間、一時的に共有する鍵などが入る。発行用チケットは発行機関用の鍵で保護し、サービスチケットは利用先サービス用の鍵で保護する。クライアントがチケットを運ぶからといって、その暗号化部分を自由に読み書きできるわけではない。基本概念はMIT Kerberosの解説に整理されている。

初回ログインで何が起きるか

ここではパスワードから導出した長期鍵と、暗号化した時刻による事前認証を使う例を考える。パスワードそのものをネットワークへ送る手順ではない。

クライアントは入力されたパスワードから鍵を導出する。
最初の要求であるAS-REQに本人の識別情報を入れる。事前認証の例として、導出した鍵で現在時刻を暗号化した情報も送る。
認証機関は登録済みの鍵でその情報を検証する。成功すると発行用チケットと、クライアントが発行サービスとの通信に使う一時的な鍵を用意する。
応答であるAS-REPを返す。クライアント向けの鍵情報は本人の長期鍵で保護されるため、クライアントは手元で導出した鍵を使って取り出す。

発行用チケットと取り出した鍵は資格情報キャッシュに保存する。その後のサービスチケット取得では、この保存済みの情報を使えるのでパスワードを再入力しなくてよい。処理の詳細は最初の認証交換の説明に対応する。

Kerberosの最初の認証方法はパスワードだけに限られない。公開鍵暗号と証明書を利用するPKINITという拡張もある。ただし、最初にどの方式で認証したかと、その後にチケットを使う流れは区別して理解する。RFC 4556はこの拡張を定めている。

利用先への接続を追う

最初の認証を終えた利用者が社内のファイルサーバへ接続するとする。接続先を示す識別情報を使って、そのサーバ用のチケットを要求する。

順序	メッセージ	主な内容
1	TGS-REQ	発行用チケット、接続先の識別情報、要求を作った本人を確認する情報を認証機関へ送る
2	TGS-REP	接続先用のサービスチケットと、接続先と共有する一時的な鍵が返る
3	AP-REQ	サービスチケットと、新しく作った本人確認用の情報を利用先サーバへ送る
4	AP-REP	相手側の身元も確認する場合、サーバが共有した鍵を使った応答を返す

接続先と共有する鍵は二通りに届けられる。クライアント向けには発行サービスとの間で共有した鍵で保護して返す。利用先向けにはサービスチケットへ入れ、そのサービスの長期鍵で保護する。これで両者は同じ鍵を取り出せる。サービスチケット取得の説明にこの対応が示されている。

チケットと一緒に送る本人確認用の情報を認証子（Authenticator）と呼ぶ。これは時刻などを含み、共有した鍵で暗号化される。サーバはチケットを開いて取り出した鍵で、クライアントが作成した情報も検証する。サーバが同じ鍵を使って応答すれば、クライアント側も正しい相手であることを確認できる。このように両者が相手を確認することを相互認証と呼ぶ。クライアントとサーバの認証交換を参照できる。

盗聴した要求の再送を防ぐ

チケットには有効期間があるが、有効期間内なら盗聴した認証要求を何度でも再送してよいわけではない。サーバは認証要求中の時刻が許容範囲内かを調べ、必要な場合はリプレイキャッシュで同じ情報の再利用を検出する。時刻確認だけでは許容範囲内の再送を区別できないためである。

その結果、クライアント・認証機関・利用先サーバの時計が大きくずれると、正しい利用者も認証に失敗する。許容する時刻差は実装や設定に依存するため、NTPなどによる時刻同期を設計に含める。チケットの有効期間と、認証要求の時刻に許すずれは別の条件である。

また、認証に成功した後のアプリケーションデータが必ず暗号化されるわけではない。Kerberosで得た鍵を通信の保護に使うか、TLSなどを併用するかは利用するアプリケーションの設計による。再送への対策と認証後のデータ保護はRFC 4120で区別されている。

名前・通信経路・鍵をそろえる

Kerberosで管理する利用者やサービスの識別名をプリンシパルと呼び、その管理範囲をレルムと呼ぶ。異なるレルム間でも信頼関係を設定すれば連携できるが、同じ文字列のユーザ名だから自動的に同一人物と判断するわけではない。

Windowsではサービスの識別名としてSPN（Service Principal Name）を使う。クライアントが要求する名前と、実際にサービスを動かすアカウントとの対応が重要である。DNSの別名を追加しただけでは、その別名に対応する登録まで自動的に整うとは限らない。Microsoftのサービス識別名の説明を参照できる。

MIT Kerberosなどでは、サービスの長期鍵を保存するkeytabを利用する。サービスの鍵を更新したら、サーバ側の保存内容も一致させる必要がある。鍵の世代を示すKVNOや対応する暗号方式が食い違うと、正しいチケットを受け取っても復号できない。鍵ファイルには読み取り権限を限定する。

クライアントから認証機関への通信ではTCPまたはUDPの88番ポートを使う。利用先サーバへの通信は、そのサービス本来のポートを使う。名前解決や時刻同期も必要なので、認証用のポートだけ開けば全体が動くとは限らない。構成上の条件はMIT Kerberosのサーバ運用資料で確認できる。

障害を手順のどこで起きたかに分ける

MIT Kerberos環境では、次のように最初の認証と保存済みのチケットを分けて確認できる。以下のユーザ名とレルム名は説明用である。

kinit [email protected]
klist

最初のコマンドでチケットを取得し、二つ目で発行先と有効期間を見る。パスワードはコマンド行へ直接書かず、入力を求められてから入力する。操作方法はMITのチケット管理資料に基づく。

現象	切り分ける観点
最初の認証が失敗する	認証機関への到達性、本人の認証情報、時計のずれを確認する
最初の認証は成功するが特定サービスだけ使えない	要求するサービス名、登録先アカウント、サーバが持つ鍵との対応を確認する
認証機関の障害後も一部の通信が続く	有効なサービスチケットや既存接続を使っているか確認する
名前を変更してから失敗する	DNS名だけでなくサービスの識別情報も更新したか確認する

認証機関が停止しても、発行済みの有効な情報を使う処理が直ちにすべて停止するとは限らない。一方で新規のチケット取得や更新は影響を受ける。この違いを踏まえて認証機関を冗長化し、障害時には新規ログインと既存接続を分けて試す。

認証情報が盗まれた場合の限界

パスワードを送らないことは、端末が侵害されても安全であることを意味しない。保存されたチケットと対応する鍵を奪われれば、本人として使われる危険がある。認証機関やサービスの長期鍵を奪われた場合はさらに広い範囲へ影響する。端末保護と管理者権限の制限も必要である。

MITは、暗号化された認証情報を手掛かりにパスワードを推測される危険も整理している。認証方式に合った事前認証や強い認証情報を選び、古い暗号方式へ安易に戻さない。辞書攻撃のリスクに関する資料を参照できる。

設計問題での考え方

例えば「利用者のパスワードは合っているが、新しい別名で接続すると認証できない」という条件なら、パスワードの再入力だけでは解決しない。名前を変えたことで要求するサービスの識別情報も変わり、登録情報や鍵との対応が崩れた可能性を調べる。

また「時刻同期を必要とする理由」を問われたら、単に証明書の期限確認と混同しない。認証要求の鮮度を確認して再送を排除する仕組みが、時計のずれによって正当な要求も拒否するためである。どのメッセージを誰が検証しているかまで結び付けると、障害の原因を説明できる。