[OASIS Issue Tracker] Commented: (MQTT-77) Should the Connect packet Useri Name and Password fields be binary rather than UTF-8

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/MQTT-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=34510#action_34510 ] 

Raphael Cohen commented on MQTT-77:
-----------------------------------

I'd certainly prefer a binary encoding if it's possible. The question is, as usual - what's the impact on existing implementations?

Some idea bits & bobs:-

* The common SASL mechanisms, such as PLAIN and I think EXTERNAL, require a UTF-8 encoding which doesn't permit U+0000 (ie NUL). Whilst we're not using SASL in MQTT, we should be aware:-
- implementations may map the login credentials to a SASL mechanism, if the broker is one that already has such features (and we can map to at least EXTERNAL, ANONYMOUS, PLAIN and probably to CRAM-MD5/DIGEST-MD5/SCRAM-SHA1-[PLUS], although I haven't thought that through completely)
- we map want to add SASL support in the future (I would push for this in any breaking-change MQTT version)
- implementations might want to map to LDAPs, the RFCs for which do support arbitrary binary user names and passwords (although casing is a problem in some implementations) as well as SASL mechanisms (although doing a LDAP SASL bind to auth an user does seem a little odd)
- we want to make sure that _if_ an implementation uses TLS with client certs, that the cert subject name (IIRC) can be also placed in the login name (so one can use a SASL EXTERNAL binding or do a limited 'two factor' auth [cert + password]). I'm not sure if this requires binary usernames, because I can't think if the ASN.1 X509 cert allows them or not in the subject name (I suspect it does).
- I'm not sure about OAuth 100%, but as it can use the HTTP Auth header, I suspect it's OK
- I'm not sure about OpenId2, OpenId Connect and SAML2
- I recall HTTP basic auth doesn't have binary passwords

Overloading Meaning
This *will* occur in either the username field or elsewhere to support the following needs by implementers and their clients:-
- Not supporting binary passwords means one has to do a base64 encoding in the password field, thus requiring knowledge and potentially additional detail
- There is no current mechanism for supplying authzid as well as authcid, thus ditto
- There is no current mechanism for supplying a realm / container / virtual host / topic space, thus ditto

The last is important for, say, AD forest integration or cloud providers, as well as front-door proxies. In practice, implementations will simply embed a special syntax in the username field, probably modelled on the SASL PLAIN syntax with an extra field for realm / container / thing.

Summarising:-
- UTF-8 encoded usernames allow full compatibility with SASL, but possibly not LDAP or X.509
- Non-UTF-8 encoded usernames are probably exceedingly rare
- Binary passwords and other syntaxes (eg base64) will probably be accommodated by a 'prefix', eg 'b:', as people have done in HTTP over the years, if we don't support this. This is unlikely to cause a major interop problem - if a client migrates to another broker implementation vendor, it's highly unlikely the password database would migrate across (after all, it's probably salted or the like in a form that the other vendor doesn't support).



> Should the Connect packet Useri Name and Password fields be binary rather than UTF-8
> ------------------------------------------------------------------------------------
>
>                 Key: MQTT-77
>                 URL: http://tools.oasis-open.org/issues/browse/MQTT-77
>             Project: OASIS Message Queuing Telemetry Transport (MQTT) TC
>          Issue Type: Improvement
>          Components: core
>            Reporter: Andrew Banks
>
> The WD10 draft says :
> 3.1.3.4 User Name
> If the User Name Flag is set to 1, this is the next field in the payload. User Name is a UTF-8 encoded string and can be used by the server for authentication, and authorization. 
> 3.1.3.5 Password
> If the Password Flag is set to 1, this is the next field in the payload.,Password is a UTF-8 encoded string and can be used by the server for authentication of the client
> This allows implementer s to display these fields on admin screens but prevents them from being from carrying binary tokens. 
> We don't need to change the wire format to encode this if the binary field is prefixed with a 2 byte length.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira