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

[Andrew Deason]

On Fri, 1 Feb 2013 15:54:42 -0500 (EST)
Benjamin Kaduk <kaduk@MIT.EDU> wrote:

> The rxgk-afs draft currently only mentions vlservers and fileservers,
> with only a passing mention of database servers.  If we want to stick
> to defaulting to the vlserver for GSSNegotiate, we should probably
> mention that other database servers are expected to be able to accept
> such tokens.  Alternately, we could specify that all database servers
> must offer the negotiation service, but that doesn't seem quite right.
> (The bosserver will need special treatment, though, as we want to be
> able to use rxgk authentication to bring up the vlserver!)

First of all, the current draft mentions the following, which I think
may be a little unclear:

[Last paragraph of section 3]
   Tokens returned from the GSSNegotiate call MUST only be used with
   database servers.  Tokens for fileservers MUST be obtained by calling
   AFSCombineTokens before each server is contacted.

Without context, that doesn't seem clear to me whether it means the
database server processes and the fileserver process, or if it means the
actual machines. It seems like it would make more sense to me to say to
only use AFSCombineTokens when talking to fileserver processes via
RXAFS_* calls, and all other processes can use tokens from GSSNegotiate.
Does that make sense?

I'm not sure if RXAFS_* calls is how you specifically want to make that
distinction, but I think you know what I mean. AFSCombineTokens is only
for traffic dealing with clients fetching/storing/etc data to/from
fileservers, not for administrative actions.

> Any thoughts one way or the other?

Now, as you say, if we have GSSNegotiate only running via the vlserver,
obviously that's a problem since we can't authenticate if the vlserver
isn't up. Conceptually I think it would make sense to run that on the
bosserver instead (since that's always around) except:

 1. BOZO_ doesn't really seem like a client-friendly interface; so far
 it's only been for administrative tools. So I've been kind of
 considering it like the VOLSER_ RPCs, in that compatibility etc is a
 little less important, since it doesn't talk to random clients.

 2. Existing firewalls and stuff surely let the vlserver port through,
 but may not let the bosserver port through.

So, moving GSSNegotiate doesn't seem like the answer. But, to me it
would make sense to say we run GSSNegotiate on vlservers and on
bosservers. For acquiring credentials for administrative actions, try
bosserver first; for user credentials intended for fileserver access,
try vlserver first.

Thinking down the road, I'm not sure how we're going to make that choice
user-visible in the implementation, but it seems more tractable than
needing to specify which 'service' to authenticate to when you acquire
credentials.

This requires bosserver to be running and reachable to have
authenticated access to e.g. ptserver, but that seems reasonable (and
certainly more reasonable than requiring vlserver to be up). But having
other services accept GSSNegotiate calls I could maybe see, though: for
example, if for whatever reason you can't talk to bosserver or vlserver,
you can still do authenticated actions on ptserver. That doesn't strike
me as terribly common, though, so it doesn't seem like a great concern.
Maybe it could be optional?

-- 
Andrew Deason
adeason@sinenomine.net