Wireshark-bugs: [Wireshark-bugs] [Bug 3440] Failure to dissect long SASL wrapped LDAP response

Date: Sun, 21 Jun 2009 15:14:05 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3440





--- Comment #3 from Matthieu Patou <mat@xxxxxxxxx>  2009-06-21 15:14:03 PDT ---

>As I see it, the LDAP dissector currently knows if SASL authentication >was
>used, but not if SASL integrity or confidentiality services have >negotiated
>(requested by the client). If it knew a security layer had been >negotiated,
>then it would know that any PDU was SASL, regardless of the PDU size.

I guess otherwise their is no reason for the code to be like it is ... at the
same time is it possible to negotiate SASL auth without SASL
integrity/confidentiality ... ?


>The security layer negotiation is mechanism specific and I guess we >are looking
>at GSSAPI in your case?

Yes it seems

> Would that be a sensible, solution?
The simple one (but the most likely to hit a bare sooner or latter ...) to 16MB
(well I hope not so soon to seen such LDAP message but with MS worser is always
an option !). As it correspond to 0x00 on the first byte and FF FF FF on the 3
others.

Because the real solution would be to follow this rfc for SSL 

http://www.ietf.org/rfc/rfc2830.txt

Which indicate that we should search for an special oid indicating the starttls
start (I guess this should occur before the bind ...).
But for differencing LDAP with SASL or without the ldap dissector should
receive a notification from the authentification dissector (GSSAPI) of which
attributes (security/integrity/...) have been negociated (have fun ...)

Third way might be first try a normal dissection, then an ssl and then a sasl
one (and we stop one we have a valid ldap message).



Concerning SSL, I though that there was a LDAP_AUTH_SSL flag but in fact no so
forget about my remark.


-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.