■ KDC

おね〜さんと、

ほげたんのっ!!

3 Minutes Networking、

Supplement !!

まだまだKerberosが続くわけだけどね。

うん。共通鍵暗号化を使った認証システムだよね。

そう。で、Kerberosの基本として、「第三者」つまりKDCが重要な役を果しているのはわかったと思うけど。

KDC、キー配布センターだね。
セッション鍵を配って、認証とかにつかう。

うん、そのKDC。
で、このKDC。役割が2つあるのに気づいた？

2つ？ 2つもあったっけ？

前回使った図を見てみましょ。

ユーザを認証するKDCと。

他サーバのための認証をするKDC。この2つよ。

ん〜、そう言われれば役割が違うかな。

でしょう？ この2つ、それぞれ名前があるの。
まず、最初のクライアントを認証する方のKDCが、AS、「認証サーバ」ね。

クライアントを認証するから、認証サーバ、と。

もう一方、他サーバのための認証をするKDC、つまりクライアントに他のサーバへ「認証されたユーザですよ」と証明するための鍵を渡すKDCね、これはTGS、「チケット交付サーバ」と呼ばれるわ。

てぃーじーえす？ チケット交付サーバ？ チケットって何？

簡単に言えば、さっき言った「認証されたユーザですよ」という証明をするものね。これをチケットって呼ぶの。

ん〜っと、チケットはKDCがクライアントに渡すものだから、もしかして、セッション鍵と関係がある？

あるわね。というか、セッション鍵がチケット、といってもいいくらい。ま、チケットについては次で話すわ。
そして、KDCにはもう1つ、大事なものがあるのよ。

大事なもの？

そう、共通鍵データベース。コレ。

あぁ、そうか。KDCはユーザ、サーバの鍵を持つんだっけ。

そうそう。KDCはなんらかの手段で鍵を保持していなければならない。
これは使うKerberosアプリケーションによって違うわ。普通にファイルデータベースとして持っているものもあれば、LDAPとして持つものもある。

えるだっぷ……、Windows ActiveDirecotryのことだね、おね〜さん。

そう、Kerberos5を認証に使うWindowsドメインは、鍵をLDAP（ActiveDirectory）で保持してるわ。
ま、ともかく、この3つからKDCは成り立ってるってこと。

この3つはそれぞれ独立しててもいいし、1つのアプリケーションとして運用されててもいいの。
実際は、KDCとして1つのアプリケーションで運用されていることが多いわね。

役割的には3つ、アプリケーションとしては1つが多い、ということだね。

■ チケット

さてさて、さっきでてきた新しい言葉、「チケット」。
kerberosではこのチケットをやりとりすることにより認証を行うの。

さっきの話だと、「認証されたユーザですよ」という証明をするもの」だっけ。

そう、Kerberosで身分を証明するものが、「チケット」ということね。
これをもらったり、サーバに渡したりして認証してもらう、ってこと。

それを渡すのが、TGS、「チケット交付サーバ」ってことだね。

そういうこと。
さて、このチケットだけど、以下のデータから成り立ってるの。

これをサービスの共通鍵で暗号化したものがチケット。

うぅぅ？ サービスの共通鍵で暗号化する？

そう、前回の図を思い出して〜。

セッション鍵はサービス（サーバ）の鍵で暗号化されていたわよね。
サービスの鍵を持つのはKDCだけ。つまり、サービスの鍵で暗号化されていることは…どういうこと、ほげたん？

KDCが発行したことを示す。
チケット＝セッション鍵と考えていいの？

そうね、基本的にはそれでOK。
後のデータは悪用されないように付加されているものだからね。

悪用？

チケットを盗聴して使う、とかね。
ともかく、チケットは、KDCから発行されたものである＝正しいセッション鍵であるという証明になるものよ。

で、その正しいセッション鍵で暗号化されたデータを送ってきたユーザ＝正しいセッション鍵を持つユーザ＝認証されたユーザ、って形になるわけだね。

■ 認証サービス交換

さて、だいたい重要キーワードの説明が終わったから、Kerberosの実際の動作を説明しましょ。
まず、ユーザは何するんだっけ、ほげたん？

KDC、この場合ASだね、ASに認証してもらうことからスタートでしょ？

そうね。まずこれから説明しましょう。

