[AFS3-std] Re: rxgk-afs tokens for ptservers, etc.

[Andrew Deason]

On Thu, 14 Feb 2013 08:49:12 +0000
Simon Wilkinson <simon@sxw.org.uk> wrote:

> The possibilities here seem to be requiring the identity<->UUID
> mapping to be part of the server configuration (which would permit any
> form of identity to be used), using a leap of faith where the first
> identity used to register a UUID is the only one which can then make
> changes to that UUID, or using an identity which contains the server's
> UUID. For the latter, using afs3-fileserver@UUID is tempting, but
> means that we lose any domain-to-realm magic that may be required.

afs3-fileserver@<UUID>.<cell> ? Needing to export the identity based on
the UUID seems pretty annoying, though (I think most operators aren't
really familiar with the idea of a fileserver even having a uuid).

However, I don't think the first 'leap of faith' / race is too bad. The
only security issue I see is if you issue several of them at around the
same time; then any of those in that batch could screw up the others in
that batch (and you'd notice pretty quickly, I think). If you just issue
one at a time and wait for it to register, that fileserver can only mess
with its own UUID, or presumably any UUID for an rxkad-only fileserver.

The latter could possibly be prevented by requiring an administrator to
flag something in the vldb that indicates a given UUID is about to be
upgraded from rxkad to a departmental rxgk fileserver.  But I think the
common case for per-server keys would be completely new fileservers, or
migrating from a cell-wide key, so maybe you could just not allow that
at all. I mean, if you're upgrading from rxkad, they just had the
cell-wide key, so temporarily given them a cell-wide key to upgrade
doesn't seem terrible.

-- 
Andrew Deason
adeason@sinenomine.net