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