On 03/03/12 15:17, Michael Ströder wrote:
Daniel Pocock wrote:
On 03/03/12 12:46, Michael Ströder wrote:
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.
It does not have to 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.
Yes.
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:
I can't see any language which clearly defines rules how to derive the reference identity from a LDAP naming context. Just poiting out that it is no problem with SIP is not sufficient.
Many a mini-RFC about best practice for RFC 6125 in the LDAP world would be useful though
You would have to clearly define what a client has to do to derive and check the reference identity if its configuration simply contains ldaps:///dc=example,dc=com
Frankly I don't like RFC 6125. IIRC I gave up reviewing the I-Ds when the authors insisted on adding support for wildcard certs.
The concepts proposed in RFC 6125 may not be ideal, but it does provide a stronger solution than we have now when using DNS SRV + TLS together
The current implementation of the client code uses the hostname derived from a DNS SRV lookup as a reference identity
Also, whatever is implemented, it may not please everyone: so just as you can choose whether you want TLSv1 or SSLv2 support in the client code, I think it is reasonable that an administrator should be able to choose the policy they prefer for server validation: I'm not proposing that a single solution should be imposed for everyone.
If I understood you correctly you propose that if a server's cert contains subjectAltname::dNSName:example.com this cert should be accepted for any application protocol having something like dc=example,dc=com, @example.com etc. I don't like that approach. It broadens the semantics in such a way that you cannot have distinct server certs for different services. Mainly I think that untyped GeneralName::dNSName was defined before we had several types of SRV RRs (except MX RRs) and no-one ever clearly specified its semantics.
I agree it is not perfect: however, it is stronger than what we have now.
Some sites will find that level of security is quite sufficient (just checking that the subjectAltname::dNSName = base DN). Bigger sites will want something more, as you correctly point out ...
Same problem like looking up MX RR for a domain and then connecting to the MX servers with StartTLS.
For a naming context ldaps:///dc=example,dc=com one could specify that subjectAltname MUST contain dNSName:_ldaps._tcp.example.com to at least express the connection to the SRV RR for the LDAP service. Or other approaches with other types of GeneralName.
XMPP tried using otherName, but also support dNSName like SIP, here is an example openssl.cnf fragment:
http://wiki.xmpp.org/web/XMPP_Server_Certificates
I believe adding the Extended Key Usage (EKU) extension to the certificate provides the service-specific validation that you are aiming for (e.g. to ensure that someone who has a cert for the mailserver of example.org can't set up an unauthorised LDAP server for example.org)
Here is how they do it for SIP using EKU, maybe this RFC could even be adapted as a model for LDAP:
http://tools.ietf.org/html/rfc5924#section-4
OpenSSL can generate such certs without too much trouble:
http://www.openssl.org/docs/apps/x509v3_config.html#Extended_Key_Usage_