Streamlining distribution of Kerberos keytabs (and other data)

[Russ Allbery]

Jan-Piet Mens <jpmens.dns at gmail.com> writes:

> FWIW, I've written [1] a short article on my very good experience with
> Wallet. Thanks to Russ for having created it and for help in
> understanding!

Thanks for the pointer and the nice words!

I should probably mention that initial keying is a problem that I still
want to solve in a better way, since the method that you describe requires
giving a widely-deployed (or at least deployable) keytab access to a wide
variety of other keytabs, and it would be nice to limit initial keying in
more ways than that.  The current approach that I'm kicking around is to
be able to create objects that can be downloaded anonymously from a
particular IP address, but only once.  Then, you can create such an object
before the system build (possibly automatically as part of whatever
process you use to kick off the build), and then the system will be able
to anonymously retrieve its keytab, with all subsequent accesses locked
out unless someone opens them up again.  This is similar to the initial
leap of faith used for ssh host keys.

I'm not sure yet whether requiring support for anonymous PKINIT will be
too high of a bar.  Anonymous authentication in remctld has the right
semantics and lets one continue to use remctl for the privacy layer, but
it requires a lot of KDC infrastructure.  One can still use a
service/initial-build keytab that's considered "equivalent to anonymous,"
which would be simpler to set up.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>