On Thu, 14 Feb 2013, Andrew Deason wrote:
On Thu, 14 Feb 2013 15:28:52 -0500 (EST)
Benjamin Kaduk <[email protected]> wrote:
On the other hand, if a fileserver is to be upgraded from rxkad to
rxgk, there needs to be some way to indicate in the configuration that
it is ready to do so, otherwise all rxkad fileservers are subject to
hijacking by a rogue RegisterAddrsAndKey call.
I think the distinction here is between cell-wide-key fileservers and
per-server-key fileservers; rxkad or not doesn't really matter. A
Well, sure, having the cell-wide key allows it to print a token with
whatever identity it wants (regardless of our MUST have an empty
identity), so a printed token should be sufficient authorization to do an
upgrade.
fileserver with the rxgk cell-wide key should be able to upgrade itself
without intervention. And if you convert a fileserver from cell-wide-key
to per-server-key, you need to have an administrator flag the UUID
somehow, or else the fileserver could hijack any rxkad or cell-wide-key
rxgk fileserver vldb entry.
I'm not sure I understand you correctly, but I agree that going from
cell-wide key to per-server key requires administrator action on that
UUID.
I'm thinking of this as just a general administrator command to change
the UUID<->GSS mappings. You'd need the same thing if you change the
e.g. kerberos principal used by a fileserver (say, if it's hostname
changed, and you want the principal name to accurately reflect the
hostname).
Yup.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
