#2 U2U misc

[KAMADA Ken'ichi]

Comments from Sam are devided and have dedicated issue number,
so I'm replying to Ken's comments.

At Tue, 22 Feb 2005 17:49:09 +0900,

#2 [*] U2U (section 3, 4.2, and 5.1.2)
(not yet analyzed)
I think we need to look at how u2u works at various parts of
the protocol. In particular I'm concerned about choosing the right
u2u principal, dealing with cross-realm u2u and dealing with
recovering from reboots. We should confirm all these work out.
(Sam Hartman)
# choosing the right u2u is discuessed in #3.
# cross-realm u2u is discussed in #19.
# how to know and get new TGT when peer reboots is discussed in #7
More examination of user-to-user case, especially situations where
it might *not* be two PKINIT clients, which section 3 says is possible.
(Ken Raeburn)

As far as I understand, U2U is involved when the responder
needs it and the initator has nothing to do with it. So if KINK
works with two PKINIT clients, it would also work well when the
responder is only a PKINIT client.
Am I missing something?

In the user-to-user case with TGTs, I think the KINK draft may be
over-specifying things that should be dealt with at the Kerberos level.
If things are underspecified in Kerberos Clarifications, let's deal
with that. (Ken Raeburn)

Could you point more specifically?
I guess you are talking about the RealmName description of section
5.1.5. If it (you are talking on section 5.1.5) is the case,
I've proposed changing the KINK_TGT_REQ format, so this issue
may be disappers.