Issues bringing 'new SPENGO' to MIT Kerberos 1.8 builds

[Andrew Bartlett]

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
> the GSSAPI API.
> 
> >   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                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org