Getting TGTs non-interactively

[Jeffrey Altman]

Russ Allbery wrote:
> Fredrik Tolf <fredrik at dolda2000.com> writes:
> 
>> See, there are a lot of places where one would like to obtain a ticket
>> non-interactively. Apart from such places as cron, where there's
>> obviously no other choice than to store the key in a keytab, there is
>> the problem with SSH public-key authentication. I'm thinking that it
>> should somehow be possible to have the SSH client (which has access to
>> the private key) decrypt a key for the server, which can then get a TGT
>> with that key. Is that possible, or is there any other solution that I
>> haven't thought of.
> 
>> Similarly, what about HTTPS connections where the client has a client
>> certificate? Obviously, there *is* a private key involved, but is there
>> any way the HTTP server can ask the client to decrypt a TGT key for it?
> 
> Sounds like you want pkinit (Kerberos initial authentication using
> public/private key cryptography).  This is currently being standardized.
> I'm not aware of any fully deployed and robust implementations, but I
> haven't been following this area very closely.

I do not believe that PKINIT would help in this situation.  PKINIT can
be used to obtain a TGT (or other initial service ticket) but only if
the private key is in the possession of the party performing the request.

In both the SSH public-key auth and the HTTPS client cert models, the
private key is in the hands of the client, not the server.  Therefore
the server cannot use the private key to obtain a TGT.  What is required
in both of these situations is for the client to obtain the credential
prior to establishing the connection and to delegate (or forward) the
credential to the server.

For SSH this can be done by authenticating with GSSAPI instead of with
public-key auth.  For HTTP, this can be done by authenticating with
HTTP Negotiate instead of with client certs.

Jeffrey Altman