Peer to Peer instead of Client to Server

Douglas E. Engert deengert at
Mon Apr 7 15:43:41 EDT 2008

Jeffrey Hutzelman wrote:
> --On Monday, April 07, 2008 01:30:42 PM -0500 "Douglas E. Engert" 
> <deengert at> wrote:
>> This sounds like user2user. DCE had it and Windows has had it for
>> years. There where some IETF Kerberos and GSSAPI drafts written
>> by Microsoft, but never caried forward. Globus could do it through
>> GSSAPI, using its GSI and there where mods to Kerberos to support
>> user2user so Globus could call GSSAPI/Kerberos.
> Kerberos does U2U; see RFC4120 section 3.7 for details.

But is it in any GSSAPI implementations yet?

> However, it's not clear to me that this application requires U2U, the 
> main feature of which is that it permits authentication to a "server" 
> which has a current TGT but does not know its long-term key.  In the 
> described application, the servers all have keytabs and currently do not 
> run with tickets, so U2U really doesn't apply here.

You are right, reading closer, it looks like U2U is not needed, as each
server has a keytab.

The key to the misunderstanding in the original note might be in:

 >> The server to server authentication is a bit trickier, though
 >> something like requesting a TGT for the server principal, then
 >> using that to get server tickets in the same way as a client
 >> does, except that the very begining of that process requires
 >> the input of a password, and If I go storing passwords on the
 >> servers, I might as well use the service password, yes?  In other
 >> words, is there any way to use the server keytable as a means for
 >> getting a TGT?

kinit -k -t can use a keytab to requests a ticket. No password is needed.

> -- Jeff


  Douglas E. Engert  <DEEngert at>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

More information about the krbdev mailing list