Re: OpenLDAP TLS server authority verification

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

On 03/03/12 12:46, Michael Ströder wrote:
> 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.

`derived' means a value that came from a network information services
(e.g. DNS SRV lookup), in contrast to a value explicitly configured by
the user or administrator (such as the base DN or a hostname in a
hardcoded LDAP URI)

>> I believe it should not be trusted unless someone overrides this
>> administratively.
> 
> I don't see the problem you have.

The problem is that it is useful to use services like DNS SRV for ease
of administration and fault tolerance, but DNS is not always trustworthy
by itself

As I've mentioned, this is a problem common to other protocols (e.g. SIP
and XMPP), they also use DNS SRV to facilitate federated
interconnection, whereas LDAP servers just need fault tolerance

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

`reference identity' is something to be determined by the client before
checking the cert.  The client should know what `reference identity' it
wants to validate before it even makes the TLS connection.

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

The RFC does not say that.  Neither does it state that an implementation
should support the concept.  It appears to leave the implementor some
discretion about their choice of reference identity.

One of the pre-RFC drafts insists on hostnames:
http://tools.ietf.org/html/draft-ietf-ldapext-ldapv3-tls-05#section-4.6
but it appears that they took that language out when making the RFC

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

It is already in RFC 6125:

http://tools.ietf.org/html/rfc6125#section-6.2

RFC 6125 is not referred to by the LDAP RFCs, but I do not believe they
are incompatible

Many a mini-RFC about best practice for RFC 6125 in the LDAP world would
be useful though

> The right discussion forum could be the ldap-ext and ietf-tls mailing
> lists.

My question is really about how OpenLDAP client code supports this (or
is anyone working on such things already)

>> 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.
> 
In SIP and XMPP, there are much bigger problems, like how do you verify
that an incoming call is not spam?  So TLS is used with mutual
authentication.  DNS SRV is also obligatory otherwise you could not have
federation.

Here is an RFC that is more specific to that protocol:

http://tools.ietf.org/html/rfc5922#section-5

For LDAP, the problem is not so big, it is just a problem of deciding if
a particular TLS server is trusted for a configured base DN