要約

  • RFC 1510では、中継先のない一段のRealm間経路でtransitedが空になる。運用者は利用者とサービスのRealmを別欄から照合して経路を読む。
  • RFC 4120は最終判断をアプリサーバーに置いた。KDCの検査印がなければ、アプリが経路を確認するかRealm間チケットを拒否する。運用監視の焦点はKDCだけでなく、受け側サービスの実装にも及ぶ。

分析

二つの端点はリストの外

説明用のRealm名を置く。ALPHA.EXAMPLEに登録された利用者が、BETA.EXAMPLEのファイルサービス用チケットを求める。両Realmが必要なRealm間鍵を共有し、間に第三のRealmがなければ、transited欄は空になりうる。チケットの別欄が両端を示し、空欄は中継Realmのない直結を記録する。

RFC 1510がいうRealmは、それぞれKerberosサービスを運営する管理領域だ。利用者の主体名には登録先Realmが含まれ、受け側サービスはその名前を見て要求を受け入れるか決められる。Realmをまたいで認証を渡すには管理者がRealm間鍵を設ける。通信方向ごとに別の鍵を使ってもよい。遠隔Realmでは、相手側のチケット授与サービスを主体として登録する。遠隔KDCは共有鍵で相手が発行したチケットを復号する。

利用者が行き先ごとに別アカウントを作らずに済むのは、この仕組みのおかげだ。まずローカル側から遠隔Realmのチケット授与サービス（TGS）向けのTGTを受け取り、それを使ってアプリケーション用のチケットを得る。共有鍵は暗号上の橋になる。橋を作り、鍵を保守するかは管理判断だ。

中継Realmを集め、順序は記録しない

経路にRealmがいくつも入ることもある。RFC 1510によると、一般的な構成では各Realmが親と鍵を共有し、子ごとに別の鍵を持つ階層を作る。両端に直接の鍵がなくても、階層をたどれば経路を組み立てられる。効率のために中間Realmを迂回する経路も認められていた。階層構造でない場合は、別のデータベースから経路を求めることもある。

RFC 1510は中継Realm名を順不同の集合として扱い、一般的な階層名を圧縮する。経由した順番はこの欄から分からず、時系列の監査には別の記録が要る。

チケット授与サービスは、受け取ったチケットを発行した前のRealmを追加する。自身のRealmはこの欄の外にある。RFC 1510の意図は、サーバーが自分の名前を省いて参加を隠すのを防ぐことだ。ほかのRealmを省く余地は残るため、受け側は残りの申告を自らの信頼方針で評価する。

2005年7月のRFC 4120はRFC 1510を置き換え、最終判定をアプリケーションサーバーに定めた。サーバーは参加したKDCが対象の利用者を認証するに足る信頼を持つか確認する。行き先RealmのKDCが方針に沿って経路を検査すれば、サービスチケットにTRANSITED-POLICY-CHECKEDを付けられる。印がなければ、アプリは自分で経路を検査するかRealm間チケットを拒否する。RFC 4120は、信頼できないKDCが一覧そのものを偽造できるとも指摘する。

権限は三か所に分かれる。管理者はRealm間鍵を設け、KDCはチケットを発行して行った検査を示し、アプリケーションは受け入れる経路を決める。鍵を一つ加えれば経路は短くなり、手間が減る。つながったサービスが受け入れうる利用者の範囲も広がる。設定ファイルに鍵を書くと、将来のアクセス関係が決まり、その経路がネットワーク図にも表れる。

1993年9月のRFC 1510は、仕様が審査中で、その時点ではInternet標準として提出していないと記した。RFC 4120は2005年にStandards Trackへ進み、実装責任を明確にした。欠けているのは、1990年代にどのアプリケーションサーバーがtransitedを検査したかを示す導入記録だ。その記録があれば実運用での確認状況を判断でき、RFCから分かるのはプロトコル設計までとなる。

出典