http://tools.ietf.org/html/rfc4513#section-3.1.3 gives some detail about how a client should check an LDAP server's TLS certificate. The language used there is very general though.
Can anyone comment on how OpenLDAP does this, and whether it can be tweaked from the client side (e.g. through settings in /etc/ldap/ldap.conf or URI parameters) to mandate a particular policy for choosing the `reference identity'?
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. To give an example:
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) - therefore, when it connects to ldap1.outsource.com, if the TLS certificate contains CN=ldap1.outsource.com only, it would not trust the connection, - but when it finds the subjectAltName mycompany.com in the cert too, it should trust the connection
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.
- 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.
Ciao, Michael.
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.
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.
On 03/03/12 12:46, Michael Ströder wrote:
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.
`derived' means a value that came from a network information services (e.g. DNS SRV lookup), in contrast to a value explicitly configured by the user or administrator (such as the base DN or a hostname in a hardcoded LDAP URI)
I believe it should not be trusted unless someone overrides this administratively.
I don't see the problem you have.
The problem is that it is useful to use services like DNS SRV for ease of administration and fault tolerance, but DNS is not always trustworthy by itself
As I've mentioned, this is a problem common to other protocols (e.g. SIP and XMPP), they also use DNS SRV to facilitate federated interconnection, whereas LDAP servers just need fault tolerance
- 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.
`reference identity' is something to be determined by the client before checking the cert. The client should know what `reference identity' it wants to validate before it even makes the TLS connection.
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.
The RFC does not 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.
One of the pre-RFC drafts insists on hostnames: http://tools.ietf.org/html/draft-ietf-ldapext-ldapv3-tls-05#section-4.6 but it appears that they took that language out when making the RFC
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
RFC 6125 is not referred to by the LDAP RFCs, but I do not believe they are incompatible
Many a mini-RFC about best practice for RFC 6125 in the LDAP world would be useful though
The right discussion forum could be the ldap-ext and ietf-tls mailing lists.
My question is really about how OpenLDAP client code supports this (or is anyone working on such things already)
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.
In SIP and XMPP, there are much bigger problems, like how do you verify that an incoming call is not spam? So TLS is used with mutual authentication. DNS SRV is also obligatory otherwise you could not have federation.
Here is an RFC that is more specific to that protocol:
http://tools.ietf.org/html/rfc5922#section-5
For LDAP, the problem is not so big, it is just a problem of deciding if a particular TLS server is trusted for a configured base DN
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 right discussion forum could be the ldap-ext and ietf-tls mailing lists.
My question is really about how OpenLDAP client code supports this (or is anyone working on such things already)
If there are no clear rules yet OpenLDAP IMO cannot support it.
Basically we both disagree on what we consider to be sufficiently specified and secure: 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.
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.
Ciao, Michael.
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_
Daniel Pocock wrote:
http://tools.ietf.org/html/rfc4513#section-3.1.3 gives some detail about how a client should check an LDAP server's TLS certificate. The language used there is very general though.
Can anyone comment on how OpenLDAP does this, and whether it can be tweaked from the client side (e.g. through settings in /etc/ldap/ldap.conf or URI parameters) to mandate a particular policy for choosing the `reference identity'?
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. To give an example:
Sounds like you understand it fine. In practice, there are no APIs that tell us whether a DNS lookup used DNSSEC or not. IMO relying on DNS SRV records is dicy, but as long as your certificate trust chains are intact it shouldn't be an issue.
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)
- therefore, when it connects to ldap1.outsource.com, if the TLS
certificate contains CN=ldap1.outsource.com only, it would not trust the connection,
- but when it finds the subjectAltName mycompany.com in the cert too, it
should trust the connection
openldap-technical@openldap.org
-
Daniel Pocock -
Howard Chu -
Michael Ströder