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

Re: [patch] miscellaneous mechglue stuff


>. 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.

Of course, I could be completely misunderstanding the problem. Have
not had a coffee yet today!

-- Luke