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.
