#2 U2U misc
"KAMADA Ken'ichi" <[email protected]> Mon, 07 Mar 2005 16:53:05 -0600
| Newsgroups | gmane.ietf.kink |
|---|---|
| Message-ID | <20050307165305VZ%[email protected]> |
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, "KAMADA Ken'ichi" <[email protected]> wrote: > > #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. -- KAMADA Ken'ichi <[email protected]>