https://bugs.openldap.org/show_bug.cgi?id=10065
--- Comment #9 from Ondřej Kuzník ondra@mistotebe.net --- On Mon, Jun 12, 2023 at 01:01:25AM +0000, openldap-its@openldap.org wrote:
I have really only spoken about what slapd puts into it's "supportedSASLMechanisms" attribute. If the client is preconfigured to use a particular mechanism, it would probably not query the supportedSASLMechanisms value. If the client requests "EXTERNAL" without checking it's availability, authentication should still succeed - provided slapd has constructed an authid.
Hi Sean, I think you're overcomplicating things. Trying to have clients that ignore the rootDSE isn't going to land well when it's possible to do things according to the protocol.
The relevant capabilities exist in the PROXY protocol already and somehow I can't see any reference to that in your analysis. Together with a wall of unnecessary text that is in part inflammatory that you just lob at the ticket, this didn't help[0].
Be straight to the point and sure, attach/reference things for people that want to read them if you think it's helpful but I'd always appreciate a TL;DR in that case.
But this interaction is still mediated by Cyrus-sasl. Indeed, it is SASL that defined the semantics of "EXTERNAL", it would be hard completely remove it. I suppose if the ONLY mechanisms supported were PLAIN and EXTERNAL, you could create a trivial SASL implementation and do without Cyrus-sasl. That might be a good way to reduce the attack surface, but a better way would be to put the TLS layer into a separate process. Back to idea of using an external proxy.
Even without a libsasl, EXTERNAL mechanism implementation is available in slapd. PLAIN isn't and won't as it requires decoding the SASL payload and a state machine.
You are welcome to implement relevant bits of the PROXY protocol to inject the reported authid/session existence into the connection when provided and post it for review. It might not be the easiest part of slapd to get started in but should be doable given you've looked into it already.
[0]. For one, the whole first paragraph painting ACLs as insecure while ignoring the fact that everything that you propose should be achievable with an ldaps:// listener that requires a client certificate to be provided at the time of TLS negotiation. That way it is the same gatekeeper to ACL machinery as your proxy would. That's not hard to audit, test or maintain, leaving ACLs to implement any remaining policy that would be there regardless.
Regards,