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

[Benjamin Kaduk]

On Wed, 13 Feb 2013, Simon Wilkinson wrote:

> On 13 Feb 2013, at 05:32, Benjamin Kaduk <kaduk@MIT.EDU> wrote:
>
>> Well, we allow out-of-band key management as well as VL_RegisterAddrsAndKey to get per-server keys.  So conceivably, those could have GSS identities.
>
> If you are using RegisterAddrsAndKey you need to have a GSS identity on 
> the server. Departmental file servers have to have GSS key material.

Yes.  But do we have to suggest a name for the identity of that key 
material, and do clients wanting to talk to (bosservers on) them need to 
know that identity?

>>> Anyway, my concern/confusion with this is that the per-server keys are
>>> associated with a server UUID, which I believe is purely a notion of the
>>
>> Again, only if the RegisterAddrsAndKey method is used.  But we want to 
>> support it, so we must have a way to cope regardless.
>
> RegisterAddrsAndKey is the only mechanism to declare yourself as a 
> departmental file server.

Is it?  I thought we allowed for an out-of-band key management system, 
which I thought was enough to allow departmental file servers.

>> But, as you note, machines with only a fileserver will still run a 
>> bosserver to manage the fileserver, and may not have a GSS identity 
>> avaialble.
>
> I don't think it's overly onerous to require that all machines running a 
> bos server have a GSS identity. In most cases this just means that they 
> need a Kerberos key, which most sites will already have a means of 
> provisioning for their servers.

It does seem quite likely that there will be *some* GSS identity on the 
machine, and yes, I think we will probably require it.  I think what we're 
debating is whether we need to specify that there is (also) an afs3-bos 
identity.

I am coming around to thinking that requiring an afs3-bos identity is 
reasonable, but I am still pondering whether we want the global cell 
admins to be able to completely control departmental fileservers (e.g., 
with bos -localauth or similar).

-Ben