Subject: RE: Unbind (Was: Lifetime of associations)

From: "Ramsay, Ron" <[email-masked]>
Date: Tue, 5 Oct 2004 13:57:57 +1000

Kurt,

No, I wasn't. Nor would I.

What I was thinking was that, an unbind can be sent at any time. It is possible that responses would have been sent by the server before it received the unbind request, so that the client could possibly receive (in a sense, legally) responses after sending an unbind. This comes down to the fact that the unbind is not acknowledged (yuck!).

I thought that, in a response to Hallvard, I would have to dot my i's and cross my t's :-)

Ron

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[email-masked]]
Sent: Tuesday, 5 October 2004 12:01
To: Ramsay, Ron
Cc: Hallvard B Furuseth; [email-masked]
Subject: Unbind (Was: Lifetime of associations)

Ron,

In a couple of recent posts you implied it was okay for
LDAP PDUs to be transmit by the client after sending an
Unbind request and by the server after performing
an Unbind operation.  Such behavior is prohibited in
[Protocol] (as it was in RFC 2251).

Kurt

At 06:43 PM 10/4/2004, Ramsay, Ron wrote:
>Comments inline
>
>-----Original Message-----
>From: Hallvard B Furuseth [mailto:[email-masked]]
>Sent: Tuesday, 5 October 2004 01:31
>To: Ramsay, Ron
>Cc: [email-masked]
>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