[OpenAFS-devel] Re: rxkad.keytab rotation

[Andrew Deason]

On Wed, 23 Oct 2013 10:12:44 -0400
Chaskiel Grundman <cg2v@andrew.cmu.edu> wrote:

> This seems rather more heavyweight (at least from the perspective of
> implementing it in openafs), since it would involve inserting some
> sort of loop around client rpcs in every server and any client that
> uses localauth,

Yeah, it also struck me as way more complex from a coding perspective
than any of the other options, though from a user's perspective it's
clearly much simpler.

I'm not sure if we need to check the results and possibly reinit for
every single RPC, though. I _think_ we can issue some low-impact "probe"
RPC during startup to verify the connection is okay (I think all of the
relevant services have an existing RPC that is suitable), and negotiate
the key to use using that. That is a lot easier, though obviously it
doesn't handle any such errors if they are encountered after startup.

I think that allows for a "robust" rotation procedure. It gets a little
more difficult when you want to revoke the "old" key, since it's
difficult to tell what key we're using for outgoing connections. If we
have the 'new' and 'old' keys in our rxkad.keytab, but we fell back to
the 'old' key for outgoing conns for any reason, obviously we'll fail
once the 'old' key is revoked on the remote side, and we need to
reconnect for any reason.

That's either solved by checking every RPC return code as you mentioned,
or we could just log which key we're using for outgoing connections, and
have "proper procedure" say to have the administrator sanity check that
the log says the expected kvno.

A kind of "middle ground" may be to check all RPC return codes in
servers (where we already have a bit better error handling than just
"print out an error message and exit"), but for command-line utilities
with -localauth, we could just use some "probe" RPC during
initialization.

-- 
Andrew Deason
adeason@sinenomine.net