Subject: RE: When to not deref aliases

From: "Ramsay, Ron" <[email-masked]>
Date: Wed, 17 Jan 2001 12:39:19 +1100

I believe that dereferencing is the default for X.500. I say this because I
believe the option dontDereferenceAliases was added to allow management of
the alias entry itself. If the default were never to dereference, I would
have expected the option to be dereferenceAliases.

As regards the bind, we always dereference aliases. You gain the ability to
allow multiple logins (for access control) for the one user, though we
haven't used this feature in practice.

If you don't take the default as being dereference, it seems you are saying
that alias entries are second-class entries.

Just my thoughts.

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Wednesday, 17 January 2001 4:02
To: Jim Sermersheim
Cc: Ramsay, Ron; [email-masked]
Subject: RE: When to not deref aliases

At 09:02 AM 1/16/01 -0700, Jim Sermersheim wrote:
>I don't think it's it's implied across the board.
>It's explicit for some operations.

Which is why I believe dereferencing is disallowed otherwise...

However, I agree that both interpretations are reasonable and
we need to got down to one interpretation.

When choosing one over the other, besides looking at the
technical merits of each, we should consider which interpretations
have been implemented and demonstrated interoperability.

In this case, I believe that aliases should not be dereferenced
in absence of a operation field (or control) specify the behavior
is a reasonable interpretation, a sound technical approach, is
widely implemented, and has demonstrated interoperability.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 16 Jan 2001 19:43:00 -0800

At 12:39 PM 1/17/01 +1100, Ramsay, Ron wrote:
>I believe that dereferencing is the default for X.500.

>I say this because I
>the alias entry itself.

I believe it the option was added when support for deferencing
alias in update operations was added (in the 2nd edition).  Note
that the option was not added to bind, hence I don't believe
aliases are to be dereferenced during bind operations.

>If the default were never to dereference, I would

Additional alias functionality was added to the second addition,
along with statements noting were the behavior could not be
expected by older DSAs.  Note that the bind operation, unlike
update operations, does not contain such a note.

>As regards the bind, we always dereference aliases.

Do you dereference aliases for add, compare, modify, moddn, or delete?
For bind, if you have an alias problem or dereferencing problem,
what result code do you return?

>You gain the ability to

You also incur numerous security risks.  I note that if the
consensus is to allow/require bind to dereference aliases, the
security considerations would have to be documented.

>that alias entries are second-class entries.

I thought they were.  :-)  They certainly were in LDAPv2 and
the first edition of X.500.

Note that X.511(93) says:
  If simple is used, it consists of a name (always the distinguished name of an object),
  an optional validity, and an optional password.

IMO, X.511 nor LDAP allows binding to an alias name.

Kurt