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

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Thu, 22 Mar 2001 07:45:30 -0800 (PST)

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"

---

From: David Chadwick <[email-masked]>
Date: Sat, 24 Mar 2001 23:04:53 +0000

> directory deployers have said they would like this change to be made.

Bob

Can you give us more details about how this migration path is supposed
to work. And also why creating low down dc branches is more beneficial
than creating dc branches from the root. I would like to understand how
and why they want this change in the locate ID to be made, and if there
is a sensible technical reason for choosing the method they are
proposing, rather than one that conforms to the existing locate ID.

thanks

David

-- 
*****************************************************************

David Chadwick, BSc PhD
Post: IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 161 745 8169
*NEW* Mobile: +44 77 96 44 7184 *NEW*
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Mon, 26 Mar 2001 00:47:28 -0800 (PST)

David:

> than creating dc branches from the root. I would like to understand
> how and why they want this change in the locate ID to be made, and if
> there is a sensible technical reason for choosing the method they are

Well ... because with an already-deployed directory it's (perceived as)
easier to change names of lower nodes rather than top ones.

But I have to think that the burden of proof goes the other way.  What is
the "sensible technical reason" for having the mapping the way it is in
-05?  Why is a mapping that imposes more limitations on naming better than
one that permits more options, however unsightly they may seem to some?
So far there has been a lot of hand-wringing but not a single substantive
reason that I can see.

 - RL "Bob"

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 26 Mar 2001 07:34:31 -0800

>So far there has been a lot of hand-wringing but not a single substantive

As long as folks don't start asking us to walk up the DN/DNS tree to
find their SRV records, I don't have a significant objection to the
proposal.  What?

Say you have a DN "dc=foo,dc=com,ou=domains,dc=bar,dc=net" and there
is no DNS SRV information for "foo.com.bar.net".  However, the admin
actually has all of "dc=bar,dc=net" in held by one server and doesn't
want to administrate SRV records for all DNs which contain DC values
under her context point as this change would require.

Anyways, my point here is that the mapping change is not necessarily
"more flexible" in that it hinders other uses of DCs for naming as it
requires all DCs used for naming to also be used for location.

Kurt

---

From: David Chadwick <[email-masked]>
Date: Tue, 27 Mar 2001 00:18:14 +0100

> So far there has been a lot of hand-wringing but not a single substantive

My opinion is that we cannot convert from all possible LDAP DNs to DNS
names. I think everyone agrees with that (too many attribute types). We
can only convert dc attribute types. And we have made the decision to
restrict that to single AVA RDNs, thereby forbidding dc=abd+dc=com for
example. We could convert from all possible combinations of single AVA
dc RDNs in a DN into DNS names, (e.g. dc=abc, ou=x, dc=xy, o=efg, dc=
def, dc=com, c=gb -> adc.xy.def.com) or we could convert all contiguous
dc RDNs into DNS names (in which case the last example poses a problem,
is the answer abc or xy or def.com?) or we could convert all contiguous
dc RDNs from the root (which is the current approach of Locate-05 and
would yield null in the current example) or all contiguous RDNs from the
leaf (in which case abc would be the answer), or the first contiguous
set of dc RDNs working from either the leaf or the root (giving answers
of abc and def.com respectively).

So there are many possible algorithms. Do you agree? So which is the
best?

In order to answer this we might ask why are we using dc based RDNs. The
answer is firstly to leverage the DNS name registration scheme to get
globally unique LDAP DNs. In which case, the dc based names will start
at the root of the DIT and will name the context prefix entry.
Thereafter the organisation can build its tree without using the dc
naming attribute, and can use the dc components to perform SRV lookups
(the purpose of the locate draft). Thus the sensible algorithm is to use
contiguous dc RDNs from the root (and guess what - this is what
locate.05 already says). 

Then someone suggests an alternative algorithm (yourself) which is more
flexible and when asked to justify the requirements does not have one,
other than a spurious reason that its easier to change nodes lower down
in the tree. Heck, as LDAP administrator I can create nodes anywhere in
the DIT with minimum of hassle. SO I dont buy that one.

Then someone says, my PKI CA creates subject DNs where they are all
subordinate to the name of the CA, hence I cannot change the top of the
DIT, only the leaves. But that is not true. Firstly you cannot change
any subject names without creating new certificates. So when you create
your new certificates, it already contains the CA (authority) name and
the subject name can be anything to uniquely identify the subject, so
why not use the globally unique dc based name form starting from the
root (which was one of the original drivers for dc names). Why would you
want to stick some dc based names at the end of the new subject name
thus making it unduly long? And have the CA name twice in the
certificate? It simply does not make sense to me. Instead, create a new
dc based tree for new subjects and let the old tree based on the CA name
at the top, wither and die (as it was a dumb naming scheme anyway).
Incidently, the algorithm for finding the LDAP server for these
certificates could be based on the CA (authority) name and not the
subject name, since it could be the LDAP server for the CA that we want
to find (but that is a separate issue).

David

David Chadwick, BSc PhD