$Date:: 2005-11-09 09:28:01 +0900 #$

Kerberos5 User-to-User 認証


User-to-User 認証を行う場合の流れ
---------------------------------

0. client は、何らかの方法で server の TGT を取得する

	Kerberos プロトコルでは規定されていない。アプリケーションに
	まかされている。

1. client は TGS-REQ する。

	ENC-TKT-IN-SKEY オプションを付ける。
	additional ticket に TGT を付ける。
	このときクライアントは、TGS-REQ の sname を省略することができる。

2. KDC はサービスチケットを作って返す。

	ENC-TKT-IN-SKEY フラグが立っているので、
	KDC はサーバとの共有鍵ではなく、additional ticket (TGT) の
	セッション鍵を使って、サービスチケットを暗号化する。
	sname が省略されている場合、
	KDC は additioanl ticket の名前 (cname) を使う。

3. client は USE-SESSION-KEY フラグを立てて AP-REQ する。


メモ
----

Q. TGS-REQ の sname が省略されていなかった場合、
   sname と additional ticket の cname が違っていたら、
   KDC はどうするのか。

	KDC は sname と TGT の cname を比較し、違っていたら reject する。
	[clarifications-07 3.3.3]

Q. client は、いつ user-to-user をしようと思うのか。

	- manually configured
	- アプリケーションレベルで何らかのネゴを行う。
		RFC 4120 section 3.7 の気持ちはこれかな。
	- TGS-REQ したときに、KDC_ERR_MUST_USE_USER2USER と言われる?
	- AP-REQ したときに KRB_AP_ERR_USER_TO_USER_REQUIRED と言われる?

Q. server は、USE-SESSION-KEY と言われたときにどの TGT か分かるのかな。

	たぶん、そもそも cross-realm TGT を使わないのが簡単。
	(cf. krb5-cross-realm.ja.txt)

	実装の面から見ると、
	MIT krb5-1.4.2 では自分で auth_context->keyblock を渡さないと
	いけない。すなわちアプリケーションが自分で U2U していることを
	認識し、どの鍵を使うか識別しないといけない。
	(cf. krb5_rd_req_decoded_opt()@src/lib/krb5/krb/rd_req_dec.c)

	まあ、結局はアプリケーション依存なのかも。