On Tue, Aug 27, 2002 at 02:46:02AM +0930, Richard Sharpe wrote:
> 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.
If you mean "the GSS-API dissector reports, for the security blob in the
Session Setup andX reply, 'Unknown header (cls=2, con=1, tag=1)'", yes,
I think that's the issue - cls=2 is ASN1_CTX for context-dependent
types, and con=1 means a constructed type, and RFC 2478 says
3.2.1. Syntax
This section specifies the syntax of the corresponding
"innerContextToken" field for the first token and subsequent
negotiation tokens. During the mechanism negociation, the
"innerContextToken" field contains the ASN.1 structure
"NegociationToken" given below, encoded using the DER encoding
conventions.
NegotiationToken ::= CHOICE {
negTokenInit [0] NegTokenInit,
negTokenTarg [1] NegTokenTarg }
and, if I remember my ASN.1 correctly (there's a non-trivial chance that
I don't), a NegTokenTarg would be a context-dependent constructed type
with a tag of 1.