No Subject

. 2) gss_spnego_accept_sec_context creates a NegTokenInit w/
. mechList token (and hijacked mechListMIC aka negHint for MS) if
. input_token_buffer->length == 0. Are we sure this is right?
. 
. From reading the SPNEGO RFC 2478 it sounds like gss_init_sec_context
. generates only NegTokenInit tokens and gss_accept_sec_context generates
. only NegTokenTarg tokens:
. 
.   4.1.  Initial steps
.      ...
.      (I) invokes GSS_Init_sec_context() with :
.      ...
.      Output
.        major_status = GSS_S_CONTINUE_NEEDED
.        output_token = negTokenInit
.      ...
.   4.2  Successful negotiation steps
.      ...
.      (T) receives the negotiation token (negTokenInit) from (I)
.      (T) invokes GSS_Accept_sec_context() with :
.      Input
.           input_token = negTokenInit
.      Output
.           ...
.           output_token = negTokenTarg
.      ...
. 
. I think the "correct" behavior would be to do gss_init_sec_context to
. get the mechList (provided you could somehow suppress the mechToken)
. and then just discard the half-baked security context. Now the client
. sends a NegTokenInit which is used with gss_accept_sec_context.
. 
. The client must do the same sort of thing calling gss_accept_sec_context
. and then start over calling gss_init_sec_context. Consider the SMB
. extended security exchange:
. 
.   SMBCMD                      CLIENT          SERVER
.   NEGOTIATE                                ->
.   NEGOTIATE Response                       <- NegTokenInit
.   SESSION_SETUP_ANDX          NegTokenInit ->
.   SESSION_SETUP_ANDX Response              <- NegTokenTarg
. 
. So the NEGOTIATE Response and the SESSION_SETUP_ANDX *both* send
. NegTokenInit tokens. So maybe the server is switching roles from initiator
. to acceptor and visa versa for the client.

Nothing I have done since indicates the above is wrong. The changes in
my diff implement this "correct" method (I took care not to break your
method but I have not tested that).

Mike