Re: Is there anything in LDAP that works similar to HTTP's virtual hosting.

[Rick van Rein <rick@openfortress.nl>]

Hi Michael et al,

(John, we're sidetracking from your question, as you can probably tell.)
>> IMHO, the hostname check is immaterial (and potentially confusing, when
>> hosting multiple dc=,dc= trees)
>
> Not sure I understand "immaterial". One would have to right a spec which maps the "name"
> (here LDAP URL) used by the client to something stored in the TLS server cert.

I meant to say that the name does not have to be checked against the
certificate to establish a secure connection.  A direct result can be
obtained by simply validating through key material:

0. have a dc=,dc= name
1. form a DNS name out of it [RFC 3088]
2. if possible, map to a server hostname with DNS SRV + DNSSEC
3a. lookup the address for the server with AAAA/A (don't care about DNSSEC)
3b. lookup TLSA record for the server with TLSA + DNSSEC
4. connect to the server and start TLS
5. compare the certificate presented with the TLSA data

 * step 2 cannot be insecurely denied
 * step 3a can be caught out as invalid through TLS
 * step 3b cannot be insecurely faked
 * step 4 is not conductive to men in the middle or other fakers
 * step 5 uses information from validated DNS to validate the LDAP server

>From the certificate, we need notBefore / notAfter, plus either the
public key or the entire certificate blob in DER encoding.  The path
above validates the server without needing to look into specific
certificate attributes.  This is what I like about DANE -- it can be
applied to all uses of TLS.  Other things I don't like as much.


> I expected somebody to raise the DANE hype.

DANE isn't perfect, agreed.  In an automated-keying setting, it can add
a lot of value, IMHO.  (And since we're working towards one, this has my
interest.)

> Note that DANE requires DNSSEC to be really secure.

Not sure what you mean by "really", but yes, DNSSEC is the basis of
trust on which DANE is built.  Although it may be used in-addition-to
existing certificate infrastructure, whether this is acceptable is the
validating party's choice.

> Also someone would have to write a
> spec detailing how to map ldap:///dc=example,dc=com to DANE (DNS) name

You mean in addition to RFC 3088 in the "duplicated locally" variant?
This has an implementation in the slapd-dnssrv backend.

RFC 3088 is experimental, but sufficiently accurate I would say; and
according to the RFC Editor,

Experimental RFC + Implementation == Independent Submission.

> (just like a spec
> is needed for TLS hostname check).

That's what I think can be entirely avoided with the aforementioned
validation path.


What I'm saying is that AFAIK we have all the tools to formally validate
foreign LDAP servers, there is no need for anything to be added.


Cheers,

Rick van Rein
OpenFortress