RE: When to not deref aliases

["Steven Legg" <steven.legg@adacel.com.au>]

Ron,

> -----Original Message-----
> From: owner-ietf-ldapbis@OpenLDAP.org
> [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Ramsay, Ron
> Sent: Monday, 29 January 2001 13:05
> To: Volpers, Helmut; Kurt D. Zeilenga; Jim Sermersheim
> Cc: ietf-ldapbis@OpenLDAP.org
> Subject: RE: When to not deref aliases
>
>
> Helmut,
>
> Huh?
>
> The note in Section 9.2 of X.501 actually says:
>
> Note - The set of names of an object thus comprises the set
> of alias names
> for the object, together with the distinguished name of the object.
>
> The difference between this and what you wrote is that
> 'distinguished name'
> is singular. (I don't understand why you went on about
> attribute values - I
> think it is missing the point.)

Helmut was quoting from the 1997 or 2000 edition of X.501, which uses
the plural, "distinguished names", because of the introduction of
contexts on attribute values. An entry is permitted to have more than
one RDN, where the different RDNs are differentiated by the contexts
on the distinguished values. Consequently, an entry can have multiple
distinguished names in the absence of any alias entries.

>
> The definitions in 9.1 do not describe different 'things' but
> are different
> descriptions of the same thing. For example, distinguished
> name is defined
> syntactically in terms os RDNs. Semantically, a directory
> name is a name
> that denotes an object. The fact that there may be many
> directory names for
> an object is due to the presence of aliases, not the
> mumbo-jumbo about the
> true significance of an attribute value. An alias name is 'an
> alternative
> name for an object'. (It is curious the the punctuation seems
> to be American
> but the dictionary seems to be English!) The 'purported name' is any
> distinguished name which purports to be (or pretends to be,
> or appears to
> be) a valid name for the operation (here, bind).

I agree with Helmut. The editor(s) of X.501:2000 appear to have been
consistent in their use of terminology for names. I think it is clear
that an alias name for an entry is not a distinguished name,
though it is a name, a directory name and an RDNSequence.
The third note in clause 9.7 of X.501:2000 is particularly telling:

"NOTE 3 - Because only the object entry and its superiors are involved,
distinguished names of objects can never involve alias names."

The immediately following sentence is: "Alias entries also have
distinguished
names; however, this name cannot be the distinguished name of an object."

>
> Anyway, so much for the semantics. Thomas and I are waiting
> for you to point
> to the line in any X.500 standard that says aliases may not be used in
> binds. I think you can't do it.

The name in a SimpleCredentials in a BindArgument (X.511:2000) is explicitly
a distinguished name, not a name or a directory name, so alias names
are excluded by clause 9 of X.501:2000.

The name in Read, List, Compare or Search is not explicitly a distinguished
name, it's an RDNSequence, and the descriptions cover the possibility that
the name is an alias name.

That seems like a clear and deliberate distinction to me.

Regards,
Steven

