■ クロスレルム認証

おね〜さんと、

ほげたんのっ!!

3 Minutes Networking、

Supplement !!

さて〜っと。Kerberosで認証する方法を説明してきたわけだけど。

うん。TGSとAS。チケット、だね？

そうそう。でね、いままでの説明は、基本的な認証、つまり1つのレルム内の認証だったわけでね。
認証されるユーザと、そのユーザが使うサーバと、KDCはみんな同じレルムにあったという場合なわけでしょ？

ん、そういえばそうだね。よくよく考えてみると、「レルム」って言葉はKerberosの第一回以来、ひさびさに聞いた気がするよ。

まぁ、基本的なのは、やはり同一レルム内の認証だからね。でもでも、同一のレルムだけの認証ですべてやっていける、ってわけじゃないわよね。
例えば、部門別でレルムを作っていたり、大学（レルム）間で共同作業をしたり、そういうことだってしたいわけじゃない。

ん〜っと、つまり、別のレルムのサーバを使うために認証されたいわけだよね。
じゃあ、そのレルムにユーザを登録しておけばいいんじゃない？

それはSSOの理念に反することになっちゃうじゃない。
Aというレルムのユーザが、Bというレルムのサーバを使いたいから、Bレルムにアカウントを作る。ユーザは、AとBの両方のアカウントを使わなきゃいけないのよ？

SSO、シングルサインオンは、1つのアカウントですべてのサーバに認証され、1度の認証だけでOKにしたい…。
確かに、レルムごとにアカウント作ったらSSOじゃなくなっちゃうよね。

そういうこと。これを解決するのが、クロスレルム認証なわけ。

くろすれるむ？

「レルム横断認証」ってところかな？

KDC間の信頼関係？
あれれ？ 信頼ってどっかで聞いたような…、ActiveDirectory？

うん、そうね。ActiveDirectory、つまりKerberos5レルムで使われてるわね。

あ、あ〜、そうだ。ツリーやフォレストの信頼関係だ。
そうでしょう、おね〜さん？

ほげたん、正解。そう、まさしくActiveDirectoryで言われてる信頼関係は、このクロスレルム認証の信頼関係のことなのよ。
さて、このクロスレルム認証、まずそうね、ほげたん、これなんだっけ？

え？ 3min.jpのKerberosチケット交付サービスプリンシパル？

そう、ユーザは「TGTを交付するサービス」つまりASに対し、認証を要求してTGTをもらうんだったわよね。
その時に使う「要求するサービスのプリンシパル」が「krbtgt」で始まるプリンシパルよね。

うん、そうだよ。

今回、クロスレルムで使用する「要求するサービスのプリンシパル」は、これになるわ。

ん？ んんんん？ なんか変？

プリンシパル名は、「サービス名/サービスのホストのFQDN@レルム」だったわね。
それを踏まえて、このプリンシパル名で要求するってのはどういうこと？

「3MIN.JPレルム」の「30min.comのホスト」の「krbtgtサービス」を要求する？
3MIN.JPレルムにある30min.comホスト？

そうよ。「krbtgt/30min.com@3MIN.JP」を要求して、30min.comホストのサービスチケットを入手することで、クロスレルム認証は行われるのよ。

え〜っと、自分のレルムのKDCに、認証されたい他レルムのKDCのチケットを発行してもらうんだ。

そういうことね。最初の自レルムのKDCからTGTをもらうのはお約束だからいいとして。
他レルムのKDCに認証されるために、krbtgtチケットをもらうわけね。

で、そのkrbtgtチケットは、信頼関係を結んだKDCの双方が保有する秘密鍵で暗号化されてるから。krbtgtチケットを送ってきた＝信頼関係にあるKDCが発行した、で認証するわけだね。

そういうこと。で、ポイント1。
その秘密鍵だけど、鍵はプリンシパル1つにつき1つ作成されるものよね。同じ鍵を持つ2つのプリンシパルがあるって変よね。

うん、そうだね。

よって、信頼関係は方向がある。

krbtgt/30min.com@3MIN.JPは、レルムが3min.jpだから、3min.jpに所属するサービス扱い？
30min.comのKDCは「3min.jpで30min.comのチケットを配布するサービス」って意味になっちゃうってことかな？

その理解でOK。よって、30min.comのユーザがkrbtgt/30min.com@3MIN.JPを使うことはできないわけ。違うレルムのサービスだからね。

krbtgt/30min.com@「3MIN.JP」だから、30min.comのユーザは使えない、と。

だから、30min.com側にはkrbtgt/3min.jp@30MIN.COMという「30min.comで3min.jpのチケットを配布するサービス」のプリンシパルが必要ってこと。

そういえば、ActiveDirectoryでも、信頼は両方に設定しなきゃダメだったっけ。

ポイント2つめ。
このクロスレルム認証方式は、「ダイレクトクロスレルム認証」って呼ばれてるんだけど。

ダイレクト？

うん。KDCがクロスレルムするレルムの鍵を持つ方式って意味なんだけど。
ほげたん、この方式だと、クロスレルムするレルムの数が多くなるとどうなる？

クロスレルムするレルムの数だけ、鍵が必要になるよ。
え〜っと、もしかして、鍵の数が多くなるのが問題？

