[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (MQTT-77) Should the Connect packet Useri Name and Password fields be binary rather than UTF-8
[ 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]