Re: OpenLDAP TLS server authority verification

[Daniel Pocock <daniel@pocock.com.au>]

On 03/03/12 11:45, Michael Ströder wrote:
> Daniel Pocock wrote:
>>
>> From RFC 4513, "The client determines the type (e.g., DNS name or IP
>> address) of the reference identity and performs a comparison between the
>> reference identity and each subjectAltName value of the corresponding
>> type until a match is produced" is very vague.
>>
>> My understanding of `reference identity' is that it should be a
>> statically/administratively configured value on the client host.  On the
>> other hand, a value derived/mapped from a network source (e.g. DNS SRV
>> lookup) can never be trusted as a reference identity.
> 
> Mainly this is subject of local policy regarding of what you consider to
> be a sufficiently trustable reference identity. Hence the vague language.
> 
> E.g. your local policy could be to trust your DNS either because it's
> completely within a closed LAN or because you have correctly configured
> DNSSEC in place. The latter would be just another layer of
> pre-configured trust.
> 
>> ldap[12].outsource.com:
>> - are the OpenLDAP hosts (run by an external company)
>> - both have a TLS certificate with CN=ldap[12].outsource.com, and
>> subjectAltName mycompany.com
>>
>> _ldap._tcp.mycompany.com:
>> - an SRV record pointing to ldap[12].outsource.com
>> - mycompany.com DNS is not secured (no DNSSEC)
>>
>> webserver.mycompany.com:
>> - wants to authenticate a user logging in
>> - has dc=mycompany,dc=com statically configured in some cfg file, so it
>> trusts mycompany.com as a `reference identity'
>> - discovers ldap1.outsource.com from DNS SRV lookup on mycompany.com,
>> (so the LDAP client should not consider ldap1.outsource.com as a
>> reference identity, because it is a value from DNS)
> 
> 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.  I believe it should
not be trusted unless someone overrides this administratively.

>> - 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'

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)

A hostname can be a reference identity

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

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)

This is already how things are (should be) done in SIP and XMPP, 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.