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