$Date:: 2005-11-21 18:22:58 +0900 #$

Kerberos5 cross-realm 運用の内部で何が起きるかメモ


基本
----

もし B.REALM が A.REALM を信じるなら、両方の realm に
krbtgt/B.REALM@A.REALM という principal を用意する。
これを使って B.REALM のサーバが A.REALM のクライアントを
認証する。(言い方を変えると、krbtgt/B.REALM@A.REALM 宛ての TGT は、
A.REALM で発行された、B.REALM のチケットを取得するための、TGT。)


鍵の設定
--------

お互いの realm にある krbtgt/B.REALM@A.REALM の鍵は
当然同じでないといけないけれど、
krbtgt/B.REALM@A.REALM と krbtgt/A.REALM@B.REALM の鍵が
同じである必要はない。


例
--

B.REALM が A.REALM を信用し、C.REALM が B.REALM を信用している場合、
各 realm には次のような principal が用意される。

	A.REALM
		krbtgt/B.REALM@A.REALM

	B.REALM
		krbtgt/B.REALM@A.REALM
		krbtgt/C.REALM@B.REALM

	C.REALM
		krbtgt/C.REALM@B.REALM


foo@A.REALM が bar@C.REALM に対するチケットを手に入れる場合の流れ。

	1. get a ticket for krbtgt/A.REALM@A.REALM from the AS  of A.REALM
	2. get a ticket for krbtgt/B.REALM@A.REALM from the TGS of A.REALM
	3. get a ticket for krbtgt/C.REALM@B.REALM from the TGS of B.REALM
	4. get a ticket for bar@C.REALM            from the TGS of C.REALM


cross-realm で U2U するとき何が起こるか
---------------------------------------

additional-tiket として、どの TGT を使うのか?

	RFC 4120 section 5.4.1 (page 80) には、その KDC の local realm で
	発行されたものでも、remote KDC から発行されたものでもいいと
	書いてあるが……

	inter-realm 関係がすべて双方向である環境では、
	どの TGT でも表面上は動く。
	(ここで言う「表面上」とは、すべてのパーティーが必要な鍵を
	持っていて、必要なチケットを入手することができる、という意味。
	その鍵が表現している信頼関係 (誰が誰を何に関して信用しているか)
	を満たしているかどうかを考慮していない。)

	- realm 間の信頼関係が片方向で、
	- (mutual authentication ではない) client auth
	な状況を考えると考えやすいかな。

	たぶん initial TGT を使うのが妥当だと思う。
	(initial TGT という言い方は間違っているかも。
	INITIAL フラグが立っているという意味ではなく、
	server が所属する realm の TGT、cross-realm TGT じゃないやつ
	という意味)


cross-realm での信頼関係 (mutual authentication も含めて考える)
---------------------------------------------------------------

(inter-realm 用の) krbtgt/DST@SRC という principal と鍵を設定する
ということは、次のことを意味する。

- KDC of DST は、KDC of SRC が発行するチケットの cname が
  正しいことを信じる。(TGS の処理のときに TGT を正しく検証するかとか、
  transit するときに SRC が信頼する KDC からの TGT かどうか
  チェックするかとか、……)

- realm SRC は、KDC of DST が発行するチケットの sname が正しいことを
  信じる。(チケットを発行するとき、要求された sname に対応する
  鍵が正しく使われると信用する。)

client 認証の裏で、誰が何を信頼しているのか:

	client@SRC というクライアントが server@DST というサービスを使うとする。

	1. client@SRC は TGT を取得する。
		AS@SRC は共有鍵で client@SRC を認証する。

	2. client@SRC は TGT を使い、TGS@SRC から krbtgt/DST@SRC 宛の
	   チケットを取得する。
		TGS@SRC は自分が発行したチケットの cname を信じて、
		cross-realm チケットを発行する。

	3. client@SRC は krbtgt/DST@SRC 宛のチケットを使い、
	   TGS@DST から server@DST 宛のチケットを取得する。
		TGS@DST は、TGS@SRC が発行した cross-realm チケットの cname を
		信じて、自分が発行するサービスチケットの cname にコピる。

	4. client@SRC は server@DST 宛のチケットを使い、サービスを利用する。
		server@DST は、TGS@DST が発行したチケットの cname を信じる。

server 認証の裏で、誰が何を信頼しているのか:

	client@SRC というクライアントが server@DST というサービスを使うとする。

	1. client@SRC は TGT を取得する。
		client@SRC は、AS@SRC が正しく TGT を作ると信じる。

	2. client@SRC は TGT を使い、TGS@SRC から krbtgt/DST@SRC 宛の
	   チケットを取得する。
		client@SRC は、TGS@SRC が正しく krbtgt/DST@SRC 宛の
		チケットを作ると信じる。

	3. client@SRC は krbtgt/DST@SRC 宛のチケットを使い、
	   TGS@DST から server@DST 宛のチケットを取得する。
		client@SRC は、TGS@DST が正しく server@DST 宛のチケットを
		作ると信じる。

	4. client@SRC は server@DST 宛のチケットを使って、AP-REQ を送り、
	   AP-REP を受け取る。
		AP-REQ で送った ctime, cusec が AP-REP で返ってくれば、
		相手が AP-REQ をほどけたということ。