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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
