OASIS Message Queuing Telemetry Transport (MQTT) TC

  • 1.  Connect with existing ID

    Posted 11-15-2013 15:37
    I never before noticed this line in the input spec: If a client with the same Client ID is already connected to the server, the "older" client must be disconnected by the server before completing the CONNECT flow of the new client. It corresponds to this in the WD: If the ClientId represents a client already connected to the server then the server MUST disconnect the existing client. Isn't this a bit of a security hole? If I can guess a ClientID I can disconnect it. If there is anyone using the clientId as a topic for replies and relying on clientId for security (e.g. in Mosquitto's ACL  %c to match the client id of the client), then this is also a security hole.  Can anyone comment? Paul -- Paul Fremantle CTO and Co-Founder, WSO2 OASIS WS-RX TC Co-chair, Apache Member UK: +44 207 096 0336 US: +1 646 595 7614 blog: http://pzf.fremantle.org twitter.com/pzfreo paul@wso2.com wso2.com Lean Enterprise Middleware Disclaimer: This communication may contain privileged or other confidential information and is intended exclusively for the addressee/s. If you are not the intended recipient/s, or believe that you may have received this communication in error, please reply to the sender indicating that fact and delete the copy you received and in addition, you should not print, copy, retransmit, disseminate, or otherwise use the information contained in this communication. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions.


  • 2.  Re: [mqtt] Connect with existing ID

    Posted 11-15-2013 16:59
    Paul, This is essential for stuck clients, clients that don't realise they've got a dead connection and reconnect, clients taking over when a node's unresponsive, etc. The same functionality exists in AMQP, where it features at the link level - there it's called link stealing. Think of it as STONITH for mq clients. It shouldn't be a security hole if you're authenticating and authorising your clients. It may not be clear that's needed - if you like, you might want to add a JIRA. It's a pain in the neck to implement, too, as a server, as it's the only time one connection 'needs to know' about another. Raphael Cohn Chief Architect, stormmq Co-Chair, OASIS MQTT Standard Secretary, OASIS AMQP Standard raphael.cohn@stormmq.com +44 7590 675 756 UK Office: Hamblethorpe Farm, Crag Lane, Bradley BD20 9DB, North Yorkshire, United Kingdom Telephone: +44 845 3712 567 Registered office: 16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom StormMQ Limited is Registered in England and Wales under Company Number 07175657 StormMQ.com On 15 November 2013 15:36, Paul Fremantle < paul@wso2.com > wrote: I never before noticed this line in the input spec: If a client with the same Client ID is already connected to the server, the "older" client must be disconnected by the server before completing the CONNECT flow of the new client. It corresponds to this in the WD: If the ClientId represents a client already connected to the server then the server MUST disconnect the existing client. Isn't this a bit of a security hole? If I can guess a ClientID I can disconnect it. If there is anyone using the clientId as a topic for replies and relying on clientId for security (e.g. in Mosquitto's ACL  %c to match the client id of the client), then this is also a security hole.  Can anyone comment? Paul -- Paul Fremantle CTO and Co-Founder, WSO2 OASIS WS-RX TC Co-chair, Apache Member UK: +44 207 096 0336 US: +1 646 595 7614 blog: http://pzf.fremantle.org twitter.com/pzfreo paul@wso2.com wso2.com Lean Enterprise Middleware Disclaimer: This communication may contain privileged or other confidential information and is intended exclusively for the addressee/s. If you are not the intended recipient/s, or believe that you may have received this communication in error, please reply to the sender indicating that fact and delete the copy you received and in addition, you should not print, copy, retransmit, disseminate, or otherwise use the information contained in this communication. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions.


  • 3.  Re: [mqtt] Connect with existing ID

    Posted 11-15-2013 18:34
    Paul A secure system should always check at Connect time that a would-be user is authorised to use the client ID that's in the Connect packet, as the client ID is the key to any MQTT state held by the server on behalf of the client. Consider the case where the genuine user of the client ID is not connected. If an imposter were able to connect with that client ID then he/she would receive any queued up messages belonging to the genuine user's subscriptions. Incidentally, the resolution to issue MQTT-82 now lets an MQTT server accept zero-length client IDs. A client is only allowed to set a zero-length client ID if it has set cleanSession = true (so there is never any pre-existing state, and once the client disconnects all its state is lost). If it accepts a zero-length client ID, the server treats each such client as independent, so there's no forcible disconnection of any other client. Peter Niblett IBM Senior Technical Staff Member Member of the IBM Academy of Technology From:         Raphael Cohn <raphael.cohn@stormmq.com> To:         Paul Fremantle <paul@wso2.com>, Cc:         "mqtt@lists.oasis-open.org" <mqtt@lists.oasis-open.org> Date:         11/15/2013 04:58 PM Subject:         Re: [mqtt] Connect with existing ID Sent by:         <mqtt@lists.oasis-open.org> Paul, This is essential for stuck clients, clients that don't realise they've got a dead connection and reconnect, clients taking over when a node's unresponsive, etc. The same functionality exists in AMQP, where it features at the link level - there it's called link stealing. Think of it as STONITH for mq clients. It shouldn't be a security hole if you're authenticating and authorising your clients. It may not be clear that's needed - if you like, you might want to add a JIRA. It's a pain in the neck to implement, too, as a server, as it's the only time one connection 'needs to know' about another. Raphael Cohn Chief Architect, stormmq Co-Chair, OASIS MQTT Standard Secretary, OASIS AMQP Standard raphael.cohn@stormmq.com +44 7590 675 756 UK Office: Hamblethorpe Farm, Crag Lane, Bradley BD20 9DB, North Yorkshire, United Kingdom Telephone: +44 845 3712 567 Registered office: 16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom StormMQ Limited is Registered in England and Wales under Company Number 07175657 StormMQ.com On 15 November 2013 15:36, Paul Fremantle < paul@wso2.com > wrote: I never before noticed this line in the input spec: If a client with the same Client ID is already connected to the server, the "older" client must be disconnected by the server before completing the CONNECT flow of the new client. It corresponds to this in the WD: If the ClientId represents a client already connected to the server then the server MUST disconnect the existing client. Isn't this a bit of a security hole? If I can guess a ClientID I can disconnect it. If there is anyone using the clientId as a topic for replies and relying on clientId for security (e.g. in Mosquitto's ACL %c to match the client id of the client), then this is also a security hole.  Can anyone comment? Paul -- Paul Fremantle CTO and Co-Founder, WSO2 OASIS WS-RX TC Co-chair, Apache Member UK: +44 207 096 0336 US: +1 646 595 7614 blog: http://pzf.fremantle.org twitter.com/pzfreo paul@wso2.com wso2.com Lean Enterprise Middleware Disclaimer: This communication may contain privileged or other confidential information and is intended exclusively for the addressee/s. If you are not the intended recipient/s, or believe that you may have received this communication in error, please reply to the sender indicating that fact and delete the copy you received and in addition, you should not print, copy, retransmit, disseminate, or otherwise use the information contained in this communication. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU