On Mon, 2006-05-01 at 09:59 +1000, Luke Howard wrote: > Mike, > > >. I think the "correct" behavior would be to do gss_init_sec_context to > >. get the mechList (provided you could somehow suppress the mechToken) > >. and then just discard the half-baked security context. Now the client > >. sends a NegTokenInit which is used with gss_accept_sec_context. > > I think the client should just send an empty buffer and not call > gss_init_sec_context() until it has received the NegTokenInit from the > acceptor, rather than calling gss_init_sec_context() for the initial > token. I'm not sure whether this works with current code, but that's > how I think it should work. > > Don't forget that this MS behaviour is non-standard anyway, so there > is little point trying to follow the spec. I believe they refer to > this as "acceptor sends first" which supports the idea that the > initiator should not call gss_init_sec_context() until it has > received a token from the acceptor. > > Note that just because the server sends a NegTokenInit does not mean > that it is the initiator. This is exactly how Samba4 deals with the issue. The only time we throw away a security context is when we prepare the negprot reply, because it is impractical to keep the security context for the multiple possible session setups that may use it. For LDAP et al, we just use one context. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net
This is a digitally signed message part