Subject: result code for a deleted identity on a connection

From: "Vithalprasad Gaitonde" <[email-masked]>
Date: Wed, 30 Apr 2003 04:23:31 -0600

If a client does a bind with an identity and then while the bound
connection is still open, the object which has bound gets deleted, what
is the expected server behaviour when the client tries to make the next
request on that connection?
Should the connection revert to anonymous ? - This seems inappropriate
as the client would not know why he is suddenly not getting access to
some objects which he had access to earlier.
The appropriate behaviour should probably be to send a result code back
and close the connection (as if there had been an unbind).
None of the current result codes defined in
http://www.ietf.org/internet-drafts/draft-ietf-ldapbis-protocol-13.txt
seem to be apprpriate for this. The closest is insufficient access.
We should probably have a result code like invalidIdentity which is
sent back with a notice of disconnection (section 4.4.1 protocol draft)
followed by a closing of the connection by the server.

Comments ?

Prasad

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 30 Apr 2003 14:13:53 +0200

> some objects which he had access to earlier.

Right.

> and close the connection (as if there had been an unbind).

I suspect it might be a lot of work for servers to keep track of this.
So I think the server should have that option, but it should also have
the option not to notice this condition and keep serving requests as if
nothing happened.

> We should probably have a result code like invalidIdentity

How about invalidCredentials?

> which is sent back with a notice of disconnection (section 4.4.1
> protocol draft) followed by a closing of the connection by the server.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 30 Apr 2003 07:56:37 -0700

>request on that connection?

The server should likely disconnect the client immediately upon
knowing the credentials are no longer valid.  (I note that
the server may not immediately know the credentials are invalid.)

>Should the connection revert to anonymous ?

Well, I think the server should move the client into an "authentication
state unknown" state and refuse to process operations (other those
which establish authentication associations) until both client and
server have established a new authentication association.   That
is, the server should not just continue as if the client had
established an anonymous authentication association.

RFC 2251, 4.4.1:
>   - strongAuthRequired: The server has detected that an established
>     underlying security association protecting communication between
>     the client and server has unexpectedly failed or been compromised.

I think it would be reasonable to return this in this case as well.

Kurt