keytab to krb5_creds?

[Brian Candler]

On Fri, Jan 28, 2011 at 02:09:14PM -0600, John Hascall wrote:
> 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?

Well, the point of the KDC is that principal A can prove its identity to
principal B without knowing principal B's secret key (and vice versa). For
two entities with the same key, the KDC is indeed irrelevant.

If you're writing the data into a file, maybe just encrypting it with the
key from a "keytab" would be sufficient - e.g.  using gpg in symmetric mode
and read the passphrase from a file (or gpg with pub/priv key, reading the
priv key passphrase from a file).  As you say, anyone who can read the
keytab can also read the data, but that's going to be a fundamental
limitation of your design anyway.  Ultimately, each process is going to need
credentials suitable for decrypting data written by the other process,
otherwise it can't work, and it has to get those credentials from somewhere.

A few alternatives:

1. you store those secret info in the filesystem or in the application
itself (which makes it readable to anyone else with sufficient privileges)

2. you prompt for it when each process starts, and keep it in RAM (which
means restarts require manual intervention)

3. you have a parent-child relationship between the two processes: process A
can think of a random key, fork, and process B knows the same key. This also
keeps it in RAM only, but any existing files on disk will become useless if
you restart the processes.

4. you use some sort of hardware approach like TPM or a crypto module - but
even then, you have to make sure that only processes A/B can ask the module
to decrypt the data, which brings you back to the same problem. You could
perhaps run the two processes in separate VMs, and communicate via a shared
filesystem such as NFS.

5. does it really need to go via the filesystem? Could you use TLS over a
socket instead?

Just a few thoughts.

B.