Re: Lifetime of associations

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

I wrote:
> The term "association" seems to be used in two ways:
> (a) Bind destroys one association and replaces it with a new one.
> (b) A connection has one enduring association which Bind modifies.
>
> (...)
> [Protocol] uses it in the (b) sense, e.g. "terminating the
> association",

Um... no, really.  I just found one I'm sure about which is right.
Several places s/association/LDAP exchange/ would improve the document,
e.g. the ones I quoted.  (What have message IDs to do with authorization
IDs?)  I list the others below.  Some just the English word.  With a few
I don't know.

I hope it's not worth worrying about at this stage; it depends a bit on
the answer to some things it made me wonder about (also listed below).
Frankly, I'm wondering if I have gotten lost in wordings and the reply
will be that I have misunderstood practically everything:-)

The the English word "association":

> 4.5.3. Continuation References in the Search Result
>    the abandon operation described in Section 4.11 applies only to a
>    particular operation sent on an association between a client and
>    server.

This is just a wordy way to say "the LDAP exchange".

> 4.2.1. Processing of the Bind Request
>    Clients may send multiple Bind Requests on an LDAP exchange to change
>    the authentication and/or security associations or to complete a
>    multi-stage bind process. Authentication from earlier binds is
>    subsequently ignored.
 
I take it a "security association" is a TLS, SASL or other security
layer, since it is not the "authentication association".

> 4.4.1. Notice of Disconnection
> A.2 Result Codes
>    - strongAuthRequired: The server has detected that an established
>      security association between the client and server has
>      unexpectedly failed or been compromised, or that the server now
>      requires the client to authenticate using a strong(er) mechanism.

This "security association" includes both security layers and "the
association".  But it looks a little strange to me to give the same
result code for failure of both.  Shouldn't the server try to tell the
client as much as possible about what has happened?

Also, there is no requirement to close the connection when this happens.
One could just send the result code with the following outgoing
responses instead of with Notice of Disconnection.  I have no idea if
this is a real issue - i.e. if there are security protocols where this
makes sense.  But the Modify text below seems to indicate that.

> 4.2. Bind Operation
>    - version: A version number indicating the version of the protocol
>      to be used in this LDAP association.

RFC 2251 said "protocol session".  Saying "association" makes me wonder:
Is this intended to use meaning (a), saying that one may switch back and
forth between LDAPv2 and LDAPv3 during a session?

> 4.6. Modify Operation
>
>    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. If the association changes or the connection fails,
>    whether the modification occurred or not is indeterminate.

"the association changes" - i.e. is invalidated in the middle of the
modify operation?  Then strongAuthRequired does not tell the client
whether or not the modification was done.  That's not good, though the
client can check if the association was invalidated by performing a
"safe" non-Bind request and see if that gets strongAuthRequired too.
But this would be clearer if invalidated associations produced
invalidCredentials instead (see the "authmeth-12 review notes" thread).
Or the server could send Notice of Disconnection and close the
connection; that's clear enough to the client but it is not mandated in
this situation.

> 6. Security Considerations
>    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.

This is the only one which is clearly "the association", and it works
equally well with meaning (a) and (b).

-- 
Hallvard