Re: authmeth-15 notes

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

Sorry, I seem to have forgotten to reply to this one.

Roger Harrison writes:
> I've made significant changes in authmeth-16 to this section based on
> Kurt's suggestions on the Invalidated Authorization State thread.  I
> believe they will resolve the concerns raised below.
>
>>>> Kurt D. Zeilenga <Kurt@OpenLDAP.org> 09/26/05 10:35 pm >>>
> At 03:26 PM 9/22/2005, Hallvard B Furuseth wrote:
>>When was this decided?  Copied from my message
>><http://www.openldap.org/lists/ietf-ldapbis/200503/msg00006.html>,
>>
>>  The last I remember, we gave up on having invalidated associations
>>  return a result to a rejected request: thread 'Result code for
>>  invalidated associations', 2004.
>
> Well, I think we did reach consensus that result codes
> describe why the requested operation could be successfully
> completed.  They do not generally describe the authorization
> state or other session level details.  LDAP does not offer
> a general mechanism for communicating authorization state
> changes at the server.

Yes.

>>  The whole mess about them doing so
>>  just got too ugly.  Instead, if a request is rejected because the
>>  association is invalidated, just send Notice of Disconnection and
>>  terminate the session.  I don't remember which result code we ended
>>  up with; I think that issue came up in several threads.
>
> I think part of the problem is that we're trying to oversimply
> authorization state, something which is inherently complex
> given multiple factors and sophisticated policy controls.
>
> If the authorization state is such that the server doesn't
> want to continue, then certainly sending a notice of disconnect
> and disconnecting would be appropriate.  However, there
> are cases where authorization state allows the server to
> continue.  Maybe for the requested operation the server
> requires new authentication and hence returns
> strongerAuthRequired.

But if the current authorization identity has become suspect, or the
server suspects that the client may not know that the authz id has
changed (e.g. after graceful TLS closure), then even an anonymous Bind
would fix the problem.  strongerAuthRequired would be a misleading
result code.  I think invalidCredentials was turned down for that too,
but I don't remember why.

This is a state which should be communicated to the client somehow, and
which it might be useful to have a term for - if only just to state that
this is a situation the server might need to act on.  Though perhaps
"quality of association" would have been a better term than "invalidated
association".  The quality could be OK for search but not modify, for
example.  Anyway, Notice of Disconnection if the client sends an
"unacceptable" request would be a reasonable way to handle it.

> Or maybe the server just performs the operation but at reduced
> authorization level (for instance, processing a search operation as if
> submitted anonymously instead under the previously established
> authorization identity).  That is, some authenticated authorization
> states may allow no more (maybe even less) access than some anonymous
> states.

This sounds like a *very* bad default behavour if the client has not
been informed of the auth state change.  For example, we store mail
routing, delivery and login info in LDAP.  If the auth state silently
changed, the mail system would behave as if various addresses did not
exist.  Mail to valid addresses would bounce, users could not log in.
OTOH, if the LDAP requests fail, the mail system will retry - possibly
after reporting a temporary error to the user/sender.

-- 
Hallvard