Thanks on the SPNEGO stuff

[Andrew Bartlett]

On Wed, 2004-07-07 at 15:02, Stefan (metze) Metzmacher wrote:
> Andrew Bartlett schrieb:
> > Just a quick note of thanks for your work on the SPENGO code, the new
> > work looks really good!
> > 
> > (And as much as I enjoy the authentication stuff, I'm happy to have
> > somebody else figure out exact bits on the wire ;-)
> > 
> > The tasks I see in the near future are:
> > 
> > ordered negTokenInit:
> > We need to define some way to say that Kerberos is always first in our
> > list of available mechs, etc.  Currently this works fine, as NTLMSSP is
> > our only option, but we will want to get this right in future.
> 
> yep, we need to be able to configure this, like the endpoint servers in 
> DCERPC server
> because a gensec backend is implemented, it's not said that we want to 
> offer it...

Why not ;-).  We also need to initialise each backend before sending
it's OID.  That way, if we don't have a realm, or need to get a TGT, we
can do that before we say 'I support that'.  

> I would preferr to skip the fallback to GSSAPI or raw NTLMSSP first and 
> just implemted a clean SPNEGO gensec backend.
> 
> and when we are shure we have it right we can deal with the fallback...

The fallback is nicely isolated, so I'm happy to leave it in.  As we
know we need it in the SASL and HTTP case anyway...

> I think the problem why the spengo/ntlmssp over cifs doesn't work is 
> caused by the diffs between ntlmssp.c in 3.0 and 4.0,
> 3.0 use other NTLMSSP nego flags...

I doubt it.  I would believe that if Kerberos worked, but NTLMSSP
didn't, so perhaps it's a good reason to get Kerberos going.

> > Server negTokenInit:
> > We need the server-side negTokenInit, but that should not be hard.
> yep, but first we should get the client working

:-)

> > Kerberos:
> > There have been a lot of changes in the Samba3 Kerberos code, and we
> > need to merge these in.
> yep
> 
> > Async:
> > We need to make this code async, particularly for the server.  See the
> > NTLMSSP code for how I sort of expected it to be split.  GENSEC needs to
> > have some way to deal with all this (where we 'return' then the layer
> > that 'waited' calls a continuation function.
> yep, on linux futex's can create a filedescriptor which we can use in the
> main event loop in the select()...but that's not portable:-(

I don't think triggering the event is the problem - the problem is
getting back to the right place in the call stack, with the right
state.  It is here that I understand why people like threads...

Andrew Bartlett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20040707/b1fbf8b2/attachment.bin