On Thu, 11 Jul 2013, Jeffrey Hutzelman wrote:
On Thu, 2013-07-11 at 15:40 -0400, Benjamin Kaduk wrote:
Well, whether it's an abort or something else, there comes a point where
the server decides that the negotiation has failed. It doesn't _have_
to return any particular error, but it needs to commit to that exchange
never succeeding, and ideally it should not call GSS_Accept_sec_context
again for that exchange. It would be polite to return an error, but I
suppose it could do something else.
Ideally the server deciding there's an error will also make the client
decide there's an error, quickly.
Are you claiming that the breakdown in step 4 is an invalid decomposition?
I believe it's incorrect. In that breakdown, if the server asserts that
another cycle is needed but the client's last call returns
GSS_S_COMPLETE, then the loop terminates successfully. But this is
actually a failure condition.
The client will (must!) fail if there is no usable ClientInfo returned.
I'm not sure that we need to be terribly concerned about whether we call
this a negotiation failure or just a failure.
I'm not sure I understand your statement, though.
Oh, hm. s/returns/returned/ may make it clearer.
If the client calls GSS_Init_sec_context and gets GSS_S_COMPLETE with a
token, and then calls GSSNegotiate() with that token and the server
asserts CONTINUE_NEEDED, then your description in step 4 says
* If the most recent call to GSS_Init_sec_context() returned the
major status code GSS_S_COMPLETE and an output token, the
negotiation loop is in a success condition and terminates.
But in fact, the loop is not "in a success condition"; it's in a
condition that can only occur if the client and server state machines
are out of sync, which is an error.
Well, the loop should definitely terminate.
... now you're making me wonder if we should define "success" as "the
server returned a useful ClientInfo" and only talk about terminating the
loop.
I do think we should be explicit about this sort of thing, because what
we're essentially doing is telling people in no small amount of detail
what API calls to make when and what to do with the results.
Okay.
1) CONTINUE_NEEDED without a token is an error, and we should treat it
as such, rather than calling GSS_Init_sec_context with no input token,
which means something rather different.
The context got lost, but I will check for this in the revision process.
2) I can't remember whether "empty token" and "no token" are distinct.
That requires a rereading of the spec, and if the answer is that they
are not, then yes, I think we should word things in terms of non-empty
tokens.
I will check and/or ask around.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
