RE: When to not deref aliases

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

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