Subject: Result code for invalidated associations

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 29 Oct 2004 17:40:49 +0200

The subthread of 'authmeth-12 review notes' about invalidated
associations, with this message of 28 Sep 2004 23:56:43 as its 'tail':
  http://www.openldap.org/lists/ietf-ldapbis/200409/msg00061.html
suggests some changes that involve [protocol].

1. Due to invalidated associations, a better name for strongAuthRequired
   would be strongerAuthRequired - or even authRequired or bindRequired
   (I added the latter since anonymous bind is not exactly authentication.)

2. If we instead use invalidCredentials to indicate invalidated
   associations as I suggested, that must be reflected in [Protocol].

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 29 Oct 2004 12:34:52 -0700

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.

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.

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.  It seems that
[Protocol] could also be interpreted as not precluding
this use.  The WG should discuss further whether return
of invalidCredentials may or may not used to indicate
previously provided credentials are invalid and what
clarifications, if any, should be made to [Protocol]
in this area.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Fri, 29 Oct 2004 22:18:40 +0200

> 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].

> discussion is needed to determine if consensus supports

Yup.

> 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

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 29 Oct 2004 18:17:08 -0700

Responding as an individual,

>discussion is needed to determine if consensus supports

As I believe that changing the name of this result code to
strongerAuthRequired likely reduce confusion over the
semantics of the code, I support making this change.

>clarifications, if any, should be made to [Protocol]

It's my view that result codes are only indicative of
why the server was unwilling or unable to successfully
complete the requested operation.  The result codes
are not indicative of the outcome of subsequently
requested operations.  I believe the term "provided"
clarifies that the referred to credentials are carried
by or established through the request.  Even without the
word "provided", the referred to credentials are the
ones carried by or established through the request.

It would be inappropriate to redefine the result to
refer to credentials not carried by or established though
the request.  This is because there may be control
extensions which carry credentials that call for this code
to be returned if those credentials are invalid.

One could return Notice of Disconnect with either an
strong[er]AuthRequired or invalidCredentials to indicate
the credentials are no longer considered valid.  The
question I guess is whether the implied distinction between
the two codes (expected or unexpected) is useful. I
guess I would argue yes it is.

But, the next question would be whether folks want to return
Notice of Disconnect in expected credential invalidation.
However, providing a Notice of Credential Invalidation (or
whatever you want to call it) seems something better left
to extensions.

The short of it is, I believe that the description for
credentials is fine as is.  I do not support making changes
should be made in this area.

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 29 Oct 2004 18:56:35 -0700

strongAuthRequired (8) 

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.

---

From: Hallvard B Furuseth <[email-masked]>
Date: Sun, 31 Oct 2004 18:27:52 +0100

Kurt D. Zeilenga writes:

> requested operations.

Well, the entire point of invalidated associations is that they do
indicate to the client that future operations may fail unless it takes
appropriate action.  Though if we could find some result code to use for
this, the definition of what the result code means to the client need
not be a promise that future operation will fail, only advice that it
cannot expect them to succeed (until it fixes the association), and that
it might need to check the current TLS and SASL layer state in case the
server invalidated the association due to e.g. a TLS cipher
renegotiation.

> the credentials are no longer considered valid.

If you mean to close the connection afterwards, it seems a bit like
surrender but maybe it is the cleanest solution (when it is not handled
by some extension).

If you mean to not close the connection, that seems like an abuse of
that notice, and works badly with clients that obey this RFC 2251 text:

   4.4.1. Notice of Disconnection

   After receiving this notice, the client MUST NOT transmit any further
   on the connection, and may abruptly close the connection.

In particular if the client does not close the connection, but expects
the server to do so (which rfc2251 servers MUST do).

> The question I guess is whether the implied distinction between the
> two codes (expected or unexpected) is useful. I guess I would argue
> yes it is.

I think so.  An invalidated association may imply that the client may
need to be modified to Bind (even if just anonymously) because the
server has stricter security settings than the client expects.  And it
does not mean that the connection ought to be torn down.

Anyway, if we are going to use an unsolicited notification instead of a
result code to a request to imply an invalidated association, we may
need to reconsider the entire "invalidated association" concept in light
of that.

> whatever you want to call it)

"Bind Invalidation", maybe - since the invalidated association need not
involve any current or previous credentials.

> seems something better left to extensions.

And so is introducing a new result code, I presume?

Notification or no, the server must return _some_ result code during
invalidated associations, if the connection is not closed.  And it must
make sense by itself, since unsolicited notifications merely are
advisory (unless we choose to change that).

We could also just use unwillingToPerform.  It doesn't tell the client
implementation why the operation fails, but at least diagnosticMessage
could inform the user, and someone could write an extension with an
unsolicited notification to inform the client implementations.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Sun, 31 Oct 2004 19:03:29 -0800

>server invalidated the association due to e.g. a TLS cipher

Right, one could define some new result code which could be
indicative of the outcome of subsequent operations.  Or
one could add controls (e.g., password policy controls), or
unsolicited notifications.  But we cannot redefine existing
codes, nor can we (as part of the LDAPBIS work) add new codes.

>surrender but maybe it is the cleanest solution (when it is not handled

Trying to continue after unexpected failures/compromises takes
special care.  Termination is simple and often the best.

>If you mean to not close the connection,

I mean close the connection.