Re: Result code for invalidated associations

["Jim Sermersheim" <jimse@novell.com>]

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

<snipping discussion on how libraries might get access to unsolicited
notifications>

>> however, when the server chooses (for
>> whatever reason) [NOT] to do this, I think (because the now
invalidated
>> credentials have changed the authorization state) the proper result
code
>> to return is insufficientAccessRights). This result code can be
returned
>> for any operation requiring a certain level of authorization, is
>> typically indicative of the outcome of future (similar) operations,
but
>> can come and go as one's authZ state changes.
>
>True, but it could be confusing if the sysadmin is not aware of
having
>configured the server to change the users' authZ states like that.
The
>user complains that he has no access to an entry, the sysadmin says
"yes
>you have". Though that could be fixed simply by sending an
informative
>diagnosticMessage.

Right.

>> There's nothing currently in [protocol] though, that would indicate
to
>> the receiver of this error that the credentials have become
invalid.
>
>-- 
>Hallvard

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

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

Feedback appreciated.

Jim