As a history, enhanced authentication was proposed a MQTT-255 and extensively discussed at the Bellevue F2F and the September Hursley F2F. At that time the TC decided to approve the connect time enhanced authentication and to create another issue for reauthorization. There were actually 2 such issues created MQTT-315 and MQTT-317. We closed MQTT-315 and designed reauthorization as MQTT-317. One of the issues we raised was whether anybody actually wanted reauthorization enough to add it, and the consensus of the TC was to proceed with it. The technical issues and limitations were discussed in a subgrouip and accepted by the TC.

We can of course re-open any of the decisions previously made by the TC, but doing this risks ever getting to closure of the spec.

While the enhanced authentication avoids using the name SASL, it is clearly designed to be SASL conforming and to allow SASL mechanisms to be used as Auth Methods. In SASL authentication is all initiated by the client. Some protocols which implement SASL do allow the server to request the client to initiate authentication or reauthentication.

In response to the concerns raised:
1. To exploit the AUTH flow for some other purpose requires both a client and server which agree on such usage. In a client application using a client library this would presumably mean that the client library is involved. If we just want to flow data between client application and server, or client library and server, much better means already exist (using PUBLISH to system topics for instance) which have none of the limitations of using AUTH.

2. The SASL mechanisms with time limited tokens generally make known to the client the time limit of the token. Initiating reauthentication from the server seems to be the thing which is not used as it is not required to implement SASL.

3. Either a client or server is free to not implement reauthentication if it believes there is no requirement. Indeed, they are free to not implement any part of enhanced authentication.

Reviewed with editors. Two options:

1. Leave as is. Clients typically initiate authentication.
2. Allow the server to send Auth (reauthentication) to clients

I have added a proposal for a simple mechanism for a server to request a re-authentication. This is still not symmetrical re-authentication as the client actually initiates any such flow, but this allows the server to request it. This allows for cases such as when the client does not have a clock, or does not keep track of when its credentials will expire.

There are a number of issues around coordinating this request from a authentication flow. This proposal gets around these by making the sever to client request for re-authentication totally asynchronous to the actual re-authentication flow. We might need to say the client must ignore this request if a re-authentication flow is in progress.

I would prefer to leave re-authentication as it exists, but if we feel that we need the ability of the server to say that re-authentication is required, this simple mechanism can be added.

Reviewed during June 1 2017 TC call.