[AFS3-std] more on draft-wilkinson-afs3-rxgk-02

[Dave Botsch]

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
botsch@cnf.cornell.edu
********************************