-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: No Action
-
Affects Version/s: 5, wd13
-
Fix Version/s: None
-
Component/s: core
-
Labels:None
-
Proposal:
There is no return code on CONNACK and DISCONNECT for "Authentication Failed". The general guidance is to use "Not Authorised". This seems a little confusing as the Client can't be authorised as it's not yet authenticated. This might make debug more difficult and lead to some implementation confusion.
We do make the distinction elsewhere in the spec e.g.,
3.1.3.4 User Name
If the User Name Flag is set to 1, the User Name is the next field in the Payload. The User Name MUST be a UTF-8 Encoded String as defined in Section 1.5.4 [MQTT-3.1.3-10]. It can be used by the Server for authentication and authorization.
Jira opened following review session this week.
We do have guidance in the spec around the CONNACK case i.e., "The Server may choose to close the Network Connection without sending a CONNACK". Adding another error code isn't really eating away at that.
I agree we need to find a balance. It was an aim of the charter to improve the error framework beyond "good" and "not good".
Reviewed with editors.
Take to TC
Reviewed during June 1 2017 TC call.
It is bad security practice to tell a client the reason they are not authorized. Such information can be put in some other location for the use by authorized admins.
This was discussed during v3.1.1 meetings over the meaning of the 4 return code which in v3.1 is "Bad user name or password" which had been interpreted as a "not authenticated" return code. The description was change to clarify that this indicated that the user name or password is malformed. There was a further attempt to reword this as the 134 (0x86) return code in v5.0.
I think it is highly inappropriate to ever use even that return code, as if the client sends me a user name or password that is not valid I am quite unwilling to say anything but a generic not authorized, and I am not sure I always want to return even that.
So consider the example of a user name not being valid UTF-8. I might consider this a malformed packet or I might consider this a bad user name. I might consider this an implementation specific error, or I might consider the user to be not authorized to send in a n invalid user name. Having selected one of these, I can then decide to send a CONNACK with one of these return codes, or to just close the network connection without informing the client of why.