Re: auth state & silent change to anonymous (was: SASL Semantics Within LDAP)

I answered part of this before you sent it...  I see from authmeth-17 I
should have sent it again.  (And I'm renaming the thread back to the
"auth state & silent change to anonymous" thread, since it incorrectly
ended up in the "SASL Semantics Within LDAP" thread.)

Kurt D. Zeilenga writes:
>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 part about return code from invalidated associations, yes.
Not the part about silently changing the authz ID to anonymous.

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

Technically, this is true - because everything is being restated to talk
about the 'authentication state'.  However, this did not talk about the
authentication state, but a particular auth factor - the auth ID.

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

Sure.  But none of this applies to silently changing the authz ID.  On
the countrary, we've had several long discussions which would have been
moot if it turned out that the above was true also for changing authz
ID.

> As authorization is a local matter, servers are free to move the
> authorization state to an anonymous-like authorization state.

If so we might just as well follow up with changing the Bind definition:
A success response means that the credentials were correct and the
server *may* have changed the authz ID to the requested ID.

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

First, as I said before, the authz ID is a protocol matter (as is the
security strength), and before authmeth-16 the user could always expect
to know what it was.  And changing the authz ID does affect the whoami
operation.

Second, even if the above were technically true it does not imply a good
mental model of what is going on, nor a good model to use when
implementing this.  Just like security strength can be used as an access
control factor, but that is a bad model because e.g. Bind gets
invalidCredentials instead of confidentialityRequired.

The fact that access control is a local matter doesn't mean that client
usually have no clue what is going on.  A server is set up for some
specific purpose.  A client can use it for that purpose, and will expect
the server to be set up sensibly _for that purpose_.  A client which
uses the server as an authorative data store for something does not
expect the server to suddenly decide to act as if the data is not there
after 23:00, for example.

It is reasonale - in fact necessary for some purposes - to write clients
which expect access control to be determined by factors which the client
controls or at least is kept informed about - i.e. authz ID, security
strength, the LDAP requests's parameters, and some static server policy.

A model which says implementors can change these without informing the
client, and even present this as a security measure, can be expected to
lead to implementations which do this without the admin's knowledge, and
thus things will break - even if the admin does have the ability to
prevent this if he just reads the manual thoroughly (and maybe re-reads
the manual every time he updates the server).


The draft certainly gets one thing right though:

> 4. Authorization State
>    While it is often convenient to view authorization state in
>    simplistic terms (as we often do in this technical specification)
>    such as "an anonymous state", (...)

I've been kind of thinking of authz state more or less as I thought of
authz ID, maybe because the draft started by talking about authz ID and
then switched to authz state without too much fuss, if I remember
correctly.  (But not that it was the only authz factor, fortunately:-)
I don't seem to have been alone either.

But now that this has been pointed out, I've begun to wonder:
What exactly is the "Authorization State" concept good for?

It is not a protocol matter - it can neither be interrogated nor
controlled by the client.  Designing clients to deal with this model is
hopeless.  There is no server-side access control model which uses it
either.

Nor is it a model which gives any suggestion for how to implement access
control: "The implementation of the access control state" might be more
or less the implementation of entire server - since just about anything
can be used for access control, including any directory entry.
(E.g. groups, access to filter= and set= in OpenLDAP).

OTOH, the old access control factors were something one can relate to:
Each operation consults access control factors determined by the
operation and the server config.  There are a few factors specified in
the draft to be affected by the client, and some which are not.

-- 
Hallvard