>
> Ron.
>
> -----Original Message-----
> From: Volpers, Helmut [mailto:helmut.volpers@icn.siemens.de]
> Sent: Friday, 26 January 2001 20:10
> To: Ramsay, Ron; Kurt D. Zeilenga; Jim Sermersheim
> Cc: ietf-ldapbis@OpenLDAP.org
> Subject: RE: When to not deref aliases
>
>
>
>
> > -----Original Message-----
> > From: Ramsay, Ron [mailto:Ron.Ramsay@ca.com]
> > Sent: Donnerstag, 25. Januar 2001 02:11
> > To: Kurt D. Zeilenga; Jim Sermersheim
> > Cc: ietf-ldapbis@OpenLDAP.org
> > Subject: RE: When to not deref aliases
> >
> >
> > Regarding your last statement, I don't regard it as a
> > specification error in
> > X.509. (It is actually an authentication issue, not a
> protocol issue.)
>
> Why a specification error ?
>
> This section in X.509 describes on an abstract level how one user A
> authenticates himself to another user B and how they may use
> the Directory
> Service in doing so. It does not describe the procedure that
> has to be run
> within the DSA when a User wants to authenticate.
>
> But even this procedure describes that "the distinguished
> name" of a user
> is treated. What this means is described in X.501 9.1 and 9.2.
> "Distinguished name", "alias name" and "directory name" are clearly
> defined to mean different things. There may be several "distinguished
> names" of an object, but they differ only in contexts of
> attribute values
> involved, not really in the attribute values themselves. The
> NOTE in 9.2
> makes it quite clear: "The set of names of an object thus
> comprises the
> set of alias names for the object, together with the
> distinguished names
> of the object.
>
> X.509 6 2) speaks of "the purported distinguished name" of a
> user. This
> cannot be an alias name. The description for other operations in X.511
> explicitly speak of "Names", that might be dereferenced if
> they involve
> aliases. Of course a compare operation may be used by user B to
> authenticate user A, but as he has nothing but the
> distinguished name of
> A, this compare operation cannot dereference aliases at this place.
>
> Helmut
> >
> > However, if you could get the X.500 specs amended, I agree
> > that the LDAP
> > statement could be strengthened. Are you able to present it
> > to the X.500 WG?
> >
> > In the meantime, I don't think we should hold our breath and
> > SHOULD NOT
> > seems a workable solution.
> >
> > Ron.
> >
> > -----Original Message-----
> > From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
> > Sent: Thursday, 25 January 2001 6:08
> > To: Jim Sermersheim
> > Cc: Ramsay, Ron; ietf-ldapbis@OpenLDAP.org
> > Subject: RE: When to not deref aliases
> >
> >
> > At 11:36 AM 1/24/01 -0700, Jim Sermersheim wrote:
> > >Regarding bind, you're right. Concensus seems to be SHOULD
> > NOT (premature
> > post on my part). Though I don't believe there has been as
> > much discussion
> > regarding compare, most of the arguments are the same. I'll
> > tentatively
> > amend.
> > >
> > >Regarding the use of the SHOULD NOT imperative; it would be
> > useful to add
> > text explaining "why not". Kurt, you  mentioned security
> > issues, what are
> > they--and do they apply to the compare operation? I don't
> > like adding SHOULD
> > NOT just because we think something is wrong but we don't
> > want to break
> > existing implementations.
> >
> > Without the statement the specification can be interpreted multiple
> > ways, this leads to interoperability problems.  The SHOULD NOT
> > clarifies what the intended behavior is while not disallowing
> > implementations which have implemented some other behavior.
> >
> > I do not believe it necessary to state in the actual specification
> > why a particular imperative exists is general.  Of course, key
> > interoperability issues and security considerations should be
> > discussed within the specification.
> >
> > The primary security issues related to aliases and authentication,
> > authorization, and access control is related to use of alternative
> > names and under specification of semantics (especially in error
> > cases).
> >
> > I actually believe X.511 nor LDAP did not intend aliases to be
> > dereferenced during bind operations.  I view this as a specification
> > error which should be corrected in both X.511 and LDAP.
> >
> > Kurt
> >
> >
> > >Or am I alone in thinking phrases like: "In order to work
> > with existing
> > implementations, the server SHOULD NOT do xyz." makes for
> > sloppy protocol?
> > >
> > >Jim
> > >
> > >
> > >>>> "Ramsay, Ron" <Ron.Ramsay@ca.com> 1/23/01 9:30:29 PM >>>
> > >Jim,
> > >
> > >I thought the consensus on the bind was that servers SHOULD
> > NOT dereference
> > >aliases. You have changed this to MUST NOT.
> > >
> > >There was agreement that there was no way to indicate
> whether compare
> > should
> > >dereference aliases. I think this should be a SHOULD NOT in
> > that you are
> > >trying to make implementations nonconformant retroactively.
> > That is, you
> > are
> > >changing the spec, not clarifying it.
> > >
> > >ModDN is different because dereferencing was not the default
> > for updates in
> > >X.500. In that LDAP deferred to X.500 where there was no
> > policy, I believe
> > >that MUST is inappropriate for either bind or compare.
> > >
> > >Ron.
> > >
> > >-----Original Message-----
> > >From: Jim Sermersheim [mailto:JIMSE@novell.com]
> > >Sent: Wednesday, 24 January 2001 5:43
> > >To: ietf-ldapbis@OpenLDAP.org
> > >Subject: RE: When to not deref aliases
> > >
> > >
> > >I believe some semblance of consensus has been reached on
> this issue.
> > >
> > >- There is some agreement that BindRequest.name is not
> dereferenced.
> > >Compelling arguments include existing behavior among
> > implementations, and
> > >the lack of a mechanism to specify alias dereferencing behavior.
> > >
> > >- There is strong agreement that ModifyDNRequest.entry is
> > not dereferenced.
> > >
> > >- There is semi-strong agreement that CompareRequest.entry is not
> > >dereferenced. The arguments are the same as those for bind.
> > >
> > >Unless there are enough objections to outweigh current
> > agreements, I'll
> > make
> > >the following changes:
> > >
> > >4.2 <info added as last sentence of name description>
> > ><-      name: The name of the directory object that the
> > client wishes to
> > >bind as. This field may take on a null value (a zero length
> > string) for the
> > >purposes of anonymous binds, when authentication has been
> > performed at a
> > >lower layer, or when using SASL credentials with a mechanism
> > that includes
> > >the LDAPDN in the credentials.
> > >>-      name: The name of the directory object that the
> > client wishes to
> > >bind as. This field may take on a null value (a zero length
> > string) for the
> > >purposes of anonymous binds, when authentication has been
> > performed at a
> > >lower layer, or when using SASL credentials with a mechanism
> > that includes
> > >the LDAPDN in the credentials. Note that the server will not
> > perform any
> > >alias dereferencing in determining the object to bind as.
> > >
> > >4.9 <info added as last sentence of entry description>
> > ><-      entry: the Distinguished Name of the entry to be
> > changed. This
> > entry
> > >may or may not have subordinate entries.
> > >>-      entry: the Distinguished Name of the entry to be
> > changed. This
> > entry
> > >may or may not have subordinate entries. Note that the
> > server will not
> > >dereference any aliases in locating the entry to be changed.
> > >
> > >4.10 <info added as last sentence of entry description>
> > ><-      entry: the name of the entry to be compared with.
> > >>-      entry: the name of the entry to be compared with.
> > Note that the
> > >server will not dereference any aliases in locating the entry to be
> > compared
> > >with.
> > >
> > >Jim
> >
>