Decoding GSSAPI/SPNEGO in Ethereal

Richard Sharpe rsharpe at
Wed Aug 28 08:00:01 GMT 2002


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 

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 

Richard Sharpe, rsharpe at, rsharpe at, 
sharpe at

More information about the samba-technical mailing list