TGT？ チケット交付チケット？

うん。ユーザが最初に手に入れるチケットね。イニシャルチケットとも言われるわ。
または、「認証信任状」とも呼ぶわね。

これ、何に使うの？

TGTを持つユーザはASに認証されたユーザであることを示すのよ。
以後、ユーザはTGTを送ることで認証するってわけ。

ん〜？ なんで？

TGTがあると認証されるってことは次の説明でわかるわ。

■ チケット交付サービス交換

じゃ、このTGTを利用してサーバに対しての認証を要求する手順をいきましょ。

認証子？ サービスチケット？

まず、第一のポイントは認証子ね。
これはASとの認証サービス交換で入手したセッション鍵で暗号化されたデータよ。

TGSはTGTから入手したセッション鍵で認証子を復号化する…。

そう、これで「確実に相手が認証されていることを保証」するわけね。
だって、そのセッション鍵を持つのはASとの認証サービス交換を行ったクライアントだけなんだから。

さらに考えると、もともとそのセッション鍵はクライアントの鍵で暗号化されていたものだから、ますます「正しいクライアントである」保証になるんだね。

そうそう。「TGTと認証子を送ってきたクライアント」＝「正しいクライアント」になるってこと。
これがさっきの「TGTを持つユーザはASに認証されたユーザであることを示す」ことになるのよ。

う〜ん。確かにTGTと、それで復号化できる認証子を送ってきたら、正しいよね。

そゆこと。
で、サービスチケット。これはサーバ/サービスに渡すものよ。

TGTみたいなもの？

そうねぇ、TGTはTGSにデータを送信してきたユーザが認証されていることを示すものよね。
サービスチケットはサーバ/サービスにユーザが認証されていることを示すから、同じね。

ふ〜ん。じゃ、今度はサービスチケットを使った認証を教えてよ。

■ サーバ/クライアント認証交換

うん、それだけどね、ほげたん。
これはKerberosでは正式にこれって決まってないの。

そうなの？

ん〜、一応ベースとなるものは決まってるんだけど。
ベースとなるのは、さっきのTGSがTGTを受け取って認証子を使って認証するのと同じなんだけどね。

うん。さっきのTGSがTGTと認証子を使って認証するのと同じだね。
で、認証した後は？

さぁ？

うわ。いい加減だ。
さすが、おね〜さんだよ。

ほ〜げ〜た〜ん？（ﾆｯｺﾘ)

すいませんでしたぁぁぁぁ!!。
その笑みはやめてください。なまじっか整ってる顔なだけ迫力満点です。ほんとごめんなさい。

ちっ。まぁいいでしょ。
ま、認証した後はサーバ/サービスまかせだからどうなるかはKerberosが関与する話じゃないし。

言われてみればそうかも。

用語とか、やりとりの内容がちょっといろいろ増えてるけど、基本は前回やったコレね。

やりとりするセッション鍵＝チケットって考えると、確かにこれだね。

でしょう？ ここでもう一度、やりとりする内容を見てみると。

まず、TGTを入手するためのやりとり。

ユーザの共通鍵で暗号化されているから、ユーザしかTGTとセッション鍵を入手できないわけだね。

うん、そう。これは一番最初に行われる動作になるわけね。
例えば、クライアントに対するログオン動作がこれになったりするわけ。

ログオンするために、TGTを入手する？

そう。Windowsドメインなんかがそうね。TGTを入手して、それにより「認証されたユーザ」であることを確認して、ログオンできるようになる、とかね。

なるほど。

そして、このTGTとセッション鍵を使って、使用するサービスに対する認証するためのチケットを入手するわけでしょ。

TGTと認証子を使って認証して、サービスチケットと新しいセッション鍵を渡す。

そういうこと。
そして、サービスに対してサービスチケットと認証子を渡して認証してもらう。これね。

なるほどだよ、おね〜さん。
なんかすごいね、Kerberos。

さてさて。今回はこれにて終了〜っと。
次回も、まだまだKerberosよ。

次回はな〜に？

Kerberosがどうやって身を攻撃から守るかのお話。
じゃ、また次回。おね〜さんと、

ほげたんのっ!!

3分間ネットワーク、

サプリメントでした〜〜〜っ!!
まった次回〜〜〜〜!!