単純計算で、n²個の鍵が必要になってしまうわけよね。ちょっとそれは大変だなぁと思うわけよ。
なので、仲介レルムを使う形になるわけ。

うわ〜、なんか面倒くさい方法だね。

まぁ、そうなっちゃうわね。ユーザは所属するレルムに認証して、つぎに仲介レルムに認証して、最後に宛先レルムに認証してもらうというステップを踏むわけよ。でも、これなら仲介レルムとだけ鍵を共有すればいいから楽でしょ？

それは確かに。

実際は、これを利用して階層型信頼ってのを使うのが多いかな？
まったく別のレルム同士じゃなくて、1つのドメイン（レルム）の子ドメインって形にするの。

木構造（ツリー）？

そう。仲介レルムは親ドメインがなって、子ドメイン同士で認証するって形ね。

なるほど。

■ 転送可能チケット

クロスレルム認証は、SSOを実現するための手段として存在するわけだけど。
他にも、Kerberosを普通に使ってると、SSOにならないことってあるのよ。

くどいようだけど、2度も3度もパスワードを要求するのは、SSOとして失格よね。
これって何が問題なの？

なにが問題って……。
TGTがホストに保存されて使用されること、かな？

そうよね、TGTってホストに保存されちゃうのよね。
そのユーザがそのホストを使用している間はTGTは使いたい放題なんだけど、ホストを移動しちゃうとダメになっちゃう。

うん、でも、まぁ、これはしかたないんじゃないかなぁ。

でもよ、ほげたん。実際に物理的に移動するならともかく、リモートホストよ？ ちょっと面倒くさくない？

それは確かに面倒くさいと思うよ。

シングルサインオン、一度認証されたらそのホストからログオフするまではパスワードなんか入力する必要なし、ってしたいじゃない。
ってことで、Kerberosにはちゃ〜んと用意されてます。それが転送可能チケットよ。

ふぉわーだぶる？ 転送可能？ どこに?

リモートホストに、よ。

TGTもユーザと一緒に移動するんだ。

うん、そう考えるのがいいわよね。
それでね、これで考えることは2つ。1つ目、リモートホストに転送されたTGTは残ってしまうってこと。

残らないとまずいんじゃない？ リモートホストに保存されないと使えないじゃない。

ん〜いやいや、そういう意味じゃなくてね。リモートホストからログオフしても残っちゃうのよ。なので、ログオフ前に消すっていう作業が必要ね、ってこと。

あぁ、なるほど。

もう1つ、リモートログインの際に転送されたチケットだけど。
さらにリモートホストから他のホストにリモートログインした場合どうなるかってこと。

リモートからさらにリモートへ？ でもSSOから考えると、また転送してくれないと困らない？

うん。転送可能チケットの場合は、さらに転送される。
それとは別に、1回しか転送されないってオプションもあるのよ。こっちは代理可能チケットって呼ばれるわ。

代理、ぷろきさぶる。
最初にリモートログインされる時には転送されるけど、リモートからリモートへは転送されないってこと？

そういうこと。

■ IPアドレスとポート番号

……おね〜さん。

なに？

ちょっと気がついたんだけどさ。

これはサービスチケットだけど、TGTもサービスチケットも、クライアントIPアドレスが入ってるよね。
リプレイ攻撃を防ぐために。

うん、入ってるわね。

さっきの話。リモートホストにTGTを送って、認証に使うんだけど。
最初にTGTを取得したローカルホストと、リモートホストってIPアドレス違うじゃない。どうするの？

うん、そうよね。
そうなると、リモートホストからの要求は、IPアドレスが違うからリプレイアタックと判断されちゃうわよね。

でしょ？ どうするの？

簡単。要求の際にチケットのクライアントIPアドレスを変えてもらうことができるよ。

？ つまり、リモートホストで使うから、こっちのIPアドレスにしてって頼むわけ？

もしくは、クライアントIPアドレスなしのチケットを要求することができるのよ。

なんだ、そんなことができるんだ。

うん。他にもNATによる変換にIPアドレスが変わっちゃう場合もあるわけだしね。そこらへんは抜かりなしって感じ？

へ〜。

そうそう、Kerberosで使うポートの話してなかったわね。Kerberosは88番ポートを使います。

TCPとUDPどっち？

両方。あと、管理用749番と464番を使うの。パスワードの変更とかにね。
まぁ、基本的なチケットのやりとりは88番でOKだけど。

なるほど。

じゃ、今回はこれぐらいにしておきましょ。
まだまだKerberosの話はあるんだけど、一応これで一区切り。

そなの？

うん。他にもいずれ使われるであろう公開鍵暗号化方式との組み合わせとか、あることはあるんだけど。
これ以上詳しい話はちょっと実装面の話ばっかりになっちゃうのよ。

う〜ん、それはちょっとね。

現在のKerberos認証の代表格であるActiveDirectoryドメイン認証とか、いろいろ話はしたかったけど。うん、ここでおしまい。

次回は？

まだ、な・い・しょ。
おね〜さんと、

ほげたんのっ!!

3分間ネットワーク、

サプリメントでした〜〜〜っ!!
それはそれとして、「な・い・しょ」が壮絶に似合ってないよ、おね〜さん。

(ｷﾞﾛﾘ)

うごぁっ!!