Heimdal SPNEGO Won't Eat Negprot GSSAPI Token

Michael B Allen mba2000 at ioplex.com
Wed Oct 12 04:02:33 GMT 2005

On Wed, 12 Oct 2005 12:43:18 +1000
Andrew Bartlett <abartlet at samba.org> wrote:

> There is some work for this in the mech-glue branch of Heimdal, I
> think.  

Where's that?

> > But from reading GSSAPI C bindings v2 RFC 2744 Section 5.19:
> > 
> >     Initially, the input_token parameter should be specified either as
> >     GSS_C_NO_BUFFER, or as a pointer to a gss_buffer_desc object whose
> >     length field contains the value zero.
> > 
> > Mmm, should I just pretend I didn't hear this? What am I supposed to do
> > with the initial SPNEGO token returned in the SMB_COM_NEGOTIATE response?
> I suppose so.  

Actually I have since realized that maybe you can't feed NegTokenInit to
gss_init_sec_context. It seems the GSSAPI+SPNEGO rules are:

    gss_init_sec_context inputs NegTokenTarg and outputs NegTokenInit
  gss_accept_sec_context inputs NegTokenInit and outputs NegTokenTarg

but the initiator's first input token to gss_init_sec_context is always
empty. If this is true, then the SMB_COM_NEGOTIATE response NegTokenInit
token requires calling gss_ACCEPT_sec_context playing the role of
acceptor. Then I guess you discard the half baked security context and
start over as the initiator.

But that feels kind of odd so maybe SPNEGO just doesn't conform well
to GSSAPI over SMB and the initial NegTokenInit is meant to be handled
externally since it's just a list of available mechs.

How do you guys handle this initial token in Samba4?


More information about the samba-technical mailing list