On Thu, Aug 29, 2002 at 03:44:18AM +0930, Richard Sharpe wrote:
> After re-looking at RFC2478
...and looking at RFC 2078 as well, presumably; it's necessary in order
to fully understand what's going on.
> and looking at traces again and talking to
> Diego (:-) at IBM, it looks like the following is occurring:
>
> 1. The negProt response includes a negTokenInit with a list of OIDs for
> mechanisms that the server handles.
More precisely, at least from one capture I have, the negProt response
includes an RFC 2078 GSS-API initial token (InitialContextToken) that
specifies that the mechanism is SPNEGO (thisMech) is the OID
1.3.6.1.5.5.2, i.e. SPNEGO); the innerContextToken *inside* that
InitialContextToken is a NegTokenInit that, in turn, lists the *real*
mechanisms that the server handles ("SPNEGO" is, as RFC 2078 says, "a
pseudo-security mechanism, represented by the object identifier
iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) which
enables GSS-API peers to determine in-band whether their credentials
share common GSS-API security mechanism(s), and if so, to invoke normal
security context establishment for a selected common security
mechanism", which is "most useful for applications that are based on
GSS-API implementations which support multiple security mechanisms").
> 2. The client sends a sesssetup&X with another negTokenInit with the
> selected mechanism and a token.
Agin, from the capture I have, the Session Setup andX includes an RFC
2078 GSS-API InitialContextToken that uses SPNEGO as the mechanism, in
the innerContextToken, indicates the selected mechanism.
> 3. The server send back a sesssetup&X response with a negTokenTarg with
> appropriate things in it, however, unlike the previous negTokenInits, this
> blob is not cloaked in GSSAPI, it is raw SPNEGO!
That's a SubsequentContextToken, to use RFC 2078's terminology; that's
just an innerContextToken, which, as SPNEGO is the mechanism specified
at the GSS-API layer, is an SPNEGO NegotiationToken.
So it's not wrapped inside a GSS-API InitialContextToken, but it *does*
use GSS-API's pseudo-syntax.
> 4. There will be more negTokenTargs if the previous packet had more
> processing required set.
>
> Now, to dissect this properly in Ethereal, what I think needs to happen
> is:
>
> 1. dissect_smb_sess... should call the gss-api dissector to see if that
> works. If not, it should call SPNEGO dirrectly on the blob.
Well, that's one possibility, which would work if all SMB clients and
servers always use SPNEGO.
However, if the mechanism specified in the InitialContextToken is *not*
SPNEGO, subsequent tokens should presumably not be handed to the SPNEGO
dissector.
That requires the introduction of state; however, note that, as per
earlier mail from Devin Heitmueller, to correctly dissect NTLMSSP
messages you need to keep state around *anyway*.
Putting the knowledge of all of that into the SMB dissector would mean
that the SMB dissector could dissect all the steps of a
GSS-API-plus-SPNEGO handshake, but that *other* dissectors that handle
GSS-API, e.g., LDAP, wouldn't acquire that ability.
So I'd like to see as much of the knowledge of that as possible inside
the GSS-API dissector, as the notion of InitialContextTokens (which have
the [APPLICATION 0] IMPLICIT SEQUENCE header and the thisMech MechType
specifier, as specified by RFC 2078) and SubsequentContextTokens (which
don't have any content specified by RFC 2078) comes from the RFC 2078
GSS-API spec.
Some of the context information would, I suspect, need to be supplied by
the caller of the GSS-API dissector, so it might require some dissector
modification, but at least the dissectors wouldn't have to do *all* the
work of distinguishing between InitialContextTokens and
SubsequentContextTokens and calling the appropriate inner dissector for
the innerContextTokens (which are not necessarily going to be SPNEGO
tokens in all cases).
