Subject: Re: Result code for invalidated associations

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 09 Nov 2004 14:29:57 -0700

>>> Hallvard B Furuseth <[email-masked]> 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

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 9 Nov 2004 23:00:32 +0100

Jim Sermersheim writes:
>>> invalid is Notice of Disconnection,
>>
> was unclear that any current implementations took any steps.

Good point.

> I guess

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

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

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

> The server requires the client to authenticate using a strong(er)

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

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 09 Nov 2004 17:30:52 -0500

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

I suggest:
        The server requires strong(er) authentication in order to
        perform the operation.

Kurt