On Mon, 26 Aug 2002, Guy Harris wrote:
> On Mon, Aug 26, 2002 at 03:42:00PM +0930, Richard Sharpe wrote:
> > I am pretty close to having NTLMSSP and SPNEGO fixed to dissect things
> > properly.
>
> Presumably this includes making the handling of GSS-API stuff using
> SPNEGO stateful, so that the security blob on packets *after* the first
> Session Setup andX doesn't get dissected as a GSS-API token, but gets
> dissected as, I suspect, an RFC 2478 NegotiationToken?
Well, now that you mention it, yes. In any case, GSSAPI did not seem to
handle the OID correctly (did not account for the ASN1 headers in the
stream).
In any case, there is a problem with the susequent session setup and X
request that may be resolved by the above spec.
Also, it is interesting that Win2K seems to include two identical copies
of the NTLMSSP blob in the response to the sessionsetup negotiate. At
least that is what Samba does, and it is trying to model Win2K.
> Note that if this is the generic GSS-API token dissector stuff, that is
> also used by the ONC RPC dissector, as well as both the SMB and the DCE
> RPC dissector, and I have some changes to the LDAP dissector that I'll
> be checking in to make it use that dissector as well; if you're making
> the handling stateful, that mechanism should also be made usable by
> non-SMB and non-DCE RPC dissectors.
>
> Presumably this also includes making NTLMSSP handling stateful, as I
> think Devin Heitmueller said that the dissection of the NTLMSSP blob in
> NTLMSSP_AUTH may depend on the flags from earlier NTLMSSP_NEGOTIATE or
> NTLMSSP_CHALLENGE packets. The NTLMSSP blob dissector is also used
> outside the DCE RPC code, in the HTTP dissector.
I don't expect to perturb these in any way that would break them. The
spnego dissector (which needs to be renamed) needs to understand what it
is dealing with and hand the right stuff to the NTLMSSP dissector.
Regards
-----
Richard Sharpe, rsharpe@xxxxxxxxxx, rsharpe@xxxxxxxxx,
sharpe@xxxxxxxxxxxx