「ケルベロス認証の仕組み」

私は主にWindowsアプリケーション開発を担当している社員です。今回、とある案件でKerberos認証について調べる機会がありましたので、その一部を技術レポートとしてご報告したいと思います。
Kerberos認証は1980年代初期にはじまったマサチューセッツ工科大学のプロジェクトに由来しています。それだけ古くから存在する歴史ある認証方法ですが、現在でも幅広く利用されています。その特徴は、認証を一度だけにするという利便性と、確かな安全性を備えた画期的な方法であると言えます。以下にその特徴の概要についてご紹介したいと思います。

ネットワーク上に複数の機器やサービスが存在する環境において、別のサービスにアクセスするたびに認証の手順を踏まなければならないのは効率がいいといえません。そこで、特定の範囲内のコンピューターにアクセスする際の認証を一度で行えるようにしたものがKerberos認証です。
現在、Kerberos認証はActive Directoryドメインサービスなどで使用されています。特徴としては、図1のように認証の際にパスワードなどではなく暗号化された「チケット」を受け渡す点で、このチケットのおかげで特定の範囲内にある他のコンピューターなどに対して認証をし直すことなくアクセスすることができます。認証情報が適用される範囲のことをレルムといい、これはActive Directoryにおけるドメインとほぼ同じです。レルム内には一台以上の認証サーバーがあり、この認証サーバーからチケットを獲得することでレルム内のすべての機器やサービスにアクセスすることができます。
Kerberos認証における認証サーバーはKey Distribution Center（KDC）と呼ばれ、そのなかにAuthentication Service（AS）とTicket Granting Service（TGS）のふたつのプロセスが存在します。ASは日時情報の暗号化と復号などを通じてクライアントの認証を行います。図1のように、TGSはクライアントが接続を行おうとしているサービスにアクセスするためのチケットを発行します（①）。クライアントは、取得したチケットを使用してサービスにアクセスします（②）。

図1. 認証の流れ

はじめに、単一レルム認証における認証の手順について述べます。認証は2段階に分かれます。第1段階では、図2のようにクライアントはASによる認証をうけ、次の段階でTGSに対し必要となるチケットを取得します。第2段階では、図3のようにクライアントはTGSに対してチケットを受け渡し、接続を行いたいサービスのチケットを要求し、取得したチケットを使用してサービスにアクセスします。以下に詳細な手順を述べます。

＜第1段階＞

1.

パスワードを入力するなどして「ユーザー長期キー※1」を生成し、クライアント側に保存します。なお、ここで用意する「ユーザー長期キー」はKDC側にも同じ物が存在しなければなりません。そのため、キーを生成するための暗号化方式はKDC側に合わせる必要があります。

2.

クライアントはKDCに対してユーザーIDを含むテキストメッセージを送信します（①: KRB_AS_REQ）。

3.

KDCがメッセージを受信すると、ASは事前認証が必要であるというエラーで応答します。ここで、ASは「ユーザー長期キー」を使用して一部の情報を暗号化したものをASに送信する必要があることをクライアントに伝えます（②: KRB_AS_REP）。

4.

クライアントは現在のタイムスタンプを「ユーザー長期キー」で暗号化したものを認証子としてASに送信します（③: KRB_AS_REQ）。

5.

ASは認証子を対応する「ユーザー長期キー」で復号を試み、ASが復号に成功するとクライアントはASに対し認証済みとなります（④）。ここで、「ユーザー長期キー」はクライアント側とKDC側の両方に存在することに注意してください。

6.

検証の結果正規のクライアントであると認識すると、ASは「『ユーザー長期キー』で暗号化された『TGSセッションキー』」と「『TGS長期キー』でコンテンツが暗号化された『TGT（Ticket Granting Ticket）』」をクライアントに渡します（⑤: KRB_AS_REP）。TGT中の暗号化されたコンテンツには、クライアントID・クライアントネットワークアドレス・チケットの有効期限・TGSセッションキーが含まれています。

