RE: Lifetime of associations

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

Comments inline

-----Original Message-----
From: Hallvard B Furuseth [mailto:h.b.furuseth@usit.uio.no]
Sent: Tuesday, 5 October 2004 01:31
To: Ramsay, Ron
Cc: ietf-ldapbis@OpenLDAP.org
Subject: RE: Lifetime of associations


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.

<RR> I'm not following this. An association can only be changed by a "bind" or an "unbind". If you send either, you don't have to worry about messageIDs because any operation response after either a bind or unbind must belong to the previous association, and no response can be received after a bind response. I guess there is a problem with the unacknowledged unbind (whose ides was that!), but it is clear that youhave to discard all responses up to the response to your first request after the unbind. There should be no sequencing problems as the server should drop all responses once it receives the unbind.

<RR> "Invalidating" an association doesn't change it. An association can only be changed with a bind or unbind.

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.

<RR> You seem to be misunderstanding "modify". I'm referring here to modify operations, not to modifying the association. I don't believe you can modify an 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].

<RR> It isn't defined. See my previous email. And it wouldn't matter if it was - it's a bad definition!

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

<RR> I'm referring to the underlying TCP/IP connection. It would appear that talk of security layers has introduced confusion. Do you want me to go over it again: First, the TCP/IP connection is established; set up security layers now, it you want; now, send LDAP PDUs. Semantically, these LDAP PDUs represent the LDAP connection, regardless of the secutity layers currently in force.

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

<RR> StrongAuthRequired surely simply means that you need to reauthenticate before performing this request? If this is so, there is no need to try to introduce a mystical "security association". If I have misunderstood, please let me know.

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

<RR> Except that clients don't, do they?

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