[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [patch] miscellaneous mechglue stuff

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