7.

クライアントは「ユーザー長期キー」を使用して「TGSセッションキー」を復号し取得します（⑥）。ここで、クライアントは「TGS長期キー」は持たないため「TGT」のコンテンツを復号することができません。つまり、「TGT」を自由に書き換えることができないことを意味します。

図2. 単一レルム認証（第1段階）

第1段階の結果、クライアント側には「ユーザー長期キー」のほかに「TGSセッションキー」と「TGT」が残ります。このうち「TGSセッションキー」は復号されていますが、TGTのコンテンツは暗号化されたままで、クライアントは復号に必要なキーを持たないため復号できません。

※1 「ユーザー長期キー」「TGS長期キー」「サービス長期キー」など「長期キー」が名前に付くキーは、認証サーバーやサービス内に長期にわたって存在するもので、一度の認証ごとに消失または失効することはありません。対して、「セッションキー」が名前に付くキーはセッション期間中のみ有効なキーです。

＜第2段階＞

1.

クライアントは、「現在のタイムスタンプなどをTGSセッションキーで暗号化した認証子」「TGT」の二つとともに、特定のサービス名（サービスプリンシパル名 : SPN）へのチケットの要求をKDCに送信します（①: KRB_TGS_REQ）。

2.

TGSは「TGS長期キー」を使用して「TGT」を復号し、「TGSセッションキー」を取得します（②）。

3.

TGSは続いて認証子の復号を試みます。復号には「TGSセッションキー」を使用します。復号に成功するとクライアントはTGSに対し認証済みとなります（②）。

4.

検証の結果正規のクライアントであると認識すると、TGSは「『TGSセッションキー』で暗号化された『サービスセッションキー』」と「『サービス長期キー』でコンテンツが暗号化された『サービスチケット』」をクライアントに渡します（③: KRB_TGS_REP）。

5.

クライアントは「TGSセッションキー」を使用して「サービスセッションキー」を復号し取得します（④）。ここで、クライアントは「サービス長期キー」を持たないため「サービスチケット」のコンテンツを復号することができません。つまり、「サービスチケット」を自由に書き換えることができないことを意味します。サービスチケット中の暗号化されたコンテンツには、クライアントID・クライアントネットワークアドレス・チケットの有効期間・サービスセッションキーが含まれています。

6.

クライアントは「現在のタイムスタンプをサービスセッションキーで暗号化した認証子」「サービスチケット」を含むメッセージをアクセスしたいサービスに向けて送信します（⑤: KRB_AP_REQ）。メッセージは、Web認証用のSimple Protected negotiate Protocol（SPNEGO）に組み込まれることがあります。

7.

サービスがクライアントからメッセージを受信すると「サービス長期キー」を使用して「サービスチケット」を復号します（⑥）。そして「サービスセッションキー」を取得します。

8.

サービスは続いて認証子の復号を試みます。復号には「サービスセッションキー」を使用します。復号に成功すると、クライアントはサービスに対し認証済みとなり、サービスにアクセスできるようになります（⑥）。

9.

オプションで、サービスは定義された応答を送信します（⑦: KRB_AP_REP）。応答には「サービスセッションキー」で暗号化された認証子が含まれることがあります。「サービスセッションキー」はクライアント側も所有しているため、認証子を復号することができます（⑧）。これにより、クライアントはサービスが「サービスセッションキー」を正しく取得できたことを知ることができます。

図3. 単一レルム認証（第2段階）

クロスレルム認証とは、図4のように複数のレルムが存在する環境で別のレルムのサービスにアクセスすることです。クロスレルム認証の手順としては、単一レルム認証の場合と途中までは変わりません。違いが現れるのは、クライアントがTGSに対して「『TGSセッションキー』で暗号化された認証子」「TGT」「接続したいSPN」の3つを送り（①: KRB_TGS_REQ）サービスのチケットを要求したあとです。ここでは、現在レルム1ですでに認証済みのクライアントがレルム2のサービスにアクセスしようとしている状況を例に図5とあわせて説明します。

