[krbdev.mit.edu #6603] issues with SPNEGO

[Greg Hudson via RT]

A little analysis of the reported problems:

1. A final token produced by the initiator is not sent to the acceptor.

I would describe this problem differently: the initiator will not send
more than two tokens to the acceptor unless a MIC is required.  The bug
here is that on the second call to init_ctx_cont (the third call to
spnego_gss_init_sec_context), if no MIC is required for the negotiation,
*negState is set to ACCEPT_COMPLETE and *tokflag (aka send_token) is set
to NO_TOKEN_SEND without regard for whether the token exchange has
completed.  If the mechanism produces an output token,
init_ctx_call_init will set negState back to ACCEPT_INCOMPLETE, but will
leave send_token as NO_TOKEN_SEND, so spnego_gss_init_sec_context
returns GSS_S_CONTINUE_NEEDED without setting the output token--clearly
invalid behavior.

The proposed fix is to use acc_negState to decide which way to set
*negState and *tokflag.  However, RFC 4178 says that acc_negState is
optional after the first reply from the target; if the target doesn't
send it, then acc_negState will have the value ACCEPT_DEFECTIVE_TOKEN
(even though the token isn't defective) and we are supposed to deduce
the negotiation state from the return value of the selected mechanism's
init_sec_context call.  The proposed fix does not handle this contingency.

2. If the mechanism doesn't set
GSS_C_INTEG_FLAG, the acceptor never sets the state to ACCEPT_COMPLETE.

This appears to be a failure of the code to check for (sc->ctx_flags &
GSS_C_INTEG_FLAG) in all of the cases where it checks for sc->mic_reqd.
 The proposed fix is to set sc->mic_reqd to 0 before a particular check
of sc->mic_reqd in acc_ctx_call_acc if (sc->ctx_flags &
GSS_C_INTEG_FLAG) is false.  I don't think that improves the overall
cleanliness of the logic.  Consistently using a static inline to check
for (sc->mic_reqd && (sc->ctx_flags & GSS_C_INTEG_FLAG)) might be better.