## 2 Communication Protocols and Access Control Systems in IoT Environments
### MQTT Protocol  
The MQTT protocol was designed to exchange telemetry information following a publisher/ subscriber architecture in networks composed of constrained devices. This kind of device is usually not able to implement complex application-level protocols like the HTTP. The MQTT protocol was also devised to minimize bandwidth and energy usage (as shown in Section 4.2.1) and to be as simple and easy to integrate as possible. The protocol is usually employed with a central server (named the Broker) that coordinates the publisher/subscriber scheme based on the concept of topics. MQTT topics are labels attached to application messages that are used by the server to route the message to the appropriate subscribers. Despite the benefits described above, the MQTT protocol was not originally designed with security in mind. The core protocol offers very simple security features, like user/password credentials for authentication, and does not specify any authorization model. In the most recent versions of the standard, the committee has included a section with security considerations and recommendations on how to implement security for MQTT. These recommendations are described with respect to the usage of Virtual Private Network (VPN) and Transportation Layer Security (TLS) for the Network and Transport layers, respectively. These protocols are not always a suitable option for resource-constrained devices. The MQTT protocol has recently become an international standard [42].  
The main entities in any MQTT system are shown in Figure 1 and can be described as follows:  
* Brokers: Central servers in charge of routing and managing the MQTT messages.
* Publishers: Entities that issue messages to subscribing entities through the Broker.
* Subscribers: Entities that receive messages through the Broker. They are subscribed to a topic in the Broker, and receive the messages related to it. An entity can be both a publisher and subscriber.
* Topics: Identifiers of the subject of a series of messages. They can be seen as the channel used by the Publisher and Subscriber to exchange messages. They follow a hierarchical structure, where there are various levels of topics separated by a slash (e.g., /myhouse/kitchen/temperature).  
The MQTT protocol does not specify any authorization or access control scheme, and in fact, does not provide a specific authorization header in its specification, but the CONNECT message (issued to establish a new connection with the Broker) contains an optional authentication header, composed of a username and password fields, which are sent in clear text unless some encryption system is enforced over the protocol (usually Secure Sockets Layer (SSL)). Although is not part of the standard  
Figure 1: Main entities of the Message Queuing Telemetry Transport (MQTT) protocol.  
specification, it is possible to use this optional header to carry access control information, such as tokens or tickets, instead of the original username/password pair (for instance, it is possible to issue an OAuth access token in the username field, and leave the password field blank). We will take advantage of this possibility to protect the MQTT topics using UMA tokens.