Decoding GSSAPI/SPNEGO in Ethereal

Richard Sharpe rsharpe at ns.aus.com
Wed Aug 28 08:00:01 GMT 2002


Hi,

After re-looking at RFC2478 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.

2. The client sends a sesssetup&X with another negTokenInit with the 
selected mechanism and a token.

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!

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.

2. the gssapi dissector needs some way to indicate that it could not 
dissect the data it was passed.

So, my question is: What will break if I change gss-api to return and 
indication of success or failure, or should I add an intermediate 
dissector?

Regards
-----
Richard Sharpe, rsharpe at ns.aus.com, rsharpe at samba.org, 
sharpe at ethereal.com




More information about the samba-technical mailing list