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

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

Kurt D. Zeilenga writes:
>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

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.

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

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

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

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