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

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 07:39 AM 11/8/2005, Hallvard B Furuseth wrote:
>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.

I have a bit of deja vu here...

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

Actually, I think the particular authorization factor of issue
here is not the authentication identity but the authorization
identity.

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

I disagree.

But let me take a slightly different argument...

Which authorization identities a server associates with the
client (based upon whatever factors) is a local matter.
That is, there is nothing in the specification that prevents a
server from mapping the authentication identity to multiple
authorization identities, some anonymous and some non-anonymous,
and then selecting which identity to use in making any
particular authorization decision based on whatever factors
it believes is appropriate.

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

The issue of whether the authorization identity is or isn't
changed is moot as the case is indistinguishable at the client
from other allowed actions of the server.

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

A success indicates that the client's credentials are valid
and implies that some authorization identity(ies) has been
establish.  Nothing in LDAP (or SASL) should suggest what
identit(ies) the server chooses to use in making authorization
decisions. 


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

No.  The user knows what credentials they provided, may know
what credentials were used, but doesn't know all
the factors are used in determining authorization identities,
and certainly doesn't know how these authorization identities
are used in authorization decisions.

>And changing the authz ID does affect the whoami operation.

  This specification describes a Lightweight Directory Access Protocol
  (LDAP) [RFC3377] operation which clients can use to obtain the primary
  authorization identity in its primary form which the server has
  associated with the user or application entity.

  ...

  Servers often associate multiple authorization identities with the
  client and each authorization identity may be represented by multiple
  authzId [RFC2829] strings.  This operation requests and returns the
  authzId the server considers to be primary.  In the specification, the
  term "the authorization identity" and "the authzId" are generally to
  be read as "the primary authorization identity" and the "the primary  
  authzId", respectively.             


If after completing a bind, the server associates both
  a) non-anonymous authorization identity (for use as long as
        certain factors are met)
  b) an anonymous identity (for use otherwise)

the server is free to return which ever it currently considers
to be the 'primary' when requested.

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

I think it appropriate to make it clear to client
developers that server may follow authorization
models that some would not consider to be "good".

>The fact that access control is a local matter doesn't mean that client
>usually have no clue what is going on.

I disagree.  In absence of apriori knowledge of the server and
its configuration, a client has little to no clue as to what
going on.

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

Well, the design an extension to LDAP that keeps clients informed.

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

Well, if nothing else, to present some of the implications
upon client implementors of leaving authorization models/systems
in the hands of server implementors.

>It is not a protocol matter - it can neither be interrogated nor
>controlled by the client.

... but its a reasonable matter for the protocol specification
to discuss.