Getting TGTs non-interactively - Kerberos

This is a discussion on Getting TGTs non-interactively - Kerberos ; Hi list! I'm sure I'm not the only one with the following problem, and I'd like to know if/how someone else has solved it. See, there are a lot of places where one would like to obtain a ticket non-interactively. ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Getting TGTs non-interactively

  1. Getting TGTs non-interactively

    Hi list!

    I'm sure I'm not the only one with the following problem, and I'd like
    to know if/how someone else has solved it.

    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?

    Thank you for your attention!

    Fredrik Tolf

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. Re: Getting TGTs non-interactively

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

    --
    Russ Allbery (rra@stanford.edu)

  3. Re: Getting TGTs non-interactively

    Russ Allbery wrote:
    > Fredrik Tolf 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

+ Reply to Thread