Subject: Misuse of the term "association" in [Protocol]

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 01 Oct 2004 08:53:50 -0700

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.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 5 Oct 2004 16:45:32 +0200

>>   operation), whether the modification completed successfully

Why the "due to..." part - doesn't the same apply to an operation
abandoned by the abandon operation?

I disagree with the change to "completed sucesssfully".  The new
language looks like the modification might be partially completed.

>>   The MessageID is that of an earlier request whose response is

Why not just s/LDAP association/LDAP exchange/ instead of these two
changes?  The new text is fine from the client's point of view, but
on the server side, the response may no longer be outstanding when
the abandon request is received.

>>   which these issues are addressed are application and/or

I'd like to see renaming or deleting an identity (or a DN) retained in
the text as at least an example.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 05 Oct 2004 08:42:24 -0700

>abandoned by the abandon operation?

Yes, but it doesn't necessarily apply to the operations
otherwise abandoned (for instance, by the cancel operation).
The original sentence was intended only to cover two cases,
re-bind and connection termination.  The other case (abandon
operation) is separately handled.  The new text does the same.

>language looks like the modification might be partially completed.

Good catch.

>changes?

No reason.

>The new text is fine from the client's point of view, but

Good catch.

>the text as at least an example.

That would be fine.  One could inject between the two sentences
something like:
        For instance, the credential information used to authenticate
        the user could become invalid or the authorization policy
        describing what the user can access could change.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 5 Oct 2004 18:19:55 +0200

> operation) is separately handled.  The new text does the same.

Do we need this sentence at all?  It is mentioned under Abandon,
Operation and LDAP Exchange Relationship etc, and it is not mentioned
in the sections for the other update operations.

The same goes for the preceding sentence:

   Due to the requirement 
   for atomicity in applying the list of modifications in the Modify 
   Request, the client may expect that no modifications of the DIT have 
   been performed if the Modify Response received indicates any sort of 
   error, and that all requested modifications have been performed if 
   the Modify Response indicates successful completion of the Modify 
   Operation.

Though it's useful to keep a reminder that the operation is atomic and
will either fail or complete successfully, since its LDAPMessage "looks
like" a series of modifications.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 05 Oct 2004 09:53:35 -0700

>in the sections for the other update operations.

I have no problem with removing this sentence.

>like" a series of modifications.

A modify request expresses a sequence of modifications which
are be applied atomically.  I think reminding developers of
this is important.