RE: auth state & silent change to anonymous (was: SASL Semantics Within LDAP)

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

At 08:06 PM 11/10/2005, Hallvard B Furuseth wrote:
>Ramsay, Ron writes:
>> I agree with your position. I also don't believe that a server has the
>> right to assign an authorisation ID at its whim.
>>
>> However, I don't like these arguments about how to inform clients when
>> their bind state changes.  There was a lot of dicussion about what
>> happens if credentials expire. Aaaargh.
>
>Aaaargh indeed.  And I phrased my response to the latest round of that
>badly, though I corrected it later.  Just for the record,
>
>> My view is that the server should disconnect rather than change the
>> bind state.  That way, whether the client unserstands what has gone
>> wrong or not, the rebind will fix everything (or make it apparent that
>> the credentials are no longer valid).
>
>I think that's the best way (of the solutions in scope for LDAPbis), but
>should not be mandated.

As previously discussed on the list, it would be bad for a
server to disconnected upon StartTLS simply because it doesn't
want to use some previously established credential information
during the performance of subsequent operations.  Instead,
the server can in response to some subsequent request
return an appropriate response (e.g., a response consistent
with whatever authorization model the server implements and
applicable policy information).

However, this is not to say that there isn't some authorization
model where disconnect would be appropriate in some circumstance.
The technical specification doesn't preclude this alternative.

>Second best, maybe suggested for an admin to choose, to reduce the
>"quality of the authz ID" and return invalidCredentials to operations
>that want the authz ID to decide results.  That's just he old
>"invalidated association" restated.

As previously discussed, the invalidCredentials result code,
indicates that credentials provided in the request, including
possibly an attached control, are invalid.  Expanding the use
of the code to cases where previously provided credentials
are invalid is problematic as it means that clients would not
be able to distinguish whether credentials in the request
were invalid or previously provided credentials were invalid.

>If the draft is to say something as specific as mentioning alternatives,
>which I think would be a good idea, at least those two alternatives
>should be mentioned, plus that other ways could be configured.

Though I don't think it necessary (as I believe the technical
specifically reasonably clear that disconnection/termination
options are always available to the server), I personally wouldn't
object to adding something like to the end of Section 4
of [authmeth]:
        It is also noted that server may disconnect
        the client with notice, as discussed in Section 4.1.1
        of [Protocol], or terminate the connection, as discussed
        in Section 5.3 of [Protocol], in cases where the server is
        unwilling or unable to continue due to current
        authorization state or transitions of authorization
        state (such as those described above).

>If the admin wants to configure the server to switch to anonymous, by
>all means let him - whether or not the draft blesses this.

Whether it the implementation that admin or the implementor that
determine whether a particular implementation "switch[es] to
anonymous" is an implementation detail that is generally
beyond the scope of [authmeth].

>Servers allow plenty of nonstandard configurations anyway, when someone thinks that is convenient.  However the draft should not promote this as a
>reasonable default,

The draft doesn't "promote" this as a default, or any default.
The draft is stating what the range of allowed server behaviors
are so that client implementors hopefully won't make false
assumptions that these behaviors are disallowed.

>and if it mentions the possibility it should warn
>about it: That "negative" results from the server will not be
>authoriative, and whatever other surprises it can lead to, if any.

The term "authoritative" is a bit overloaded, so I'm going to
avoid it in my response.

I believe revised LDAP technical specification, especially
[Protocol] and [AuthMeth], are reasonable clear that returned
results are subject to access and other administrative controls,
the server may lie to avoid unauthorized disclosure of
information, authorization is a local matter, etc..  It
should be obvious that if a client falsely assumes the
server response is truthful to the best of server's knowledge,
and the server wasn't truthful, bad things can happen.

Kurt