[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: OpenLDAP TLS server authority verification
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:
>>
>> http://tools.ietf.org/html/rfc6125#section-6.2
>
> 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_