Decoding GSSAPI/SPNEGO in Ethereal
rsharpe at ns.aus.com
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 ns.aus.com, rsharpe at samba.org,
sharpe at ethereal.com
More information about the samba-technical