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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
