[AFS3-std] New Version Notification for draft-wilkinson-afs3-rxgk-06.txt (fwd)

[Benjamin Kaduk]

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