[erlang-questions] Adding StartTLS support to eldap (for use Ejabberd)

[Rory Byrne]

On Mon, Aug 06, 2012 at 09:24:53PM +0100, Gavin Henry wrote:
> 
> > I've changed the subject of this email in the hope that someone
> > from the ejabberd community might offer some advice.
> 
> Ha, naughty! I've created a new thread as it was going off a bit.

Good thinking!

> Yes, unfortunately most people that develop LDAP libs forget StartTLS and
> just go for LDAP over SSL which isn't a standard and is deprecated. StartTLS
> is a standard - http://www.rfc-editor.org/rfc/rfc4513.txt

Well, adding support for LDAP over SSL is pretty simple and we all 
know how lazy programmers are! :-) 

Both methods have their merits and they're both going to be around
a long time, so supporting both makes lots of sense.
 
> Then again, the whole point of TLS and *getting it right* is to
> validate certificates
> which a lot of libs don't offer or admins don't bother with.
 
Actually, it looks like eldap is currently hard-coded not to verify 
the server's certificate when using LDAP over SSL, so this would 
need to be updated as well.

> RFC 4513 is what needs to be read for this work and it's sponsorship, which
> also covers the SASL side too.

And probably parts of RFC 4511 too.
 
> > However, they might accept a patch that uses the OTP version of
> > eldap when it's available. Ultimately it would be more beneficial
> > for everyone if the STARTTLS and SASL functionality were added to
> > the OTP version. Certainly if I was writing a patch, I'd much
> > rather it was for the OTP version.
> 
> My company would not sponsor the Ejabberd version of eldap. What would
> be the point,
> that helps no one and would be a shortsighted piece of sponsorship on
> our part :-)
 
Actually, the more I look at the ejabberd eldap version, the more I 
get the feeling that there is no chance that they will opt to use 
the OTP version as it stands. One of the first things they did with 
the eldap code was to rewrite it be asynchronous so it can have multiple 
ongoing requests to the LDAP server at the same time. The OTP eldap,
on the other hand, is synchronous - it blocks on each request to 
the server waiting for a response. Clearly in the context of a large
multi-user XMPP server, having asynchronous communication with your
directory server is something you'd want.

I suspect there's a few other useful changes that they've made that 
they (or you) wouldn't be willing to give up. 

> If the patch is done right then I'm sure it wouldn't be too difficult
> to add initial
> support to the ejabberd eldap version at the same time, with a caveat that
> no further support will be provided and the ejabberd team would need
> to either bring
> in OTP eldap or maintain it themselves.
 
I wish this were the case. Unfortunately the two sets of code are vastly
different - at least to my eyes. I can't see how a patch for OTP eldap
would be of any use against the ejabberd version. Basically, you should
consider them two unrelated projects, at a code level that's what they
are. That said, if you wrote a patch for one of them, you'd have a good
idea of what you're doing when writing a patch for the other one.

> >> In our situation we're not using cliebt certificate based TLS with
> >> SASL EXTERNAL. But it should be added at the same time rather than an
> >> incomplete patch.
> >
> > Yeah, I reckon it's worth having.
> 
> It would certainly add excellent support for enterprises using eldap.
> Some of our OpenLDAP
> support customers will *only* use SASL EXTERNAL with X.509 certificate based
> auth.

Yeah, I can well imagine. If you're going to put the money and effort 
into a PKI, you'd be mad not to use it!

Rory