I've been having issues with SASL and having the hostname canonicalized in two places, once in OpenLDAP's SASL code, and again in the SASL provider (GSSAPI) library. I'm able to disable the SASL mechanism step, but it is mandatory in current OpenLDAP code.
I found discussion from a few months ago surrounding the submittal of a patch to disable hostname canonicalization [1]. The issue appeared to be settled with discussion of a single use case where the URI references a CNAME which redirects to one of several machines in a cluster, in which case the canonicalization needs to be done to relate to the actual machine connected to. I agree that in such a situation, the canonicalization is required.
I have one of many imaginable use cases, however, where the canonicalization is strictly must *not* occur in order for proper function. Two cases that I have personally, I'm sure there are others that are similiar:
1) As an ISP service provider I may have several DNS service names that happen to be on the same server, yet I want to maintain separate identities to make the services nearly transparent to migrate to dedicated hardware in the future if the need arises. Suppose that I have directory.example.com and imap.example.com on the same box, whose hostname is lucy.example.com. I would have three A records (or one A record and two CNAMES) for the same box, but since I can only have one PTR record,
2) On my home network I wish to use OpenLDAP, but my local server is on a DSL connection and I have no control over the DNS PTR records, and as such the records are effectively meaningless to the operation of my system. I do impose the requirement of mandatory TLS (via security ssf=128) which in and of itself provides stonger server authentication than name canonicalization via reverse DNS.
A deficiency of the previously patch [1] appears to be that the option is not configurable, so I have created a related patch [2] (currently against 2.4.8, not quite HEAD) to add a runtime configuration option to select whether or not the name canonicalization should be performed. It defaults to true, the current behavior. The patch is still in progress, but has the functionality and provides an illustration of my approach. The following are known issues that will be addressed:
1) The actual hostname we successfully connected to should be used instead of blindly using ldo_defludp->lud_host
2) There is as of yet no implementation for the ldap_{set,get}_option cases for the new options. I have a stub in ldap_int_set_sasl_option, but haven't pulled in the LDAP_INT_GLOBAL_OPT reference to get access to the boolean values.
3) As a result of 2, there is not a commandline option specified.
I propose that this would be a very valuable option, especially since there are cases where name canonicalization is infeasible if not impossible, as well as the fact that combined with TLS stronger server authentication is available. To use GSSAPI with SASL, it should also be noted that the more recent Kerberos RFCs have specifically required that reverse DNS *not* be used [3]. I'm looking for comments on the viability of such a patch being included in the base software, as well as comments on the patch itself.
Thanks, Joel Johnson
[1] http://www.openldap.org/lists/openldap-devel/200710/msg00088.html [2] http://www.lixil.net/~mrjoel/contrib/openldap/sasl-canonicalization-configur... [3] RFC 4120 - "Implementations of Kerberos and protocols based on Kerberos MUST NOT use insecure DNS queries to canonicalize the hostname components of the service principal names"
Joel Johnson wrote:
- As an ISP service provider I may have several DNS service names that
happen to be on the same server, yet I want to maintain separate identities to make the services nearly transparent to migrate to dedicated hardware in the future if the need arises. Suppose that I have directory.example.com and imap.example.com on the same box, whose hostname is lucy.example.com. I would have three A records (or one A record and two CNAMES) for the same box, but since I can only have one PTR record,
First off, you don't ever want to use CNAME aliases for mail services. That's going to seriously screw you up right there. Have everything directly resolve to the same IP address. That will solve a lot of canonicalization problems.
Secondly, there's absolutely nothing in the DNS that says you can't have multiple PTR records. However, application behaviour in the face of multiple PTR records is not defined by the standard, and different applications will handle this in different ways. You need to find out how your applications handle it.
Thirdly, you could always have the same services on the same server, but with multiple IP aliases bound to the same machine. Each service could get a separate IP address, and there would be one and only one PTR record for that IP address. If/when you decide to move that service to another machine, just move the IP address and leave everything else alone.
I've worked at both large & smaller scale ISPs and these problems are well-known, and their solutions are also well-known.
- On my home network I wish to use OpenLDAP, but my local server is on a
DSL connection and I have no control over the DNS PTR records, and as such the records are effectively meaningless to the operation of my system. I do impose the requirement of mandatory TLS (via security ssf=128) which in and of itself provides stonger server authentication than name canonicalization via reverse DNS.
I've seen a lot of cases where the certificate is more screwed up than the reverse DNS. Scratching this itch might help your one particular case where you can guarantee the reverse, but this isn't likely to be of much use in the general populace where such a feature would just give them more ammo to use in blowing off their feet with their own thermo-nuclear shotgun.
I propose that this would be a very valuable option, especially since there are cases where name canonicalization is infeasible if not impossible, as well as the fact that combined with TLS stronger server authentication is available. To use GSSAPI with SASL, it should also be noted that the more recent Kerberos RFCs have specifically required that reverse DNS *not* be used [3]. I'm looking for comments on the viability of such a patch being included in the base software, as well as comments on the patch itself.
That's a good question. If it were me, I might accept the patch into the tracking system, but it wouldn't be a high priority item to fix. But then I'm not one of the core developers.
"Joel Johnson" mrjoel@lixil.net writes:
A deficiency of the previously patch [1] appears to be that the option is not configurable, so I have created a related patch [2] (currently against 2.4.8, not quite HEAD) to add a runtime configuration option to select whether or not the name canonicalization should be performed. It defaults to true, the current behavior. The patch is still in progress, but has the functionality and provides an illustration of my approach. The following are known issues that will be addressed:
For what it's worth, this approach (making canonicalization configurable and defaulting to on) is the same approach that's been taken by GSSAPI implementers. (By setting rdns = false in [libdefaults] for MIT Kerberos, for example.)
On Tue, March 4, 2008 12:44 pm, Russ Allbery wrote:
"Joel Johnson" mrjoel@lixil.net writes:
A deficiency of the previously patch [1] appears to be that the option is not configurable, so I have created a related patch [2] (currently against 2.4.8, not quite HEAD) to add a runtime configuration option to select whether or not the name canonicalization should be performed. It defaults to true, the current behavior. The patch is still in progress, but has the functionality and provides an illustration of my approach. The following are known issues that will be addressed:
For what it's worth, this approach (making canonicalization configurable and defaulting to on) is the same approach that's been taken by GSSAPI implementers. (By setting rdns = false in [libdefaults] for MIT Kerberos, for example.)
-- Russ Allbery (rra@stanford.edu) http://www.eyrie.org/~eagle/
This is precisely why I have need of the patch. I wish to use GSSAPI through SASL, but the OpenLDAP SASL behavior masks the ability to make use of the rdns=false selection from the underlying library.
Joel
Joel Johnson wrote:
I've been having issues with SASL and having the hostname canonicalized in two places, once in OpenLDAP's SASL code, and again in the SASL provider (GSSAPI) library. I'm able to disable the SASL mechanism step, but it is mandatory in current OpenLDAP code.
I found discussion from a few months ago surrounding the submittal of a patch to disable hostname canonicalization [1]. The issue appeared to be settled with discussion of a single use case where the URI references a CNAME which redirects to one of several machines in a cluster, in which case the canonicalization needs to be done to relate to the actual machine connected to. I agree that in such a situation, the canonicalization is required.
I have one of many imaginable use cases, however, where the canonicalization is strictly must *not* occur in order for proper function. Two cases that I have personally, I'm sure there are others that are similiar:
- On my home network I wish to use OpenLDAP, but my local server is on a
DSL connection and I have no control over the DNS PTR records, and as such the records are effectively meaningless to the operation of my system. I do impose the requirement of mandatory TLS (via security ssf=128) which in and of itself provides stonger server authentication than name canonicalization via reverse DNS.
On my home network I used /etc/hosts for a while, now I just run my own caching DNS and make it primary for my subnet.
I propose that this would be a very valuable option, especially since there are cases where name canonicalization is infeasible if not impossible, as well as the fact that combined with TLS stronger server authentication is available. To use GSSAPI with SASL, it should also be noted that the more recent Kerberos RFCs have specifically required that reverse DNS *not* be used [3]. I'm looking for comments on the viability of such a patch being included in the base software, as well as comments on the patch itself.
No. RFC4120 says that *insecure name services* should not be used for canonicalization. On my machines, the local /etc/hosts file is a secure name service. Likewise, my local DNS server is secure. You're focusing on the wrong part of this RFC text. Secure your name service providers.
Thanks, Joel Johnson
[1] http://www.openldap.org/lists/openldap-devel/200710/msg00088.html [2] http://www.lixil.net/~mrjoel/contrib/openldap/sasl-canonicalization-configur... [3] RFC 4120 - "Implementations of Kerberos and protocols based on Kerberos MUST NOT use insecure DNS queries to canonicalize the hostname components of the service principal names"
-
Brad Knowles -
Howard Chu -
Joel Johnson -
Russ Allbery