Re: Result code for invalidated associations

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

        strongAuthRequired (8) 
           Indicates that the server has detected that an established 
           security association between the client and server has 
           unexpectedly failed or been compromised, or that the server 
           now requires the client to authenticate using a strong(er) 
           mechanism. 

I guess I have a major problem with this description.
It's my view that the strongAuthRequired result does not
generally mean the established security association
has failed.  It means that the operation failed because
strong(er) authentication is required for that operation.
I believe the security association stuff only applies to
Notices of Disconnect.

Having two meanings here is quite problematic as the
client really needs to be able to distinguish the cases.
If the security layers have been compromised, then both
peers should cease using those layers.  That implies
that some sort of notice of failure should be sent,
either in the comprised layer (e.g., SASL, TLS) or
a Notice of Disconnect should be returned.  To only
return strongAuthRequired is inadequate as the client
may interpret this code as meaning its okay to continue
without re-establishing new layers.

Hence, it seems to me that the StrongAuthRequired should
be described as in the resultCode appendix as:
        Indicates that the server requires the client to
        authenticate using a strong(er) mechanism.

I think we need to clarify that as unsolicited notifications
are not (generally) associated with a particular operation,
the provided result does not reflect the outcome of an
operation.   It is necessary for each kind of unsolicited
notification to say what the codes are indicative of.
Then, for Notices of Disconnect, we should say that the
code is indicative of the reason the server is terminating
the connection.  We'll then have to say that certain codes
have meaning beyond their obvious meaning.

Sorry, it seems we need to revert some changes.

At 01:18 PM 10/29/2004, Hallvard B Furuseth wrote:
>Kurt D. Zeilenga writes:
>> As chair, I note my desire to try to divorce [AuthMeth]
>> and [Protocol] issues as much as possible in hopes that
>> will allow the WG to complete both in a timely fashion.
>> At this time, I would like to focus on issues pertaining
>> to [Protocol].  As [Protocol] doesn't use the term "LDAP
>> association", I rather we avoid it in this discussion.
>> Instead, I rather we talk in terms of credentials, cipher
>> keys, and their invalidation.
>
>I was just pointing out that an outstanding [Authmeth] discussion
>may affect [Protocol], in case that affects [Protocol]'s progress.
>I agree "invalidated associations" should not occur in [Protocol].
>
>> In regards to renaming the strongAuthRequired to be
>> the strongerAuthRequired (or something else), it seems
>> that there is some support for renaming.  However, further
>> discussion is needed to determine if consensus supports
>> such.
>
>Yup.
>
>> In regards to return of invalidCredentials, it seems
>> you are interpreting [Protocol] as precluding the use
>> of the result code to indicate that previously
>> provided credentials are invalid.
>
>The server can and probably should invalidate even anonymous
>associations.  So an invalidated association need not involve
>credentials that have become invalid.  The association just isn't
>trusted to match the state the client believes it to have.  That is
>not covered by invalidCredentials's description in [Protocol]:
>
>        invalidCredentials (49) 
>           Indicates that the provided credentials (e.g. the user's name 
>           and password) are invalid. 
>
>As for previously provided credentials becoming invalid,
>strongAuthRequired is currently the result code whose description in
>[Protocol] indicates that it is intended for this use (before the comma
>below), and whose description at least resembles what an invalidated
>association requires of the client (after the comma), so the current
>text does at least discourage server implementors from using
>invalidCredentials - and client implementors from recognizing it
>as suggesting an invalidated association:
>
>
>
>(Except for that, I had the impression that there were objections to
>using invalidCredentials for invalidated associations, but I'll be happy
>not to be proven right.)
>
>-- 
>Hallvard