Decentralized Management of Access Control

Decentralized Management of Access Control Olav Bandmann, Babak Sadighi Firozabadi, Olle Olsson

Swedish Institute of Computer Science, Kista, Sweden 1 February 23, 2001

1 This

project was supported by FMV

Executive Summary This report describes the results of a study of the problem of managing access privileges in an organization. There is a critical need to assure that subjects (e.g., users or applications) are allowed to access only those resources (e.g., data, information, applications) that they are authorized to access. In an environment where the organizational structure is decentralised, exible and dynamic, and where the information technology infrastructure is distributed and dynamic, access privileges must be easily managed. This imposes requirements on the models and mechanisms supporting changes of privileges. Such models and mechanisms must be:  exible and adaptive; it must be easy to make changes in the current set of

privileges, and these changes must take eect immediately.

 expressive; it must be possible to express the privileges implied by the or-

ganisational structure.

 decentralised; it must be possible to make changes in the set of privileges lo-

cally, not having to rely on central administrators to eectuate these changes.

Present-day models, mechanisms and technology does not support these requirements fully. This report describes results produced in a study performed by SICS which was sponsored by Forsvarets Materielverk (FMV). The main results are models for representing privileges, models for representing organisational structures (w.r.t. management privileges), and a mechanism for delegating privileges. These models and mechanisms are based on the concept of credentials: a request from a subject to access some resource is accompanied by a set of credentials. These credentials express the reasons why the subject should be allowed access to the resource. The local security management system that manages this resource evaluates these reasons, and permits or denies access accordingly. We relate the concept of credentials to digitally signed certi cates, as a way of guaranteeing un{forgeability of credentials. The delegation model permits privileges to be managed locally, and provides a structured way of distributing constrained privileges. In summary: this report describes a model that provides a conceptual framework for decentralised management of access privileges, satisfying requirements on adaptiveness and expressiveness.

Chapter 1

Overview 1.1 The Problem Increased use of open and dynamic networks and applications built upon these networks has raised a number of new security issues. Beside the problem of authentication in open networks, there is a need for a exible and decentralised model for managing security policies and in particular access permissions. Organisations change over time, and managing how a change re ects on actual access permissions can be an error-prone and cumbersome task. Because of more interactivity between organisations through computer networks, there is a need to not only install own privilege changes but also to keep track of certain changes in collaborating organisations. The main focus of research and development in access control mechanisms has been to answer the question \who is permitted to do what?". But the question \who is authorised to update access permissions" has not been examined as much. This is primarily an organisational issue, and the existing models and systems do not capture it. In such systems, there are designated administrators who implement the organisational decisions into the data systems i.e., by updating its access control lists. But rapid changes in organisations will require a better model of updating access permissions. To solve the issue of changing access permissions as a result of rapid changes in organisations, we need models that capture conditions and mechanisms for these changes. In order to make the update procedure exible and faster, we need to decentralise the management of privileges. This means that we need to enable managers at various levels of an organisation to implement their decisions directly in the system, instead of having system 1

administrators implementing decisions made by others. Decentralising management of privileges requires a mechanism for delegating various privileges in the organisation. The idea is that authorities propagate from higher levels of an organisation to its lower levels, through delegation. Traditionally, access permissions are encoded in access control lists (ACL). For each object of a system, there is an ACL which contains the subjects (e.g., the users) and the actions each of these subjects is permitted to perform on the object. In the recent years there have been eorts to use digital certi cates to distribute authorisations between users. The most well-known approach is trust management [BFL96, BFIK99]. The idea is that a user together with his access request to an object provides a number of credentials that prove his right for that access. It is the server in control of the object that validates the certi cates and also check whether they comply with its local policy before it grants or rejects the requested access. Parallel to the trust management approach, Simple Public Key Infrastructure (SPKI) [EFL+ 99] was introduced as a standardisation proposal for digital certi cate designed in particular for authorisation. The idea is that the SPKI certi cates can be used as credentials by a user that makes a query to a server. Although this approach solves some of the issues of the traditional ACL model, it does not address issues related to the management of privileges.

1.2 The Goal One of purposes of this project has been to examine the need for exible and decentralised management of security policies in military scenarios. However, the main goal of the project is to develop a model for decentralised management of privileges and also to show its bene ts by giving some examples. Since we are addressing the management issues in our model, we need to study these issues from an organisational aspect before we suggest any technical solutions. From the organisational point of view, it is useful to have a generic model to represent a management structure, in terms of power relations in an organisation, and also to represent how such a structure can change.

2

1.3 The Results The results of this study is a model for:  mapping access permissions  mapping management structures  realising a delegation mechanism

The delegation mechanism is the core concept of the model by which a management structure can be created and changed in a controllable way. These results are described in this report and some examples are given to illustrate what we mean by a management structure and how the delegation mechanism works. As part of our scienti c work, we characterise concepts such as empowerment, authority and permission. We also examine how these concepts can be used to develop a conceptual framework for decentralising management of access privileges. We compare these ideas with more traditional models for representing and reasoning about access permissions. Furthermore, we de ne the concept of constrained delegation and propose a formalism based on regular expressions. We relate our work to the most recent results in distributed authorisations such as trust management and simple public key infrastructure (SPKI). The latter is a standardisation proposal at IETF. The requirements upon which this work is based were identi ed through a process of collaboration between FMV and SICS. The envisioned context in which the results shall be used is future military applications and infrastructures, characterised by openness, adaptiveness, decentralisation, and mobility.

1.4 Overview of this report In Chapter 2, we start with describing the traditional model for encoding access permissions. We present some of the drawbacks of this model, and discuss in more details the issue of managing access permissions in a dynamic environment. Later, we present two possible approaches, bottom-up and top-down, for creating a management structure. Further, we introduce the notion of declaration certi cates and discuss how a management structure can be created by a delegation chain. Finally we discuss two possible architectures. The rst one is based on a centralised control mechanism for 3

management activities. The second one has no centralised control mechanism. We brie y discuss the advantages and disadvantages of these two architectures. In Chapter 3, we give a brief overview of possible infrastructures for authentication/authorisation. This overview is structured in two, to some extent, orthogonal dimensions. One is the choice between public key methods and symmetric methods (and combinations in between). The other dimension is the span between the two extremes of assuming that local networks are completely isolated, with respect to communication, and assuming unrestricted global communication (at any time). In Chapter 4, we present a scenario that highlights critical requirements on security and access in a decentralised and dynamic adaptive environment. It also illustrates how our model supports these requirements. In Chapter 5, we describe a formal model for constrained delegation, which supports the requirements noted in chapter 4. We illustrate this model by applying it to a simple example.

Acknowledgement  We would like to thank Thomas Odman, Mats Ohlin, and Johannes

Lindgren at FMV for their support and for many valuable discussions. We are also grateful that FMV arranged a meeting with Professor Virgil Gligor from Maryland University in USA, which gave us the opportunity to present our ideas to him. Virgil Gligor gave a number of valuable inputs for future directions of this work. During this project, we have had many valuable discussions with a number of researchers. Hence, the authors would also like to thank Mads Dam, Andres Martinelli, Bjorn Bjurling from the AMANDA group at SICS, and also Leon van der Torre from Virje Universiteit Amsterdam, who visited us at SICS in October 2000. Of course, the input of these people has in uenced the work presented in this report.

4

Chapter 2

Background and Concepts Access to resources and services of a system or an organisation are usually subject to certain rules and regulations. Such rules and regulations can be expressed at various levels of abstraction. In his well known paper [Lam74], Lampson introduces the access matrix as an abstract model for representing access permissions to objects of a system, e.g. the applications and the les of the system. The idea is to de ne a matrix where each row represents a subject of the system, each column represents an object of the system, and each cell that is the intersection of a row and a column represents the actions that the subject of the row can perform on the object of the column. Typical actions in these systems are the following: read, write, delete, and execute. For practical reasons, one does represent access permissions either in terms of the columns of a matrix (Access Control Lists (ACL)), or in terms of the rows of a matrix (Capability Lists). However, the ACL model is the most implemented model, in which one keeps associated to each object, the list of subjects and the actions that they are permitted to perform on the object. The ACL model is simple and eÆcient for representing and for looking up access permissions of a system's objects. For any regulation system, there is a need for an enforcement policy and an enforcement mechanism that ensures the given access permissions. An example of enforcement policy is the separation of duty policy which describes how dierent agents should be authorised for certain tasks in order to decrease the risk of fraud. For example, within an organisation no one should have both a purchaser's and an invoicer's privileges. Usually in computer systems such as operating systems the component that enforces or monitors the access permissions is called the reference monitor. The refer5

ence monitor works in such a way that each access request goes through it, and it grants access based on the enforcement policy and given permissions. Here, we will use the neutral word the enforcer to refer to the component that implements based on an enforcement mechanism.

2.1 Distributed Authorisation In the past few years, there has been a focus on how to solve the issue of authorisation in distributed and open systems. The most well{known approach is called trust management, [BFL96, BFIK99]. The basic idea in this approach is that a client together with his request, provides credentials that prove his right to what he requests. Then, the server receiving the request must answer the question \Does the set of credentials C prove that the request r complies with the set of local policies P?". One can have various types of solution for how to gather and reason about the credentials. One solution could be that each client gathers all the necessary credentials and provides them to the server, which does the reasoning. Another solution would be that the server both nds the necessary credentials and also does the reasoning. A third solution that is proposed in [AF99], is that the client not only provides the credentials but also a proof of his right to what he requests, and the server only checks the proof. Parallel to the trust management approach, research is done on how to use public key infrastructures for distributed authorisation. The most known PKI approach for authorisation is called Simple Public Key Infrastructure, (SPKI), [EFL+ 99] 1 . The original ideas behind distributed authorisation in open environments is described in [BGS92], in which the authors discuss two dierent approaches: server based and infrastructure based. In the rst approach, each server decides, based on its policies, whether to grant or reject access to the objects in its control. The idea here is the source of each authorisation must be the server that is in charge. In other words, a valid delegation chain of an authorisation is a cyclic chain starting with and ending at the server in control. In the infrastructure based approach, the servers are not the highest authorities in the system. Instead other components hand out access certi cates (capabilities) to clients, by applying some security policies. The 1

In the beginning the SPKI was mainly developed for addressing the authorisation issues, but later it was merged with Simple Distributed Security Infrastructure, (SDSI), [RL96], which was mainly addressing the issue of naming in large distributed systems such as the Internet.

6

authors of [BGS92] argue that the server based approach is more practical, mainly because the veri cation procedure can be made by the server at the time of request. This implies that changes in authorisations, i.e. revocation of access certi cates, can easily be managed. Which approach to implement in a speci c case would of course be dependent on the type of application. However, many of the real distributed applications require an infrastructure approach in which for certain type of access there are designated agents that are authorities having the necessary power. For example, a server that grants access to its services based on payments would accept a payment certi cate issued by a bank which is recognised by the server as an authority for payment certi cates.

2.2 The Drawbacks of the ACL Model Although the ACL model is well suited for representing authorisations and eÆciently look them up, it has a number of drawbacks:  Many applications operate in open environments, in which the iden-

tity of potential clients of a service may not be known in advance to the server. This makes it impossible to create and use ACLs as authorisation records. What is needed, for such applications, is a method and an infrastructure that supports introduction of new clients and blacklisting of some of the old ones.

 When the security context gets more complex as the environment

grows more heterogeneous, then there is a need for inferring various information for proper access decisions. But, the ACL model does not capture any inference mechanism.

 In many applications, an access decision is not based on the identity of

the client, but perhaps based on some other attributes of him, i.e. the balance of his bank account, or his age. This makes the ACL model unsuitable since it is identity based. Note that identities do not change as frequently as some other attributes of agents, e.g. the balance of their bank accounts, and hence a more exible model capturing dynamics of this type of attributes would be useful.

 The model is static and its administration is usually performed in a

centralized way, i.e. designated administrators apply changes to the ACLs' entries when they are required. There are at least two issues involved here: 7

1. The model does not map the management power/responsibility structure of an organisation, hence it is diÆcult to decentralise the management such that updates can be performed locally, at the point of the update decisions. 2. It relies to much on the trustworthiness of the administrators, since they usually are given full power to modify these lists. This can in fact be a serious security weakness in a system, because it enables administrators to abuse their power.

2.3 A Model for Decentralized Management In this research we address the issues presented in the previous section, by developing a model that not only support the speci cation of access control permissions, but it also supports their dynamics and their management. The issue of the dynamics of policies is described in the Department of Defence (DoD) Goal Security Architecture (DGSA): The issue of who may change the security policy, how it may be changed, and what change means in a distributed system are still subjects of research; however it may be hypothesized that security policy may be organized so that some or all attribute values may be changed dynamically, but the structure of a policy and its attributes may not be changed, except through administrative creation/deletion of a policy. Delegation is commonly used as an act of distributing access permissions among the agents in a distributed system. However, there is no standard de nition of this term, and it is used in at least the following two ways:

1. Delegation in terms of creating new privileges: The delegatee receives his own privilege that is independent from the delegator's privilege in the sense that if the delegator's privilege is revoked, then it does not necessarily mean that the delegatee's privilege is revoked. In this case delegation is the act of issuing a new privilege. An agent may have the power to create a privilege for another agent without having that particular privilege himself, or even be empowered to create that for himself. Transfer of a privilege can be seen as a creation of a new privilege and revocation of an old one. 2. Proxy type delegation: The delegatee does not receive his own privilege, but he can exercise the privilege of the delegator, in the 8

sense that he speaks for or acts on behalf of the delegator. In this case, if the delegator's privilege is revoked, then the delegatee cannot exercise that privilege anymore. Some applications may require support for both of the two types of delegation, hence a model that captures both would give a better support for the dynamics of access permissions. In the model we propose here, the act of delegation will be de ned in terms of declarations and revocations as illocutionary acts with declarative force 2 . A declarative illocutionary act is an act that, if successful, brings about some institutional fact, namely the fact that is in its scope. A declaration act is successful only if its declarer has the necessary institutional power for it, for more details see [FS99]. An example of institutional power is the power of a manager, within an organisation, to create certain institutional facts that are recognised by that particular organisation. For example, the head of an organisation (O) is empowered to employ new members for O and perhaps create some privileges for them, whereas a low ranked employee may not have any of these powers. 2.3.1

Management Structure

Any organisation can be structured by means of its management relations and its management roles, as in gure 2.1. Each role can be seen as the set of privileges (permissions and institutional powers) that each of its occupants gets. A management structure is a tree describing the hierarchical relations between empowered agents in an organisation. If x is a higher level manager than y, then x is empowered to change the management structure at the level which y belongs to. In [FvdT98], we address the issue of nested control levels, and we argue that an information system could be decomposed into a core system and its control systems. This means that, the access permissions to the resources could be de ned as the permissions in the core system or the level 0. The permissions governing changes of the permissions at level 0 would be the level 1 permissions, and so on. We further argue that the regression of these control levels are practically stopped at the level in which one either strongly trusts the agents performing actions at that level, or believes that the risks involved at that level are negligible. Here, we discuss two possible approaches of constructing management structures: the bottom{up approach and the top{down approach. We also 2

For details about illocutionary acts and speech acts we refer to [Sea69, Van90]

9

SICS The Managing Director

Financial Dept.

Research Dept.

Finance Director

Scientific Director

Research Gr. 1 Group Leader

Researcher 1

Research Lab 1

Research Lab 2

Lab Leader

Lab Leader

Research Gr. 2

Research Gr. 3

Group Leader

Group Leader

Researcher 2

Research Lab 3 Lab Leader

Researcher 3

Figure 2.1: Organisational chart representing a management structure discuss the advantages of the top{down approach for decentralisation of the management of authorisations.

Bottom{up approach In the ACL model, each object has a list associated to it. Each entry of this list (ACE) contains a subject and a list of actions that this subject is permitted to perform on the object. The management of an ACL is usually done by the owners of its objects and/or some designated administrators. A ne{grained management of ACLs can be achieved by seeing an ACL as an object which has its own ACL, listing its managers and their permitted actions. For example, one could permit some agents only to read the content of an ACL, while some other agents to update its ACEs. This corresponds to the case where some agents are assigned to update a row in an access matrix, by extending the matrix with a new row with the ACLs in the previous row as its objects. Of course this second level ACL can itself be seen as an object with a third level ACL containing its managers and their permitted actions. This will lead to a regression of ACL levels, and theoretically one can build an in nite number of ACL levels between the object and its owner. In practice, regression is normally terminated after a small number of levels, leaving ner managerial 10

structures to be resolved outside the system. An even more ne{grained management of access permissions can be achieved by regarding each ACE of an ACL as an object which has its own ACL, listing its managers and their permitted actions. This corresponds to the case where some agents are assigned to update a cell in an access control matrix, by extending the matrix with a row with that cell as its object. Again, one can create an in nite number of management levels between an object and its owner. One can see the nested levels of ACLs representing the actual power structure in an organisation. This means that the owner of an object or a resource can create a hierarchical structure for updating the existing access permissions and management powers. In other words, the owner can determine who is permitted to access an object, who is empowered to change that permission, who is empowered to change that power, and so on. Note that, although this is a power structure for performing changes, there is no dynamics for the changes of the structure itself i.e., within the model there is no support for the creation of the ACL levels. Note that, the structure can only be built and/or changed by the owner or the designated administrators. The power structure in an organisation changes over time, and an authorisation model should have an automated support for these changes. In addition to this, changes are usually made locally, where the empowered agents can restructure their own sub{organisations i.e., when an agent appoints some new managers at the level below to control parts of his sub{ organisation. In the bottom{up approach, the activities for changing the actual management structure are centralised.

Top{down approach Here, we suggest a new methodology for creating a dynamic access control mechanism. In this approach we do not only address how to represent a management structure but also how to change such a structure i.e., how to create new levels of management. In other words, besides a method of changing information at the access level, we describe a method for changing the structure of authorisation management. We de ne a primitive action operator called declares, an illocutionary act with a declarative force. An agent creates/modi es/deletes a permission or an empowerment by declaring it. A declaration can also be used as the means for creating a relation or for assigning an agent to a role. Note that, each of these declarations will require that its declarer has the necessary institutional power. 11

The Owner

Root Level

The Owner

ACL Level 0

Obj

Object Level

The Owner

Root Level

ACL Level 1

ACL Level 0

Obj

Object Level

The Owner

Root Level

ACL Level n

ACL Level 1

ACL Level 0

Obj

Object Level

Figure 2.2: The Bottom{Up Approach 12

The idea in the top{down approach is to let the access control lists be created/modi ed/deleted by the managers who make the decisions. Any access permission is either directly created by the owner of the object or indirectly created by the managers of the object. In the top{down approach we start from the ownership relation between a subject and its objects. The initial ACL for an object is automatically created from the ownership relation of the object, i.e. the owner of an object may originally receive the permission to perform any action on his object. Beside these permissions stored in the object's ACL, the owner will also have complete administrative power over the object. This means that the owner can assign other subjects to create/modify/delete various permission concerning the object. A more ne{grained management would be that the owner not only assigns some subjects the necessary management powers for creating new permissions, but also give them the power to assign new administrators for this object. These administrative powers resemble the organisational levels of an organisation, where the top level is represented by the owner of the object, the lowest level is represented by those who have actual permissions to operate on the object, and the intermediary levels represent all the possible administrators who have received their powers directly or indirectly from the owner. A similar approach is given in [EFL+ 99] by giving an example of how to manage the policies of the rewall at the department of defence, as quoted below: . . . One could not, for example, have someone in the Army have the power to decide whether someone in the Navy got access. In fact, the ACL would probably need not one level of its own ACL, but a nested set of ACLs, eventually re ecting the organisation structure of the entire Defence Department. By contrast, let the access control be controlled by authorisation certi cates. The rewall would have an ACL with one entry, granting a key belonging to the secretary of defence the right to delegate all access through the rewall. The Secretary would, in turn, issuing certi cates delegating this permission to delegate to each of his or her subordinates. This process would iterate, until some enlisted man would receive permission to penetrate that rewall for some speci c one protocol, but not have permission to delegate that permission. The certi cate structure generated would re ect the organisation structure of the entire Defence Department, just as the nested ACLs would have, but the control of these certi cates 13

Top Level Management Level 1

The Owner Man 1

Man 2 Man 3

Management Level 2

Object Level

Top Level

Management Level 2

The Owner Man 1

Man 1.1 Man 1.2

Object Level

Man 2 Man 3

Man 1.3

Man 3.1

Management Structure

Management Level 1

Obj

Obj

Figure 2.3: The Top{Down Approach

14

(via their issuance and revocation) is distributed and need not show up in that one rewall or be replicated in all rewalls. . . . The SPKI approach is based on a top{down model, in which one identi es the most trusted level in the organisation i.e., the head of the organisation or the owners of the resources, and then lets the other levels be de ned dynamically and in a decentralized manner, by delegating and revoking SPKI certi cates.

2.4 Declaration Certi cates and Delegation Chains As described earlier, a declaration can be seen as an act of creating a fact, which is successful only if its declarer has the necessary power to create that fact. However, this power must have been given to him by another agent with necessary power to give that rst power to him. This means that for an agent to receive a privilege (a permission or a power), a chain of declarations must have been made. Indeed, any declaration chain must be anchored to an agent with the initial power. We call this agent the root of the chain. Usually, the root of a chain for a permission concerning an object is the owner of the object. For example, a permission to withdraw money from a certain bank account must be given either directly (one step delegation) or indirectly (several steps delegation) by the owner of the account.

2.5 Architectures In this section, we will discuss various possible architectures for a dynamic access control mechanism. Dierent applications and dierent scenarios will require dierent architecture solutions. For practical reasons we distinguish between the access level and its management level. The main two reasons for this distinction are: 1. The number of access requests are normally much larger than the number of management requests. Notice that it is very fast to look up an access permission in an ACL. 2. The ACL model is commonly used and it would be bene cial to keep that structure in the existing applications, and only support the changes of these ACLs.

15

Management Level Object Level

Manager Authorisation Server

Manager Manager

Access Enforcer

App

Figure 2.4: The two control levels Let the permissions for actions on an object be represented in an ACL. Let the access to the objects of a system be enforced by the system's enforcement mechanism e.g., its reference monitor. In addition, an authorisation server could be introduced for updates of the ACL and its management structure. The enforcer of access permissions is supposed to answer the question \Is the requester X permitted to perform the action it requests on the object?". The enforcer at the management level is supposed to answer the question \Is the requester empowered to make the changes he requests?". Here, we suggest the use of digital certi cates for declarations. A declaration certi cate will be a tuple of the following form: (Issuer, Subject, Privilege/Attribute, Validity Interval, Time Stamp). The issuer argument is an identi er of the person issuing the certi cate. The identi er can be either the distinguished name or the public key of the issuer. The subject argument is an identi er of the individual, the group of individuals, or a role that will enjoy the privilege. The privilege/attribute argument is an expression representing a privilege (a permission, or a power), or an attribute such as a group membership, or a role occupation.

16

2.6 Centralised Control vs. Decentralised Control One of the main issues addressed in [BFL96, BFIK99] is how to solve the issue of authentication and authorisation in a highly distributed architecture, where there is no central directory for all access permissions and no centralised enforcement mechanism. In this approach either it is the job of a client to show the server, in control of a resource, that he has the permission for his request, or it is the job of the server to gather the necessary credentials that support the request of its client. In both cases, a request will be granted only if there is a chain of delegations starting from the server and ending with the client. However, in none of these two cases, there is a central registry for credentials. In this type of architecture, revocation is a hard problem, since there may not be any central registry of all the revoked credentials. It is also very hard to enforce any kind of global constraints, when validity of one privilege is dependent on the existence or the absence of some other privileges. For example, if a server grants agent a the privilege p, conditionally on that a does not already have a privilege q , then it can be practically impossible for the server to determine whether the agent has received q from somewhere else. Another type of global constraint that is diÆcult to enforce is when an agent receives a privilege usable only a limited number of times. For example, when an agent receives a ticket (as a digital certi cate) that he can use only once. In the lack of a central enforcement, the agent can use as many copies of the ticket as he wants without being detected. All these examples can be reduced to the issue of not having a central registry of revoked certi cates, and a central enforcement mechanism. There are suggestions to use short{lived certi cates in order to decrease the damage resulting from no revocation mechanism. A short{lived certi cate is a certi cate that has a relatively short validity interval. However, this is not a very satisfactory solution for certi cate revocation in many distributed applications, because it requires that the server issuing the certi cates is always online and reachable. Another approach would be to have a central registry for certi cates that can be reached by a number of applications. This, of course, does not support applications of a fully distributed nature, but it does support the decentralisation of privilege management. For instance, all management activities will be performed using a component called authorisation server (AS). This authorisation server can be accessed both by managers and applications or access enforcers of an organisation. The managers perform their declarations by sending declaration certi cates to AS and the applications consult AS for making access decisions. This is shown in gure 2.4. 17

2.7 Constrained Delegation of Empowerments As we have discussed earlier, delegation is the core concept of our approach. We have argued that a exible method for decentralising the management activities in an organisation can be achieved by enabling delegation of privileges. Distinct from other approaches such as [EFL+ 99], we would like to support managers to constrain the future delegations. There are many reasons for having a mechanism for constraining a delegation chain. For example, a manager may want to restrict a permission only to a group of users independent of the chain of delegations that leads to that permission. Assume the scenario in which the owner of an object appoints another agent as the administrator of his object in the sense that this administrator can give access permissions to a certain group of users, to which he may not belong himself. By enabling constrained delegation, in the top{down approach of a management structure, a manager can control the boundaries for how the future management structure originating from him can develop. This feature is useful in many scenarios e.g, when one organisation out{sources some management activities to another organisation. In Chapter 5, we discuss a formalism for representing constrained delegation and we also give an example to illustrate the bene ts of it. The delegation-by-proxy model inherently constrains what privileges can be delegated: no more privileges can be passed on than was received. A departure from this model, however, makes the handling of constraints an absolute necessity.

18

Chapter 3

Cryptological Infrastructures Before we delve into the scenario we will give a brief comparison between symmetric and asymmetric (public) key systems, both in a centralised and a decentralised context. In the rest of the report centralised will refer to systems where there is a globally trusted authority that is reachable almost all the time. For decentralised systems, on the other hand, we do not assume networked units to be in contact with central trusted authorities most of the time, hence requiring them to make autonomous security decisions. Note that, the terms centralised and decentralised were used earlier for management activities, which is dierent from the use of these terms here.

3.1 Symmetric Key Approach In this section we assume that only traditional symmetric key crypto systems are employed in encryption, authentication and authorisation. We begin with a simplistic approach. In a decentralised scenario, it is hard to imagine that every entity has its own security identity. If this is the case, it implies that every node in the network has access to a complete ACL for all entities (the entire personnel/hardware) that might ever have to get authorisation for something in this network. Furthermore, the authorisations will have to be known in advance. The conclusion is that there has to be relatively few keys and the authorisations will normally need to be very liberal. Thus, no ne grained authorisation structure is really possible. On the other hand, with fewer keys that have a larger spread, the system will be more compromised in the case of key exposure and the risk of key exposure increases. A more complex (centralised) approach is to use one or several trusted 19

authorities, that are reachable at the time of the request (or shortly before), which grants \tickets" a la Kerberos. In this approach every entity needing authentication has its own unique key. This key can be used to request authorisations from a central server. Whenever an entity A wants to requests something from B he contacts a central server which gives him a ticket (if the request was granted). This ticket can then be used by A (for some limited amount of time) to prove to B that his request is authorised. Although such a scheme can be elaborated on further, e.g. by granting tickets that authorises entities to grant tickets themselves and thereby introducing a ticket granting hierarchy, this approach is still rather centralised and non exible. It is also communication intensive with all the potential problems and vulnerabilities that entails. >From our perspective, an even more interesting problem is how such a system is administered. How does the central server know who is authorised to do what? If one assumes a huge ACL stored at some central server, then the administrative workload becomes unreasonably high. Furthermore, how are all the implicit and explicit rules in the military organisation enforced? These are some of the main issues that our model addresses.

3.2 Public Key Approach In this section we assume the use of public key crypto systems for (at least in part) encryption, authentication and authorisation. In particular encryption could with advantage use a combined approach: symmetric keys combined with public key methods. This could signi cantly strengthen the system regarding key exposure compared to a pure symmetric key approach. We rst discuss a centralised model. As in the \Kerberos{style" approach every entity needing authentication has its own unique key (pair). This key can e.g. be used to request authorisations from a central server. An entity C can sign credentials and send them to the authority, thus enabling e.g. A to retrieve them later on. Whenever A needs these credentials to prove (perhaps at some later point in time) that he is authorised to request something from B , he contacts one of the authorities which gives him the credentials signed by C . In this centralised model, revocation of certi cates is not hard. As in the symmetric key case, one drawback of this approach is its centralised communication intensive nature. But, as we shall see later on, many of the problems of this model can be eliminated by sacri cing strict enforce20

ment of global constraints. Similarly to the \Kerberos{style" approach, the administration of authorisations present a real problem. Should very high ranking oÆcers sign each and every certi cate whenever someone needs an authorisation? If not, how is the management of authorisations to be organised? This problem will be addressed later on. We now consider a decentralised public key model. In a trivial sense this might be regarded as the public key version of the \simplistic" symmetric key approach. There are however several very important dierences: 1. Every entity in this model can still have a unique key (pair). This, combined with a certi cate proving the identity of the key holder, will enable authentication. One can thus retain a ne{grained user model. 2. In a similar fashion, certi cates carried by the user can be used (together with the local policy of the receiver of the request) to prove to the receiver that the user has certain authorisations. Thus, no ACL is needed and a ne{grained authorisation model can also be retained. 3. There is no need to specify all authorisations in advance. In principle a high oÆcer, who has the administrative power to do so, could sign a certi cate granting an authorisation \on the y", and transfer this certi cate to someone whenever this is needed. Thus, it enables adaptiveness. The main drawback with the decentralised approach is that it becomes much harder to enforce global constraints and to adapt to non{anticipated global changes. E.g. revocation becomes diÆcult since this information (that a certain certi cate has been revoked) is hard to distribute. As in the centralised model, the administration of authorisations becomes very diÆcult. Should e.g. the \owner" (some high ranking oÆcer, say) of a certain set of hardware devices personally sign all authorisations to use these devices? If so, he may have to be in many dierent places at almost the same time if the system is to retain its adaptiveness, or at least sign the certi cates and send couriers (remember that we did not assume continuous on{line communication). Not a very desirable situation! Even if we allow some limited communication, the fact that this oÆcer needs to spend time signing a, possibly large, set of certi cates does not seem desirable. If one furthermore considers that the total number of personnel and machinery might be very large, and that every entity must have its appropriate authorisations at any moment in time when they are needed, these problems are likely to become insurmountable. 21

3.3 Conclusion By combining the centralised and decentralised public key models, using freshness constraints 1 on received certi cates in the local policies, one gets a better trade{o between global enforcement and local autonomy. In all the described models, the management of authorisations was never decentralised. This is an important reason why the management becomes very diÆcult. To address this problem, we propose a model in which controlled delegation of management power is used to decentralise the management of authorisations.

1 A freshness constraint is a condition on the amount of time elapsed since the certi cate was issued.

22

Chapter 4

A Scenario This chapter describes a scenario that highlights critical requirements on security and access in a decentralised and dynamic adaptive environment. It also illustrates how our model supports these requirements.

4.1 Preliminaries In this scenario we will assume that authorisations are hierarchically organised and that network entities (personnel/hardware devices) are organised in groups. Roles will be used to model dierent functions in the armed forces. Entities in the system may have several keys, e.g.:  A \personal" public key pair for authentication.  One or several root keys to which certi cates may be chained. These

keys are public keys. One of them corresponds to the secret key of the \owner" of the entity. Another is used for chaining authentication certi cates. Etc...

 A symmetric key for changing the other keys and/or changing the

policy (a \re{PROMing" key). We use certi cate chaining to enable decentralised o{line authorisation. To illustrate this mechanism we give a simple example of unconstrained delegation. The idea is as follows: 1. Let S0 ; S1 ; : : : ; S be entities and let pk0 be the public key of S0 . n

2. The device E contains pk0 as a root key and a policy that says that any statement signed by S0 is regarded as valid. Furthermore, E controls read access to a le f . 23

3.

signs a certi cate stating that any statement signed by S1 is valid. S1 signs a certi cate stating that any statement signed by S2 is valid, and so on until S 2 signs a certi cate stating that any statement signed by S 1 is valid. S0

n

n

4. Finally, S le f .

n

1

signs a statement, stating that

Sn

is authorised to read

5. Later S presents all these certi cates to E , which can now deduce that S should be granted read access to the le f . n

n

4.2 The Scenario This scenario concerns the life{cycle and use of some piece of equipment (e.g. a weapon) by an organisation (e.g. the armed forces). It is described in terms of events in which this equipment is a critical component, events that have important security implications. The main events of the scenario are: 1. The equipment leaves the factory 2. \Mobilisation" (new personnel arrives) 3. Personnel in the eld try to accomplish an anticipated goal 4. An authorisation con ict arises 5. Unanticipated events that require new authorisations 6. Unanticipated events that require removal of authorisations The scenario will be presented from two dierent views: an external view consisting of what the users see and do, and an internal view giving the system level perspective on the events. The internal view concerns details in the \behind{the{scene" technical mechanisms, mechanisms that belong to the technical infrastructure. 4.2.1

External View

\What the user sees and does"

1. The Equipment Leaves the Factory Before the equipment is moved to wherever it is supposed to be, it is initialised electronically by personnel from the armed forces.

24

2. Mobilisation All the personnel that arrives at the mobilisation site receives an initialised Personal Electronic Device (PED) together with the rest of their equipment. This device is personalised at that time. When an oÆcer meets his subordinates (for the rst time) to brief them and give them orders, he gives them electronic information and authorisations using his PED connected to the PEDs of his subordinates. These lower ranking oÆcers repeat this process with their subordinates, etc...

3. An Anticipated Event Using their PEDs, the soldiers in a certain group connect to dierent entities, thereby creating a spontaneous network. They request information from, receive (send) orders from (to) entities in this network using their PEDs or equipment connected to it.

4. An Authorisation Con ict

A soldier S1 is in network connection with the entity E , and orders E to perform some action. The entity E happens to be connected to another soldier S2 in some other group. This soldier orders E to perform some action that contradicts the orders E received earlier from S1 . E resolves the con ict, possibly by querying a higher authority (but not necessarily). E sends a message to S2 that his order has been accepted or rejected. If S1 's order was cancelled, he will be informed of this.

5. New Authorisations A group of soldiers is to perform an operation which might not have been planned/prepared in advance. The local commander transfers necessary information and authorisations to the group leader. The group leader in turn transfers information and authorisations to his soldiers. When feasible, all these transfers can be achieved completely transparently. The soldiers connect to dierent entities establishing a network and accomplish their task. The entities in the network need not be aware of the changes in the management structure that have taken place!

25

6. Removal of Authorisations A group leader GL is missing in action. A commander decides to make sure that GL's administrative power and authorisations are not usable in the future. Note that the powers/authorisations GL has delegated before he went missing, should remain valid in this case. The commander cancels GL's powers and authorisations from now on. When the commander's PED is in direct (or indirect) contact with a central authority, or some of the entities aected by this decision, a message will be sent cancelling GL's powers/authorisations from now on. The commander will be noti ed when the revocation is con rmed. Any entity aected by the revocation will, whenever it is in contact with some other entity having access to the revocation information, check if it's certi cates should be modi ed or revoked. In a similar fashion, aected entities will try to get hold of relevant information regarding certi cates they might receive in the future. A Final Comment on Revocation: It might not be possible for some entities to receive reasonably up{to{date revocation or modi cation information. Small simple autonomous devices might be especially susceptible to this problem. 4.2.2

Internal View

\The system level perspective"

1. The Equipment Leaves the Factory The physical device shipped from the factory is electronically initialised, using a symmetric key. As part of the initialisation process, a policy and root keys are loaded into the device.

2. Mobilisation The personalisation of a PED consists of loading (chains of) certi cates giving the owner of the device the necessary powers to operate within networks and to delegate powers to others to do so. In practice this might be accomplished by attaching the owner to one or several instantiated roles and thereby (among other things) giving the owner power to attach others to (possibly other) roles. An oÆcer delegates administrative power and authorisations to his subordinates by signing certi cates attaching them to roles. These certi cates (and possibly other certi cates that the oÆcer received/signed earlier) are then transmitted to his subordinates.

26

3. An Anticipated Event When the soldiers connect to a network they authenticate themselves (automatically) by sending chains of certi cates rooted at keys known by at least one of the other participants. The entities in the network (including the soldiers) get authorisations for their requests by sending chains of certi cates with known root keys. An entity in a network having the appropriate root key might (if authorised to do so) sign a single certi cate rooted at a dierent root key to transfer authorisations to other members of the network.

4. An Authorisation Con ict An entity in a network receives an order con icting with a previous order. Using its local policy it must resolve this con ict. Its policy might possibly (but not necessarily) require contacting a higher authority or retrieving some global data. Other policy requirements might be any function of local data, e.g.:  Order of arrival  Freshness constraints  Signers group memberships  Signers roles  Etc...

5. New Authorisations The local commander signs and transfers the relevant certi cates to the leader of the new group, a similar procedure as in 2. The group leader in turn signs and transfers relevant certi cates to his soldiers, again a similar procedure as in 2. The soldiers connect to dierent entities establishing a network, proceeding as in 3. Higher commanders, owners of root certi cates or signers of certi cates higher up in the chain, need not be involved in this process. (Unanticipated) local changes to the organisation are completely re ected by local changes in the certi cate structure! Other entities in the networks need not be aware of the changes that have taken place. Thus, the changes are transparent to other network entities!

6. Removal of Authorisations The commander signs a certi cate shortening the validity interval of the group leader's (GL) certi cate.

27

This new certi cate gets distributed, when communication allows, to central authorities and/or local entities directly (or indirectly) aected by this decision. Entities receiving this information will use it to discard (and possibly report) requests that depend on a use of GL's certi cate that has an invalid time stamp. Note that using time{related modi cation information might not be feasible for an autonomous entity if this requires a secure time stamping functionality. Another approach is to revoke GL's certi cate completely and replace it with a new one.

4.3 Remarks A note on secure time stamps The last part of the scenario brings us to a general problem: Even if time information is distributed in some secure way (by satellite or other means), general time{stamped signatures require two way communication. In a one way communication scenario it is not possible to \forward{ date" certi cates, but it is possible to \back{date" them. In a two way communication scenario the time server also signs (a hash of) the certi cate after adding a time stamp to it. A more complex approach might be to distribute time stamping to a higher degree, e.g. to allow local entities to supply time stamping facilities. If one allows time{stamping facilities to be distributed (using certi cate chains) to such an extent that key exposure becomes a real risk, how does one handle revocation of time server certi cates? In a restrictive scenario such a revocation might invalidate (at least to some extent) all certi cates containing time{stamps from one or several time servers.

A note on \public" Networks Some comments on using networks, not controlled by the armed forces, for communication: Using SSL{like protocols, one can set up a secure cryptographic tunnel between the communicating parties. This is done by exchanging freshly generated keys encrypted with public keys (of which at least one must be sent in plaintext). With this tunnel in place, authentication using identity certi cates (signed with known root keys) can take place, preferably beginning with the initiator of the communication. 28

To avoid certain traÆc information to be exposed (IP spoo ng, etc...), and to get a higher level of security in general, a better approach could be to combine the tunnel set{up above with the use of symmetric keys (known in advance by both parties). Thus, one avoids to send anything, except network protocol information, in plaintext. These symmetric keys could have a rather large spread since the damage resulting from key exposure would be limited. After using the set{up above, or some similar scheme, all the authorisation mechanisms mentioned in this report could be used.

29

Chapter 5

A Formal Model for Constrained Delegation A formal model for constrained delegation (cf. section 2.7) is described in [Ban]. In this chapter we present a simpli ed example illustrating this model.

5.1 Assumptions in the Example In this very simpli ed example we will assume that we are authorising read and write access to the directory mission/ which contains two les fa.txt and fb.txt. Group membership will be the only property explicitly treated in this example, i.e. no roles, conditions, auditing requirements, time{stamps, etc... The groups are: 1. A platoon P with commander CP 2. Two groups A and B with group leaders CA and CB 3. Four soldiers:

S1

, S2 , S3 and S4

5.2 Certi cates A certi cate is a signed (and time{stamped) statement used for delegating an authorisation. It consists of two parts:

30

Chain condition describing who can use the certi cate. To use a certi cate means one of the following two things: to delegate the authorisation further (by issuing a new certi cate) or to use the delegated authorisation (see the next item) itself to perform some act. The chain condition also de nes which (one) of these two uses are (is) permitted1. If the chain condition permits further delegation, it contains a description of which resulting delegation chains are permitted (in terms of group memberships, etc). Authorisation describing what is authorised by the certi cate. The authorisation does not concern delegation; it concerns \object level actions" like, e.g., read or write certain les, detonate a mine, give a certain set of orders to information gathering sensors of a certain type, etc... A typical chain of events is as follows: An agent wants to delegate an authorisation. He issues a certi cate delegating the right to another agent to delegate this authorisation further. That agent in turn, repeats this process (by issuing another certi cate), and so on, until this chain of delegations reaches the end user, the one that can enjoy the authorisation. An important point here is that each agent in the delegation chain can use the chain condition part, of the certi cate he issues, to control the rest of the delegation chain, given that this new chain condition satis es the requirements of the previous ones in the delegation chain. It is not obvious how this can be achieved, and it is, in fact, one of the core aspects of our model. In the next section we present the internal structure of chain conditions and explain how they enable this functionality.

5.3 Chain Conditions and their Restrictions Chain conditions are tuples of group names. The group names may be followed by an optional star ( ). What these tuples mean and how they are used is explained below using a small example (before we arrive at the bigger example alluded to in section 5.1). The chain condition (C; D ; E ) e.g., means that the delegation chain must start with a member of C , continue zero or more steps through members of D and nally end with a member of E . In particular, only members 1

it might be both of them

31

of E might enjoy the authorisation delegated (e.g. r/w some le). Anybody in C can sign a certi cate with a new chain condition that is a restriction of the rest of the chain condition, i.e. a restriction of (D ; E ). Restricting a group name without  is done simply by replacing the group with a possibly smaller group. Restricting a group name with a star is done by replacing it by a (possibly empty) sequence of smaller groups, with or without stars. Examples of possible restrictions of (D ; E ):  (E )  (D; E ) or (D1 ; E ), where  (D1 ; D2 ; D3 ; E1 ), where

contained in E .

D1 D1

,

is contained in D D2

,

D3

are contained in

D

and

E1

is

 etc...

If someone in C chooses to use a certi cate with chain condition (C; D ; E ) and sign a new certi cate with chain condition (D1 ; D2 ; E ), he has restricted the chain so that only members of D1 can use this certi cate. They in turn can restrict the chain condition (D2 ; E ), and so on, until we nally reach someone in E .

5.4 Restricting Authorisations The authorisations can be restricted in every step of the delegation. E.g., r/w access to all les in mission/ can be restricted to read access to the le mission/fb.txt. In general, since authorisations are hierarchically organised, a given authorisation A can be restricted by replacing A by any authorisation beneath A in the hierarchy.

5.5 An example of how to use the formalism In gure 5.1, the commander of platoon P (CP ) delegates read and write permissions for the le mission/fa.txt, and the power to delegate these rights further within the group A, to the commander of A (CA) by signing a certi cate. This is denoted in the gure by CP : (P  ) ! (CA; A ). The notation is to be interpreted as follows: CP restricts the delegation chain (P  ) to the chain (CA; A ). In a similar fashion, shown in gure 5.2, the commander of group A (CA) delegates read permission for the le mission/fa.txt to the soldiers S1 and 32

Platoon P CP P  )

Chain: ( Auth:

CP : (P  ) ! (CA A )

;

r/w mission/

;

Group A CA A )

Chain: ( Auth:

;

r/w mission/fa.txt

Figure 5.1: Delegation of r/w access to mission/ directory (1)

Platoon P CP P  )

Chain: ( Auth:

CP : (P  ) ! (CA A )

;

r/w mission/

;

Group A CA A )

Chain: ( Auth:

CA : (A ) ! (S1 ) Soldier S1 Chain: (S1 ) Auth:

;

r/w mission/fa.txt

CA : (A ) ! (S2 )

Soldier S2 S2 )

Chain: (

r mission/fa.txt

Auth:

r mission/fa.txt

Figure 5.2: Delegation of r/w access to mission/ directory (2) (who are in group A). Note that S1 and S2 do not receive the power to delegate this right further. In the gure, this is denoted by CA : (A ) ! (Si ) for i = 1; 2, i.e. CA restricts the delegation chain (A ) to the chain (S ) for i = 1; 2. In gure 5.3 the building of the management structure is continued by CP who delegates read and write permissions for the le mission/fb.txt, and the power to delegate these rights further within the group B , to the commander of B (CB ) by signing a certi cate. This is done in a similar fashion as in gure 5.1. Finally, the commander of group B (CB ) delegates read permission for the le mission/fb.txt to all soldiers in the group B . Again, this does not include the power to delegate this right further. The delegation is denoted by CB : (B  ) ! (B ), i.e. CB restricts the delegation chain (B  ) to the chain (B ). S2

i

33

Figure 5.3: Delegation of r/w access to mission/ directory (3)

34 Auth:

;

Auth:

r mission/fa.txt

Soldier S2 S2 )

;

r/w mission/

CA : (A ) ! (S2 )

Chain: (

r/w mission/fa.txt

r mission/fa.txt

Chain: (

Soldier S1 S1 )

CA : (A ) ! (S1 )

Auth:

Chain: (

Group A CA A )

;

CP : (P  ) ! (CA A )

Auth:

Platoon P CP P  )

Chain: (

Auth:

;

r/w mission/fb.txt

Group B CB B  )

Chain: (

;

CP : (P  ) ! (CB B  )

The dierence between the delegations that CA and CB performed is that CA only gave the permission to the soldiers S1 and S2 in his group, whereas CB gave the permission to any member of his group. If a new soldier S5 in A arrives and he needs to read the le mission/fa.txt he must get the permission to do this from CA (or CP ). On the other hand, if another soldier S6 in B arrives, he can read mission/fb.txt without anybody having to sign any new certi cates.

5.6 Conclusion Adaptiveness in a model for access control is much simpler to achieve if one allows un{constrained delegation, like e.g. in SPKI (described in [EFL+ 99]). The major drawback of such an approach is its weak security/trust model. Another drawback is the inability to allow an agent to delegate an authorisation without being able to enjoy the authorisation himself. Our model overcomes these weaknesses by including a mechanism for constrained delegation. Such a mechanism is essential for enabling the type of functionality described in the scenario (chapter 4) in a secure and controlled way. Our model is the rst model of delegated access control that includes such a mechanism. Note that the description of constrained delegation in this chapter has been considerably simpli ed for ease of presentation. Many extensions are needed and can be accommodated within this framework (details can be found in [Ban]).

35

Figure 5.4: Delegation of r/w access to mission/ directory (4)

36 Auth:

;

Auth:

;

r/w mission/

r mission/fa.txt

Soldier S2 S2 )

Auth:

r mission/fb.txt

Soldier S3 B)

;

Auth:

r mission/fb.txt

Soldier S4 B)

CB : (B  ) ! (B ) Chain: (

r/w mission/fb.txt

Group B CB B )

;

CP : (P  ) ! (CB B  ) Chain: ( Auth:

Chain: (

CA : (A ) ! (S2 ) CB : (B  ) ! (B )

Chain: (

r/w mission/fa.txt

r mission/fa.txt

Chain: (

Soldier S1 S1 )

CA : (A ) ! (S1 )

Auth:

Chain: (

Group A CA A )

;

CP : (P  ) ! (CA A )

Auth:

Platoon P CP P  )

Chain: (

Chapter 6

Summary and Future Work This report has described models and mechanisms for decentralised management of access privileges. The core components are:  A novel approach to solve the issue of access privilege updates  A mechanism for delegating privileges in a constrained and controllable

way.

 A formal language for representing privileges and their delegations.

Within the project, we have also studied how these components t into various architectures and cryptological infrastructures. These studies are illustrated using a number of scenarios and examples. There are several issues that need to be further re ned and developed. Some of these are:  To produce a detailed architecture for decentralised management of

access privileges, including certi cate formats and communication protocols.

 To study various revocation scenarios and to extend the model and

the architecture to support a set of revocation mechanisms.

 To implement a prototype based on the model to examine scalability

and eÆciency of various algorithms.

 To demonstrate the functionalities and the bene ts of the model in a

realistic context.

37

Bibliography [AF99]

Andrew W. Appel and Edward W. Felten. Proof-carrying authentication. In 6th ACM Conference on Computer and Communications Security, 1999.

[Ban]

Olav Bandmann. Constrained delegation. To be published.

[BFIK99] M. Blaze, J. Feigenbaum, J. Ioannidis, and A. Keromytis. The role of trust management in distributed systems security. In Vitek and Jensen, editors, Secure Internet Programming: Security Issues for Mobile and Distributed Objects. Springer-Verlag, 1999. [BFL96] M. Blaze, J. Feigenbaum, and J. Lacy. Decentralised trust management. In Proceedings of the 17th Symposium on Security and Privacy, pages 164 { 173, Los Alamitos, 1996. IEEE Computer Society Press. [BGS92] J.A. Bull, L. Gong, and K.R. Sollins. Towards security in an open systems federation. In Proceedings of the European Symposium on Research in Computer Security, volume 648 of Lecture Notes in Computer Science, Toulouse, France, 1992. Springer-Verlag. [EFL+ 99] Carl M. Ellison, Bill Frantz, Butler Lampson, Ron Rivest, Brian M. Thomas, and Tatu Ylonen. Spki certi cate theory, May 1999. Published online: http://www.ietf.org/internet-dr afts/draft-ietf-spki-cert-theory-0.5.txt. [FS99]

Babak Sadighi Firozabadi and Marek Sergot. Power and permission in security systems. In B. Christianson, B. Crispo, and M. Roe, editors, Security Protocols, number ? in Lecture Notes of Computer Science, page ?, Cambridge, UK, April 1999. Springer Verlag. 38

[FvdT98] B. Sadighi Firozabadi and L. van der Torre. Towards a formal analysis of control systems. In Henri Prade, editor, 18th European Conference on Arti cial Intelligence, pages 317{318. John Wiley and Sons, Ltd, 1998. [Lam74] B. Lampson. Protection. ACM Operating Systems Reviews, 8(1):18 { 24, 1974. [RL96]

Ronald L. Rivest and Butler Lampson. Sdsi- a simple distributed security infrastructure, April 1996. Published online: http://theory.lcs.mit.edu/ cis/sdsi.html.

[Sea69]

John R. Searle. Speech Acts. Cambridge University Press, Cambridge, 1969.

[Van90]

D. Vanderverken. On the uni cation of speech act theory and formal semantics. In Philip R. Cohen, Jerry Morgan, and Martha E. Pollack, editors, Intentions in Communication, chapter 11, pages 195{220. The MIT Press, Cambridge, Massachusetts, 1990.

39