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

[Benjamin Kaduk]

On Fri, 28 Jun 2013, Jeffrey Hutzelman wrote:

> On Mon, 2013-06-24 at 18:30 -0400, Benjamin Kaduk wrote:
>> For those following along, I finally got around to putting in extra markup
>> to split out the control flow of the GSS negotiation loop into enumerated
>> steps.  There are no changes to the body text.
>
> I've taken a look at this, and the structural changes look pretty good.
> I've also reviewed the description of the negotiation loop in section
> 6.2, and have a few comments...
>
> - In step 3, you don't say anything about the case where the major
>  status code from GSS_Accept_sec_context indicates an error.

This was something of a conscious decision, as the client need not know 
the server's gss_accept_sec_context() return value directly.  Even in 
RFC4462, it is only "the server MAY send a message informing the client of 
the details of the error" and "SHOULD send the error token [if it 
exists]". The failure of context establishment will become clear quite 
soon, regardless; either gss_init_sec_context() will fail due to a 
missing/invalid token, or the server will have failed to return a token. 
Do you really want explicit text here?

I suppose I should consider whether to permit sending a GSSAPI error from 
routines other than GSS_Accept_sec_context(); my implementation at least 
used to do this, I may have cleaned it up since then.

> - If the server decides that negotation has failed for a reason other
>  than GSS_Accept_sec_context returning an error status, , it should
>  indicate this to the client by returning an error from the RPC or
>  by some other indicator.  It should not synthesize a GSS-API status
>  code that was not actually returned by the GSS-API.

You are taking issue with the synthesis of GSS_S_BAD_QOP?
To represent this error case (GSS_Accept_sec_context returns 
GSS_S_COMPLETE but ret_flags & (GSS_C_CONF_FLAG | GSS_C_INTEG_FLAG) != 
GSS_C_CONF_FLAG | GSS_C_INTEG_FLAG) as a com_err error, I believe we would 
need to introduce a new RXGK error code.  Do you have suggestions for this 
error code name and text?

> - In step 4, if the GSSNegotiate() fails for any reason, the client
>  should consider the negotiation to have failed.

Well, the client should not decide to downgrade to rxkad because 
GSSNegotiate returns -1!  I can add explicit text for what to do if the 
RPC fails if you want, though I think the intent was that the last 
paragraph of 6.2 would cover this case.

> - Don't conflate GSS_S_CONTINUE_NEEDED with an output token.  The
>  GSS_S_CONTINUE_NEEDED flag indicates that another call with an input
>  token is expected, not that an output token was provided.  So...

Right.

>  + If GSS_Init_sec_context produced a token when the server wasn't
>    expecting one, or failed to produce one when it was, that is an
>    error, and negotiation fails.
>
>  + If GSS_Accept_sec_context produced a token when the client was
>    not expecting one, or failed to produce one when it was, that is
>    an error, and negotiation fails.

These will both be caught by the counterparty's next GSS call and need not 
be handled explicitly.

>  + If GSS_Accept_sec_context produces an output token but does not
>    set GSS_S_CONTINUE_NEEDED, that is _not_ an error -- it means the
>    client needs to call GSS_Init_sec_context() once more, and that
>    call is expected to succeed without producing an output token.
>    Of course, at this point, the acceptor believes the context has
>    been established, but the initiator may need to process that last
>    token in order to finish setting up the context.

Yes, this is the "half round trip" mentioned at the top of 6.2.

> So in step 4, if the GSSNegotiate RPC failed, or returned a GSS status
> indicating an error, then negotiation has failed.  Otherwise, there
> are three cases...

Hmm, saying "the major status code" here is a bit ambiguous as to whether 
it is from initiator or acceptor (it's supposed to be the acceptor, if I 
remember correctly.

>  (a) The server returned GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED, with
>  an output token, and the client was expecting a token.  In this case,
>  the client begins the next cycle.
>
>  (b) The server returned GSS_S_COMPLETE without an output token, and
>  the client was not expecting a token.  In this case, negotiation
>  succeeds.
>
>  (c) All other combinations are failures.

This is a valid decomposition, but I would prefer to not introduce the 
notion of the client "expecting" a token; instead, I like to refer only to 
what has already happened.  Thus, "the most recent call to 
GSS_Init_sec_Context() returned the major status code GSS_S_COMPLETE" 
instead of "the client was not expecting a token".

Are you claiming that the breakdown in step 4 is an invalid decomposition?

If the server is not GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED, it is in 
error, of course (as your (c), my first bullet point).  If the client was 
not expecting a token (second bullet point) and gave one to the server, 
the server cannot be setting GSS_S_CONTINUE_NEEDED (right?) because the 
client is already GSS_S_COMPLETE and will produce no further tokens. 
Thus, the conditions from the first bullet point mean that the server 
returned GSS_S_COMPLETE as well, so both sides are done and the 
negotiation was successful (your (b)).  If Init_sec_context was not 
GSS_S_COMPLETE and also did not fail the negotiation, the client was 
expecting another token, and thus we should proceed with the loop and call 
GSS_Init_sec_context() again to examine that (the third bullet point, your 
(a)).

I believe I used to have an explicit case for the client expecting a token 
and the server not returning one, but Simon noted that we can just 
continue the loop and the next Init_sec_context call will detect the 
error.

> GSSNegotiate is intended to be called over an unprotected channel.
> So, there is no security reason to favor reporting results via an
> output parameter instead of via an Rx abort.

That text at the end of 6.2 was intended to call to mind the security 
considerations 12.1.  I guess the description as written is not really 
consistent with the class of errors for which the security consideration 
applies, though.

Thanks for the comments.

-Ben