Re: invalidated/anonymized Authz state (was: SASL Semantics Within LDAP)

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

(Wrong thread or subject line:-)

Roger Harrison writes:
>>Hallvard Furuseth wrote:
>> 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.  (...)
>
> I agree with Hallvard on this.  It seems that this situation really
> could leave the client clueless as to its current state and the need
> to take action to reestablish its desired authentication state.

If you are still brushing up on authmeth-17, I suggest to leave it alone
for now, or at least until Kurt can reply.  His current text has after
all been sitting more or less unopposed for a while, and there isn't
chance for much discussion for -17 now.  I'll be posting a reply to Kurt
soon.

> I see three possibilities for the server to communicate an event that
> has caused the authentication state being moved to anonymous:
>
> 1. Use an unsolicited notification
> 2. Send a notice of disconnect
> 3. Use a specific result code in subsequent operation responses
> (...)

4. Don't try to inform the client of the real problem (except maybe in
the diagnosticMessage field), just keep sending failure result codes
that fit each individual request.

5. Kurt pointed out that it would be quite valid to use the "authz ID is
now unreliable" as an access control factor.  I think something like
that is a lot better than reverting to anon; getting back to that in a
reply to Kurt.

> None of these options seem particularly nice, but I believe we need to
> choose one of them.

Or let the server admin choose.

I think #1 and #3 were shot down and that's one reason we gave up on
invalidated associations, except as extensions (maybe after the client
has requested them).

-- 
Hallvard