Slightly confused by user-to-user authentication...

[Chris Hecker]

> 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 a at FOO.COM to b at FOO.COM 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           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>