[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Misuse of the term "association" in [Protocol]
I believe it is best to removing use of the term "LDAP association"
(and, hence, its definition) from [Protocol] as [Protocol]'s use
of it is not consistent with how that term is used in [AuthMeth]
discussion of authentication, authorization, and other security
factors.
As Hallvard noted, in most cases, the term "LDAP exchange" should
have been used where the term "LDAP association" was used. In other
cases, the term "association" (where used to refer to a LDAP
association) can simply be avoided in [Protocol] or is used in
a manner which appears to clear.
I have reviewed each occurrence of the word "association" in
[Protocol] technical specification and believe the following
changes should be made:
The section 2 text:
> The term "association" refers to the association of the LDAP exchange
> and its current authentication and authorization state.
should be removed.
The 4.1.1.1 text:
> The message ID of a request MUST have a non-zero value different from
> the values of any other uncompleted requests in the LDAP association
> of which this message is a part.
should read:
> The message ID of a request MUST have a non-zero value different from
> the values of any other uncompleted requests in the LDAP exchange.
The 4.1.1.1 text:
> A client MUST NOT send a request with the same message ID as an
> earlier request on the same LDAP association unless it can be
> determined that the server is no longer servicing the earlier request
> (e.g. after the final response is received, or a subsequent bind
> completes).
should read:
> A client MUST NOT send a request with the same message ID as an
> earlier request in the LDAP exchange unless it can be
> determined that the server is no longer servicing the earlier request
> (e.g. after the final response is received, or a subsequent bind
> completes).
The 4.2 text:
>version: A version number indicating the version of the protocol
> to be used in this LDAP association.
should read:
>version: A number indicating the version of the protocol
>to be used.
The 4.3 text:
> The function of the Unbind Operation is to terminate an LDAP
> association and close the connection.
should read:
> The function of the Unbind Operation is to terminate an LDAP
> exchange and close the connection.
The 4.3 text:
> The Unbind Operation has no response defined. Upon transmission of
> the UnbindRequest, each protocol peer is to consider the LDAP
> association terminated, MUST cease transmission of messages to the
> other peer, and MUST close the connection.
should read:
> The Unbind Operation has no response defined. Upon transmission of
> the UnbindRequest, each protocol peer is to consider the LDAP
> exchange terminated, MUST cease transmission of messages to the
> other peer, and MUST close the connection.
The 4.4.1. text:
> Upon transmission of the Notice of Disconnection, the server is to
> consider the LDAP association terminated, MUST cease transmission of
> messages to the client, and MUST close the connection.
should read:
> Upon transmission of the Notice of Disconnection, the server is to
> consider the LDAP exchange terminated, MUST cease transmission of
> messages to the client, and MUST close the connection.
The 4.5.3 text:
> In order to complete the search, the client issues a new search
> operation for each SearchResultReference that is returned. Note that
> the abandon operation described in Section 4.11 applies only to a
> particular operation sent on an association between a client and
> server. The client must abandon subsequent search operations it
> wishes to individually.
should read:
> In order to complete the search, the client issues a new search
> operation for each SearchResultReference that is returned. Note that
> the abandon operation described in Section 4.11 applies only to a
> particular operation sent on the LDAP exchange between a client and
> server. The client must abandon subsequent search operations it
> wishes to individually.
The 4.6 text:
> If the association changes or the connection fails,
> whether the modification occurred or not is indeterminate.
should read:
> If the LDAP exchange is terminated, or the Modify operation
> is abandoned due to subsequent operation which requires all
> outstanding operations to be abandoned (e.g., the Bind
> operation), whether the modification completed successfully
> or not is indeterminate.
The section 4.11 text:
> The function of the Abandon Operation is to allow a client to request
> that the server abandon an uncompleted operation.
should read:
> The function of the Abandon Operation is to allow a client to request
> that the server abandon an uncompleted operation previously requested
> in the LDAP exchange.
(The above clarification facilitates the below change.)
The section 4.11 text:
> The MessageID is that of an operation which was requested earlier in
> this LDAP association.
should read:
> The MessageID is that of an earlier request whose response is
> outstanding.
The section 6 text:
> Server implementors should plan for the possibility of an identity in
> and association being deleted, renamed, or modified, and take
> appropriate actions to prevent insecure side effects. Likewise,
> server implementors should plan for the possibility of an associated
> identity's credentials becoming invalid, or an identity's privileges
> being changed. The ways in which these issues are addressed are
> application and/or implementation specific.
should read:
> Server implementors should plan for the possibility of that
> information used to establish security factors may change
> (due to protocol or external events) during the course of
> the LDAP exchange, and even during the performance of a
> particular operation, and should take steps to avoid
> insecure side effects of these changes. The ways in
> which these issues are addressed are application and/or
> implementation specific.