DN->DNS mapping in draft-ietf-ldapext-locate-05.txt

["RL 'Bob' Morgan" <rlmorgan@washington.edu>]

As folks know there is an issue with draft-ietf-ldapext-locate-05.txt
regarding how DNs are mapped to DNS names before input to the SRV
lookup.  There was discussion of this at the ldapext WG meeting this
week.  Here is my point of view on this.

Section 2 of the draft says, regarding DN->DNS
mapping:

   The output domain name is initially empty.  The DN is processed in
   right-to-left order (i.e., beginning with the first RDN in the
   sequence of RDNs).  An RDN is able to be converted if it (1)
   consists of a single AttributeTypeAndValue; (2) the attribute type
   is "DC"; and (3) the attribute value is non-null.  If it can be
   converted, the attribute value is used as a domain name component
   (label).  The first such value becomes the rightmost (i.e., most
   significant) domain name component, and successive converted RDN
   values extend to the left.  If an RDN cannot be converted,
   processing stops.  If the output domain name is empty when
   processing stops, the DN cannot be converted into a domain name.

The proposal is to replace this sentence in the above paragraph:

   If an RDN cannot be converted, processing stops.

with these sentences (more or less):

   If an RDN cannot be converted, it is skipped.  Processing continues
   until all RDNs in the sequence have been processed.

which I'll call the "looser" mapping algorithm.  Obviously, it is a
small change both to the document and to any software that would do
the translation.

Claimed benefit:

Proponents of this change say that using the "looser" algorithm will
permit more flexibility in DIT design, in particular providing a
migration path for directories that currently use X.521 Annex B
(o=, c=) naming, by letting them get the benefits of DNS SRV lookup
while only changing the lower levels of their DIT.  A couple of large
directory deployers have said they would like this change to be made.

Potential problems:

(Problem 1: bidirectional mapping)  It has been said that RFC 2247 also
defines a mapping of DN to DNS name, and that this document should not
contradict it; or if it does, that 2247 must be updated to accomodate
it.

IMHO none of this argument has any merit.  Section 3 of 2247 specifies
a mapping of DNS names to DNs, and the inverse mapping *for those
converted DNs*:

   This section defines a subset of the possible distinguished name
   structures for use in representing names allocated in the Internet
   Domain Name System.  It is possible to algorithmically transform any
   Internet domain name into a distinguished name, and to convert these
   distinguished names back into the original domain names.
   <...>
   Distinguished names in which there are one or more RDNs, all
   containing only the attribute type DC, can be mapped back into domain
   names. Note that this document does not define a domain name
   equivalence for any other distinguished names.

2247 doesn't specify any particular purpose for the DNs which have
been mapped from DNS names, other than (in section 2):

  These distinguished names may be used to identify objects in an LDAP
  directory.

Even less does it say what the DNS names might be used for that are
mapped from the 100% DC DNs.  The mapping defined in the locate draft
is simply a different thing, specifically designed to support
directory location.  A particular deployment might wish to be as
bidirectional as possible, but there's no fundamental reason that I
can see that all deployments have to be.

The DN->DNS mapping currently specified in
draft-ietf-ldapext-locate-05.txt is itself *already* different from
the DN->DNS mapping implied in 2247, because it permits DNs to be
mapped that have non-DC components in their less-significant
positions.  2247 specifically "does not define a domain name
equivalence" for these names.  So if we followed the "consistency with
2247" argument we would have to exclude translation of DNs (for server
location purposes) that have *any* non-DC components, which would be
such a severe restriction in scope as to render the whole exercise of
no interest (IMHO).

So, 2247 simply doesn't apply (other than defining the DC attribute
itself).

(Problem 2: security implications)  It has been said that the looser
mapping has an additional security consideration:  A user might be
given the ability to create and name sub-objects under their directory
entry; if those objects can be named using DC attributes, the user can
then affect the name passed to the SRV lookup, hence affect the LDAP
server that gets contacted based on that DN.

This argument is also without merit as an argument against the looser
algorithm.  Firstly, this concern is also present if the stricter
algorithm is in use.  If a user entry is:

  dc=Bob, dc=People, dc=example, dc=com

then if Bob can create DC-named sub-objects he can affect the lookup
in the same way.

Secondly, this "consideration" is also a feature.  Consider:

  dc=sales, ou=Sales, dc=example, dc=com, o=Example Corp, c=us

where the ability to put the "dc=sales" at the bottom lets the Sales
directory be found via a lookup to _ldap._tcp.sales.example.com, which
may be an attractive way to delegate directory configuration to this
subgroup.  If a mechanism can have beneficial uses for legitimate
users but can be abused by malicious users, then we can't say it's a
bad thing in itself; it's simply a matter of saying that directory
managers need to manage their directories to prohibit this abuse (by,
e.g., restricting the attribute types usable in DNs created by
possibly-irresponsible users).

(An alternative would be to design a mechanism (say a particular
attribute type) that would indicate "stop processing now" to the
DN->DNS mapping process.  Does anyone think this is necessary?)

So my conclusion is that there is substantive benefit in supporting
the looser algorithm, users with large directory deployments are
asking for it in order to use the SRV location mechanism, there are no
significant arguments against it; hence we should make this change and
move on (ie, doing another WG last call on the revised doc).

 - RL "Bob"