Inline responses below... On Mon, Feb 20, 2012 at 08:10:47PM +0000, Simon Wilkinson wrote: > > On 20 Feb 2012, at 18:51, Dave Botsch wrote: > > 1.1 requirements langauge - define client, application, and connection > > (I am guessing that "client" refers to an individual workstation, and > > "connection" refers to each individual application attempting to access > > afs? Anyway, definitions here would help > > connection is an RX connection (which is the RX unit at which security is > applied).
I would request that the document be updated with the definition of what a "connection" is, a "client" is, an "application" is, etc (in the real world, these terms are unfortunately used interchangably, so being clear on what is what here would be good). > > > startparams ... so, is this affected by the security level set on the > > client? If the client wants "encryption", should it also say it will > > take "integrity" and "clear"? Or is the expectaion that the client will > > only ask for "encryption" with no fallback? > > That's an implementation decision for the client. On some occasions it may be > appropriate to ask for encryption with no fallback, in others you may be > happy with encryption/integrity, in others you may be prepared to settle for > whatever is available. > Does this need to be stated? > > As an aside, what's the feedback mechanism to the user so that the user > > knows he/she is getting what he/she asks for? > > That's an implementation decision. > > > And can the encryption level be downgraded upon renegotiation? > > Yes. When you get new tokens (which is what renegotiation is, in effect), you > can request a different encryption level. > > > 8.1 Overview - the "challenge" referenced, is that the chanllenge in the > > below section(s)? "the standard RX security establishment protocol"... > > to what is this referring (a section in this document or something in > > another document? > > The challenge is the RX security challenge - it's a defined part of the RX > protocol, as is "the standard RX security establishment protocol". These are > defined, as best as we can currently get, in > http://web.mit.edu/kolya/afs/rx/rx-spec > Should there be a reference to that from this document? > > 10.1 - why aren't RX Abort packets protected? Where do these fit in? > > Reference, please. > > The fact that RX abort packets aren't subject to the RX security layer is a > core part of the RX protocol. Again, http://web.mit.edu/kolya/afs/rx/rx-spec > is the best documentation of this that we currently have. > A reference to that from this section of the document would be useful (see here for details, blah blah etc). > Cheers, > > Simon. > > -- ******************************** David William Botsch Programmer/Analyst CNF Computing [email protected] ******************************** _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
