[OpenAFS-devel] Re: rxkad.keytab rotation

[Andrew Deason]

On Fri, 8 Nov 2013 11:32:42 -0500
Benjamin Kaduk <kaduk@MIT.EDU> wrote:

> I may be a little confused, but we're only talking about the places in
> the codebase which are currently calling afsconf_ClientAuth(), right?
> (Ignoring 1.4.)  My understanding was that once credentials are
> printed with those routines, they are used for all (*) subsequent
> outgoing connections until the process is restarted.  As such, any
> current key-rotation procedure is going to require restarting all
> server processes along the way, in order to completely remove the old
> key.
> 
> This would seem to indicate that using a "probe" RPC during startup
> (right after getting the printed credentials) would be consistent with
> the current state of affairs, and that checking every RPC would not be
> necessary.

Yes, it's not "necessary" if you have the administrator check the kvnos
on startup. In that scenario, a robust rotation is then possible, but
you still have to check the logged key manually and that relies on human
behavior not failing. So, it would be better if we didn't have to rely
on the human operator for that part, so this can be done in a purely
automated way. The bare minimum necessary is just to log the outgoing
kvno, but it's better if we don't have to; and I'd rather not have
separate procedures for doing this depending on if you're running
version X, Y, or Z (if possible).

It is technically still possible to do that in an automated way if you
have something scrape the log for the kvno (ugh), or if we had some
other command or something to query what the outgoing kvno is in a
machine-readable way. But at some point this just feels ridiculous and
none of this is necessary if we made the servers properly detect and
reinitialize their outgoing credentials.

And as a bonus, implementing that means you don't have to restart the
servers to rotate the keys, which already seems like a hassle and a
workaround for shoddy implementation.

> Looking at the viced, for example, vl_Initialize() calls ClientAuth
> and shortly thereafter loops over the vlservers and calls
> rx_NewConnection on them to pass to ubik_ClientInit.  We could
> probably through a probe RPC in there and fall back to the previous
> key if we get the "bad key" error.  This is a layer where we can
> conveniently log, so we should be sure to do so if we fall back to an
> old key.

I was thinking we'd have the calling process pass a callback function to
libauth, and that callback function would provide the appropriate
"probe" RPC and say if the key was okay, and have the ability to log,
etc.

> I think I will have some time to help implement such a solution, if
> desired.

I'll get to it soon :) I just had a couple of urgent things hit me
recently.

> (*) I seem to recall a couple of places where verious ubik recovery
> scenarios could lead to refreshing credentials, but I think these are
> rare.

We can reinitialize the _conn_ sometimes, but ubik_CRXSecurityProc is
only ever called once, in ubeacon_InitServerListCommon.

-- 
Andrew Deason
adeason@sinenomine.net