[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (MQTT-255) Alternate authentication mechanisms
[ https://issues.oasis-open.org/browse/MQTT-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=63621#comment-63621 ] Brian Raymor commented on MQTT-255: ----------------------------------- Discussed at F2F. Ken to refine Proposal 2 (see previous slides) within two weeks (see due date) with input from Konstantin and others. Will consider whether to separate revalidation into another issue. > Alternate authentication mechanisms > ----------------------------------- > > Key: MQTT-255 > URL: https://issues.oasis-open.org/browse/MQTT-255 > Project: OASIS Message Queuing Telemetry Transport (MQTT) TC > Issue Type: Improvement > Components: core > Affects Versions: 5 > Reporter: Peter Niblett > Assignee: Ken Borgendale > Fix For: 5 > > > MQTT 3.1.1 permits two client authentication mechanisms: > 1. Authentication by TLS (using a certificate/private key) prior to the CONNECT packet being sent > 2. Authentication via a username and password (or similar token) provided by a client in the CONNECT packet. > The second mechanism also requires the use of TLS encryption in order for it to be secure. > There are three reasons why we might consider adding alternative mechanisms, for example one involving server-directed challenge response during the MQTT CONNECT exchange: > i) TLS might be considered too heavyweight for some particularly constrained devices. > ii) There are many deployments where people are ok with TLS, but don't want to provision devices with bespoke Certificates. Some of these might not have a need to encrypt the MQTT protocol, but with approach 2 you end up having to encrypt all MQTT packets just in order to protect the password field in the CONNECT > iii) The organization (or standard building on top of MQTT) might already have an alternative authentication protocol. > Notes: > 1. The emphasis in this requirement is on composing with existing security mechanisms, rather than inventing new ones > 2. Some of this could be achieved by publishing Committee Notes (e.g. OAuth 2.0) rather than changing the CONNECT protocol packet exchange -- This message was sent by Atlassian JIRA (v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]