Hello,

During some tests for nslcd[1], I found that if the SASL_SECPROPS in
/etc/ldap/ldap.conf is incompatible with the SASL_MECH, then the
library:

- open a useless TCP connection to the server
- check the mechanism and fail
- close the TCP connection

===== /etc/ldap/ldap.conf
BASE    dc=baby-gnu,dc=org
URI     ldap://192.168.122.4

SASL_MECH DIGEST-MD5
SASL_SECPROPS noactive
===== /etc/ldap/ldap.conf

===== Wireshark capture
No. Time      Source         Destination    Protocol Info
3   2.728967  192.168.122.3  192.168.122.4  TCP      51521 > ldap [SYN] Seq=0 [...]
4   2.729699  192.168.122.4  192.168.122.3  TCP      ldap > 51521 [SYN, ACK] Seq=0 [...]
5   2.729714  192.168.122.3  192.168.122.4  TCP      51521 > ldap [ACK] Seq=1 [...]
6   2.739576  192.168.122.3  192.168.122.4  TCP      51521 > ldap [FIN, ACK] Seq=1 [...]
7   2.740686  192.168.122.4  192.168.122.3  TCP      ldap > 51521 [FIN, ACK] Seq=1 [...]
8   2.740702  192.168.122.3  192.168.122.4  TCP      51521 > ldap [ACK] Seq=2 [...]
===== Wireshark capture

===== ldapsearch
ldapsearch -U dad -s base -LLL supportedSASLMechanisms
ldap_sasl_interactive_bind_s: Unknown authentication method (-6)
        additional info: SASL(-4): no mechanism available: No worthy
        mechs found
===== ldapsearch

As the problem is found in a software using the libldap, I conclude the
problem is in the lib and not in ldapsearc.

Regards.

--On Saturday, November 20, 2010 1:49 PM +0100 Daniel Dehennin 
<daniel.dehennin@baby-gnu.org> wrote:

I suggest you file this as a bug with the OpenLDAP foundation:

http://www.openldap.org/its/

--On Saturday, November 20, 2010 3:22 PM -0800 Quanah Gibson-Mount 
<quanah@zimbra.com> wrote:

I went ahead and filed <http://www.openldap.org/its/index.cgi/?findid=6728>
for you.

Isn't that to be expected?

Typically, you wouldn't 'know' that there are no worthy mechs until Cyrus
attempts to negotiate, at runtime, a common mechanism which meets both the
server and the client's SASL criteria.

the 'no worthy mechs' error is most likely coming from libsasl.

For instance, specifying a mechanism that the server does not offer (e.g.
EXTERNAL) should produce a similar error, and there's no way for
(lisasl on) the client to magically know that it should use another
mechanism, because it was told to be too picky about the SASL negotiation
by the local administrator.

The same would go for SASL_SECPROPS, e.g. setting your min_ssf to something
too high would probably produce the same error even if you didn't specify a
mechanism.

Hi Daniel, hi cyrus-sasl2 maintainers,

Currently the chosen mechanisms are validated inside sasl_client_start,
after the network connection has been opened and TLS possibly
established.

https://cgit.cyrus.foundation/cyrus-sasl/tree/lib/client.c#n794

I don't see another place where mechs can be filtered against security
flags. I'm not sure it even makes sense, since as you can see from that
code, it can depend on the current situations in some ways, for example
whether or not there is a TLS layer active. I'm not really familiar with
cyrus-sasl2, though, so I could easily have missed something.

I'm reassigning this to cyrus-sasl2 as a wishlist item for a way to
validate the client setup before opening a network connection.

Feel free to reassign back to libldap-2.4-2 if I'm wrong and there is
already a way to validate the chosen mechs/flags before calling
sasl_client_start.

thanks,
Ryan