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

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 8 Nov 2005 16:39:02 +0100

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

---

From: Hallvard B Furuseth <[email-masked]>
Date: Tue, 8 Nov 2005 17:44:45 +0100

Hallvard B Furuseth writes:
> to know what it was.

Sorry, I meant something like "user of a particular server which he
knows".  Since there have been differences about if e.g. TLS closure
would revert to anonymous.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 08 Nov 2005 16:39:25 -0800

>Not the part about silently changing the authz ID to anonymous.

I have a bit of deja vu here...

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

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

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

>security strength), and before authmeth-16 the user could always expect

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.

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

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

>strength, the LDAP requests's parameters, and some static server policy.

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

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

>controlled by the client.

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

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 11 Nov 2005 04:11:02 +0100

> I have a bit of deja vu here...

Yeah, I messed about authentication ID vs authorization ID again:-(
So much for hurrying up at the last moment...  Tried to sleep on it
and use more time this time.

However, since I'm mainly talking about LDAP seen from the client side,
the error doesn't change my point much - only how it should have been
phrased.  If the server changes the authorization ID, it mostly changes
behavior to match the authentication ID - if any - which corresponds to
the new authorization ID.  (Yes it's a more complicated, like you can
request an authz ID with SASL, but nevermind.)

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

Yes.

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

OK - at least at the time of the Bind operation.
For doing it afterward, see below (about whoami).

However, such behavior would normally be explicitly configured by
the admin, the standard did not encourage the implementation to do
this on its own initiative.  The new wording does, if you extend
it to cover how to set authorization ID at the time of Bind.

And that's still what I'm mainly protesting against: A major change
in the apparent intent of the standard, and the behavior it blesses.

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

It's not moot because it's a change in the apparent intent of the
standard, how it encourages server to behave, and thus what clients
can reasonably expect of servers.

I've mentioned that it is not indistinguishable to the client due to
the whoami operation, but see below for your answer to that one.  (I
seem to have called it the whois operations a few times though:-)

BTW, the creatorsName and modifiersName values after update
operations are also affected.  Not sure if they store authorization
ID or authentication ID, but again if authorization ID is changed to
anonymous, that normally changes which authentication ID it
corresponds to anyway.

> establish.

Yes...

> Nothing in LDAP (or SASL) should suggest what identit(ies) the
> server chooses to use in making authorization decisions.

No.  The Bind operation produces the authorization ID.  That is not
authorization.  _Using_ the resulting authorization ID to decide
access (including access to complete the Bind, to be sure) is
authorization.

RFC 2251 said the equivalent thing without using the authorization
ID concept: Authorization can use the credentials from Bind.

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

OK in general - but as I said, change my statement to
"authentication ID" and it stands.  The user expects access
corresponding to the ID he provided, whatever that access might be
configured to be in the server.

(Getting back to a user of a particular server for a particular
purpose below.)

>  be read as "the primary authorization identity" and the "the primary

I hadn't noticed that whoami text.  It contradicts even authmeth-17,
which clearly refers to a single authz ID:

   "5. Bind Operation

   Some Bind mechanisms also allow the client to specify the
   authorization identity.  If the authorization identity is not
   specified, the server derives it from the authentication identity in
   an implementation-specific manner."

If the whoami text describes the current state of affairs, authmeth
is misleading and needs an update.

> to be the 'primary' when requested.

If the whoami text is right, yes.

However, this is still something which should be configured by the
admin, not something the wording should encourage implementations to
do without the admin's knowledge.

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

In this case, it would be to also make clear to client developers
and administrators that implementations may follow authorization
models that some would not consider to be "good".

Servers do and will follow such models that many would not consider
to be "good" anyway, e.g. the admin may have set up the access
control plain wrong.

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

Right.  But you don't usually Bind with a password - the most common
non-anonymous Bind as far as I know - to a server you have no
apriori knowledge of.

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

I've never heard of any suggestion that such an extension might be
needed, neither for LDAP nor X.500.  Your statement looks again to
me like a change of the stated intent, and what one can expect.

Am I really in a minority in needing to be able to set up a server
so that clients can rely on noSuchObject or a Success result with no
result entries to be authorative?  Nobody else bounce e-mail if LDAP
says an e-mail address cannot be found?  Do people simply accept
that PAM/NSS might arbitrarily give less access to their files than
they set it up to do?  Or that if a server was originally set up to
not behave that way, a server upgrade might undo such a guarantee?

Such an extension is needed if one wants that guaranatee *even
without knowing how the server is set up*, but that isn't what I'm
talking about.

> in the hands of server implementors.

And the way it does so leads to very bad conclusions, as far as I'm
concerned.

> ... but its a reasonable matter for the protocol specification

Well, maybe.

It doesn't seem to say much which can't be said at least as clearly
without it.  It does say several times that Bind/TLS can change the
state.  But you keep emphasizing that it can move to another state
at any time anyway, and then extend that to mean one should not rely
on the one access control factor which does get repeated mention
(authz ID).  If that's what the draft should say, then the wordings
about authz ID should at least be less definite.

I can't see it simplifies the discussion much either.  Only Section
4 (Authorization State) says what it's used for.  Everything else is
how Bind and TLS can move it to a different authorization state -
which could just as well be expressed in terms of access control and
security factors.  I've talked enough about one factor quhte enough
(authz ID).  And security factors are often better used in other
ways than access control, due to the invalidCredentials vs
confidentialityRequired issue.

For that matter, my entire point in this discussion started with
that "revert to anonymous when security fails" (i.e. change an
access control factor) is also better handled - at least by default
- by changing a security factor such as "quality of authz ID", so
you don't get misleading noSuchObject responses etc.

-- 
Hallvard