[AFS3-std] Finishing the core rxgk document

[Jeffrey Hutzelman]

On Thu, 2013-10-17 at 23:08 -0400, Benjamin Kaduk wrote:


> >   GSS security context token exchanges are synchronous and may involve
> >   any number of context tokens larger than or equal to one.
> >   Implementations MUST NOT assume any number of context tokens for any
> >   one mechanism, but implementations MAY set an upper bound no less
> >   than six (6).
> 
> I'm not sure where the number six is coming from, so I haven't taken this 
> part yet.  The rest of the wording is probably okay to take, though.

Me either.  Naturally, a client can give up whenever it wants.  However,
this is really not the place to introduce what is essentially a new
limitation on GSS-API mechanisms.  No one is going to say "we can't
standardize this mech because it requires 7 round trips and AFS only
supports 6".


> > - Section 6.2, structure of loop.  I think this is a bit odd and
> >   redundant.  The structure of the loop is quite standard; repeating it
> >   is useful when the reader doesn't know anything about the GSS-API,
> >   but otherwise it could be a source of bugs and confusion.

Unfortunately, while the structure of the loop _should_ be quite
standard, there is no standards-track GSS-API document which describes
it in sufficient detail.  Nico is correct that information about what
the flags need to be (and other inputs and checks on the outputs) can be
abstracted out -- the inputs (except the token) are the same for every
call, and the outputs (except the status and output token) normally only
need to be checked at the end.  However, the handling of the loop itself
has a number of edge cases that I don't think are sufficiently
well-documented in anything we can refer to.

There's a reason we described the negotiation in this level of detail in
RFC4462.

> >   For example, I think there's no need to discuss non-sensical GSS
> >   results, like GSS_S_CONTINUE_NEEDED w/ no output sec context token.

I disagree.  An implementation has to do _something_ if the library does
that, and "something" should be to fail, not to assume everything is OK.


> doing here and that if an implementor knows how to do a GSS negotiation 
> loop in general, they should be fine implementing rxgk.  The question (to 
> me) is more of whether we want to assume that level of expertise on the 
> reader

I don't think we should.  I'd be fine with referring to another document
for this, if one existed.  I'd be fine with someone writing one!  But I
don't think we should assume _anyone_ knows how to do this right without
being told, no matter how familiar they are with GSS-API.

I agree this is really KITTEN's problem more than ours, but here we are.

-- Jeff