Subject: Lifetime of associations

From: Hallvard B Furuseth <[email-masked]>
Date: Mon, 27 Sep 2004 17:35:19 +0200

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.

I always thought it meant (b), until I begun to notice how it is used in
[Authmeth] and realized that the definitions in [Protocol] and
[Authmeth] can be read both ways.

[Protocol] uses it in the (b) sense, e.g. "terminating the association",
and some definitions depend on this.  E.g.:

> 4.1.1.1. Message ID 

>    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.

OTOH, the language in [Authmeth] is inconsistent:

(a) is used in:

  Maybe 3.1.2 (StartTLS Response): "current association"
  (rather than "current state of the association").

  4 (LDAP Associations): "establish a new LDAP association".

  Maybe 4.1 (Anonymous LDAP Association on Unbound Connections):
  "session has an anonymous LDAP association"
  (rather than "the association is anonymous").

  Section 5 (Bind), 6 (Anonymous), 7 (Unauthenticated), 8 (Simple Auth):
  "establish a(n) <new/anonymous/authenticated> LDAP association".

  12.3 (Unauthenticated Mechanism Security Considerations):
  "anonymous LDAP association has been established".

(b) is used in:

  Maybe 3.2.2 (Client Assertion of Authorization Identity):
  "determine the authorization identity of the LDAP association".

  4.2 (Anonymous LDAP Association After Failed Bind):
  "LDAP association is moved to an <anonymous/authenticated> state".

  4.3 (Invalidated Associations):
  "The association remains invalidated until the next bind request".

  10 (SASL EXTERNAL Mechanism):
  "leaving the LDAP association in an anonymous state".

  Appendix A with subsections:
  A:   "states through which an LDAP association may pass".
  A.2: "affect the authentication and authorization state of an LDAP
       association".
  A.3: title "LDAP Association State Changes", "changes in the
       authentication and authorization state of an LDAP association".
  A.4: "affect authentication and authorization state of an LDAP
       association".

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 27 Sep 2004 13:25:06 -0700

>(b) A connection has one enduring association which Bind modifies.

Yes, that seems to be so.  Seems we should either:
        1) use (a) or (b) (but not both)
        2) use different terms for (a) and (b), e.g.,
           session v association?

Off hand, I think I prefer 1) with meaning (b) slightly
over 2), and these greatly over 1) with meaning (a).

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 30 Sep 2004 00:39:05 +0200

I wrote:
> (...)

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