図4. 複数レルム

1.

TGSはクライアントから要求されたSPNが別のレルム用のものであるとわかると「『レルム1のTGSセッションキー』で暗号化された『レルム2のTGSセッションキー』」と「『共有クロスレルムTGS長期キー』でコンテンツが暗号化された『レルム2のTGT(クロスレルムTGT)』」をクライアントに渡します（②: KRB_TGS_REP）。ここで、「レルム1のTGSセッションキー」はクライアントがレルム1で認証を受けたときにすでに所有しているとします。「レルム2のTGT」中の暗号化されたコンテンツには、クライアントID・クライアントネットワークアドレス・チケットの有効期間・レルム2のTGSセッションキーがあります。

2.

クライアントはメッセージを受信すると「レルム1のTGSセッションキー」を使用して「レルム2のTGSセッションキー」を復号し、「レルム2のTGSセッションキー」を取得します（③）。クライアントは「共有クロスレルムTGS長期キー」を持たないため、「レルム2のTGT」は復号できません。

3.

クライアントは「『レルム2のTGSセッションキー』で暗号化した認証子」「レルム2のTGT」をレルム2のKDCに送信します（④: KRB_TGS_REQ）。

4.

レルム2のTGSは「共有クロスレルムTGS長期キー」を使用して「レルム2のTGT」を復号し、「レルム2のTGSセッションキー」を取得します（⑤）。

5.

レルム2のTGSは「レルム2のTGSセッションキー」を使用して認証子の復号を試みます。復号に成功すると、クライアントはレルム2のTGSに対して認証済みとなります（⑤）。

6.

レルム2のTGSは「『サービス長期キー』でコンテンツが暗号化された『サービスチケット』」「『レルム2のTGSセッションキー』で暗号化された『サービスセッションキー』」をクライアントに渡します（⑥: KRB_TGS_REP）。

7.

クライアントは「レルム2のTGSセッションキー」を使用して「サービスセッションキー」を復号し、取得します（⑦）。

8.

クライアントは「『サービスセッションキー』を使用して暗号化された認証子」「サービスチケット」を含むメッセージをサービスに送信します（⑧: KRB_AP_REQ）。このメッセージはWeb認証用のSPENGOなど別のプロトコルに組み込まれる場合があります。

9.

サービスは「サービス長期キー」を使用して「サービスチケット」を復号し、「サービスセッションキー」を取得します（⑨）。

10.

サービスは「サービスセッションキー」を使用して認証子の復号を試みます。復号に成功すると、サービスはクライアントを認証したこととなります（⑨）。

11.

オプションで、サービスはクライアントに向けて「サービスセッションキー」で暗号化された認証子などを送信します（⑩: KRB_AP_REP）。これにより、クライアントはサービスが「サービスセッションキー」を正しく取得できたことを知ることができます（⑪）。

クロスレルム認証が実際に使用される場面についてですが、例えばActiveDirectoryの場合、図6に示すような構成で使用されます。相互に信頼関係を結んだディレクトリ1とディレクトリ2のサーバーが存在し、ディレクトリ2のサービスを使用したいが、クライアントのログイン情報がディレクトリ1のサーバー（=ドメインコントローラ）にしかない存在しないという場合です。
上記の場合、クライアントはまずディレクトリ１のTGSからディレクトリ２のTGT（クロスレルムTGT）を取得し（①）、そのTGTをディレクトリ２のTGSに渡すことで（②）、サービスチケットを取得します（③）。以降、クライアントはサービスチケットを使用してディレクトリ２にアクセスできるようになります（④）。

図5. クロスレルム認証

図6. Active Directoryにおけるクロスレルム認証

以上、簡単ではありますがKerberos認証についての説明でした。本稿が少しでも皆様の課題解決や認証技術理解のお役に立てれば幸いです。最後までお読みいただきありがとうございました。