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. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
