[AFS3-std] file servers, uuids, and GSS identities

[Benjamin Kaduk]

Trying to summarize the other half of the previous thread and keep forward 
momentum...

The VLDB holds (uuid,key,kvno,enctype) tuples for fileserver keys.  This 
can be managed manually or by use of RegisterAddrsAndKey; this discussion 
focuses on the latter method.
Clients wanting to talk to part of a fs bnode (i.e., fileserver or 
volserver) call AFSCombineTokens to the vlserver with the fileserver's 
uuid.

Now we get into what is probably just implementation questions.

We need to restrict who can call RegisterAddrsAndKey, so that rogue 
parties cannot hijack or rekey fileserver entries in the vldb.  These 
restrictions will be based on the GSS identity encoded in the rxgk token 
used to secure the connection over which RegisterAddrsAndKey is called. 
We can either encode the uuid into the GSS identity in some fashion (there 
have been several suggestions) or use a "leap of faith" method wherein the 
identity used to make the first registration is tied to the uuid and is 
the only identity that can make further changes (other than cell 
administrators, of course).  Or we can make GSS identity/uuid mapping 
part of the static cell configuration, but that seems like it would be 
annoying to administrators.  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 am inclined to say that RegisterAddrsAndKey should be leap of faith for 
new UUIDs, probably limited to afs3-fileserver@hostname (one uuid per 
identity, no stomping on existing addresses, etc.).  We can still allow 
cell admins to use RegisterAddrsAndKey for existing uuids, and maybe 
provide a tool to do so and write out a "keytab" that contains the key 
shared between fileserver and vldb.  Such upgraded fileservers would not 
be able to rekey themselves (say, upon address change) without 
administrator intervention, but presumably the administrator could also 
update the database to include a uuid<-->GSS identity mapping for that 
uuid.

-Ben