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