by Arthur Melissen (Coblue Cybersecurity)
Distributed role-based access control (RBAC) has become a standard for decentralised systems to manage authorisation across networks. While this model is effective at providing authorization, it fails in providing the flexibility and authorisation accountability that organisations require today. We present an extension to standard distributed RBAC mechanisms by adding an invitation and response dialogue in the assignment of roles to entities for distributed resources, such as collections of shared files. This approach offers more flexibility for delegating roles across administrative domains and increases transparency and confidence in the authorisation structure of distributed resources.
Traditionally, decentralised systems have used distributed access control and simple public key infrastructure (SPKI) [1] mechanisms to manage which entities are provided access to a given resource. Authorisation for a resource is described using an access control list (ACL). Each entry in the ACL describes a set of entities and their assigned roles and authorisation characteristics, such as read and write permissions.
An entity that has a sufficiently high authorisation is able to modify the ACL itself and control the authorisations of other entities. Granting authorisations to other entities in the system is called delegation. We shall refer to entities that have the power to delegate authorisation to other entities as administrators of a resource.
Typically, existing SPKI systems delegate authorisation by letting administrators create a new entry in the ACL and signing it with an administrator's cryptographic key. The authorisation describes the role granted and a set of entities by their public key. The updated ACL is then distributed across all relevant entities in the network and the entities are made aware of the new authorisation.
While this approach works well, it lacks the flexibility and accountability that is often desired in a modern distributed networking context. We found several areas for improvement:
First, it is possible that the entity desires no authorisation at all for a given resource. In a distributed file system, an entity from one organisation could desire to never have any authorisation for sharing files from another organisation.
Second, in a decentralised environment it is not uncommon for entities from different administrative domains to share authorisation on a resource. For example, several organisations might be working together on a single project. Each organisation has their own structure and wants to control allocation of authorisation to a specific entity under their control. Examples might be a large company that wants to select a consultant for a particular authorisation on a project or a network administrator that wants to select a server based on expected load from the company's server collection. In traditional role-based access control systems, the administrator of one organisation would need to know the entity's public key of another organisation before granting authorisation. This requires prior dialogue and collaboration between domains and does not scale well. Authorisation and allocation decisions like these should be separated in two operations local to each organisation's domain, and without needing to select an already existing entity.
Third, entities might only be sparsely connected and have no way to directly verify the willing co-operation of other entities in the same ACL. This can lead to misconceptions about the participation of other entities.
To avoid these scenarios we have added an extra layer to traditional role-based access control in the form of an invitation-response dialogue between entities before authorisation is confirmed. In our model, instead of a list of authorisations to entities directly, the ACL of a resource consists of a list of role invitations.
Each invitation in an ACL is identified by its own public key. An invitation describes the life cycle of an association between an entity and a role for the resource the ACL is linked to. An example could be that an entity is invited to become an administrator for a certain filesystem. Invitations always start as invited, and can be accepted, rejected, or terminated. The invitation can start anonymous or be associated to a specific entity. An entity needs the private key of the invitation to claim it. This key can be distributed through the network and encrypted using the entity public key or through a private channel. Claiming an invitation is done by signing the invitation using the invitation's private key. If the invitation is accepted, the invitation is also signed using the entity's private key and distributed across the network. The entity is then able to use the authorisation described in the invitation for as long as the invitation is active.
Terminating an invitation is performed by signing a special 'end signature' field in the invitation. This can be done by the entity which claimed the invitation (the entity leaves this role), or by an administrator (the entity is removed from the role). Because invitations are part of the ACL, they can only be created by an administrator.
Results
Using an additional invitation layer in the ACL yields several advantages: Every entity possesses plausible deniability for abusing any authorisation that it did not accept itself. Authorisation delegation (a task for a delegator) can be separated from entity selection for that authorisation (a task for a delegatee). Additionally, entities in an ACL can verify the acceptance of authorisation of their peers without needing to contact each other directly. Together, these measures increase flexibility, transparency and accountability in setting up shared resources across administrative domains.
This work was carried out for the Secure Information Grid project [L1] under an RVO SBIR grant.
Link:
[L1] http://www.rvo.nl/sites/default/files/SBIR12C020%20Secure%20Information%20Grid.pdf
Reference:
[1] C. M. Ellison, B. Frantz, B. Lampson, et al.: “SPKI Certificate Theory”, IETF Request for Comments 2693, 1998.
http://www.ietf.org/rfc/rfc2693.txt
Please contact:
Arthur Melissen, Michel Eppink
Coblue Cybersecurity, The Netherlands
