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