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

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

Hi Hallvard,

I agree with your position. I also don't believe that a server has the
right to assign an authorisation ID at its whim.

However, I don't like these arguments about how to inform clients when
their bind state changes. There was a lot of dicussion about what
happens if credentials expire. Aaaargh.

My view is that the server should disconnect rather than change the bind
state. That way, whether the client unserstands what has gone wrong or
not, the rebind will fix everything (or make it apparent that the
credentials are no longer valid).

Ron

-----Original Message-----
From: owner-ietf-ldapbis@OpenLDAP.org
[mailto:owner-ietf-ldapbis@OpenLDAP.org] On Behalf Of Hallvard B
Furuseth
Sent: Friday, 11 November 2005 2:11 PM
To: Kurt D. Zeilenga
Cc: Roger Harrison; ietf-ldapbis@OpenLDAP.org
Subject: Re: auth state & silent change to anonymous (was: SASL
Semantics Within LDAP)

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

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.
>
> Actually, I think the particular authorization factor of issue here is

> not the authentication identity but the authorization identity.

Yes.

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

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

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.

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

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.

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

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

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

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.

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

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

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

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.

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

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.

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

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

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

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