Issues bringing 'new SPENGO' to MIT Kerberos 1.8 builds

Andrew Bartlett abartlet at
Tue Feb 14 20:18:34 MST 2012

On Tue, 2012-02-14 at 18:21 -0500, simo wrote:
> On Wed, 2012-02-15 at 08:27 +1100, Andrew Bartlett wrote: 
> > On Tue, 2012-02-14 at 11:56 -0500, simo wrote:
> > > On Tue, 2012-02-14 at 15:50 +1100, Andrew Bartlett wrote: 
> > > > On Tue, 2012-02-14 at 13:42 +1100, Luke Howard wrote:
> > > > > What do you need gss_krb5_export_lucid_sec_context for? Can you use GSS_C_INQ_SSPI_SESSION_KEY?
> > > > 
> > > > We used it to determine if CFX was used, and therefore that the new
> > > > (returning the mechListMic) SPENGO should be used, as we implement
> > > > SPNEGO outside GSSAPI.
> > > 
> > > I meant to ask for a while, why don't we drop our own SPENGO and simply
> > > use the one in GSSAPI ? Are there deficiencies in it ?
> > 
> > I've wondered the same thing, but sadly there are some good reasons not
> > to:
> > 
> > We would have to have a good way to push NTLMSSP and any other mech we
> > wished to introduce into GSSAPI's SPNEGO.
> Well that's just a matter of writing a mechglue module, the mechglue
> interface is relatively standard given the SPI is basically teh same as
> >   Then, once we get those in,
> > we would also need a good way to get out the PAC-equivalent and session
> > keys etc, and set up the auth context that the authentication would be
> > used.
> That would be done using gss naming extensions, I do not see major
> issues there.
> > It would also be much harder to introduce server-side async processing
> > of NTLMSSP, as the GSS APIs are not async.
> This is true, but GSS-KRB5 is synchronous as well, so having just
> NTLMSSP async doesn't really help. I think we would be better off using
> worker threads to handle GSSAPI "asynchronously" and be done with it.

Actually, it helps a lot.  On the server, GSS-KRB5 needs no network
processing, while NTLMSSP needs to refer to a DC. 

However, please do experiment.  I would love not to have two different
SPNEGO implementations in the tree, and creating a GENSEC mechglue
module would be really cool, because it would allow non-Samba GSS-API
consumers to use NTLMSSP.  

As you know, once you use GSSAPI, using it for SPNEGO rather than krb5
is trivial, and gensec_gssapi already does this.  It is just off by
default, but with the recent work (in master and pending) to use GENSEC
everywhere, swapping this in for any experiments you wish to undertake
should be a matter of two smb.conf options.

Andrew Bartlett

Andrew Bartlett                      
Authentication Developer, Samba Team 

More information about the samba-technical mailing list