Subject: Re: Result code for invalidated associations

From: "Jim Sermersheim" <[email-masked]>
Date: Sun, 07 Nov 2004 09:46:31 -0700

I agree that the best course of action when credentials become invalid
is Notice of Disconnection, however, when the server chooses (for
whatever reason) 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.
 
There's nothing currently in [protocol] though, that would indicate to
the receiver of this error that the credentials have become invalid.

>>> "Kurt D. Zeilenga" <[email-masked]> 10/31/04 10:03:29 PM >>>
At 09:27 AM 10/31/2004, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>
>> It's my view that result codes are only indicative of
>> why the server was unwilling or unable to successfully
>> complete the requested operation. The result codes
>> are not indicative of the outcome of subsequently
>> requested operations.
>
>Well, the entire point of invalidated associations is that they do
>indicate to the client that future operations may fail unless it
takes
>appropriate action. Though if we could find some result code to use
for
>this, the definition of what the result code means to the client need
>not be a promise that future operation will fail, only advice that it
>cannot expect them to succeed (until it fixes the association), and
that
>it might need to check the current TLS and SASL layer state in case
the
>server invalidated the association due to e.g. a TLS cipher
>renegotiation.

Right, one could define some new result code which could be
indicative of the outcome of subsequent operations. Or
one could add controls (e.g., password policy controls), or
unsolicited notifications. But we cannot redefine existing
codes, nor can we (as part of the LDAPBIS work) add new codes.

>> One could return Notice of Disconnect with either an
>> strong[er]AuthRequired or invalidCredentials to indicate
>> the credentials are no longer considered valid.
>
>If you mean to close the connection afterwards, it seems a bit like
>surrender but maybe it is the cleanest solution (when it is not
handled
>by some extension).

Trying to continue after unexpected failures/compromises takes
special care. Termination is simple and often the best.

>If you mean to not close the connection,

I mean close the connection.

---

From: "Jim Sermersheim" <[email-masked]>
Date: Sun, 07 Nov 2004 11:44:55 -0700

I meant "when the server chooses NOT to do this".

>>> "Jim Sermersheim" <[email-masked]> 11/7/04 11:46:31 AM >>>

takes
for
that
the

handled

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sun, 7 Nov 2004 20:57:08 +0100

Jim Sermersheim writes:

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

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?

One unfortunate point is that there seems to be no 'natural' way for an
LDAP library to handle Notice of Disconnection without the client
explicitly asking for it.  So the client may instead have to handle the
"connection lost" error specially and explicitly ask about Notice of
Disconnection.  There will probably always be plenty of clients which
don't bother.

(I see several problems for the library, though I may be messing things
up a bit because I don't remember how TCP handles lost connections:

If the library gets "connection lost" to an attempt to send a
request, it can't always just read pending responses to see if there
is a Notice of Disconnection.  I expect the client could have another
thread which was reading responses.  In any case, it just doesn't
seem right to me to read anything in response to a "write" request.

Also, if the library does read the pending input, is there in practice
some absolute limit on how much input can be pending - both in TCP and
other transports which might implement LDAP?  Otherwise an attempt to
read it all could eat a lot of memory.

Finally, if the library does read the input and finds a Notice of
Disconnection, it needs to put the result code in some place which the
client will pay attention to.  Maybe the diagnosticMessage field would
be the best bet.  Or it could invent a bunch of private "connection
lost" result codes, indicating different result codes in the notice of
disconnection.)

> however, when the server chooses (for
> whatever reason) [NOT] to do this, I think (because the now invalidated

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.

-- 
Hallvard

---

From: "Jim Sermersheim" <[email-masked]>
Date: Tue, 09 Nov 2004 21:35:15 -0700

>>> Hallvard B Furuseth [email-masked]> 11/9/04 5:00:32 PM >>

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

I guess it depends on the operation. If it's on a Notice of
Disconnetion, then no. If it's on a BindResponse, then yes. Similar to
this is confidentialityRequired. While Notice of Disconnection is free
to send this, so are other operations. I suppose even loopDetect could
be sent on a Notice of Disconnection.

Do you think we need to add your suggested text? (if so, why?)

Jim