RE: Lifetime of associations

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

As no-one has replied to this, let me say one or two things.

1. Protocol probably uses "association" in the (a) sense. This is true at least for messageID reuse and for receiving notification that a modify was successful.

2. I would have thought an "LDAP exchange" would be a single request and response (though, unlike X.500, responses are not always "single").

3. I have included some comments inline.

Ron

-----Original Message-----
From: owner-ietf-ldapbis@OpenLDAP.org
[mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of Hallvard B Furuseth
Sent: Thursday, 30 September 2004 08:39
To: ietf-ldapbis@OpenLDAP.org
Subject: Re: Lifetime of associations


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".
<RR> Yes, "association" is redundant.

> 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.
<RR> You can't use "LDAP exchange" here. This is referring to the persistent underlying connection.
 
I take it a "security association" is a TLS, SASL or other security
layer, since it is not the "authentication association".
<RR> I think "security association" in this paragraph is complete gobble-de-gook. It appears to be referring to security layers.

> 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?
<RR> Once again, "security association" does not do it for me! Why have you joined 4.4.1 with A.2? On an unrelated point, "Notice of Disconnection" seems to be a completely useless concept. If you simply close the undelying connection, this will force the client to reconnect and to offer credentials which can then be rejected.

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?
<RR> It means (a) but it is not meant to encourage changing version. The use of "LDAP association" is meant to distinguish it from the underlying connection.

> 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.
<RR> No, not invalidated. I think the author must have been thinking of losing security layers. The simpler case is where the underlying connection is lost. At the time, some people on this list got really excited about credentials becoming invalid while an (LDAP) association was valid but, really, it all went a bit too far. By the way, if the response to the modify was strongAuthRequired then this would be an LDAP error and, consequently, the modify would not have been performed.

> 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).
<RR> It means (a). Of course, my response is yada, yada, yada.

-- 
Hallvard