[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: When to not deref aliases
I finally found a definitive statement in X.511, 8.1.2 Directory Bind
arguments: "If simple is used, it consists of a name (always the
distinguished name of an object), ... "
Since aliases are entries but not objects they are explicitly excluded from
use in the Bind.
I guess we are now all in agreement that an alias cannot be used as the DN
of a simple bind.
> -----Original Message-----
> From: Steven Legg [mailto:steven.legg@adacel.com.au]
> Sent: Sunday, January 28, 2001 10:55 PM
> To: 'Ramsay, Ron'; 'Volpers, Helmut'; 'Kurt D. Zeilenga'; 'Jim
> Sermersheim'
> Cc: ietf-ldapbis@OpenLDAP.org
> Subject: RE: When to not deref aliases
>
>
>
> 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
> > >
> >
>