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

[Benjamin Kaduk]

[aggressively trimming quoted texts to prevent growth of message size]

On Wed, 13 Feb 2013, Jeffrey Hutzelman wrote:

> On Tue, 2013-02-12 at 23:25 -0500, Benjamin Kaduk wrote:
>
> The kaserver doesn't even use rxkad, except for KAM (the admin service).
> Even that has no need for rxgk, since it's fairly well tied to what the
> kaserver does.  I think it can safely be ignored.

Yup, ignoring kaserver was the plan.  We might even make --enable-rxgk 
imply --disable-kauth at configure time, who knows.

>> That would imply that the update server should have the cell-wide key and
>> be able to accept tokens from GSSNegotiate.
>
> Possibly.  On the other hand, the upserver might just as usefully use a
> host-based service.  It is a management tool that is not particularly
> tied to the AFS service other than by being shipped in the same source
> tree.  I sort of wonder how many people are even still using it.

I also wonder.  It's certainly not in the critical path for my rxgk 
implementation roadmap, but I think it's still worth thinking about how it 
would work.

> No, butc is not a component that runs on fileservers.  It's the tape
> controller, and runs in places that have tape drives, or whatever passes
> for them.  Volume dumps are obtained from fileservers via the volume
> dump mechanism.  To my recollection, butc is also actually not really a
> server.  It gets run by an admin, with admin credentials.

The documentation is pretty clear that butc is started manually by an 
administrator and runs with administrator tokens, but I'm not entirely 
sure what the privilege is used for.  If it's just fs/volser stuff, that 
could be done with not-the-cell-wide-key, but if the vldb is modified, 
maybe not.

> In any case, I'm not convinced that either the upserver or the backup
> suite are actually part of the protocol suite we're standardizing,
> rather than simply implementation-specific tools which ship with
> OpenAFS.

I don't think we need to explicitly describe them in the protocol 
document, right.  We can still think about how they would work and whether 
that has an impact on what we do put in the document, though.


>> key, that means the per-server key will probably end up on disk somewhere.
>> Which doesn't really seem like a problem, just something to note.
>
> It needs to be on disk anyway, because it needs to survive a fileserver
> restart.  Otherwise, restarting a server would invalidate all of the
> tokens issued for it.  Not to mention a variety of other problems.

I guess I would have expected a fileserver to call VL_RegisterAddrsAndKey 
when it (re)starts, which produces a new key.  I suppose this does not 
technically have to invalidate existing tokens, my expectation was that it 
would do so.  There's also the matter that this RPC must be called over an 
RXGK_LEVEL_CRYPT connection, so the fileserver must have a GSS identity to 
produce a token for that connection.  This could just be the machine's 
host keytab, I think, and does not need to be connected to anything that 
might be used by an RX service as an acceptor.

> Also, in a world where fileservers don't know the cell key, the
> fileserver's secret key is what it uses to authenticate to the vlserver
> for registration purposes.

I don't think this is quite correct (per the above).  The fileserver has a 
long-term key used to authenticate to the vlserver for registration, but 
it is distinct from the "fileserver secret key" that is known to the 
vlservers.  The latter is specified to be random-to-key(PRF+(K0, K, 
nonce1||nonce2)) where K0 is the master key from an rxgk token.

-Ben