keytab to krb5_creds?

[John Hascall]

> On Fri, 2011-01-28 at 14:49 -0500, John Hascall wrote:
> > It seems to me that one ought to be able to construct a
> > krb5_creds struct given a keytab (and the princ name you
> > want from it)?  [probably re-inventing a number of wheels
> > due to non-publically visible functions]

> > Is this correct?

> The problem is not completely specified.  A keytab entry contains a
> principal and a key (and some other stuff).  A krb5_creds struct
> contains a client principal, a service principal, a ticket session key,
> and a ticket (and some other stuff).

> If you have a keytab entry for the principal P, then you can locally
> construct C->P credentials for any client principal C.  We don't have
> the library routines to make it easy, and you won't necessarily get the
> authdata you want in the ticket, but it's possible without any
> additional knowledge.

> If you have a keytab entry for the principal P, you can contact the KDC
> to get P->S principals for most service principals S.  This is a common
> use case and is implemented by krb5_get_init_creds_keytab().  You can't
> locally construct credentials like that because you don't know S's key.

OK, more specific.  I have two processes on the same machine which
exchange data via a file.  Now this file is going to contain somewhat
sensitive info.  Both processes are already "kerberized", and have
access to a common keytab, so my thought was:
    krb5_mk_req+krb_mk_priv -> file -> krb5_rd_req+krb5_rd_priv.
However given the data in the file and access to the key from the keytab,
one could obviously reconstruct the sensitive data.  Unless the
key had since been changed.  So then I'm thinking about a rapidly
changing key and keytab.  Which lead me to think: these are the only two
things in the whole world which use this key -- why should the KDC
be involved at all?

Hence, my initial question.


John