https://bugs.openldap.org/show_bug.cgi?id=10065
--- Comment #9 from Ondřej Kuzník <[email protected]> --- On Mon, Jun 12, 2023 at 01:01:25AM +0000, [email protected] 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, -- You are receiving this mail because: You are on the CC list for the issue.
