[AFS3-std] Finishing the core rxgk document

[Benjamin Kaduk]

On Fri, 18 Oct 2013, Nico Williams wrote:

> On Thu, Oct 17, 2013 at 11:08:18PM -0400, Benjamin Kaduk wrote:
>> On Mon, 14 Oct 2013, Nico Williams wrote:
>>
>>> - Section 5, is there any latency expectation regarding how long it
>>>  takes to identify a client user from a token?
>>
>> I don't think there are any particularly concrete expectations.
>> The client does have some timeouts at the connection level, but
>> those will be seconds at least.  (I don't know the concrete values
>> offhand.)
>
> I was just curious as to what implementation alternatives besides
> "encrypted token" are permitted.  Note that if the token concept is not
> nailed down in detail then different implementations of servers in a
> cell may not interop.
>
> Oh, speaking of which, should the term "cell" be defined?  It's odd to
> read this I-D and not see "cell" come up at all.

It turns out that there are consumers of the RX network protocol other 
than AFS.  This document is really just talking about rxgk as applied to 
pure rx applications; there's a separate document that talks about the 
particular bits of using rxgk for AFS.  In particular, a stock RX 
application has conceptually just a single server, and it only sees tokens 
it hands out, so there's no worry about different servers in a cell.
For AFS, we do have to specify a token format so that servers are 
interoperable, but that's in the other document.

The only other real alternative I've heard to an encrypted token is to 
hand out a large random number, and use this as a key for a lookup table 
of the necessary information.

>>> - Section 5, maybe the notional *minimal* contents (decrypted or
>>>  looked-up) of the token should be described with an XDR struct?  See
>>>  comment below about K0; it'd help to state that the root session key
>>>  is part of the token.
>>
>> I think I could picture a scenario when only the session key is
>> needed, amusingly enough.  (The negotiation service only issues
>> tokens to authorized users, all users have full permissions, and no
>> one cares about expiry.)  The companion document
>> draft-wilkinson-afs3-rxgk-afs does have an explicit token format for
>> the use with the AFS protocol.
>
> Hmm, but the user ID info has to be in there for ACL evaluation
> purposes.  An ACL-less server wouldn't need that... but that'd be
> boring.

It would be boring, yes, but if the application only does one thing 
("reboot this server"?), it's enough.

>> I added some text calling out GSS_S_COMPLETE as 0, and noting that
>> any distinction between different non-zero values is purely
>> informational, but this setup is kind of ugly.  I think the protocol
>> as currently set up does need an external indicator that the
>> rxgk_info has valid contents, though (that is, that the server is
>> GSS_S_COMPLETE and has produced a token), and this field is probably
>> the best place to do so.
>
> So specify the use of the C bindings' major status codes.  I.e.,
> reference RFC2744 for this.

That might make for awkwardness in non-C implementations, but it would at 
least be something concrete and easy to write.  Hmm.

-Ben