Re: [patch] miscellaneous mechglue stuff

[Michael B Allen <mba2000@ioplex.com>]

On Mon, 1 May 2006 09:59:43 +1000
Luke Howard <lukeh@PADL.COM> wrote:

> 
> Mike,
> 
> >. 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.
> 
> I think the client should just send an empty buffer and not call
> gss_init_sec_context() until it has received the NegTokenInit from the
> acceptor, rather than calling gss_init_sec_context() for the initial
> token. I'm not sure whether this works with current code, but that's
> how I think it should work.
> 
> Don't forget that this MS behaviour is non-standard anyway, so there
> is little point trying to follow the spec. I believe they refer to
> this as "acceptor sends first" which supports the idea that the
> initiator should not call gss_init_sec_context() until it has
> received a token from the acceptor.

That's not what I'm saying. Consider the sequence of calls:

     SMBCMD                      CLIENT          SERVER
  1. NEGOTIATE                                ->
  2. NEGOTIATE Response                       <- NegTokenInit
  3. SESSION_SETUP_ANDX          NegTokenInit ->
  4. SESSION_SETUP_ANDX Response              <- NegTokenTarg

And their descriptions regarding specific gss_*_sec_context calls:

1. The SMB client starts by sending the negotiate (note:
   gss_init_sec_context is NOT called, there's no GSS token in an SMB
   NEGOTIATE).

2. The server then calls
   gss_init_sec_context(GSS_SPNEGO_NO_OPTIMISTIC_FLAG_X) to generate the
   list of available mechs and sends the NegTokenInit (w/o a mech token)
   to the client in the NEGOTIATE Response.

3. The client calls gss_accept_sec_context with the above token
   and provided it doesn't return GSS_S_BAD_MECH the application then
   throws away the half-baked gss_ctx_id_t (note: the output token from
   gss_accept_sec_context should be empty here).

   NOW the client initiates the actual authentication by calling
   gss_init_sec_context fresh, sends the NegTokenInit to the server and
   rest of the authenticate proceeds per normal.

This is consistent with the "acceptor sends first" because the server
is (ultimately) the acceptor - it just does a little reverse direction
preamble first.

Your point about this MS behavior being non-standard anyway is well
received. But I just think having gss_accept_sec_context generate
a NegTokenInit is very awkward. Gss_init_sec_context only takes
an empty token or a NegTokenTarg as input and it only outputs a
NegTokenInit. Gss_accept_sec_context only takes a NegTokenInit as input
and it only outputs a NegTokenTarg (or an empty token in the special
case where there's no optimistic mech token in the input token).

But I think the two techniques can coexist. I don't believe that my
change affected the logic of your code.

Mike