> Sorry for the slow response time. krb5 user-to-user auth is a little > off the beaten track of Kerberos usage, but this is the intended use > case.
Awesome, thanks. And yes, the entire reason I'm using Kerberos is to avoid rolling my own security protocol, so I'm glad I happened across the user-to-user stuff before starting the other thing. :) One more question about user-to-user: the FAQ says that the "Clocks Adrift" paper's solution for not forcing clients to have synced clocks is implemented in krb5. How does this relate to user-to-user sessions? Or, am I misunderstanding? It would be awesome to only have to have my servers synced, and have the clients be, well, clients, with random bad clocks, but if I want to user-to-user authenticate does that force them to be synced? http://www.faqs.org/faqs/kerberos-faq/general/section-22.html Thanks, Chris On 2011/07/06 10:35, Greg Hudson wrote: > On Fri, 2011-07-01 at 15:33 -0400, checker wrote: >> But, I happened across the user-to-user credentials stuff, and this >> seems like it's the better way to go because it doesn't require both >> clients to talk to the TGS, and it establishes just one session key >> for both, rather than having two? So, since both clients will have >> tgts, I pick one to talk to the KDC to get the user-to-user >> credentials and then they can authn each other? > >> Is that the right way to do this? Is there anything to look out for here? > > Sorry for the slow response time. krb5 user-to-user auth is a little > off the beaten track of Kerberos usage, but this is the intended use > case. > > If you don't use user-to-user auth, you will not be able to meaningfully > request credentials from [email protected] to [email protected] if b does not have a > keytab. You would have to bootstrap a session key for the users using > the server connections, which would amount to creating your own > cryptographic security protocol, which is fraught with peril. So if > user-to-user auth can work for you, it's probably a better option. > > > ________________________________________________ > Kerberos mailing list [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
