Re: authmeth-16: auth state & silent change to anonymous

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

I wrote:
>Kurt D. Zeilenga writes:
>> Consider an authorization system where instead of moving the state to
>> anonymous on the event, moved the state to an authenticated state with
>> a factor indicating the event occurred.  Then in making an
>> authorization decision determines, based on this and other factors, to
>> not only deny access to the object, but deny disclosure that the
>> object exists.  Many implementations support such functionality,
>> presumedly because there is sufficient call for the functionality for
>> them to provide it.  As authorization is a local matter, its clearly
>> allowed.
>
> That's fine.  Note however that authorization like this is normally
> configured by the admin.  Also, the configured authz directives are
> commonly related to the entries being accessed.  So one may e.g. have
> one tree which can be accessed even with poor quality authz ID, and
> another tree which cannot.
>
> OTOH, "reverting to anonymous" when presented as a security measure
> might sound like a nice idea where one doesn't realize the consequences
> until getting bitten.  Or the way it's suggested in the draft, the
> implementor might even choose it as a nice secure default.  Or it could
> be bundled in some "strong security" option which the admin can choose
> if he doesn't want to read up on every security-related detail.

BTW, this resembles the issue with using the security strength as an
access control factor for userPassword.  (So the user gets
invalidCredentials and maybe thinks he mistyped the password, instead of
getting confidentialityRequired which gives the right advice.)

A common point is that access control - in the sense of just hiding data
and/or returning insufficientAccessRights - is not a general enough
model to control access to data.  One also needs to be able to change
which result code is returned - and to make a search fail instead of
returning fewer entries.

I.e. a "return confidentialityRequired for unprotected Simple Bind"
directive instead of using a security strength access control factor,
and now a directive for what to do if the authz ID is untrusted -
e.g. close the connection or return unwillingToPerform or whatever.

Since access control is mentioned in the draft, maybe it should mention
this as well next to it.  Not sure how to formulate it, though.
(Wording which suggests one could allow the admin to configure any
result code at to be returned anytime would probably be a bad idea:-)

-- 
Hallvard