# Feasibility Assessment of a Fine-Grained Access Control Model on Resource Constrained Sensors
## 3 Access Control Model
### Access Control Scenario  
The considered access control scenario consists of a set of severely constrained CDSs that publish some tiny services. These services on CDSs can be accessed by subjects through IP networks. These CDSs communicate at the link layer with a more powerful base station using specific protocols, such as IEEE 802.15.4 [25], which covers short ranges and enables low bit rates. At the network layer, each CDS implements IPv6/6 LoWPAN, enabling the establishment of IP communications with any device in the Internet without the need for intermediary proxies. There are three basic actors in the access control scenario, as shown in Figure 2: a _subject_ (1), constrained or not, which intends to access an either operational or management service as a _resource_ in a CDS (2), with the collaboration of a trusted third entity in the establishment of a security association, namely, an _ACS_ (3). This schema is aligned with the IoT reference stack [26], where perception layer integrating CDS, and network layers are exploited by the application layer on the top, often through the corresponding graphical user interfaces. The _subject_ endpoint, depicted as a sensor, a smartphone and a workstation, can be a constrained or less constrained endpoint, located in the related application datacenter, or behave as a less trusted mobile endpoint. Note that the term _subject_ is adopted as a logical entity, which is a running software or process, acting on behalf of an individual or a service in a machine-to-machine environment. This is a well-known term in access control related models and standards [27; 28]. For clarity and uniformity purposes, subject term is used from now on in all aspects of access control model definition, and is equivalent to the client principal term adopted in some standards such as Kerberos [29]. In a similar way, note that the term _resource_ is adopted as a logical entity, which is a software component that provides data from or is used in the actuation on physical entities such as constrained devices acting as sensors or actuators. _Resources_ typically have correspondent interfaces to interact with them. This is also a well-known term in access control related models and standards. For clarity and uniformity purposes, resource term is used from now on in all aspects of access control model definition, and is equivalent to the service principal and server terms adopted in related standards. Explicitly, the proposed access control architecture consists of two parts: a standardized cross-domain access control central checkpoint as an initial mandatory filter, namely, the ACS, which is not resource constrained, and a distributed checkpoint in each CDS, which enables dynamic and fine-grained access control, based on local context as well as accounting. This proposed multi-step enforcement approach, which combines centralized and distributed access control architectures, adopts the benefits derived from each and makes E2E security both light and efficient in CDSs. This ACS, which can be a powerful workstation or a cluster of servers using standard security and traditional access control standards and technologies, supports most resource-intensive features of the Hidra security protocol such as identity and credential management, cross-domain federated authentication, preliminary authorization, policy life cycle management and accounting. Furthermore, the ACS avoids a large number of unsuccessful message exchanges with the CDS when it refuses unauthorized access attempts, and this is a crucial point in terms of energy saving. Additionally, the ACS enables a unified and coherent policy management, which, on the one hand, is becoming a critical aspect in many fully distributed deployments and, on the other hand, reduces storage requirements in the CDS in open and flexible E2E scenarios. Moreover, when a positive preliminary  
Figure 2: Access control scenario.