[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patch] miscellaneous mechglue stuff
- To: mba2000@ioplex.com
- Subject: Re: [patch] miscellaneous mechglue stuff
- From: Luke Howard <lukeh@PADL.COM>
- Date: Mon, 1 May 2006 09:59:43 +1000
- Cc: abartlet@samba.org, heimdal-discuss@sics.se
- Organization: PADL Software Pty Ltd
- References: <20060427183214.622555ce.mba2000@ioplex.com> <1146373560.6574.20.camel@localhost.localdomain> <20060430020334.7d36597a.mba2000@ioplex.com> <200604300636.k3U6ashi018116@au.padl.com> <20060430112905.09420489.mba2000@ioplex.com> <200604301547.k3UFlGes038355@au.padl.com> <20060430154727.0c26ee39.mba2000@ioplex.com>
- Reply-To: lukeh@PADL.COM
- Sender: owner-heimdal-discuss@sics.se
- Versions: dmail (bsd44) 2.6d/makemail 2.10
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.
Of course, I could be completely misunderstanding the problem. Have
not had a coffee yet today!
-- Luke
--