[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [patch] miscellaneous mechglue stuff
- To: firstname.lastname@example.org
- Subject: Re: [patch] miscellaneous mechglue stuff
- From: Luke Howard <lukeh@PADL.COM>
- Date: Mon, 1 May 2006 09:59:43 +1000
- Cc: email@example.com, firstname.lastname@example.org
- Organization: PADL Software Pty Ltd
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <200604300636.k3U6ashi018116@au.padl.com> <firstname.lastname@example.org> <200604301547.k3UFlGes038355@au.padl.com> <email@example.com>
- Reply-To: lukeh@PADL.COM
- Sender: firstname.lastname@example.org
- Versions: dmail (bsd44) 2.6d/makemail 2.10
>. 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!