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
- a validation of the server's cert against a pre-configured trusted CA
cert (chain) and
- 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