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

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 20 Oct 2005 22:04:51 +0200

Authmeth-16 now says:

4. Authorization State has been changed to include

>   It is noted that other events both internal and external to LDAP may
>   result in the authentication and authorization states being moved to
>   an anonymous one.  For instance, the establishment, change, or
>   closure of security services may result in a move to an anonymous
>   state, or the user's credential information (e.g., certificate) may
>   have expired.  The former is an example of an event internal to LDAP
>   whereas the latter is an example of an event external to LDAP.

As I wrote in message
<http://www.openldap.org/lists/ietf-ldapbis/200510/msg00012.html>,

"internal" events that revert the auth to anonymous can lead to major
breakage at the client side, e.g. for clients that treat noSuchObject
as information that the some value is not present in the directory.
At our site, e-mail to valid addresses would bounce since LDAP informed
the mail system that the address is not present.

I suppose the draft could allow for server admins to configure such
behaviour, and add warnings about it, but unless there is a strong call
for this functionality I don't see a good reason for blessing it.

If this change was done in response to the invalidated associations
discussions, this is not the right answer.  The possibilities that I am
aware of is for "unacceptable" requests could get some "didn't perform
the operation"-result code, or cause the the server to close the
connection.

OTOH, I also note that the draft has generalized the definition of
Authorization State to include other factors than the authorization ID.
I don't remember if that was discussed, but I haven't had time to follow
LDAPbis closely.  Anyway, I can see that the above change may be a
natural result of this generalization, but if so that implies that the
effect of this generalization may need to be reviewed more carefully.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 20 Oct 2005 23:45:07 -0700

At 01:04 PM 10/20/2005, Hallvard B Furuseth wrote:
>breakage at the client side,

I note that clients do know that an internal event did occur,
but as they have no clue as to what events impact authorization
and how, I don't see the impact to the client being significantly
different than of external events.

>e.g. for clients that treat noSuchObject

>for this functionality I don't see a good reason for blessing it.

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.

Such a system would be functionally equivalent to what's
described in the draft, its only described in different
terms.  The paragraph in question uses the 'simplistic'
term, "an anonymous state".  It could have used more
complex terms, but that would likely have only clouded
things.

>discussions, this is not the right answer.

How is this any different for a change done in response to
some factor orthogonal to the authentication state?

>The possibilities that I am

There are many other possibilities.

>LDAPbis closely.

See http://www.openldap.org/lists/ietf-ldapbis/200509/msg00026.html

>Anyway, I can see that the above change may be a

Careful review is always welcomed.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sat, 22 Oct 2005 06:28:00 +0200

Kurt D. Zeilenga writes:
> I note that clients do

I assume you lost a "not" here...

> know that an internal event did occur, but as they have no clue as to
> what events impact authorization and how, I don't see the impact to
> the client being significantly different than of external events.

I guess it's mostly the mental model of the whole issue, and what
solutions it invites implementors and administrators to use.

However, note that it _is_ different since the authz ID is a protocol
matter while authorization is not.  The whois operation returns the
authz id, and the creatorsName and modifiersName will contain it (in
this case, if anonymous updates are allowed).

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

> complex terms, but that would likely have only clouded

As you can see, I think it obscures a quite significant issue which
_should_ stand out.

>(...)

Thanks.  Found it in my mailbox now, still with a "really need to get
around to this message" mark - just like 100 or so others:-(

-- 
Hallvard

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sat, 22 Oct 2005 06:56:15 +0200

> 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