[Date Prev][Date Next]
Re: Result code for invalidated associations
>>> Hallvard B Furuseth <firstname.lastname@example.org> 11/7/04 2:57:08 PM
>Jim Sermersheim writes:
>> I agree that the best course of action when credentials become
>> 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
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. 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.
>rfc2251 said Unsolicited Notifications are merely advisory, but it
>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
<snipping discussion on how libraries might get access to unsolicited
>> however, when the server chooses (for
>> whatever reason) [NOT] to do this, I think (because the now
>> credentials have changed the authorization state) the proper result
>> to return is insufficientAccessRights). This result code can be
>> for any operation requiring a certain level of authorization, is
>> typically indicative of the outcome of future (similar) operations,
>> can come and go as one's authZ state changes.
>True, but it could be confusing if the sysadmin is not aware of
>configured the server to change the users' authZ states like that.
>user complains that he has no access to an entry, the sysadmin says
>you have". Though that could be fixed simply by sending an
>> There's nothing currently in [protocol] though, that would indicate
>> the receiver of this error that the credentials have become
So, I'm not sure where to go with this thread. My feeling is that we
don't actually need to prescribe a course of action.
I do plan to _move_ this description of strongAuthRequired back up to
Notice of Disconnection:
Indicates that the server has detected that an established security
association between the client and server has unexpectedly failed or
I also plan to update the current general description of
The server requires the client to authenticate using a strong(er)