keytab to krb5_creds?

[John Hascall]

Well, I'm surely not claiming my approach here is particularly
general, but I'm working with a large system that's been around for
over 20 years, so it has accreted considerable mass and inertia.
It already uses kerberos, and the model:
   producer -> [circular file transaction buffer] -> consumers
is fixed.  So, the fact that I can do what I need in 100 lines
of code or so on each end, and come up with it in less than a
day is a good thing.


John


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