When reviewing the information flows the architecture focuses on we need to take note of the fact that the message flow may pass unprotected paths. The interaction between principal level actors is not a concern since existing mechanisms can be employed. The critical points in the message flow are the messages between constrained nodes and constrained nodes and their less constrained counterparts. These messages can after all contain permissions, client and server attributes, conditions on resources, not to mention keys and credentials. This control information may also be rather asymmetric in the client and server side. (Gerdes et al., 2015a)
The architecture assumes that the necessary credentials are provided for the control information flows between constrained and their less-constrained counterparts and it needs to be part of a solution. The problem statement for authorization in constrained environments is derived from the information flows and can be summarized by three major points:
1. Less-constrained nodes control the interaction between potentially constrained nodes on behalf of their principals.
2. The interaction needs to be secured between endpoints in end-to-end manner, including scenarios with intermediary nodes, including necessary key establishment.
3. Transferring control information needs to be secured in an end-to-end manner, including scenarios with intermediary nodes. This may require employment of pre-established keying material. (Gerdes et al., 2015a) The first potential information flow is a push sequence initiated by Client, first acquiring credentials using CAS and presenting them to RS is presented in Figure 4.
Figure 4: Information flow (Gerdes et al., 2015a)
But the architecture does not imply that this would be the only possibility.
It states “Authorization information is transferred from AS to RS using Agent, Push or Pull mechanisms” (Gerdes et al., 2015a). This implies that another potential information flows would be possible. Such as a pull sequence. Again initiated by C, but using RS as intermediary for authorization with AS, which then communicates to CAS.
5.3 Summary
The architecture is intended to be used as a framework for designing authorized authentication mechanisms for constrained environments. It does not pose tight restrictions on such things as authorization sequence or in which actual device the different elements of the mechanism reside. The architecture can so be seen as a set of objectives on how to realize such mechanism. Table 4 summarizes the objectives gathered from the architecture. These objectives are the second building block for the main artifact of this study.
TABLE 4 Architecture objective summary
Objective Description
Delegation of demanding
tasks Demanding tasks are assigned to other less constrained entities. Functionalities should be grouped by their demands on the platform to determine if they should be assigned to a constrained level device or a less-constrained level device.
Validation of actors • The client has to validate that the resource server is an authorized endpoint for the resource it wants to access.
• Resource server needs to validate that the client requesting a resource has an authorization to do so.
• The Client Authorization Server needs to validate that the Resource Server is an authorized server for the Resource.
• The Authorization Servers needs to validate the Client on behalf of the Resource Server and determine the Clients permissions to the Resource.
Autonomous functionality • Less-constrained nodes control the interaction between potentially constrained nodes on behalf of their principals.
• Authorization Server must be able to act on behalf of the Resource owner handling access request on behalf of Resource Server.
• Client Authorization server making resource request and handling their responses on behalf of the Client.
End-to-end security The interaction needs to be secured between endpoints in end-to-end manner, including scenarios with intermediary nodes, including necessary key establishment and control information.
6 Security concerns
This chapter deals with common security concerns for a distributed system that need to be achieved even in constrained environments. It also discusses the different options on choosing an authentication sequence and authentication method. This chapter provides the third part for the main artifact of this study.
Constrained devices are designed to be small, inexpensive and easily integratable. By this definition they are meant to be used in various environments. They can be in control of important functions and have access to large amount of valuable data. In this kind of scenario the need to protect from unauthorized access is self-evident, but there are other scenarios to take into consideration. Even gathering seemingly innocuous data and information of functions can lead to insights of a system that can be used to gain some level of control. Another scenario could be that the devices themselves are not the primary target, but they are used as an intrusion point to infiltrate the network and used to attack other more valuable devices. Because constrained devices have limited capabilities they can be the weakest link in a network and hence an attractive target. (Selander, Mani, Kumar, Seitz, & Gerdes, 2015)
First objectives for a secure and reliable conduct for a distributed system has to be defined. Pfleeger & Pfleeger (2002) address the security goals of a computer-related system with three aspects. These aspects are confidentiality, integrity and availability described in Table 5.
TABLE 5 Security objectives for a computer-related system
Objective Description
Confidentiality Ensuring that assets are accessed only by authorized parties.
Access includes not only reading privileges, but also viewing, printing and knowledge of the existence of an asset.
Integrity Only authorized parties have the ability to modify the assets.
Modification includes writing, changing, changing status, deleting and creation.
Availability All authorized parties have access to the assets, at the time they need it.
These three objectives are considered as hallmarks of solid security. Their first appearance in literature is found as early as 1972 in James P. Anderson's essay in computer security (Anderson, 1972). These properties are referenced as the C-I-A triad or the security triad. (Pfleeger, Pfleeger, & Margulies, 2015) These properties define how resources should be secured.
Nguyena, Laurentb & Oualhaa (2015) propose five objectives in their definition for security objectives of IoT: confidentiality, integrity, authentication, authorization and freshness. These properties are centered on data shared between devices and they address message security (confidentiality, integrity, authentication and freshness) and access rights (authorization). (Nguyen, Laurent, & Oualha, 2015) These objectives are summarized in Table 6.
TABLE 6 Security objectives for IoT
Objective Description
Confidentiality Exchanged messages in the IoT may need to be protected.
An attacker should not gain knowledge about the messages exchanged between a sensor node and any other Internet entity.
Integrity The alteration of messages should be detected by the receiver.
Authentication The receiver should be able also to verify the origin of the exchanged messages.
Authorization IoT devices should be able to verify whether certain entities are authorized to access their measured data. At the network layer, only authorized devices should be able to access the IoT network. Unauthorized devices should not be able to route their messages over the IoT devices, because it may deplete their energy.
Freshness This property ensures that no older messages are replayed.
This is important to secure the communication channel against replay attacks.
Both taxonomies can be seen congruent by content, but the grouping of the objectives take different perspectives. The second taxonomy adds more IoT specific features dealing with more message centric issues. Such as alteration detection and origin verification for the messages. It also acknowledges the possibility of replay attacks as a separate property. These issues can be dealt with securing the communication between devices and enforcing authorized authentication. Next chapters describe different methods for communication and resource security.