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

Re: OpenLDAP TLS server authority verification



Daniel Pocock wrote:
On 03/03/12 11:45, Michael Ströder wrote:
Practically the LDAP client when configured to use
ldaps://ldap1.outsource.com, ldaps://ldap2.outsource.com or
ldap://mycompany.com hopefully does

1. a validation of the server's cert against a pre-configured trusted CA
cert (chain) and

2. a hostname check looking into the validated server's certificate to
check whether the cert contains the expected hostname.

- therefore, when it connects to ldap1.outsource.com, if the TLS
certificate contains CN=ldap1.outsource.com only, it would not trust the
connection,

There's no reason why accessing ldaps://ldap1.outsource.com should not
be trusted provided check 1. was done correctly.

Not quite: ldap1.outsource.com is a derived value.

Whatever "derived" means in your context.

I believe it should not be trusted unless someone overrides this
administratively.

I don't see the problem you have.

- but when it finds the subjectAltName mycompany.com in the cert too, it
should trust the connection

Mainly the hostname check verifys whether the server's cert contains the
hostname configured at the client side - the hostname under which the
client expects to connect the right server. Whatever that is. DNS
spoofing is prevented by fully validating the server cert.

I think you need to make a distinction between `hostname' and `reference
identity'

IMO in the context of SSL/TLS over TCP you either have a fully-qualified domain name or an IP address as reference identity in the server's cert. You should clarify which other naming or address information there might be.

The text in RFC 4513 was written with the abstract term "reference identity" inspired by other possible transports.

The RFC talks about `reference identity' because hostnames are not the
best solution in every case (e.g. when using DNS SRV over insecure DNS)

Using DNS SRV is simply not specified regarding SSL/TLS. There's no way to map a naming context to a server cert despite your local security policy says your DNS is trusted by some other means.

A hostname can be a reference identity

But a reference identity is not always a hostname.  It depends on the
client configuration.

The naming context (aka search root) cannot be a reference identity in the context of SSL/TLS. Period.

Feel free to write an Internet draft updating TLS-RFCs and RFC 2782. This could specify how a naming context is compared to some information in a subjectAltName extension since there's no standard saying something about this yet. A suitable GeneralName choice would be directoryName. The right discussion forum could be the ldap-ext and ietf-tls mailing lists.

So if a client is configured without any LDAP server hostname, but the
administrator has statically configured a base DN of dc=example,dc=org,
then the client could use example.org as a reference identity (both for
SRV lookups and for inspecting certificates)

No. This is not possible without further assumptions about a possibly trusted DNS infrastructure.

This is already how things are (should be) done in SIP and XMPP,

I doubt that.

they have quite a few RFCs describing it in some detail, as a good SIP
implementation needs to check subjectAltNames against the headers in each
individual SIP message relayed to/from another host.

I'm not familiar with SIP in detail. Please point to the RFCs. I expect that SIP headers have another name/address space considered trusted because it's preconfigured in the client.

Ciao, Michael.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature