[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Completed SASL canonicalization option patch

Joel Johnson wrote: 
Here is the completed version of the patch (against 2.4.8) I initially
brought up a week or so ago. It makes the hostname canonicalization step for
SASL optional, both via ldap.conf and commandline arguments for the client
tools. I submit it for consideration into the mainline code, as I believe it
would provide a great benefit to a number of users such as myself.


Contributions intended for integration must follow the standard guidelines.
http://www.openldap.org/devel/contributing.html

Patches posted to the -devel list are merely treated as points of discussion, nothing more.

I present the completed version after some of the comments on the initial
snapshot.  The majority of comments were, frankly, what I had expected -
"fix the DNS, that's the real problem."  I argue that such an approach is
somewhat narrow. While undoubtedly a best practice, it is not always
feasible. I'll share my thoughts and comments on some of the previous
responses. I hope to get some good feedback and reconsideration of the
knee-jerk reactions.

You already got good feedback, derived from (at least in my case) 20+ years experience developing and deploying Kerberos in the real world.

SASL authentication is not strictly dependent on hostname canonicalization
in any form. There are, however, certain common implementation schemes that
do require a canonical hostname determination in order to function properly.
This unfortunately seems to have led to an implicit edict that all DNS
configurations must be perfectly compliant in order for OpenLDAP to be able
to use SASL authentication. The emphasis is always to 'fix your DNS, then
we'll talk', rather than relaxing the overly strict requirement of the
canonicalization step - overly strict because it is *not* required from SASL
itself, only from OpenLDAP's usage of SASL.


There exist broken DNS setups for which a user/admin may not be in a
position to remedy the errors. Sorry Howard, saying "just use static
/etc/hosts files" or "run your own local authoritative DNS server" are not
very viable options. On my home server I have a dynamic IP. When I get a new
IP, the machine updates its own /etc/hosts file, and while it would be
possible to push the value to others, there are synchronization issues, not
the least of which is that the other machines are more than likely not
powered on when the update occurs.

This argument is utter nonsense. If your home server's dynamic IP address is changing, then none of your clients will know how to find it anyway, until you magically inform the clients of the server's new IP address.

Running my own DNS server works great
when within that netwok, but what about the cases where I'm at
work/school/friend/in-laws/wherever and would like to connect? Or when I
give access to external users? They certainly aren't going to be using my
DNS server as a first line source. Anyway, why should I need any of that
additional overhead when alternative, perfectly viable solutions exist.

What alternatives? From what basis have you determined that these other solutions are perfectly viable?

What benefit does the hostname canonicalization procedure provide? In a
nutshell, it is simply a method of determining the identity of the entity
with whom I'm communicating.

No. It is not a method of *determining* anything. It is a method of *specifying* the identity of the entity with which you intended to communicate.

When done using DNS it certainly has known
security issues, but aside from direct attacks is generally quite reliable
if properly configured. I believe that this is why it's not atypical to say
"fix your DNS" if something isn't working properly. But why must this be the
only option? There are at least two other cases to consider: 1) there are
cases where we may not really care one iota about server authentication, and
2) there are options other than DNS for providing, at the very least, the
same level of confidence in the identity of the peer.


As for the first case, it's not one I'm involved in nor all too familiar
with, but it certainly doesn't stretch the imagination to think of a case
where the data returned is self-validating or requires no validation.

The canonicalization is only an issue for mechanisms that provide mutual authentication. If you don't care about mutual authentication, then don't use SASL mechanisms that require it.

If you don't know anything about the requirement, then you're in no position to make any judgements about its validity.

With regard to the second case, alternative host identification, I'm
currently using TLS for this, requiring a minimal level of validation. Yes,
you can shoot yourself in the foot on this too (no self-signed certs,
minimally a cert signed by a self-signed "CA"), but it certainly provides an
option where there otherwise might not be one (as in my case).

TLS server certificate validation isn't much different here, it still requires the server certificate name to match the hostname provided by the client. Except in this case, the implementation is explicitly forbidden from canonicalizing/altering the hostname provided by the client. Either way, it requires that the client has a reliable mechanism for deriving a server's address from a provided hostname, or that the client simply uses the IP address and the IP address is provided in the server cert's subjectAltName.

RFC 4752 (SASL GSSAPI), Section 5 states:
     "When constructing the input_name_string, the client SHOULD NOT
      canonicalize the server's fully qualified domain name using an
      insecure or untrusted directory service."

I mentioned a similar quote from a less SASL-specific (more
Kerberos-specific) RFC before. The emphasis of this statement is to not use
improper directory services to perform canonicalization. However, this does
*not* imply that canonicalization must be performed, rather it states that
*if* the client decides to use it, then a trusted naming service should be
used to perform it. RFC 4422 (SASL) makes this explicit and confirms that
the canonicalization is at most optional for a client, directly stating that
"there is no requirement that the authorization identity string be
canonical" (Section 5).

The text you're referring to in RFC4422 is talking about the client's identity, not the server's.

Having said all of that, it is also noteworthy to note that canonicalization
will often be enforced server-side simply based on the authentication
configuration. In the specific case of using Kerberos, if the service
principal uses the canonical hostname, the client better be getting a ticket
using the canonical hostname as well.

"if the service principal uses the canonical hostname" - Kerberos service principals are REQUIRED to use a canonical name.

As a wrap-up, DNS has issues - some technical and some non-technical. I'm
not in anyway suggesting that a proper setup should not be pursued, if such
an option is available. But the fact of the matter is that it is not always
possible. In such situations, the OpenLDAP software should not overtly
preclude the user from using it (or indirectly require large workarounds) to
the greatest extent in any situation, even if the configuration of a certain
system is not idyllic.

It may be reasonable to turn off the canonicalization and just let the authentication fail if the client provided the wrong name. However, that's not traditionally what Kerberos-enabled software has done, because that doesn't actually improve security. Using a less-than-fully-qualified name may simply obtain a ticket for the wrong principal.

A few (or more) thoughts for consideration - Thanks,
Joel Johnson

Your thoughts appear to be based on a mistaken and incomplete understanding of the problem space.

--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP     http://www.openldap.org/project/