Re: SASL Semantics Within LDAP

At 08:21 PM 10/21/2005, Roger Harrison wrote:
>I agree with Hallvard on this.  It seems that this situation really could leave the client clueless as to its current state

I believe we've been through this before.

The client is always clueless as to its current authorization
state.  Authorization is a local matter.  Even though the client
may know at times (such as upon connect) that its in an anonymous
authorization state, it doesn't know which anonymous state its in
(they might not all be equivalent).  And when some authenticated
state, it doesn't know (through the protocol) which authenticated
authorization state its in, nor what authorization that state
may grant/deny, or whether or not that state is equivalent to
some anonymous state.

>and the need to take action to reestablish its desired authentication state.
>I see three possibilities for the server to communicate an event that has caused the authentication state being moved to anonymous: 

> 1. Use an unsolicited notification 

There is no such unsolicited notification defined.
LDAPBIS is not chartered to add any.

> 2. Send a notice of disconnect 

A server can certain disconnect the client if it wants to,
but it also free to continue providing service to the
client in whatever authorization state the server considers
the client to be in.

> 3. Use a specific result code in subsequent operation responses 

LDAP Result codes are only indicative of why the requested
operation failed.  LDAPBIS is not chartered to add new
result codes.

> None of these options seem particularly nice, but I believe
> we need to choose one of them. 

Historically, LDAP servers have reduced service to clients
to fit their current authorization instead of returning
authorization errors, including reduction of service to
that equivalent to an anonymous user.  LDAP servers may
also, and some do, support "don't disclose on error"
capabilities.  Clients need to designed with both of these
aspects in mind.

As authorization is a local matter, servers are free to move the
authorization state to an anonymous-like authorization state.
This anonymous-like authorization state may be functionally
equivalent an anonymous authorization state.  The distinction
is irrelevant in the protocol and to the client.  To the
server, whatever distinction that might be there is simply
an implementation detail.

While some may not like this, without re-engineering the
protocol, there is nothing we can about this.  As such
re-engineering is beyond the scope of our charter, the
best we can do is detail these aspects of LDAP and
offer appropriate considerations.

-- Kurt