Issues bringing 'new SPENGO' to MIT Kerberos 1.8 builds

[simo]

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.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>