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

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

At 01:04 PM 10/20/2005, Hallvard B Furuseth wrote:
>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,

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

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.

>If this change was done in response to the invalidated associations
>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
>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.

There are many other possibilities.

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

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

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

Careful review is always welcomed.