Peer to Peer instead of Client to Server

[Jeffrey Hutzelman]

--On Monday, April 07, 2008 11:11:56 AM -0600 John Stevens 
<john at betelgeuse.us> wrote:

> 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.

... and the disadvantage of giving the operator of any server
which handles a request for a client the ability to masquerade
as that client to any other service, anywhere.  If you insist
on following this approach, you should at least forward only
tickets for your service, instead of TGT's which can be used
to obtain tickets for any service.


>  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".


> 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?

Yes, absolutely.  For example, you can use
kadmin -kt <keytab> <service_principal>

or the equivalent krb5_get_init_creds_keytab() API call.


> 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.

Telnet is probably not a good example of how to do things.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
   Carnegie Mellon University - Pittsburgh, PA