Re: Result code for invalidated associations

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

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:

        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. 

(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