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

[Simon Wilkinson]

On 13 Feb 2013, at 17:21, Benjamin Kaduk <kaduk@MIT.EDU> wrote:

> Just to make sure I'm understanding correctly, "completely different servi=
ce" means that you do not attempt to use a cell-wide key to negotiate a toke=
n with the RXGK_GSSNegotiate service offered by a bosserver?

Correct. bos doesn't use the cell wide rxgk key at all.

> However, I do like the ability to treat dbserver machines as interchangabl=
e, or even as identical (in the sense that they are just different faces of t=
he same distributed database);

I think this as abstraction violation. Whilst the service presented by ptser=
ver or vlserver makes database servers interchangeable, the platforms upon w=
hich these services are hosted are not necessarily interchangeable. Bos is j=
ust another example of this.

For example - a user might choose to host a file server on one (but not all)=
 of their database server machines. Multiple cells might be hosted on a sing=
le machine (so which cell-wide key do you accept?) Migrations may be perform=
ed where the cells hosted by a machine change without restarting bos, and so=
 on. Not all of these things are possible in OpenAFS today, but I don't thin=
k we should design rxgk based on our current limitations.

> this makes me inclined to allow the dbserver machines to use the cell-wide=
 key (aka the afs-rxgk@_afs.<cellname> GSS identity) for fielding GSSNegotia=
te calls on the bosserver port.  Do you oppose allowing this? =20

Yes, I think I do - for the reasons I outline above.

> I'll think about it more; I could still be convinced that always using an a=
fs-bos (or afs3-bos?  We should be consistent about whether we use a '3') id=
entity for bosserver tokens is the right thing to to.

For services which have an entry in /etc/services, I think we should maintai=
n the Kerberos convention of using that service name for our identities.


S.