--On Saturday, August 05, 2017 3:05 PM -0400 David Hawes dhawes@gmail.com wrote:
With ITS #8568 [1], I notice that the first SASL EXTERNAL (using TLS client auth) bind on a connection succeeds, but subsequent SASL EXTERNAL binds on the same connection fail with:
slapd[31088]: conn=1009 op=3 RESULT tag=97 err=48 text=SASL(-15): mechanism too weak for this user: mech EXTERNAL is too weak
Please file an ITS for this, thanks. I would think the expected behavior for SASL/EXTERNAL is the SASL SSF matches the TLS SSF, given it's a TLS encrypted connection.
--Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Quanah Gibson-Mount wrote:
--On Saturday, August 05, 2017 3:05 PM -0400 David Hawes dhawes@gmail.com wrote:
With ITS #8568 [1], I notice that the first SASL EXTERNAL (using TLS client auth) bind on a connection succeeds, but subsequent SASL EXTERNAL binds on the same connection fail with:
slapd[31088]: conn=1009 op=3 RESULT tag=97 err=48 text=SASL(-15): mechanism too weak for this user: mech EXTERNAL is too weak
Please file an ITS for this, thanks. I would think the expected behavior for SASL/EXTERNAL is the SASL SSF matches the TLS SSF, given it's a TLS encrypted connection.
This whole SSF numbering stuff is - ummh, let's say - interesting. ;-)
If a client connects via TLS with strong cipher suite (full-featured PFS, yeah!) but uses a 512-bit RSA key in its client certificate with SASL/EXTERNAL should this be counted to have a strong SSF?
So better do not use SSF values in a fine-grained security policy.
Ciao, Michael.
openldap-technical@openldap.org
-
Michael Ströder -
Quanah Gibson-Mount