RE: Lifetime of associations

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

Ramsay, Ron writes:
> 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.

I think (b) is better for messageID reuse and both work for modify.

MessageID:  It's true that Bind both changes the association and makes
old message IDs available, but these are two separate effects.  Tying
messageID reuse to changed associations in the (a) sense means you need
to worry about just when the association changes at both server and
client side, and whether invalidating the association "changes" it (in
which case (a) is plain wrong).  With the (b) meaning it's much
clearer, and it's spelled out explicitly anyway.

Modify: (a) vs (b) here is just different usages of English.  "If the
association changes" with (a) would be change from one association to
another, with (b) it would be a modification to the single existing
association.

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

I'm using the term "LDAP exchange" as it is defined in [Protocol].

> This is referring to the
> persistent underlying connection.

No, the underlying connection may be speaking TLS or a SASL layer.  Bind
requests are not sent at that level.  That's why we have the term "LDAP
exchange".

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

Do you have a better wording?

>> Why have you joined 4.4.1 with A.2?

Because the quoted definition occurs in both, except that formatting
and a few introductory words differ.

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

Sentence #2 in section 4.4.1 explains its purpose:
   "This notification is intended to assist clients in distinguishing
   between an error condition and a transient network failure."

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

Yes, that makes sense.

-- 
Hallvard