[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: forcing encryption for external server access while allowing unencrypted localhost connections

Howard Chu wrote:

But what if I'm not accessing any object?  What if I'm just doing
a bind (e.g., using LDAP to check credentials - which happens all
the time in real-world deployments)?  If, e.g., it's a SASL bind
and the server is set with a bind_ssf, then I believe your ACLs
won't have any effect.

In that case, then it doesn't seem to matter one way or another. If the SASL bind uses independent credentials (e.g. SASL/GSSAPI or SASL/EXTERNAL) then the authentication is already encrypted. If the SASL bind uses secrets that are stored in LDAP, then the ACLs will take effect.

Sure. But suppose I have an enterprise authentication system based on, say, Netware, or on a Radius server, etc., and I need to configure LDAP to use saslauthd, and have saslauthd simply to refer credentials on to PAM, which will utilize the authentication flavor of the day (Radius or whatever).

In this case I must allow PLAIN or LOGIN SASL and then simply pass
credentials on as-is.  I.e., in this case I'd need to rely on the
security of the connection itself (e.g., whether it's over a Unix
socket, a local interface, or it's encrypted), rather than on any
inherent protections in SASL.

It's not at all far-fetched, I don't think - again, assuming I'm not

Also, I believe it would be nice for sysadmins to alter the currently
hardcoded SSF assigned ldapi connections (71).  It really should be
up to the local systems and networking people to determine what sorts
of connections (ldapi, local interfaces, etc.) get what baseline SSF
values, because it all depends on the security of the network, the
machine, of particular interfaces, routes, etc.

I think it's pretty clear what you're asking for. But it's not clear that the alternative spelled out above won't address the need.

I'm trying :-). So is Chris.


Richard Goerwitz                               richard@Goerwitz.COM
tel: 507 645 7015