Re: Result code for invalidated associations

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

Kurt D. Zeilenga writes:

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

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.

> One could return Notice of Disconnect with either an
> strong[er]AuthRequired or invalidCredentials to indicate
> 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.

> However, providing a Notice of Credential Invalidation (or
> 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