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

[Benjamin Kaduk]

On Wed, 13 Feb 2013, Andrew Deason wrote:

> On Wed, 13 Feb 2013 00:32:54 -0500 (EST)
> Benjamin Kaduk <kaduk@MIT.EDU> wrote:
>
>>> 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.
>
> I don't think so; if you only use RegisterAddrs but use the per-server
> key thing, it's still tied to the UUID. You need to specify the UUID to
> AFSCombineTokens in order to get tokens for that server.

You're right, sorry for being snippy.

> As you mention later, a BOZO_GetUUID may not be a good idea. I think it
> doesn't make a lot of sense to expose the fileserver UUID through that.
> While it's conceivable to generate some new bozo-specific UUID to
> identify the server, I don't think that's worthwhile.

Yup, that doesn't seem like a useful path to follow.

> I assume above you are talking about the case where bosserver remote
> access stops working because someone changed the hostname. While I do
> think that's annoying, it doesn't need to be as potentially disastrous
> as I originally mentioned. It's possible to have the implementation
> somewhat check for that at startup, making the error obvious early on.
> Using a separate bos identity for each server seems fine.

I was also thinking about having the implementation check at startup.  I 
don't think it would be a perfect check, but it would probably be enough.

> And as has been mentioned, this stuff doesn't need to go in this
> document, since it's not for contacting RXAFS, VL, et al. But I could
> see a small note about how other AFS services are not specified here,
> but they could just use bare gssnegotiate credentials, using their own
> per-server identity or the cell-wide key.

That seems reasonable to me.

-Ben