Peer to Peer instead of Client to Server

[Douglas E. Engert]

John Stevens wrote:
> Greetings,
> 
> I'm working on a project where the services are distributed, thus
> they need "peer to peer" authentication.
> 
> Currently a client authenticates to any of the hosts running one of
> the servers that are part of the distributed service, but for that
> server to be able to contact a peer I've had to use a trick where I
> kinit as a user, then start the server as a process owned by that
> user.
> 

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.

Google for combinations of: user2user Kerberos GSSAPI Globus


> Guessing wildly, there appears to be two possible ways to solve
> this problem: copy a forwardable TGT through the network of
> service servers, or to have individual servers authenticate
> themselves to other servers.
> 
> The first solution, (forwardable TGT) seems to add quite a
> bit to the network traffic, while having the advantage of
> authenticating all work done as being done for the user of
> the client.  The second seems more "correct" as each server
> is part of a distributed service, so in effect having
> servers authenticate to other servers is "part of the service
> authenticating itself to another part of the same service".
> 
> If I may solicit input: are both methods possible (there is
> very little documentation, developer's guides, etc. for
> forwardable tickets . . . in fact, there is very little
> Kerberos developers documentation period)?  If both
> are, is there one you see as being better for some
> reason (more secure, etc.)?  Finally, besides the raw
> code, is there any documentation or simple examples you
> can point me at that suggest which functions to use, and
> how to string them together to implement either?
> 
> I did find the code that seems to forward a TGT in the
> telnet code in the MIT Kerberos source, but I couldn't find
> anything to suggest how to use said ticket (though I'm guessing
> that the correct process would be to receive said TGT, create
> a new cache on the server side, stick this TGT into it, then
> use that cache in a "client" to server authentication in
> pretty much the exact same way as you would in any client to
> server authentication.
> 
> 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?
> 
> Finally, the telnet code seems to basically copy the TGT to the
> other host in the clear.  Is this secure?  Or did I miss an encryption
> step along the way?  The telnet code uses a function I can't find
> documentation for, as well, so I'm not sure what it does or is
> supposed to do.

Forget telnet.

A good example of where user2user could be used, is FTP which can
connects to two different ftpd on different machines andf have
them transfer data between the ftpds.

Google for GridFTP

> 
> Any pointers to documentation, suggestions, criticism, etc. would
> be deeply appreciated.
> 
> TIA,
> John S.
> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
> 
> 

-- 

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