Re: Result code for invalidated associations

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

Jim Sermersheim writes:
>>>>Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 11/7/04 2:57:08 PM
>>Jim Sermersheim writes:
>>
>>> I agree that the best course of action when credentials become
>>> invalid is Notice of Disconnection,
>>
>> I'm concerned that clients may not report such notices to the user.
>> How common is it to implement Notice of Disconnection on the client
>> side?
> 
> How common is it for servers to do _anything_ when credentials become
> invalid during the course of an LDAP client/server exchange? This was
> only recently added as a security consideration, and at that time, it
> was unclear that any current implementations took any steps.

Good point.

> I guess
> what I'm saying is that as people begin to pay attention to this, both
> client and server implementations may have to change.

That clients have to change doesn't necessarily mean that they do it...
Not sure how much weight to give that, though.


>> rfc2251 said Unsolicited Notifications are merely advisory, but it
>> also said this about Notice of Disconnection:
>>   After receiving this notice, the client MUST NOT transmit any
>>   further on the connection, and may abruptly close the connection.
>> It has been removed from [protocol] - do we need to reinstate that
>> clients SHOULD or MUST notice a Notice of Disconnection?
> 
> The server is required to cease transmission, and to close the
> connection, so I'm not sure we need to require the client to do the
> same.

I mean require clients to notice the Notice (and take some action like
informing the user), not require them to close the connection.


> I also plan to update the current general description of
> strongAuthRequired to:
> The server requires the client to authenticate using a strong(er)
> mechanism.

...in order to perform the current LDAP operation?

-- 
Hallvard