Access Control and Mobile Agents

Access Control and Mobile Agents

` noma de Barcelona Submitted to Universitat Auto in partial fulfillment of the requirements for the degree of Master of Computer Science

by Guillermo Navarro Arribas September 2003

c Copyright 2004 by Guillermo Navarro Arribas °

Abstract Mobile agent systems provide an scenario for new distributed applications such as Seaof-) && (@dollars < 10000); Figure 3.5: KeyNote policy assertion example.

KeyNote-Version: 2 Comment: this credential delegates a spending authorization Authorizer: "RSA:dab212" Licensees: "DSA:feed1234" Conditions: (app domain=="SPEND") && (@dollars < 200) Signature: "RSA-SHA1:9867a1" Figure 3.6: KeyNote credential assertion example.

Evaluation of queries The compliance checker receives an action query and returns a compliance value. Specifically, the parameters for the compliance checker are: • Identifier of the principals requesting the action. • Action attribute set describing the requested action. • Set of compliance values of interest to the application, ordered from minor to major. • Policy and credential assertions to be included in the evaluation. The identifiers are normalized as canonical keys or case–sensitive strings (considered as opaque identifiers). The set of assertions form a directed graph, which is used to calculate the compliance value by a depth first search. The base for the calculation is the monotonic principle. Adding more assertions does not provide a request with a lower compliance value.

3.3. TRUST MANAGEMENT

59

Applications of KeyNote KeyNote can be used in several scenarios. As an authorization infrastructure provides the needed mechanisms to manage and evaluate authorizations. Although access control is not the main purpose of KeyNote it can be easily adopted for distributed access control management. The possibility to delegate authority makes the distribution easy and feasible. Some of the current applications of KeyNote are: • Web access control : KeyNote is used by Apache-SSL [ASS], a secure web server, based on Apache [ASF] and SSLeay2 /OpenSSL3 . KeyNote provides a module to manage authorizations to control the access to the server, it is integrated with SSL and X.509 certificates. • IPSec: KeyNote can be used to provide security at a network level, by allowing the fine grained management and control over IPSec tunnels. In [BIK01b], the authors propose a simple framework for adding trust management capabilities to IPSec through KeyNote. The implementation of IPSec in the OpenBSD operating system4 uses KeyNote. • Active networks: KeyNote has been used in the project SANE (Secure Active Network Environment)[BFIK99b]. • Firewalls: In [IKBS00] the authors propose the use of KeyNote to regulate the network traffic in a distributed firewall architecture. • Offline micropayments: The use of KeyNote for offline micropayments is described in [BIK01a]. Although KeyNote has been used in several implementations and scenarios, its use is not very widespread in the commercial market, and it is normally confined to research projects. It presents several limitations such as the monotonic principle, 2

http://www.psy.uq.edu.au/~ftp/Crypto http://www.openssl.org 4 http://www.openbsd.org 3

60

CHAPTER 3. CERTIFICATE-BASED ACCESS CONTROL

which prevents the use of credential revocation. It is important to note that relaxing this principle can make the compliance checking problem undecidable [BFS98]. Another limitation is the complexity of the language used to express assertions. The language was designed to be human readable but it still presents a high degree of complexity, which may not be easy to understand by the end user. In most applications, there will be a need to develop complex tools to automatically generate assertions hiding the complexities of the language to the users. Finally, KeyNote does not provide any framework for the creation and distribution of credentials. This leaves the credential discovery task to the implementation.

3.4

Secure Assertion Markup Language

SAML or Secure Assertion Markup Language is a framework for exchanging authentication and authorization information. The version 1.0 of the specification [OAS02] was adopted as an OASIS standard last November 2002 [OASb]. The requirements that tries to fulfill SAML are: single sign-on (SSO), authorization services, and back office transactions.

3.4.1

SAML Assertions

SAML information is expressed through security assertions. An assertion is defined as a statements (or declaration of facts) about a subject made by an issuer. It provides two XML schemas: one for the definition of security assertions and another for the definition of a request/response protocol used to exchange assertions. SAML also defines bindings for using assertions with standard transport and messaging services (currently only defines a binding for SOAP over HTTP). SAML provides three different kinds of assertion statements: • Authentication: the subject has been authenticated by some means at a given time. • Attribute: the subject is associated with the given attributes and values.

3.4. SECURE ASSERTION MARKUP LANGUAGE

61

• Authorization Decision: response to an access request, whether the access has been granted or denied. SAML assertions are issued by SAML authorities, so in relation to the previous assertions types, we find: authentication authorities, attribute authorities and policy decision points. Figure 3.7 shows a sample domain model provided in [OAS02].

Figure 3.7: SAML Domain Model

Delegation is not directly supported (nor even mentioned) by the current SAML specification (version 1.0) and the last draft of version 1.1 published by the time of writing.

3.4.2

SAML Protocol

The SAML specification [OAS02] provides a simple request/response protocol. Although SAML assertions may be used in a great variety of protocols and scenarios, SAML implementations may use this protocol to elaborate simple queries about SAML assertions. The protocol is described in an XML Schema and has two main components: the request and the response (see Figure 3.8).

62


Figure 3.8: SAML request/response protocol.

3.5

eXtensible Access Control Markup Language

The eXtensible Access Control Markup Language (XACML) provides a standard language based on XML to specify access control policies. The version 1.0 of the XACML specification [OAS03] became an OASIS standard in February 2003 [OASa].

3.5.1

Top-level policy elements

XACML provides three top-level policy elements: rule, policy, and policy set, see Figure 3.9.

Figure 3.9: XACML top-level policy elements

A rule is the basic elemental unit of a policy. Each rule has a target, which defines the set of resources, subjects, and actions to which the rule is intended to apply. The

3.5. EXTENSIBLE ACCESS CONTROL MARKUP LANGUAGE

63

condition of a rule is a boolean decision function, which redefines the applicability of the rule. Finally the rule has an effect, which is either Permit or Deny and describes the consequence of a true evaluation of the rule. Rules cannot be evaluated alone, they have to be combined into a policy. The policy has, besides a set of rules, a rule-combining algorithm. It also includes a policy target, which defines the set of resources, subjects, and actions to which the policy applies; and an obligations element. The policy set encapsulates a set of policy elements, with a policy-combining algorithm, a target, and obligations.

3.5.2

XACML model

The model proposed in XACML comprises several entities, among them we find: • Policy Administration Point (PAP): entity that creates a policy or policy set. • Policy Decision Point (PDP): entity that evaluates applicable policy and renders an authorization decision. • Policy Enforcement Point (PEP): entity that performs the access control. • Policy Information Point (PIP): a source of attribute values. • Context handler: is responsible for isolating XACML from the application environment. The main entities are shown in the data-flow diagram of Figure 3.10 proposed in [OAS03]. The XACML model described in Figure 3.10 operates following these steps: 1. The PAP writes polices or policy sets, making them available to the PDP. 2. An access requester sends an access request to the PEP. 3. The PEP sends the access request to the context handler.

64


Figure 3.10: XACML data-flow

4. The context handler requests attributes of the subject, resource, and action to the PIP. 5. The PIP obtains the requested attributes. 6. The PIP returns the requested attributes to the context handler. 7. The context handler may include the resource in the context. 8. The context handler sends a decision request to the PDP. The PDP uses the target from the decision request to identify the applicable policy, and evaluate the policy. 9. The PDP returns the response to the context handler. 10. The context handler returns the response to the PEP.

3.5. EXTENSIBLE ACCESS CONTROL MARKUP LANGUAGE

65

11. The PEP fulfills the obligations, and if access is granted, permits access to the resource.

3.5.3

Evaluation of policies

In order to evaluate the policies in XACML, the target element of the rule or policy is used. When a decision request arrives, the PDP tries to match the target of the request with the target of a policy or rule by using the matching functions described in both targets. The whole evaluation is performed at three levels: target and condition evaluation, policy evaluation, and policy set evaluation. A target a matches another target b if all the elements of target a match all the elements of target b. That is, the subject, resource, and action specified in both targets must match. Then, the evaluation of the rule is said to have the value match. If one of the elements of the targets does not match the value is no-match. A target may require the presence of some attributes (a role for example) to be matched. If the specified attribute cannot be obtained, the value of the target evaluation is indeterminate. For all the evaluations, the Condition elements shall be true. A rule is evaluated regarding the target and condition elements of the rule. The outcome of the evaluation is called the rule value and can be: the effect specified in the rule (permit or deny), not applicable, or indeterminate. Figure 3.11 shows the possible rule values. Target match match match no-match indeterminate

Condition true false indeterminate – –

Rule Value Effect NotApplicable Indeterminate NotApplicable Indeterminate

Figure 3.11: XACML Rule evaluation

The policy evaluation depends on the target of the policy and the value of the rules included in the policy. The evaluation my use the rule-combining algorithm to

66


determine the final value of the policy (see Figure 3.12). Policy target match match match no-match indeterminate

Rule values at least one is Effect all are NotApplicable at least one is Indeterminate – –

Policy value rule-combining algorithm NotApplicable rule-combining algorithm NotApplicable Indeterminate

Figure 3.12: XACML Policy evaluation

Finally, the policy set evaluation is based on the target of the policy set and the policy value. To determine the final value it also uses a policy-combining algorithm. The possible value of a policy set evaluation is shown in Figure 3.13. Target match match match no-match indeterminate

Policy value At least one is Decision All are NotApplicable At least one is Indeterminate – –

Policy Set Value policy-combining algorithm NotApplicable policy-combining algorithm NotApplicable Indeterminate

Figure 3.13: XACML Policy set evaluation

The combining algorithms determine how the rules and policies have to be combined to determine the final value of the policy or policy set. Briefly, the combining algorithms used in XACML are: • Rule-combining algorithms: – Deny-overrides: deny takes precedence over permit. – Permit-overrides: permit takes precedence over deny. – First-applicable: the first applicable rule determines the result. • Policy-combining algorithms:

3.6. PERMIS

67

– Deny-overrides: deny takes precedence over permit. – Permit-overrides: permit takes precedence over deny. – First-applicable: the first applicable policy determines the result. – Only-one-applicable: if only one policy is applicable, it determines the result.

3.6

PERMIS

PERMIS [PER] stands for PrivilEge and Role Management Infrastructure Standards Validation. Its main goal is to manage credentials for users mainly by implementing RBAC with X.509 attribute certificates. It started in 2001 as an EU founded project with 10 partners, being the University of Salford the leader and most active partner. It has received quite attention and the University of Salford plans to continue the project in the future. PERMIS software has been included in the US Internet2/Grid NMI (NFS Middleware Initiative) [NMI] software release. PERMIS combines a PKI for identification and authentication through X.509 identity certificates, and a PMI for providing authorization services by using X.509 attribute certificates. It implements access control based on RBAC. Although the aim of the project is to provide a distributed authorization systems, the current implementation of PERMIS introduces some restrictions to increase the system efficiency, which does not allow a fully distributed environment. These restrictions are: • Role specification and permission assignments are placed in just one policy to simplify the validation process. • All role assignments are stored in a distributed LDAP directory. This way PERMIS does not need to use CRLs, a SOA can simply delete revoked attribute certificates from the LDAP directory.

68


3.6.1

PERMIS Architecture

The PERMIS PMI architecture [CO02a] is based on two main components; the privilege allocator and the privilege verification subsystem. It uses an XML based policy language to express all the related information. The privilege allocator (PA) is responsible for allocating privileges to users and signing the authorization policies. That is, the PA assigns roles to users in the form of attribute certificates. The main structure of PERMIS PA can be seen in Figure 3.14.

Figure 3.14: PERMIS Privilege Allocator The PA is used by a SOA or AA perform the role assignment. All the information (attribute certificates, and attribute certificate revocation lists) is stored in an LDAP directory publicly available. The LDAP also contains information from the PKI (public key certificates, and public key certificate revocation lists), which can be used to authenticate and identify users. The main components that the PA facilitates are: • X.509 role-assignment attribute certificates. • X.509 policy attribute certificates. These certificates are attribute certificates with the following special characteristics:

3.6. PERMIS

69

– the holder and the issuer are the same (normally the SOA). – the attribute type is pmiXMLPolicy. – the attribute value is an XML policy file. The privilege verification subsystem receives access requests from user. Its main task is to authenticate the user and validate the authorization related to the access request. Figure 3.15 shows the PERMIS verification subsystem.

Figure 3.15: PERMIS verification subsystem.

It presents two separate components implemented as an application gateway: • Access Enforcement Function (AEF), which receives the access request from the user. The AEF is application-specific and can be adapted to required scenarios. It has to authenticate the user by any available mechanism such as an S/MIME email message or an SSL connection. Once it has the identity of the user it asks the ADF if the user is allowed to perform the requested action.

70


• Access-control Decision Function (ADF). The ADF uses the identity of the user to retrieve his role attribute certificates from the LDAP directory. Then, the ADF validates the role attribute certificates against the policy, and returns the access request decision to the AEF, which will present the request to the target if it was successful. The ADF is application independent and is sometimes called the access control decision engine. It is important to note that the ADF uses a pull-model. The main reason for not using a push-model (although PERMIS supports it) is that the current implementation does not uses CRLs. The authors state that a push-model could also be used with sort-lived attribute certificates.

3.6.2

XML-Based Policy

PERMIS uses a policy language based on XML[CO02b]. The reason for using XMLbased policies and not X.509 policies is expressed by the authors stating that X.509 policies does not specify languages for describing actions, policies or the ADF [COB03]. Some other issues contributed to the adoption of XML: the extensive tool support for XML, and the fact that XML is becoming and industry standard. A DTD5 of the PERMIS XML policy was published in XML.org. The policy includes the following components: • Subject: it specifies the domain of users who may be granted roles. Domains are defined as LDAP subtrees. • SOA policy: determines the identity (or DN) of SOAs trusted to issue role assignments. • Role hierarchy: determine the role hierarchies supported by the system. Role hierarchies can be modeled as directed graphs. • Delegation6 : directly taken from the X.509 standard specification specifies whether 5

The DTD can be found at http://sec.isi.salford.ac.uk/download/policy9.dtd It is important to note that although delegation is considered by the policy, the current design and implementation of PERMIS does not support delegation. 6

3.7. CONCLUSIONS

71

a role assignment can be further delegated or not. If it can be delegated it also provides the allowed depth of delegation. The delegation information is included in the role assignment component. • Role assignment: specifies which roles can be assigned to which subjects by which SOAs. Includes delegation information. • Target: determines the target domains covered by the policy. Again, the domains are specified as LDAP subtrees. • Action: specifies actions supported by the policy. • Target access: is a set of target access clauses. Each clause determines which actions can be performed by which roles over which objects. A clause can provide additional conditions to be satisfied for an access request to be granted.

3.7

Conclusions

In this chapter we have reviewed some of the current efforts in access control. As we have seen, X.509 provides some good support for implementing access control policies. The X.509 standard is used widespread in security products, even though the main purpose of these systems tends to be focused toward authentication. This makes X.509 a good candidate to implement access control systems which can be integrated in existing security infrastructures. Using a certificate to store access control information has some interesting advantages. The information can be easily transmitted through unreliable networks, which is desirable in distributed systems where different users generate information, and there may be distributed sources of information. Using X.509 for access control implies a two step process: authentication and authorization. That is, when a user accesses the system it is authenticated and then, based on the identity of the user, the authorization information can be retrieved. Another approach is to bypass the authentication step by using authorization-based solutions. In this case, the identity of the user is not directly relevant to the system.

72


When a user request a resource the system (or the access request verifier) just needs to know if the user has a proper authorization. Eliminating the authentication step makes the access control system simpler and easier to implement. On the other hand X.509 is always associated with the idea of a trusted third party (TTP) (both for authentication and for authorization) which creates the need for a strong trust relation between all the entities of the system and the TTP. Trust management systems such as KeyNote bind public keys directly to authorizations or permissions. The same idea is used in the Simple Public Key Infrastructure (SPKI) that we present in the next chapter. Another interesting issue regarding trust management systems is that they do not normally assume the presence of a TTP. This is specially interesting in scenarios where several independent entities interact with each other. Another important current research topic in access control is focused in XMLbased frameworks and languages. XML has become a de facto standard for representing and exchanging all kinds of digital information. In this chapter we have seen SAML, an XML framework for exchanging authentication and authorization information. SAML is focused around the concept of assertion, which can be seen as an XML simplified counterpart of a X.509 certificate. Although SAML is currently an OASIS standard its stage of development and adoption is still a bit premature, but may possibly play a key role in the next years. Following with XML, we have seen the XACML. XACML provides a standard language based on XML to specify access control policies. It does not directly address the problem of exchanging information and thus cannot be considered as certificatebased access control. We have include a short description due to its widespread relevance, and close relation to SAML. Finally we have described the main ideas behind the PERMIS server as an example of access control system, which makes use of certificate-based access control. PERMIS uses X.509 attribute certificate for authorization and X.509 public key certificates for authentication. An interesting feature of the PERMIS server is that, together with X.509, it uses an XML-based language to express policies. This policy language does not follow any standard, possibly because when it was developed there was not such

3.7. CONCLUSIONS

73

a standard. Today this language could have been XACML. We think that the authorization-based access control like the one used in KeyNote provides an interesting and novel approach for access control. In a complex distributed system such as mobile agent systems, we normally find applications where independent entities have to interact in some task. The use of a TTP may impose an artificial scenario, which does not corresponds to the actual needs of the application. On the other hand, as identities are not a requirement for the system, the access control system and its implementation can be simplified. Although KeyNote introduced an interesting precedent for authorization-based access control we have focussed in a more mature technology: SPKI. Next chapter gives an extended overview of SPKI.

74


Chapter 4 Simple Public Key Infrastructure 4.1

Introduction

In 1996 Rivest and Lampson (MIT) designed the Simple Distributed Secure Infrastructure (SDSI), with the main objective of creating a secure infrastructure to facilitate the building of scalable and secure distributed systems. At the same time, a working group from the Internet Engineering Task Force (IETF) leaded by Carl Ellison proposed a standard for a secure infrastructure with a simple, well defined, and flexible authorization model under the name of Simple Public Key Infrastructure (SPKI). Both initiatives merged in 1998 with the name SPKI/SDSI, which has produced two RFCs by the moment:SPKI Certificate Theory[EFL+ 99a] and SPKI Requirements[Ell99]. SPKI/SDSI is mainly based on two mechanisms, which can be seen as independent issues: • Management and control for authorizations based on distributed delegation of authorizations (main contribution of SPKI). • Distributed local name system (main contribution of SDSI). These two issues will be developed in the following sections. But before we will outline the main characteristics of the SPKI/SDSI and introduce the main concepts and definitions. 75

76

CHAPTER 4. SIMPLE PUBLIC KEY INFRASTRUCTURE

• Authorization as a main objective rather than authentication. • Key-oriented system: all the entities, parties or principals are public keys. • Egalitarian design: there is no need for a global hierarchy. • Each entity can act as a Certification Authority (CA). • Distributed local name space. • Simple data structures, every SPKI/SDSI object has a clear and readable ASCII representation with S-expressions. • Oriented to the Internet (online). • Easy and flexible schema for the definition and management of groups. • Role support for the organization of the authorization control model. Possibly the most important issue is that the main goal of SPKI/SDSI is authorization rather than authentication. This introduces important differences with current security infrastructures, where authentication and identity management are the core features. SPKI/SDSI introduces the concept of authorization certificate. An authorization certificate directly assigns an authorization to a public key. As Figure 4.1 shows, authorization certificates have an important implication in access control. Traditional access control systems based on identity (normally global identities), use two different bindings. One, binds an identity to an authorization, and another binding is needed to bind the identity to a public key. In SPKI we can directly bind an authorization to a public key. Thus, simplifying the access control models. The data format chosen for SPKI/SDSI is S-expressions. It is a LISP-like parenthesized language, further information can be found in [Riv97]. In SPKI/SDSI each participant, physical person, organization, software agent or whatever entity taking part in SPKI/SDSI is known as a principal. A principal is defined as a cryptographic key, which can verify a digital signature, normally it refers

4.2. LOCAL NAMES

77

Figure 4.1: Binding identities, authorizations, and public keys to the public component of an asymmetric cryptographic key (or public key). Thus, in SPKI/SDSI a principal is a public key. In other words one can say that each principal is identified by its public key. It is important to note that for the rest of the document when referring to a principal in the SPKI/SDSI context, we will be referring to it as a public key.

4.2

Local Names

Although SPKI/SDSI is a key-oriented oriented system, it provides a novel and interesting approach to identify principals by means of local names. In SPKI/SDSI, each public key (principal) has a local name space which contains local names. A local name can be strictly defined as an S-expression with two elements, the word name and the identifier of the name. For example, Alice can define the name bob in her local name space: alice: (name bob) One of the main characteristics of SPKI/SDSI is the capability of defining compound or extended names. Following the example, if Bob defines the name carol in his local name space:

78


bob: (name carol) Alice can refer to Carol as: alice: (name bob carol) That is, the name carol as defined in the name space of Bob. SPKI/SDSI proposes the interpretation of this compound name as Bob’s Carol. A local name space is defined by its public key (the public key owning the name space). This public key stands for a global identifier of the local name space. That is why normally a local name is referred as a public key (or its hash) followed by an identifier. A local name can be more strictly defined as: “A local name is a sequence of length two consisting of a key K followed by a single identifier”. While an extended name can be defined as: “An extended name is a sequence consisting of a key followed by two or more identifiers”. If a name does not include the lead key, it is assumed to be the key of the local name space where the name is defined. Some of the main advantages and the reasons why SPKI/SDSI adopted this local name schema are: • Provide a simple, clear a useful way for referring to another principal. Humans are used to manage local names and it is very difficult not to make a mistake or imprecision when using global identifiers. It is easer to refer to Alice as the local name alice than to her public key. • Provide an abstraction level to separate the name referring a principal from its public key. If Alice changes her public key, there is no need to change the certificate which identifies Alice by her local name. • To allow a principal to define a name in terms of a name defined by another principal. • To have names that refer to a group or collection of principals.

4.3. SPKI/SDSI CERTIFICATES

79

• To have names that can be able to act as attributes or credentials defining the group of principals that possess that attribute: For example at the UAB one may define: “student”, “professor”, “researcher”, “undergraduate-student”. . .

4.3

SPKI/SDSI Certificates

In SPKI/SDSI, a certificate is defined as a digitally signed document, which assigns an authorization or identifier to an entity, the subject of the certificate. Formally speaking, SPKI/SDSI provides two kind of certificates, represented by a tuple of elements. There are 4-tuple and 5-tuples certificates. Although they are normally referred as name certificate and authorization certificate respectively, most authors prefer to distinguish between three types of certificates: authorization, attribute and name certificates.

4.3.1

Name Certificates

A name certificate (4-tuple) binds a local name with a public key or another name, it has the following fields.

Figure 4.2: SPKI/SDSI Name certificate

• Issuer : public key (or its hash) of the signer of the certificate. It identifies the principal defining the name in its local name space. • Name: local name composed of a public key and an identifier.

80


• Subject: new meaning of the name defined by the certificate. It can be a public key or a name composed of a public key and one or more identifiers. If the public key is omitted, the name is considered to be defined in the issuer’s local name space, so it will begin with the issuer’s public key. • Validity specification: validity time range defined with two dates: not-before and not-after. It also contains the on-line test. Figure 4.2 shows the simplified structure of a name certificate in S-expression format. Note that the components issuer and name are included in the issuer field. This 4-tuple certificates can be denoted as C = (K, A, S, V ), where K is the issuer, A the name, S the subject and V the validity specification. There is another notation which clearly shows the meaning of a name certificate. The previous certificate C can be expressed as: K A −→ S showing that the issuer K defines the name A to be equivalent to S. The validity specification is omitted in this notation for clarity reasons. For example, suppose that Alice with public key KA wants to define the name M other to be equivalent to KM , Martha’s public key. Then, Alice will issue the following name certificate: KA M other −→ KM

(4.1)

One can say that KM is KA ’s M other or more informally, M artha is Alice’s M other. Then, Bob with public key KB issues the following certificate: KB M artha −→ KA M other

(4.2)

Bob’s certificate expresses a compound name, it defines the name M artha in Bob’s name space to be equivalent to the name M other in Alice’s name space. So the name M artha maps to KM with the help of certificate 4.1. Note that Bob does not need to know KM , he just knows that it is Alice’s mother. If Martha changes her public key only certificate 4.1 will need to change. Note that compound names introduce indirections in name definitions.


81

Groups In SPKI/SDSI a group is a set of principals with a name and a group owner. The name is defined in the group owner’s local name space and he is the only one who can change the group definition. To define the group, the owner issues a name certificate for each member of the group. For example, Figure 4.3 shows the definition of the group f riends defined by KA (public key of Alice) in its local name space. KA f riends KA f riends KA f riends KA f riends KA f riends

−→ −→ −→ −→ −→

KB KC KB Simon KC f riends KB brotherf riends

Figure 4.3: SPKI/SDSI Group definition example. The group includes KB , public key of Bob, and KC , public key of Carol. It also includes the name Simon as defined in the name space of KB ; the group f riends defined in KC ’s name space; and the group friends, defined in the name space of the principal referred by the name brother as defined in KB ’s name space. Or more informally, one can say that Alice’s friends are: Bob, Carol, Bob’s Simon, Carol’s friends and Bob’s brother’s friends. One of the main characteristics of SPKI/SDSI is the ability to define groups in a flexible way by using indirections (compound names). Groups allow an easy and intuitive definition of security policies. For example, they allow to implement RBAC models by considering a role equivalent to a group. It is important to note that groups may present security disadvantages, it is not trivial to revoke a member of the group, but this is a common problem in group and role based models.

4.3.2

Authorization Certificates

An authorization certificate (5-tuple) grants a specific authorization to a principal. Figure 4.4 shows the simplified structure of a SPKI/SDSI authorization certificate.

82


It includes the following fields:

Figure 4.4: SPKI/SDSI Authorization or attribute certificate

• Issuer : public key (or its hash) of the signer of the certificate. It identifies the principal granting the authorization. • Subject: principal receiving the authorization. It can be a public key or a name composed of a public key and one or more identifiers. If the public key is omitted, the name is considered to be defined in the issuer’s local name space, so it will begin with the issuer’s public key. • tag: specific authorization granted by the certificate. • Delegation bit: if it is true, it grants the subject permission to further delegate to others the authorization. • Validity specification: validity time range defined with two dates: not-before and not-after. It also contains the on-line test. An authorization certificate is a signed tuple of the form (K, S, T, d, V ), where K is the issuer, S the subject, T the tag, d the delegation bit and V the validity specification. Most authors prefer to distinguish between authorization and attribute certificates. If the subject of the certificate is a public key it is normally referred as an authorization certificate, while if the subject is a name it receives the name of attribute certificate.


4.3.3

83

ACL entries

In SPKI/SDSI an Access Control List (ACL) is a sequence of ACL entries. Each entry can be seen as an authorization certificate without issuer and without signature. An ACL entry can also contain certificates with a threshold subject (see 4.3.4). The issuer of an ACL entry is the owner of the ACL, and they are not signed because they do not need to be exchanged. Normally a principal uses an ACL to protect a resource, although they can also be used to set up general policies.

4.3.4

Threshold subjects

SPKI/SDSI allows the definition of a threshold subject as the subject of an authorization certificate. The resultant certificate has n subjects, and k of them are needed to accept the authorization (k ≤ n). That is, the certificate will need the signature of k subjects to be accepted. These kind of certificate can provide a fault tolerance mechanism. If one of the keys of the subject is compromised, the adversary cannot be authorized without the rest of the k keys. It is important to take special care with threshold subject certificates as they can introduce security weakness in the delegation of authorizations (see 4.4). In some cases one may need some mechanism to ensure that the keys of the subject belong to different principals. This is a bit contradictory with the SPKI/SDSI principles because there is not enough to have public keys as principals, it needs some kind of authentication of the keyholder (see 4.6.2). Some examples of the use of threshold subjects for authorization certificates are outlined in [EFL+ 99b]: • Co-signing of electronic corporate checks or purchase orders. • Establishing a root key like for example the root DNSSEC (DNS security extensions) key. This way it is possible to have several root keys and avoid all the political battles if just one country (for example) were to hold the root key to the entire world.

84


• Establishing keys via multiple algorithms. For example, one can have three public keys as the subject of an authorization certificate, each one for a different signature algorithm such as RSA, DSA and Elliptic Curve. The certificate may need the signature of two algorithms to be accepted. If one of the keys is compromised or someone breaks one of the algorithms, the certificate can still be used without compromising the security. It adds security and fault tolerance to the authorization model. • Using online and off-line issuers. One could have a permission established by an off-line key issuing a long-lived certificate and echoed by an online automated server, issuing short-lived certificates. The delegation of this permission could require both before the eventual subject gets the permission. This can be achieved through the use of (online) tests in a long-lived certificate, but the k-of-n subject mechanism may be cleaner. • Ultra-secure applications like a nuclear weapons launch authorization, which requires a multiple agreement before granting the permission.

4.3.5

Validity Specification

A certificate in SPKI/SDSI supports a variety of validity conditions expressed in the validity specification field: the traditional validity time range with two dates: notafter and not-before, and on-line tests. SPKI/SDSI has defined three kinds of on-line tests: CRL, revalidation and one-time revalidation. Online tests can be checked when a certificated is verified. It is important to note that SPKI/SDSI does not specify the protocols used for these online tests. Despite the revocation and validation online test provided by SPKI/SDSI, they may not be used very often. Due to the freedom of a principal to issue certificates by itself and the possibility to generate temporary keys without excessive cost, the most reasonable solution is to use short-lived certificates and avoid the use of revocation lists.


85

Certificate Revocation List A Certificate Revocation List (CRL) lists revoked certificates. These certificates are not valid for any operation. The revocation of a certificate is made by the issuer. For example, a certificate may be revoked because the private key has been compromised or simply because the user has not paid the quote of the CA. SPKI/SDSI only supports timed CRLs. These CRLs present the following characteristics: • The certificate must have the location of the CRL and the public key of the CRL owner to verify the signature. • The CRL must have validity dates. • The validity dates of each CRL cannot intersect. The issuer of the CRL cannot issue a new CRL before the current one has expired. CRLs are issued in a fixed time interval manner, and the validity interval of a timed CRL cannot be zero In traditional CRLs (not timed CRLs), when someone wants to revoke a certificate she just issues a CRL and the previous becomes not valid. Once a CRL is issued it is transmitted to all the locations, which may have a copy of the CRL. This process, although theoretically allows an instantaneous revocation, is not deterministic. Due to practical issues like the time propagation of the network, one cannot be sure if the CRL used to verify the certificate is the last one issued. In fact a malicious user may prevent the issue of a new CRL just by tampering the network. With timed CRLs a certificate using a CRL cannot be authorized without a valid CRL. When we verify a certificate against a CRL we now which CRL is valid at this very moment. The obvious disadvantage is that the revocation of a certificate will not be effective since the issue of the next CRL, meanwhile the certificate will be considered valid. That is why in SPKI/SDSI, the CRL is seen as a completion of the certificate, rather than a message to the world announcing a change of mind. Because a CRL may become very long, SPKI/SDSI allows the use of delta-CRL. They show the changes from the previous CRL, so there is no need to issue a complete CRL each time.

86


Revalidation A revalidation is the positive version of a CRL. It shows valid certificates. The revalidation process in SPKI/SDSI follows the same ideas of the CRL process. So it uses timed revalidation lists in the same way as timed CRLs. In revalidation lists, it may be useful to set the validity interval to zero o very short. SPKI/SDSI does not allow to set the interval to zero but it is possible to set an extremely short one. The problem with setting a very short time interval is that time issues may be considered, thus, making the process very difficult to implement over a network and sometimes unfeasible. To solve this problem SPKI/SDSI supports one-time revalidation. A one-time revalidation test assures that the authorization contained in the certificate is used only once by the subject. Short-lived Certificates By using on-line test with a short validity time one can achieve fine-grained control methods, but due to the practical problems of short validity intervals SPKI/SDSI suggests the use of short-lived certificates. Note that short validity intervals for online test also introduce a considerable amount of network traffic and the need of processing power due to signatures and verification. These short-lived certificates are certificates with a very short validity interval so they do not need lots of on-line tests. That is why SPKI/SDSI defines an on-line tests to tell the user of the certificate the location where he can find a new short-lived certificate to replace the current one.

4.4

Delegation of Authorization

As we have seen authorization certificates have a boolean delegation system. If the delegation bit is true, the subject can delegate the authorization to another principal by issuing a new authorization certificate. The delegated authorization can be the same authorization received by the issuer or it can be restricted by the authorization

4.5. AUTHORIZATION MANAGEMENT

87

tag or the validity specification. SPKI/SDSI allows the delegation of an authorization not grated to the issuer (the issuer may get the authorization in the future) but it will never be accepted by an authorization verifier. The delegation mechanism of SPKI/SDSI is quite simple and presents some limitations. For instances in order to delegate an authorization, a principal will need to hold the same authorization (or a superset). There are some situations where this may not be desirable. For example, consider the access control management of the records of patients in an hospital. There may be some manager with the right to delegate access to the record to some physicians but without actually being able to exercise the right herself (accessing to the patients records). This situation could not be expressed with SPKI/SDSI. Another important limitation in the SPKI/SDSI delegation model is the control of the delegation flow. The only possible restriction applied to the delegation is the boolean restriction. It is not possible to express other constrains such as group or time constraints. For example one can not express that a principal has the right to delegate a given authorization but just to a closed set of principals. The delegation may also introduce some problems if it is not used properly. For example, the delegation of threshold subject certificates may allow a principal to get the authorization with less than k keys. Suppose we have a threshold subject with three public keys: K1, K2 and K3 and that the certificate requires two of them to get the authorization. Now suppose that K1 and K2 delegate the authorization to Alice. Then Alice can be authorized without the signature of another principal because she will have two different authorization chains, one for K1 and another for K2. The same problem arises when some of the subjects is a group.

4.5

Authorization Management

In this section we analyze how SPKI/SDSI can be used to set up an authorization management system. The authorization control system adopted by SPKI/SDSI is based on the delegation of authorizations in a distributed environment with signed certificates. A principal controlling a resource or a service, delegates authorizations by

88


issuing authorization certificates. And principals can re-delegate the authorizations to others. The main properties of this authorization model are: • key-oriented : the principals processing, delegating a receiving authorizations are public keys. • any public key (principal) can issue a certificate. There is no need for a central authority to control the authorization flow. • a public key may delegate rights even if it does not have them. • the issuer does not loose the rights which it delegates. The principal controlling a resource has a master key to control all the access or an ACL determining the privileges for each public key. It is important to note that in SPKI/SDSI an ACL has a different function from the ones normally used in traditional PKIs (X.509 certificate-based). Traditionally, an ACL has a list of relations < authorization, name > which are combined with certificates < name, key > which normally define groups. Suppose the case of an ACL controlling the network access of a big corporation. The ACL may be located in the firewall with a list of all the names which can access the network. Not only it may be a huge list, but there must be a way to control the access to the ACL itself. Not every one may have the right to modify every ACL entry, we need other ACLs to control the access to the main ACL. So finally there will be hierarchical structure of nested ACLs, which in some way will reflect the hierarchical structure of the corporation and consume a considerable amount of storage resources. The solution proposed in SPKI/SDSI is to exploit the possibilities of the delegation of authorizations. In this case the firewall will have an ACL with just one entry which authorizes the access to a public key. This key, owned by the main responsible of the network, may delegate the authorization to the subordinates. They will continue the delegation process until someone who has an specific authorization but not the right to delegate it. Then the authorization certificates compose an structure which also reflects the hierarchical organization of the corporation, but the control


89

of the authorization is distributed over the organization. Each principal responsible of delegating authorizations performs an simple and well understood delegation, only concerned with his direct subordinates. This schema eliminates the storage needs of the nested ACLs and simplifies the software implementation.

4.5.1

Authorization flow

Making use of delegation may allow to distribute the access control management of a resource. For example the company Acme may have a central database controlled by a guardian, which holds the SPKI/SDSI master key to access the resource. The guardian delegates the right to access the database to the manager of the company. The manager can further delegate the right to access the database to other employees and so on. Figure 4.5 show a sample delegation flow.

Figure 4.5: Delegation example

One of the most important advantages of using delegation of authorizations is to facilitate the management of authorizations by distribution. In the above example the access control management is distributed among different principals in the company.

90


Each principal is responsible to delegate authorizations to its sub-employees. This way the whole control management is not centralized and manipulated by a single administrator, which may need to be aware of the situation of all the employees of the company. The structure of the delegation chains described in Figure 4.5 can be very complex. From a general perspective it can have the form of a directed graph called delegation network [Aur98], and may contain several chains between two principals. Now suppose the situation, where Alice wants to gain access to a protected resource. The resource is protected by an ACL controlled by a guardian. Then, in order to gain access Alice has to deliver to the guardian an authorization proof. The interaction between Alice and the guardian could be described by the following steps (see also Figure 4.6).

Figure 4.6: Access request

1. Alice1 sends a request to the guardian asking for access. This first request is not authenticated nor authorized. 2. The guardian2 denies the request because the resource is protected. He sends 1 2

given that principals are public keys, Alice here is considered a public key as before, the guardian is also a public key


91

a challenge to Alice, asking for the authorization proof. This challenge carries the ACL and the authorization tag. 3. Alice generates a certificate chain to proof her authorization. This authorization chain should bind the ACL with her authorization certificate. To generate it she can use, if needed, the SPKI/SDSI certificate chain discovery algorithm [CEE+ 01]. 4. Alice sends a second request with the authorization proof. This request includes a signature of the tag and a timestamp, and the certificate chain. Note that the signature will act as an authentication of the request. 5. The guardian verifies the second request and lets Alice access to the protected resource. To verify the second request the guardian verifies the signature and the certificate chain. A very important point of this process is that the authentication does not authenticate Alice as a person or entity, it just authenticates Alice’s request. The guardian does not need to know Alice’s identity. The timestamp generated and signed by Alice at point 4 avoids some possible replay attacks. A malicious user can not re-send Alice request. Note that this is possible only if the clocks of Alice and the guardian are fairly synchronized. In fact, SPKI/SDSI assumes clock synchronization when it specifies the validity ranges of time in the certificates. Another possible solution to replay attacks is to make the guardian generate a nonce and send it in the challenge, then Alice can sign it and the guardian knows that her second request corresponds to the specific challenge. If the authorization is granted by a threshold subject, the request will need the signature of k of n keys. This authorization process may have some cost, specially when Alice has to find the authorization chain. That is why SPKI/SDSI provides an special kind of authorization certificate called Certificate Result Certificate (CRC). This certificate can be seen as summary of the certification chain. The guardian can generate this certificate once he has verified Alice’s authorization chain. Then Alice can use the CRC in

92


following requests. The certificate has the ACL owner (the guardian) as the issuer, Alice as the subject and the specific authorization tag. The steps described above correspond to a push method for distribution of certificates. That is, the user requesting access has the responsibility to provide the certificates. From a practical point of view it may be interesting to consider a pull model, where the verifier gets the credentials by itself. This way the user just needs to send the initial request.

4.5.2

Certificate chain discovery

One of the most important points of the authorization process is finding a valid proof from a set of certificates. Given a principal protecting a resource and another one requesting access to the resource, an authorization proof is a set of certificates, which links the keys of both principals. That is, it is a chain of certificates that can be verified by anyone. To find this chain of certificates there is a Certificate Chain Discovery Algorithm, described in [CEE+ 01]. It is a deterministic algorithm with a polynomial order of complexity. The previous algorithm only deals with a centralized repository of certificates. In distributed environments it is normally desirable to have the certificates distributed among a network. This makes the certificate chain discovery a really hard problem, which normally requires some additional mechanism such as the resource or service discovery algorithms found in P2P computing. In [ACMR02] the authors propose ConChord, a framework based on the Chord system [MIT]. Other distributed chain discovery propositions can be found in [LWM01].

4.6

Privacy vs. Accountability

Privacy is an important issue in certificate based system. Privacy involves anonymity, we can define anonymity as the fact that a client is able to access services without revealing its identity. For some services or applications anonymity is a desirable feature and may add value to the system, but for some specific services it will also be a

4.6. PRIVACY VS. ACCOUNTABILITY

93

need or a must. As we will see it is no easy to achieve privacy without sacrificing other features like accountability. This section discusses the privacy and accountability issues of SPKI/SDSI. Related to certificate systems, Aura and Ellison list 8 privacy problems (see [AE00]): 1. Identity certificates disclose identities. 2. Signature keys are uniquely recognizable. 3. CA hierarchies and networks mirror organization structures. 4. CAs have access to confidential organizational information. 5. Authorization certificates reveal business and personal relationships. 6. Like CA hierarchies, chains of authorization certificates mirror organization structures and business processes. 7. Threshold certificates reveal the lists of subjects. 8. Individual accountability conflicts with anonymity protection.

4.6.1

Privacy

The first 4 point of the privacy list are related to identity-oriented systems, at a first view we can see that SPKI/SDSI avoids this problems. So we can say that SPKI/SDSI as a key-oriented systems allows some degree of privacy. In a identity-oriented system, using identity certificates such as X.509 certificates, the authorization method is based on the identity of the participating entities and it is easy to identify each one. Each entity knows who is the other and a 3rd party listening the communications knows both of them. In a key-oriented system this is not so obvious. One may know the key of an entity but it does not mean it directly knows the keyholder. Using traffic analysis techniques it is possible to determine the behavior of a key and consequently the owner, so it just presents a quite low degree of privacy.

94


Now, we will consider the other problems related to SPKI/SDSI and some of the possible solutions. Certificate reduction as a privacy technique We have seen the certificate reduction as the main technique to manage certificates in SPKI/SDSI. It is important to note that it has the effect of hiding the intermediate principals (public keys) in a certificate chain. So we can minimize the information the server or a third party may get from the authorization certificate (recall Certificate Result Certificate in Section 4.5.1). The authorization tag of the certificate should include only the subset of rights that is needed for the specific request. In SPKI/SDSI a principal may re-delegate the specific rights to itself and have the certificate chain reduced. This way the certificate only shows the minimal information possible about the authorization. The problem of recognizable public keys still be present in the certificate reduction: • The first public key of the chain has to sign the reduction, it gets to see all the certificates of the chain. So normally one can not hide all this information to the server or verifier. • The key that makes the authorization request cannot be hidden, and it becomes a great target for traffic analysis attacks. The concept of certificate reduction as a privacy technique is used in the DCMS (Distributed Credential Management System) system [Cán02]. There, a trusted reductor is responsible for reducing certificate chains by issuing CRCs to users. Temporary and task-specific keys In order to avoid the traffic analysis attacks, it is possible to change keys often and create new keys for each new task. This is possible as long as there are no policies against multiple keys and simultaneous virtual identities. In a key-oriented system it is quite easy to change keys or use different public keys for different purposes, while


95

in identity-oriented systems it will require changing the identity or use one identity for each task. So there is a trade-off between cost and privacy, the cost of generating and using new keys which is not a big problem in SPKI/SDSI, it may be in an identity-oriented system. Aura and Ellison state in [AE00] that: “Probably the best privacy protection in key-oriented access control is created by combining temporary keys with certificate reduction”. Open threshold certificates One of the privacy problems listed above deals with threshold subject certificates. To avoid revealing the identity of all of the subjects in such a certificate one can use open threshold certificates. The idea is to replace the threshold certificate with several open threshold certificates, one for each subject. Each open threshold certificate has: • the same certificate identification number (a random bit string for example). • the threshold value k. The verifier will accept the k open threshold certificates if they all have the same identification number and different subject. Open threshold certificates guarantee that the shares may be kept secret by the trustees. But they also add flexibility to certificate management: • The open threshold certificates may be processed and distributed together or individually. • The trustees can be added by issuing new shares without redistributing the certificates to all the others. They do not require additional storage or communication capacity, and it is straightforward to extend the reduction of normal threshold certificates. It sounds quite good but the main problem is that SPKI/SDSI does not directly supports open threshold certificates. The use of this certificates will be implementationdependent.

Anyway, Aura and Ellison propose a trick to use this technique in

96


SPKI/SDSI without having to define a new kind of certificate [AE00], it involves the following steps: Given a normal threshold subject with S1 , S2 ,. . . , SN (k of them needed to gain the authorization). 1. create a new temporary key for each subject: Kt1 , Kt2 ,. . . ,KtN . 2. issue a normal threshold certificate with the threshold k to the temporary keys as the subjects. 3. each temporary key re-delegates the rights to one of the actual subjects with an authorization certificate. 4. destroy the temporary keys. Then, each subject gets a copy of the threshold certificate and the redelegation certificate issued to it.

4.6.2

Accountability

One of the privacy problems listed above, says that accountability conflicts with anonymity. That is an important issue in key-oriented systems, as it makes difficult for an auditor to find out the owners of the keys. SPKI/SDSI does not explicitly provide any mechanism to achieve accountability, an auditor looking for a malicious principal will be able to know its public key but not its identity. This is also important in SPKI/SDSI since each principals issues authorizations at its own risk, not only it can have a malicious behavior but it can also make mistakes. The only way one can ensure an acceptable degree of accountability in SPKI/SDSI is by using identity certificates. This is obviously a disadvantage since we loose one of the main premises of SPKI/SDSI, its necessary to use a trusted authorization to map the public key to the identity of the keyholder. Understanding identity not just as a local name but a real identity. The following sections describe some techniques that may be used in SPKI/SDSI to ensure accountability.


97

Encrypted identity certificates This approach considers a trusted agency that ensures that the identity of the public key owner can be recovered. This agency or CA issues identity certificates to each issuer and subject public key. It mainly ensures that the public key owner can be found and made responsible for anything signed by the public key. It is important to note that it is not enough to know the name or distinguished name (DN), it needs to ensure that the physical owner of the public key can be found. The identity certificates are encrypted with the verifier’s public key or those who need to check the identity, this way it will not be available to third parties. This approach adds some disadvantages to SPKI/SDSI: • Loss of privacy. • Need for a CA. • Increase of the general cost. CAs need to encrypt certificates separately for each potential verifier and the verifier needs to verify the identity of the requester. • With the encrypted identity certificates the intermediate subjects cannot verify that the credentials are acceptable by the verifier. • The verifier needs to store private keys. Identity escrow The main idea of the identity escrow approach is outlined by Aura and Ellison [AE00] as: “[. . . ] it is more important to be able to track down and make financially responsible the key owner than it is to know the key’s owner name.” Here, an identity escrow agent stores the bind between a public key and the owner’s identity. And it only reveals the identity in some well-defined circumstances. It comprises the following steps: • The escrow agent issues an escrow certificate to the public key as a proof that the identity of the key owner has been escrowed.

98


• The key owner uses the escrow certificate to prove that it has been submitted to the escrow agency. • The conditions for revoking the anonymity are stated on the escrow certificate and they may vary according to the application. The disadvantage here, is the need of some kind of CA, the escrow agency. But it ensures some degree of privacy since the escrow certificate does not reveal the identity of the principal. Even the verifier of the certificate may not need to know the identity of the principal making the request. And related to the encrypted identity certificates, the escrow certificates require less cryptographic operations. SPKI/SDSI especial accountability certificates We already said that SPKI/SDSI does not provide any accountability mechanism, but in [EFL+ 98] two kinds of authorization certificates are considered that may help in the implementation of identity escrow. These are: • Locator certificate: it acts as an escrow certificate. It provides a guarantee that a responsible entity can be found, through an escrow agency, while allowing that entity to remain anonymous until a condition specified on the locator certificate is met. The condition may be something like a court order or an economic fee. • Insurance certificate: this certificate considers a similar approach to identity escrow, but instead of an escrow agency that keeps the identity of the principal, it uses an insurance company. This company will pay the penalty amount in the event of non-performance, and then worry on its own about collecting that fee from the keyholder.

4.7

Implementations and current state

Although SPKI/SDSI proposed important novel ideas and concepts that will be used and developed in the future, it seems that the research community is not very interested in this specific technology. Possible due to its limitations and the complexity

4.7. IMPLEMENTATIONS AND CURRENT STATE

99

of the chain resolution algorithm, there are just a few implementations. Most of the SPKI/SDSI implementations come from university research projects, they seem quite immature, and do not provide a robust implementation suitable for a final product. In the following sections we list the most significant efforts: a C implementation originally developed by Intel Corporation (possible the most stable implementation of SPKI/SDSI), an a Java implementation originally written by some MIT students. Both are open source.

4.7.1

Intel Common Data Security Architecture

The Intel Common Data Security Architecture (CDSA) [Int] presents a modular architecture, which can be mainly used by independent software vendors (ISVs). It provides the necessary infrastructure and architecture for developing secure solutions to a wide range of applications. One of the CDSA modules provides support for SPKI/SDSI certificates and the SPKI/SDSI authorization model. CDSA is Open Source3 and it has been adopted by The Open Group (TOG) as an Open Group Technical Standard. As Intel claims, this standard has a big acceptance in the market through some important companies. It has been adopted by Apple as the security framework of Darwin, the core of the Mac OS X (a micro-kernel operating system based on FreeBSD and Mach 3.0) [App]. Other adopters of CDSA where listed4 at Intel’s CDSA web page: Caldera, IBM, Compaq, Hewlett-Packard, SuSE, TurboLinux and Bull SA. As service providers vendors they listed Certicom, ValiCert, Chrysalis-ITS, Rainbow Technologies and the Information Security Corporation (ISC). And CDSA-based toolkits developed by Baltimore, Cylink and Motorola. Despite the list of important vendors and companies, the use of SPKI/SDSI by most of them does not seems very spread (not to say inexistent). Although this may sound quite attractive, by the moment it is difficult to say how exactly this standard is been used and specially if the above mentioned companies 3

Currently, CDSA is hosted at SourceForge, and Intel does not directly support and maintain CDSA. 4 Currently, Intel maintains a very simple web page and points to SourceForge for more information. This list is no longer available.

100


use any of the novel capabilities of SPKI/SDSI. An interesting issue of CDSA is that one of the main responsible of the project at Intel was Carl Ellison, who has been very involved in the development and specification of SPKI/SDSI. So the inclusion of SPKI/SDSI in the CDSA may not be anecdotal and as an added value one can use the SPKI/SDSI module of CDSA as an independent module to implement specific applications

4.7.2

JSDSI

JSDSI is a Java implementation of SPKI/SDSI. It was first developed by Alexander Morcos at MIT’s Cryptography and Information Security Group for the SDSI project [Mor98]. It was then enhanced by Sameer Ajmani, also a MIT student, and now is hosted at SourceForge [JSD]. JSDSI is not a completed product nor even stable released. Thus it may seem very risky to adopt JSDSI a a reference implementation. The main problem is the difficulty to find Java implementations of SPKI/SDSI. All existing Java implementations come from research projects in universities, and JSDSI seems to be the most complete and stable. Although it may not be useful in production software it can be suitable for prototypes since it supports most of the SPKI/SDSI functionality.

4.8

Conclusions

In this chapter we have seen an overview of SPKI/SDSI. By combining the concept of distribution of authorization and local names, SPKI/SDSI provides an interesting infrastructure to deal with authorizations in distributed environments. We have seen in the previous chapter the benefits of this kind of authorizations frameworks for the implementation of access control systems. Although SPKI/SDSI provides an attractive approach towards access control it has some drawbacks, which have been discussed in this chapter. It presents limitations in the delegation model, delegation can only be constrained by a boolean value.

4.8. CONCLUSIONS

101

The lack of good implementations in several languages also imposes limitations when considering the implementation of a system based on SPKI/SDSI. We chose SPKI/SDSI as the base technology to implement an access control system for a mobile agent platform. The description of the system will be explained in Section 6.5, and the implementation in Chapter 7. Despite the drawbacks of SPKI/SDSI, it provides an interesting and novel research field to explore the use of authorization, delegation, and local names in an access control system for distributed systems and precisely mobile agent systems.

102


Part II Mobile Agents and Access Control

103

Chapter 5 Mobile Agents and Access Control Agent systems present a relatively novel field in computer science. They provide a new programming paradigm and new scenarios to develop complex applications. Agent technology has been a very active research field during the last years. Although specially relevant within the Artificial Intelligence community, its applicability has spread to other fields such as: computer networks, computer architectures or even psychology, sociology, and philosophy. Although they appeared as a very revolutionary technology, their use, specially in commercial environments, is growing sluggishly. Agent technology was considered “the next significant breakthrough in software development” [Sar92], and “the new revolution in software” [Ovu94], even in 1995 we found some claims like “in 10 years time most new IT development will be affected, and many consumer products will contain embedded agent-based systems” [Gui95]1 . Nowadays, it seems that some of the initial expectations on agent technology were a bit optimistic. Although the research community, specially in academia, has been very active in agent technology the use of agent systems in commercial environments does not seem to follow the same direction. Possibly one of the major problems which prevents the widespread adoption of agent systems in commercial environments is the security. Providing a secure agent 1

Cites taken from [JW98].

105

106

CHAPTER 5. MOBILE AGENTS AND ACCESS CONTROL

system is a very important requirement for applications in general (not only commercial) an still in a primer stage when it comes to agent technology. This is specially relevant in mobile agent systems, where code is moving from one host to another through a possibly unreliable network. In this part of the report we focus on a specific security service for mobile agent systems, the access control. Access control should be enforced in all the accesses to resources of the system, from data resources such as file systems or databases, to machine resources like processing power or memory consumption.

5.1

Agents

An agent can be defined as a software object on an execution environment that is acting on behalf of a person or organization [JW98]. An agent presents the following characteristics: • reactive: the agent can perceive its environment and react to its changes. • autonomous: the agent has its own thread of execution, it can control its own actions and initiate the execution of tasks. • proactive: the agent does not simply act in response to its environment. It presents an goal–oriented behavior, and it can take the initiative where appropriate. • continuous in time: an agent is constantly under execution. Other characteristics are: • communicative: the agent can exchange messages with other agents. This allows several agents to interact in other to accomplish their goals. Some authors say that agents are social. • learning: the agent can use its previous experience to adapt its own behavior. • mobile: the agent can move or migrate from an execution environment to another.

5.1. AGENTS

107

The execution environment of agents is normally called agency, agent platform, or more generally, Multi Agent System.

5.1.1

Mobile agents

A mobile agent is that which can move from one execution platform to another. On the other hand an agent that cannot leave its execution platform is called a static agent. The mobility of agents, also called migration can be classified in [Rob03]: • Remote execution: the data and code of the agent is sent to an execution platform. There, the agent is executed until it finishes its execution. • Weak migration: the agent sends its data and code during its execution. The programmer is responsible of designing some mechanism to resume the execution of the agents after the migration. • Strong migration: the agent sends its data, code, and state of execution during its execution. The agent is automatically resumed after the migration from the same execution point it was just before migration. Apparently the highest degree of mobility provided by strong migration seems the most suitable kind of mobility for a mobile agent system implementation. The main problem with strong migration is due to its complexity. It requires low level mechanisms for execution restoring, which may be used transparently in heterogeneous environments. Thus the most popular kind of migration found in most implementations if the weak migration. In [Rob03], a discussion of general agent mobility can be found.

5.1.2

Standards for agent systems

There have been considerable efforts to provide standard frameworks for agent systems. Currently we find two major efforts in the standardization of multi agent systems: the Mobile Agent System Interoperability Facility (MASIF) [MBB+ 98] by the Object Management Group (OMG), and the specifications produced by the Foundation for Intelligent Physical Agents (FIPA) [FIP00c].

108


MASIF The OMG accepted MASIF as an OMG standard in 1998, and the last specification was issued in 2000. Currently there are several agent systems implementing the MASIF standard, the most notable ones are: Grasshopper from IKV++ Technologies AG (Germany) [IKV], and the Secure and Open Mobile Agent (SOMA) System from the Universitá di Bologna (Italy) [SOM]. MASIF provides standard interfaces for agents and agent systems using the same language. It does not standardize local agent operations, agent interpretation ,serialization, or execution. It mainly standardizes: • Agent Management: creation, suspension, resumption, or finalization of agents. • Agent Migration: mobility of agents between agencies. • Agent Tracking: every component (agents, agencies, etc.) is registered and can be tracked through a registration component. • Agent and Agency Naming: syntax and semantics for identifying agents and agencies. • Agent Type and Location Syntax : agents have a type, which must by supported by the agency. Localization of agents and agencies is possible through a location standard. The base technology for MASIF is CORBA (Common Object Request Broker Architecture), which provides the basic interaction services between agents and agencies. It is also important to note that MASIF does not specifies the agent communication issue. FIPA The Foundation for Intelligent Physical Agents (FIPA) is a non-profit organization, formed in 1996 by companies and universities to produce standards for heterogeneous and interaction agents and agent–based systems. The last specifications where published in 2000 and are known as FIPA 2000.

5.2. SECURITY IN MOBILE AGENT SYSTEMS

109

The FIPA web page lists 10 existing agent systems implementing the FIPA specifications, but there may be more since FIPA has become the most used standard in agent–based systems. Among these systems we find JADE (Java Agent DEvelopment Framework) from TILab S.p.A (Italy) [JAD], one of the most popular agent systems at the present time, and it is freely available. FIPA, as MASIF, provides specifications for agent management, and as an addition it provides the specification of agent communication and message transport (which was not covered by MASIF). Possibly the most novel contribution of FIPA is the Agent Communication Language (ACL), a high level language allowing agents from heterogeneous environments to communicate.

5.2

Security in mobile agent systems

It is very important to provide a good degree of security in mobile agent systems. Some of the security problems in mobile agent systems have similarities with traditional security in distributed systems, but they introduce important novel threads, specially due to the mobility of code. A classification of security issues in mobile agent systems is given in [Rob03]: • Between agents. • Between agencies. • Between agents and agencies. The first to issues are normally solved by traditional distributed systems security mechanisms. The third one can be divided in two: protecting an agent from an agency, and protecting an agency from an agent. It is important to note that these last issues are not symmetric. There are solutions and mechanisms to protect agencies from agents, such as the sandbox model used in the Java architecture. On the other hand, the problem of protecting agents from agencies is a hard one, a discussion of this problem and mobile agent security can be found in [Rob03].

110


In this work we have focused in the access control of mobile agent systems. In this case, a mobile agent system can be seen as a distributed system with some special limitations. Possibly the most important limitation is due to the fact that some principals of the system are mobile agents. That is, they are pieces of code that travel from one agency to another. Most of the access control mechanisms impose the need for cryptographic operations either for authentication or authorization purposes. A mobile agent will need to hold cryptographic keys and perform operations such as digital signatures. For example, if an agent requests a resource from an agency, the request should be digitally signed by the agent. Since we said that protecting agents from agencies is not a trivial issue, we face an important problem. The agency where the agent is in execution will be able to monitor the operation and gain knowledge of the agent’s cryptographic keys. There are some propositions to allow a mobile agent (or agent in general) to perform cryptographic operations, such as [RS98], and [CvdL02], but they do not provide a feasible solution from a practical point of view.

5.3

Access control in mobile agent systems

In this section we describe some existing approaches for access control in existing mobile agent systems.

5.3.1

Accessing the resource

One of the first problems of the access control in mobile agent systems is to consider how to actually access the resource. For instance, imagine that an agent wants to access an SQL database. Once the system has checked that the agent has the proper permissions to do so, how does the agent access the database? Can the agent perform an SQL query directly? Does the system need to parse the query to know what the agent is querying? And so on. There are some generic solutions to provide access to resources in mobile agent systems, which can be integrated with access control systems. The most notable

5.3. ACCESS CONTROL IN MOBILE AGENT SYSTEMS

111

solutions for its novelty or widespread use are the following. Since it is not the main goal of this report, we only give a short overview. Using the Java security manager Most of the mobile agent systems are implemented using the Java language and architecture. Since a Java program can be executed in several architectures and operating systems it provides an environment and interoperability very attractive to distributed system implementations, specially where code mobility is a requirement. Java provides a basic protection mechanism, which allows to assign permissions or authorizations to principals (mainly code) and control the permissions [Gon02]. Thus, we can assign permissions to agents and restrict their execution and resource access in general. The Java Security Architecture allows to specify the access control though easily configurable policies, and an extensible framework of access control structures and security checks for applications. It also includes the Java Authentication and Authorization Service (JAAS) [Sun01]. JAAS allows the use of credentials to identify principals and grant authorizations to them. The most notable system making use of the Java security manager is the JADE-S systems (see Section 5.3.4). With the security manager we can check all resource access requests to the system. Even so, it presents some limitations: • Requires the extension of the security manager for each resource. That is, each new kind of resource leads to extensions of the security architecture. The security manager can become big and it may be easy to introduce errors, bugs, etc. • Explicit definition of all the permissions available. All kind of permissions have to be explicitly defined and coded in the applications. If an extension of the system is needed it may require the modification of the code of the whole application. Although this approach may seem a good security practice it makes very difficult to introduce it to existing applications, and maintain them.

112


• Lack of a good credential distribution mechanism. In general the security manager only provides generic protection of system resources.

Proxy Objects Agents access the resource via a proxy, which has a safe interface to the resource. The proxy can be dynamically constructed by the server following a security policy when an agent requests access to a given resource. The idea of using proxy objects in distributed environments is based in [Sha86]. The use of proxies allows a considerable degree of abstraction, a proxy can be adapted to any kind of resource, but on the other hand they present some problems. The main one is that the proxy must be programed for each kind of resource, and the second one is that each access request will lead to the generation of a proxy object, thus increasing the memory and processing power needs of the application. The mobile agent platform Ajanta [Aja], uses a proxy approach to let agents access the resources of the platform (see Section 5.3.2).

Wrapper Objects Resources can be encapsulated in a wrapper object. The wrapper accepts access requests and passes them to the resource. It acts like an interface to the resource, which enforces all access control requests. Normally the wrapper contains an ACL to control the access.

Two execution environments In some cases we can distinguish between two execution environments: safe, and trusted. An agent is executed in the safe environment, where it does not have access to any resource. When the agent request access, the systems checks the request to see if it is allowed to access. If the request is successfully verified, the systems puts the agent into the trusted execution environment where the agent will be able to access the resource.


113

This approach is based on the Safe-Tcl Security Model [OLW98], where receives the name of padded cell. It is used in the Agent Tcl system [Age], and the D’Agents system [D’A] (both mobile agent systems).

5.3.2

Ajanta

Ajanta is a mobile agent system developed at the University of Minnesota [Aja]. It provides a Java-based agent programming environment for mobile agents. A description of the security solutions proposed and implemented in Ajanta for resource access control can be found in [TK98], and [TK00]. The main component of Ajanta is the agency, called agent server. It runs as an ordinary user-level process, and is subject to the host operating system security. The main components of the agent server are: • Agent environment: interface between agents and the agent server. • Domain database: agent directory, responds to status queries from agents’ owners. • Agent transfer: migration protocol. • Resource: object that acts as an interface to some service or information available at the host. • Resource registry: maintains a database of the resources available at the agent server. Figure 5.1 shows the main components of the Ajanta architecture, including the agent server and the agent. An agent is considered a collection of the following components: • Code: classes implementing its functionality. • State: includes credentials and a reference to the agent environment. • Itinerary: determines the itinerary of the agent.

114


Figure 5.1: Ajanta architecture.

In Ajanta, a principal is considered to be an entity with a unique identity in the system, such as agent, host, agent server, owner, creator, etc. All the principals are assigned global location–independent names. The resource access control in Ajanta is based on the Java security model: name– space separation based on class loaders, and the Java security manager; and it is extended with the use of credentials and public key certificates. Credentials In Ajanta, a credential is a bind between the agent ID and its owner and creator in a tamper-proof manner. Note that owner and creator may not be the same. The agent executes on behalf of a user (normally human user), which is called the owner, and it is created by some application (agent server, client application, or another agent),


115

which is the creator. The credentials are assigned to the agent by its creator. Figure 5.2 shows the credentials carried by the agent. Only the main fields are shown, it may include other fields such a validity specification by time intervals.

Figure 5.2: Agent credentials in Ajanta

The credentials include the privileges of the agent. The privileges are described in terms of the operations the agent is permitted to do: • List of servers that the agent is permitted to visit. • Number of times the agent is allowed to visit a given server. • For each server: – the names of the resources that the agent should be allowed to access. – time-to-live: maximum amount of time the agent is expected to execute at that server. – Names of remote hosts with whom the agent should be allowed to communicate from a given server. – Names of the agents with whom the agent should be allowed to communicate in the server. – Names of the agents who should be permitted to communicate with this agent in the server.

116


The credential can also include restrictions, which are seen as negative authorizations or permissions. In order to preserve privacy, privileges and restrictions concerning a given server can be encrypted with the public key of the server. Credentials are signed by the owner, and they act like an authorization tokens. Another type of credential is the ticket for the delegation of privileges, which is similar to the agent credentials but singed by the agent server. It is used when an agent server has to forward the agent to another server in order to receive some ancillary service in the form of a subcontract. Protection Domains Privileges and restrictions are enforced by means of protection domains, based on the Java security manager. Each agent has a separated protection domain. Ajanta creates a new class loader instance to load the incoming agent into its own namespace. This ensures that all classes loaded from the agent, are loaded from the local classpath and not a remote one. Summarizing: • prevents agents from installing impostor classes for existing ones in the server, • the namespace isolates the agent from other agents, thus protects agent tampering by other agents. The security manager needs to distinguish the protection domain of the agent from that of the server. To execute each agent, Ajanta creates a new thread group. Thread group operations must be considered privileged operations mediated by the security manager. It avoids an agent from creating a thread in a different thread group from that of its own. Each server maintains a domain database. It stores for each agent: the thread group, owner, creator, access privileges for the resources in the agent server, etc. And for each resource, it stores: access authorizations, usage limits, etc. The domain database can only be updated by a thread from the server’s thread group. Resource request protocol The resource request protocol has the following steps:


117

1. The resource is registered in the resource registry. 2. An agent request an access to the agent environment. 3. The agent environment queries the resource registry to locate the corresponding resource. 4. The agent environment creates an object proxy. It uses information from the domain registry to restrict the proxy with the operations, the agent is allowed to do. 5. The agent environment returns the proxy object to the agent. 6. The agent can access the resource through the proxy object. Considerations The main component of the access control in Ajanta is the agent environment and the domain database. The domain database acts like an ACL for the resources of the server. Each resource entry may include the owner of the resource. This way the server may allow a resource owner to update the entry of the resource. This approach can be seen as a traditional DAC policy implemented with a combination of ACLs and capabilities (the agent credentials are in fact a capability list). Thus it suffers from the same problems, for instance, if the server hosts a great number of resources, maintaining the domain database can be a very complex task. Although the framework allows the delegation of privileges as tokens, this delegation is very limited and only possible under specific circumstances (server forwarding, and agent owner to agent). On the other hand, we find the combined use of the Java security manager and the dynamic creation of proxies to access the resources an interesting approach. It allows to adapt the resource access to a quite heterogeneous type of resources, only limited by limitations of the Java architecture. That is, if a resource can be accessed from a Java application, it is feasible to create an specific proxy for the resource.

118


5.3.3

Yuh-Jong Hu

In [Hu01], Yuh-Jong Hu presents a framework for building a secure infrastructure for agent systems based in SPKI/SDSI (see Chapter 4). The main restriction we find in this approach is that it does not consider mobile agents. Anyway, we think it introduces an interesting approach and possibly the first proposition for using SPKI/SDSI certificates for access control in agent systems. The framework considers the following types of certificates: • Human Identity Certificate: provides a binding between a unique human identifier and the human public key. Ih − Cert = (IDh , KPu , Options) where IDh denotes the human identifier, and KPu the human public key. • Agent Identity Certificate: this certificate provides the binding between the agent’s public key and its identity. It is important to note that the agent identity is constructed as the concatenation of a human unique identity (IDh ) and an agent unique identity (IDa ). Ia − Cert = (IDh #IDa , KPa , Options) where KPa is the public key of the agent. • Human Authorization Certificate: it is a 5-tuple certificate between a human h and an agent a: Ah - Cert = (KPh , KPa , A, D, V ) where A is the authorization tag (the author calls it the authorization power for agent), D is the delegation bit, and V is the validity period. KPh is the human key granting authorization and KPa is the agent public key receiving the authorization. • Agent Authorization Certificate: a 5-tuple certificate between two agents: a1, and a2.


119

Aa - Cert = (KPa1 , KPa2 , A, D, V ) It is explicitly stated that the Agent Authorization Certificate must be signed by the issuer agent. And the signature must take place in the issuer agent’s home system2 . Related to delegation it considers: chain-ruled delegation [Aur99], threshold delegation (using the authorization tag), and conditional delegation (also using the authorization tag). The system does not deal with the certificate revocation problem. FIPA ACL for agent delegation The system is implemented in the FIPA-OS toolkit [Emo], and uses FIPA ACL to provide certificate management for agents. The author proposes several speech-act based communicative acts to manage human/agent identity and authorization certificates. This acts are: • Identity certificate registration: an identity certificate is generated locally by a human or agent and registered in a global or local X.509 CA. It is initiated when a human or agent is registering the identity certificate to the agent located at the CA. • Identity Certificate query: query the human or agent public key in a X.509 CA providing its ID. • Identity Certificate store: the CA agent stores the valid ID certificate in the verifier agent rule base. • Identity Certificate revoke: used to revoke an identity before the end of the validation3 . 2 3

This is the main reasons given for not including mobile agents in this framework. This is not supported, though.

120


• Authorization Certificate delegate: delegation by issuing an authorization certificate. It uses an specific delegate performative to notify the subject for possible further re-delegation. • Authorization Certificate threshold-initiate: it is initiated by the subject of an authorization certificate with threshold condition, to initiate the authority coordination process with the other subject agents in the threshold. • Authorization Certificate threshold-delegate: when an agent receives the thresholdinitiate, it uses this performative to give its consent to the threshold initiation agent. • Authorization Certificate store: the subject agents stores a valid authorization certificate in the verifier agent rule based. The response performative to all of the above initiators is an inform(done) FIPA ACL. The ACL messages are encoded in XML/RDF using the FIPA specifications for XML and RDF [FIP00a], [FIP00b]. Conclusion This work presents an interesting approach to provide an infrastructure based on SPKI/SDSI to agent systems. Although there are some points not very clear. The definition of performative acts and its representation as ACL messages is confusing and not very detailed. This approach also fails when considering mobile agent systems or even heterogeneous multiagent systems. The fact that agents are able to sign certificates with private keys, makes the whole system too much dependent in the trust relation between the agent and the execution platform. This is a hard problem that we think does not have a feasible solution. At least, the agent platform should provide security mechanisms to protect agents one from each other. But obviously a previous trust relation between the agent and the execution platform must be present. An interesting issue is the clear distinction between humans and agents. For example the inclusion of the human ID in the agent’s ID. Although there will be


121

scenarios where this approach may not be suitable, in some applications may provide interesting mechanisms for the authorization of agents. It is also unclear whether the human ID included in the Agent Identity Certificate belongs to the owner of the agent or to the programmer, to an organization or to an individual, etc. Related to identity and authorization certificates it is not clear if the explicit distinction of humans and agents adds any value to the system.

5.3.4

JADE-S

The JADE-S extension, is the most official security effort for JADE. Although it presents several problems. The architecture is based on a single Certification Authority (CA) for each platform, the CA is the only principal having a cryptographic key pair. That is, the CA will perform all the cryptographic operations. The main goal of JADE-S is to provide access control. It is strongly based on the Security Manager of Java, extending the permissions to fulfill the requirements of the platform. This permissions are related to agents and determine if an agent can use the resources of the platform. To avoid the inconveniences of using static permissions, JADE-S allows the delegation of permissions with certificates, they call these certificates Delegation Certificates. This certificate has a proprietary format and does not follow any standard, and there are no interfaces to standard certificates such as X.509. The implementation of the certificates does not follow the Java Cryptography Architecture (JCA), which makes it difficult to integrate JADE-S certificate facilities with other implementations. They also provide Identity Certificates, which are intended to provide authentication of agents. Each agent has a certificate folder to store certificates, normally is the subject of the certificate who keeps the certificate in its folder. This solutions may become very limited when considering complex situations of re-delegation. But JADE-S only allows direct delegation, and the agent receiving the delegation can no further delegate the authorization or permission. Besides the base problems of this approach concerning the architecture. The important thing to note is that it does not provide any extension to the communication

122


layer, such a specific ontology. That is,if an agent wants to send a Delegation Certificate to another agent it does it by sending a standard FIPA ACL message with the certificate in the content of the message. The content is a string representation of the certificate encoded in a byte sequence. In the samples provided by JADE-S one agent uses a FIPA inform message to send the Delegation Certificate. JADE-S does not provide any kind of interaction protocol for the interchange of certificates. It is not clear under what circumstances a certificate is issued. Although there are policy files, these files correspond to Java policy files and they only provide static information about the access to resources. For example, can an agent request a Delegation Certificate to another agent?, if this is possible, how is the interaction of the two agents carried out?, how does the second agent decide whether to issue the certificate or not? etc. We think these are important issues that should be solved by the infrastructure, and not leaved to the agent programmer. Conclusion We think that JADE-S may solve some security problems in specific scenarios, but it lacks some important features. The introduction of mobility may require the redesign of the whole system. For instance, it is stated in the documentation [Vit02] that: “Since all JADE certificates are signed by the platform Certificate Authority, they are valid only internally to the platform where they where signed”. It lacks interoperability with existing certificate technologies or solutions, and does not provide any kind of interaction protocol for the interaction of agents concerning certificate issues.

5.3.5

Secure Knowledge Query Manipulation Language

The Secure Knowledge Query Manipulation Language (SKQML) is an extension of the Knowledge Query Manipulation Language (KQML) proposed in [RFSL] and [TFM95], and it is heavily based on SPKI/SDSI. The naming of agents is based on the Jackal’s naming scheme. Jackal4 is a Java 4

The project home page provides links to software implementation and documentation:


123

implementation of the KQML agent communication language [CFL+ 99], which uses SPKI/SDSI local names to name agents. The whole architecture is based on some kind of authority or proxy server named Security Server Agent (SSA). This agent is responsible of distributing certificates and other signed statements on behalf of the agents. Initially all the agents are considered as principals with a public and private key pair. The SSA can be seen as a component providing the security mechanisms, which can be used by any principal agent or by a dedicated agent such as an Agent Name Server agent. The most interesting part of this proposition is the definition of KQML performatives (or actions), the KQML syntax and message format, and an SPKI/SDSI based language and ontology called (SSBL). Here we will focus on the description of the SSBL. About the KQML performatives, they are mainly based on the request, tell, refuse, and failure performatives. SSBL SSBL is a propositional content language for representing SPKI/SDSI information. The language differentiates between two types of actions: Intra-Agent and Inter-Agent actions. Intra-agent actions are the ones requested using the request performative. These actions are sent by an agent to itself to initialize its name certificate database, generate public-key pair, generate auto-certificates, and generate delegation certificates. The Inter-agent actions are also requested using a request performative, but in this case the content includes the action to be performed by the receiver agent and the result of the execution will be returned to the sender using either a tell, failure, or deny performatives. Inter-Agent Actions: • register-agent: the sender registers itself with the Agent Name Server. It sends a request performative with the action register-agent and the S-expression of a name certificate with the agent’s public key as the issuer and the agent’s local http://www.csee.umbc.edu/~cost/projects/jackal

124


name as the subject. • authenticate-agent-by-name: the sender requests the receiver to verify the name certificate included in the requests. The receiver (verifier) may respond with a tell message with the content true or false. • authenticate-agent-by-key: the sender requests the receiver agent to verify a certificate provided in the request, which includes the SPKI/SDSI public key. The receiver (verifier) may respond with a tell message with the content true or false. • sign-object: the sender requests the receiver to sign the object provided in the request with the receiver public key. • hash-object: the sender requests the receiver to hash the content of the request. • check-authorization: the senders requests the receiver to check an authorization certificate. • check-membership: the sender requests the receiver to check that a given agent is a member of a particular group. • verify-signature: the sender requests the receiver to verify a signature. • list-required-cert: the sender requests the receiver for a list of required certificates. • add-to-group: the sender requests the receiver to be included in a group identified by a name certificate provided in the requests. That is, to issue a name certificate. • reconfirm: the sender request the receiver to reconfirm the certificate included in the request. Intra-Agent Action: • generate-key: generate a pair of keys.


125

• issue-auto-cert: generate an auto-cert. • issue-local-name-cert: issue a name certificate. • issue-acl-entry-cert: issue an ACL entry to be store in an ACL certificate database. • issue-delg-cert: issue an authorization (delegation) certificate. • issue-group-member-cert: issue a name certificate referring to a group membership. • encrypt-object: encrypt an object with the agent’s public key. • decrypt-object: decrypt an object with the agent’s private key. Protocols They main objective is for two agents to agree in performing some interaction based on the possible SPKI/SDSI verification. They determine which agent is responsible for providing proofs, that is, certificate chains needed to verify the request. The protocols defined for the SKQML are: • Cooperative: the receiver agent does not provide any additional information about certificates needed to the requesting agent. • SemiCooperative: the receiver agent will inform the sender with the kind of certificates needed. • MostCooperative: the receiver agent retrieves whatever information (certificates) it needs. Conclusions The extensions provided to KQML seem quite interesting and the integration of SPKI/SDSI S-expressions into the messages is quite straightforward. Although KQML is an important precedent for agent communications languages, its future is not very

126


clear. Other initiatives such as the Darpa Agent Markup Language (DAML)[DAM], DAML+OIL5 [CvHH+ 01], or the Web Ontology Language (OWL) [OWL03], seem to be the next step for the KQML community. We also think that some of the actions described in the SKQML are redundant, and the whole communication acts could be achieved with a reduced set of actions. And the interaction could be simplified. The description of the protocols is not very detailed and some implementation issues are not very clear. For instances, it is not clear how certificates are distributed and retrieved. There is no reference to mobile agents, and the architecture is not very clearly defined. This last issue may be an advantage, since it allows a high degree of customization and adaptation to specific scenarios but may also introduce incompatibilities and reduce interoperability of different implementations. There is also a high degree of dependence in SPKI/SDSI. A more abstract definition may allow the use of other technologies such as X.509, SAML, . . . .

5.3.6

Extension of execution tracing with certificates

Hock Kim Tan and Luc Moreau presented a security framework for mobile agents in [TM02a], and [TM02b]. The framework is based on execution tracing. When an agent is executed in a platform, the platform keeps a trace of the agent’s execution. This trace contains the instructions (lines of code) executed by the agent and the external values that were read by the agent. When the agent requests to move to another platform a hash of the trace is signed by the host platform and forwarded with the mobile agent to the next host platform. This action is performed by each platform in the agent itinerary. When the agent returns, the owner can request the trace of the agent’s execution of the whole itinerary or just one agency, simulate the execution of the agent, etc. Agents are built using agent templates based on software design patterns. 5

OIL is the Ontology Inference Layer (http://www.ontoknowledge.org/oil).


127

Components The framework includes the following entities: • Certificate Authority: issues certificates and undertakes all necessary key management activities. • Agent owner platform: original departure platform for the mobile agent. This platform is assumed to be a representative of the player of the agent. • Host platform: execution platform where the agent migrates from the agent owner platform. Note that the agent platform can be a host platform for other agents. • Verification server : trusted third party (TTP) that performs the verification of execution traces. The verification is submitted by host platforms on behalf of the agent owner platform. • Capability Certificates: a validity certificate associates the identity of a host platform with its capability of correctly executing specific agent templates. In a capability certificate the subject public key is replaced by a template identifier, which identifies the template that can be safely executed in the host. • Execution Certificates: when a verification server verifies the execution trace of an agent, it issues an execution certificate. It includes among other things, the identity of the verification server, identity of the host platform that undertook the execution of the mobile agent, a timestamp, and a hash of the agent code and state (trace). It is signed by the verifier server. • Capability certificate revocation list: analogous to a traditional CRL. The entries are issued by verification servers and a mobile agent can choose to inspect the list prior to migrating to a new platform. Operation The operations of this framework can be described given the following scenario. Consider a host platform (HP1 ), with a mobile agent (M A), which will migrate to another

128


host platform (HP2 ) and then to another one (HP3 ). As the TTP we have a verifier server V S. We consider the mobile agent identifiers to be a list of agent templates implemented by the agent and the immutable code of the agent, signed by the owner platform. We will denote these identifiers with IDM A . The migration of the mobile agent will involve the following steps:

1. The IDM A is submitted to HP2 by the mobile agent M A, which from HP1 wants to migrate to HP2 . 2. HP2 checks whether it has capability certificates for the templates included in IDM A . It then sends these certificates back to the mobile agent. 3. M A consults the verification server V S to check the capability certificate revocation list. 4. With the previous information, the agent decides whether to migrate to HP 2 or otherwise choose another host platform. If the decision is to migrate, the agent M A moves to HP2 and it is executed by the platform. 5. HP2 prepares the execution trace and sends it back to V S. 6. If V S successfully verifies the trace, it issues an execution certificate, which is sent back to HP2 . This certificate is also dispatched with the mobile agent when the agent migrates to the next platform (HP3 ). This execution certificate is required by HP3 in order to accept the execution of M A.

If step 6 fails, the verification server creates a new entry in the capability certificate revocation list to invalidate previous capability certificates. This revocation list only invalidates capability certificates issued by the same verification server. The framework also introduces the need for periodical checking of traces. And it is important to note the necessity of the execution certificate at the receiving platform.

5.4. CONCLUSIONS

129

Conclusions The framework presented here seem interesting from a trust or reputation point of view. The whole certification framework could be easily adapted to a reputation system based on trust relations. One of the big problems with this approach is that the security is based on agent templates. That is, the ability of a platform to execute a given template. The platform will get capability certificates, which will assure others that it executes the given template in a non-malicious way. We think that in most scenarios security does not really deal with software templates. An agency will decide to have a malicious behavior not because the agent has a specific template, but for example because the agent acts in behavior of a given user. We also think that the implementation of the framework requires to clarify a lot of issues. The use of the verification servers as trusted third parties involves a lot problems common to traditional PKIs, which makes the system hardly scalable and distributable. It requires a lot of tasks to be performed after the action (malicious or not) did happen. Although it could be adapted for resource access control inside the platform its main goal is to provide security at a more general level, the whole execution of the agent. There is also the obvious problems with execution tracing, it requires the generation of lots of information and logs (the traces). In some scenarios this will be equivalent to having an infinite memory. Finally, the detection process is only triggered on suspicion that an agent has been manipulated.

5.4

Conclusions

In this chapter we have introduced the access control in mobile agents systems. We have described the basic notions of mobile agent system, and their security related issues. Security is an important subject in mobile agent systems and at the same time a very complex problem. The specific characteristics of mobile agent systems, specially due to the mobility of code, makes it hard to make use of existing security

130


solutions. We have described some of the existing solution to provide security infrastructures to support access control in mobile agent systems. While it is not an exhaustive description, we have focused on the most relevant solutions. These solutions although they provide interesting approaches to solve the access control in mobile agent system, do not present a general solution. Furthermore, they normally do not provide enough flexibility or they are too complex to be implemented from a practical point of view. In the next section we will present a specific mobile agent platform, focused on a specific kind of applications. As we will see, this environment requires a lightweight, flexible, and scalable solution for the access control. We will also present a design of an access control system which fulfils the requirements of this specific environment.

Chapter 6 Access control for MARISM-A 6.1

Introduction

The Architecture for Mobile Agents with Recursive Itineraries and Secure Migration (MARISM-A) is a project developed by the Combinatorics and Digital Communication Group (Universitat Autònoma de Barcelona), which defines an architecture for multiagent systems focused on mobility and security. In this chapter we introduce the MARISM-A Authorization Framework. It is a access control system for MARISM-A, which uses SPKI/SDSI as a base mechanism to implement an RBAC based access control..

6.2

JADE

The MARISM-A platform is defined on top of JADE [JAD] (Java Agent DEvelopment Framework). JADE is one of the most popular environments for the development of multiagent applications. It is a Java framework, which provides the platform and basic agent services. It is developed by TILAB (Telecom Italia Lab), and distributed under LGPL license, which allows to freely modify and use it. JADE is composed of several modules, which can be classified into three categories: • Core: components providing the basic and necessary execution environment for agents, considered as the kernel of the system. 131

132

CHAPTER 6. ACCESS CONTROL FOR MARISM-A

• Ontologies and Content Language management: components providing the processing and management facilities for FIPA ACL messages and protocols. • Message transport mechanisms: components providing transport level protocols to send and receive messages at intra-platform and inter-platform level. The JADE platform is based on the FIPA standards (see Section 5.1.2), and implements most of the FIPA specifications. The basic architecture of JADE is based on the reference architecture given in the FIPA specifications [FIP00c]. Figure 6.1 shows the reference architecture of a FIPA platform.

Figure 6.1: FIPA reference architecture

The Agent Management System (AMS) is an agent which is responsible for managing the operation of an agent platform. There is just one AMS for each platform and it is a mandatory component. It performs functions such as registering and deregistering components and control the execution of agents (start, finish, etc.), by providing white-page and life-cycle services. When and agent is registered with an AMS it receives an Agent Identifier (AID). The Directory Facilitator (DF) provides yellow page services to agents. And the Message Transport System controls the exchange of messages within the platform, to or from remote platforms. JADE provides support for FIPA ACL. It also provides support for interaction protocols and the definition of ontologies.

6.2. JADE

6.2.1

133

Mobility in JADE

An important feature of JADE is the concept of container. A container is the minimum execution environment for agents. Each agent platform has at least one container, the one which hosts the AMS of the platform (main container). It directly corresponds to a Java Virtual Machine (JVM). That is, each container is executed in a different JVM. This allows to separate agents in different execution groups and distribute a single platform by executing containers in different machines. The communication between containers is done using the Java Remote Method Invocation (RMI). JADE allows an agent to move from one container to another inside the same platform, such an agent is called a mobile agent in the JADE documentation. One can say that JADE provides agent mobility since several containers can be executed in different machines, and an agent can move between them. But it is important to note that all the secondary containers have a strong dependency with the main container hosting the AMS. The connections between containers must be permanent since most of the operations are centralized in the main container. Thus, we do not consider the current JADE mobility as a general agent migration. JADE lacks a true inter-platform agent migration, and one of the main tasks of the MARISM-A project is to provide this kind of migration for JADE.

6.2.2

JADE Agents

An agent is represented in JADE through the Agent class. A programmer creates an agent by extending this class, which provides basic functionality such as registration with the platform, configuration, etc. An agent presents a multitask model, where each task is executed concurrently. A task in JADE is called behaviour. The scheduling of behaviors is carried by a scheduler internal to the base Agent class. Each agent is executed as a single thread. The life-cycle of an agent follows the FIPA specifications shown in Figure 6.2. It is important to note again that the transit state is used by JADE to represent the mobility of agents between containers, it does not corresponds to an inter-platform

134


mobility.

Figure 6.2: FIPA Agent life-cycle.

Agent tasks are implemented as Behaviour objects. One can extend the class Behaviour and add custom behaviors to the agent. JADE provides several kinds of base behavior classes such as: SimpleBehaviour, CyclicBehaviour, FSMBehaviour 1 , etc. An overview of JADE behaviors and its use can be found in [BCTR03].

6.3

MARISM-A

MARISM-A is a secure mobile agent platform implemented in Java, on top of JADE. The main components of MARISM-A are summarized in Figure 6.3. Since everything is implemented in Java, all the architecture is portable between several operating systems supporting the Java Virtual Machine (JVM). JADE implements the standard elements of the FIPA specification and provides additional services for the management of the platform and additional features. Mobility is achieved by the MARISM-A mobility component which is integrated into JADE. On top of JADE there are the 1

FSM stands for Finite State Machine.

6.3. MARISM-A

135

main MARISM-A components such as the authorization framework presented in Section 6.5, and MARISM-A services such as: cryptographic service (crypto), resource directory service (dir), etc.

Platform Resource Authorization Framework

crypto dir

...

MARISM-A Services

MARISM-A

JADE

FIPA Services

MARISM-A Mobility

JADE Services

Platform Resource

Java Virtual Machine

Figure 6.3: MARISM-A Architecture.

Within the project MARISM-A there has been several more components developed such as an agent launcher, and an IDE (Integrated Development Environment) for the rapid and visual development of mobile agents. The main idea behind MARISM-A and the base design guides were to provide a lightweight secure mobile agent platform suitable for heterogeneous environments. The basic element of the MARISM-A platform is the agency, the environment for the execution of agents. An agency consists of a directory service, an agent manager, and a message transport service. An agent system has several agencies distributed on a network. Each agency in controlled by an entity (its owner). Agents in MARISM-A can be mobile or static, depending on the need of the agent to visit other agencies to fulfill its task. There are several types of mobile agents according to the characteristics of its architecture: basic or recursive structure, plain

136


or encrypted, itinerary representation method, etc. Agents can communicate each other through the agency communication service. All mobile agent architectures in MARISM-A share some basic characteristics, such as the differentiation of internal parts and migration mechanisms, described in [MB02]. MARISM-A supports various levels of encryption for securing the communication and the migration of agents between agencies, such as transport layer: SSL-based protocol, message: FIPA Agent Communication Language messages encryption, application level, etc. It is important to assume that agencies untrust each other. Therefore, they might try to modify results carried by the agent, or to gain knowledge about its itinerary, to favor themselves to the detriment of the rest. It is also reasonable to assume that agencies are not malicious and they do not seek to adversely affect the owner of the agent (the client), or the agent itself. From now on, we will denote Ei (m) as the encryption of m using an asymmetric cipher with i’s public key, which is denoted as Ki ; SY Mi (m) as the encryption of m using a symmetric cipher with i’s secret key, which is denoted as KSY Mi ; Si (m) as the digital signature of m using i’s private key; and hash(m) as the hash function of m.

6.3.1

Mobile Agents with explicit itinerary

Agent code is divided into several pieces in this architecture. There is a global part, which will be executed in all agencies, and several local parts, one for each agency. This feature makes MARISM-A very useful in some types of application where execution is context dependent. The global part includes: GlobalCode, GlobalData and ControlCode. The control code deals with the functions of agent management, in this case extracting the relevant parts of the agent. At the same time each local part or LocalStructure contains LocalCode, LocalData, and Agencies. Agenciesi is the agency (or agencies, depending on the type of itinerary) the agent is going to visit (migrate) next.

6.4. SEA-OF-DATA APPLICATIONS

137

To protect the agent architecture we consider the following encryption schema: Agent = ControlCode, CommonCode GlobalData, LocalStructures, So (hash(ControlCode, CommonCode)) LocalStructures = SY M1 (E1 (Ko , LocalCode1 , LocalData1 , Agencies1 , t1 , KSY M2 )), ..., SY Mn (En (Ko , LocalCoden , LocalDatan , Agenciesn , t1 , nil)) Each local structure is first encrypted with the public key of the agency, where the structure is going to be executed. Then, a chained structure of symmetric ciphers is included to avoid possible attacks by an agency that appears more than once in the same itinerary. When the agency i sends the agent to agency i + 1 it also sends Ki+1 , so agency i + 1 can decrypt its local structure. Note that each Ki is different and generated by the owner. A hash of the static common parts is signed by the owner, so each agency can verify it before accepting the execution of the agent. Finally ti is a tripmark, usually a timestamp or a nonce, and Ko is the owner’s SPKI public key. The results obtained by the agent in each agency of the itinerary are protected using a hash chain, which is described in [RMAB02], as well as a detailed explanation of the encryption schema. A variant of this agent is the mixed one, where the list of information for agencies is scrambled. This makes it not possible to know which is the part of the agent that will be executed on which agency.

6.4

Sea-of-Data applications

MARISM-A is a platform intended to provide an easy and suitable support for implementing Sea-of-Data (SoD) applications. SoD applications are those that need to process huge quantities of distributed data over a network. These kind of applications have become very relevant in the last years. As the Internet grows and the use of digital data increases, there are numerous situations where there is a need to process data, which is distributed over the Internet (or

138


other networks). A common approach to this problem is to centralize all the data processing. That is, all the distributed data has to be transmitted to a central point where it is processed. This solution introduces strong requirements in the network bandwidth (all data needs to be transmitted), and processing power (a single point has to process all the data). Mobile agents appear as the most feasible solution for SoD applications. Instead of having to centralize the data in a central point, the code to process the data can be sent were the data is located. A mobile agent (or several mobile agents) travel through all the locations of the network to retrieve the data a process it in situ. There are lots of scenarios for SoD applications, ranging from distributed network management and distributed intrusion detection systems, to general distributed data processing applications. In this section we introduce a sample SoD application for processing medical images.

6.4.1

Distributed medical image processing

This sample applications is derived from the European Commission funded project IST-1999-10310 INTERPRET (International network for Pattern Recognition of Tumors Using Magnetic Resonance)2 . It considers a medical SoD applications for radiology images. There are several hospitals, research centers, and companies with a radiology department, which produces some kind of sensitive, and possibly expensive radiology images such as magnetic resonances or high resolution radiologies. For example, a hospital can have a database of radiology images. These images can be used by doctors and physicians to treat the patients, and the patients themselves may access their own images. But the images can also be used by external research communities to train classification algorithms, develop tumor recognition tools, etc. In the later case, a researcher may want to use all the magnetic resonance images of a given type from all the hospitals to train a classification algorithm. The main idea is that the researcher can send a mobile agent to all the hospitals and train the algorithm in situ. 2

More information about the project can be found in: http://carbon.uab.es/INTERPRET. The project ended the 31st of December 2002.

6.4. SEA-OF-DATA APPLICATIONS

139

She does not need to copy and transmit all the images to a central host.

Figure 6.4: Sample SoD application.

Figure 6.4 shows a simple scenario, where a researcher from a given research center wants to process images from hospitals A, B, and C. Each institution has a MARISMA platform which can access the database. The researcher sends a mobile agent to each one of the hospitals to process the required data. As it can be seen the resource access control mechanisms provided by the platform are a key component of the system. One can think of hundreds of hospitals distributed over the country or even thousands over the world. The access control system should provide a lightweight, scalable and easily distributable infrastructure to manage the privileges and permissions of the users. The application may provide the ability for clients to process the distributed data in a variety of ways, for example testing a classification algorithm. The owner of the data may also provide itself classification services. It may have a trained classification system, which a client may use to classify a reduced set of data provided by herself. The reason for using a mobile agent approach in this application, is due to the high quantity of distributed data, which is difficult to centralize. And also because the medical data normally contains some sensitive information, which the hospitals are normally not allowed to give it to someone else. That is, a mobile agent processing

140


the data, may get back to the client with the obtained results, but not with the data. We will consider each participating entity as a principal. A principal may be a static agent or an individual (normally the owner of a mobile agent). We consider three kinds of principals, data producers, data consumers and process consumers: • data producer : updates the database, adding new images or replacing existing ones. • process consumer : provides a reduced set of data, and wants to use some processing service provided by the agency (normally a complex trained algorithm such as a classification one). • data consumer : it provides a code to be executed with the data provided by the agency. As we said, the system may become very large in number of principals. To make the authorization management easier we have choose to use an approach based on RBAC (See 2.6). RBAC allows to express the permission and authorization information in terms of roles, which may comprise several users. A simple definition of roles for the example application may be: • physician: authorized as data and process consumer for all the resources. • external physician: authorized as process consumer for a reduced set of data. • radiography technologist: authorized as a data provider. • external researcher : authorized as data consumer for a restricted set of data. These roles may be hierarchically extended, for example as radiography technologist, there may be radiographer, which provides only radiographies and mr technologist, which provides only magnetic resonances.

6.5. MARISM-A AUTHORIZATION FRAMEWORK

141

CRM Author. policy

Role policy RC

Definition of authorizations over the resource

AM

Roles

Roles’ definition, membership, and hierarchies

Author. policy Direct delegation of authorizations

RM

Delegation of authorizations to Roles

Figure 6.5: Main modules for the MARISM-A Authorization Framework.

6.5

MARISM-A Authorization Framework

One of the first problems we found when planning the authorization framework, is if the mobile agents should have SPKI/SDSI keys and be considered as principals. A mobile agent cannot trivially store a private key, so it cannot perform cryptographic operations such as digital signatures. There are some propositions to store sensitive information (private keys) in mobile agents [RS98]. But the problem arises when the mobile agent uses the private key to compute a cryptographic operation. The agency where the agent is in execution will be able to see the private key. As a result we consider that a mobile agent should not have a private key. Our solution is to establish the role membership of a mobile agent directly. In a way that the agent does not need to carry any kind of authorization information, making the agent more simple and lightweight. This issue will be discussed in section 6.5.5. The access control framework is made up of independent modules, which interact to perform all the related tasks. These modules are implemented as static agents, they have a SPKI/SDSI key and are considered as SPKI/SDSI principals (see Figure 6.5).

142


6.5.1

Authorization Manager (AM)

The Authorization Manager (AM) manages the delegation of authorizations, issuing SPKI/SDSI authorization certificates. It follows a local authorization policy, and its main responsibility is to delegate authorizations to the specific roles following its local policy. It may also provide the ability to delegate authorizations to other AMs in order to distribute the authorization management. Since the authorization policy is local to the AM agent, it does not need to follow any specification and its format is implementation dependent. We propose an authorization policy, described as an SPKI/SDSI ACL, where each rule can be expressed as an ACL entry in S-expression format, similar to the policies defined by [CG02]. An SPKI/SDSI ACL entry is an authorization certificate without the issuer and it does not need to be signed because it is local to the AM and is not going to be transmitted. It has the following fields: • Subject: the principal, who can request a certificate. Note that it does not need to be the principal receiving the authorization. This allows to separate the management of the authorization certificates (who makes the request) from the authorization itself (who receives the authorization). • Authorization tag: the authorization tag matches the authorization-request issued by the principal asking for the certificate. • Delegation bit: it indicates if the Subject can delegate the right to request the certificate. • Validity: indicates the validity conditions (time range, . . . ) under which the certificate can be requested. For example, suppose principal Ka wants to request to the authorization manager AM the certificate (AM, Ka , dummy tag, 0, V1 ), Ka will issue the following authorization-request S-expression: (authorization-request (issuer AM)


143

(subject Ka ) (tag dummy_tag) (validity V1 ))

Then AM could have the following SPKI/SDSI ACL: (acl ... (entry (subject Ka ) (tag (authorization-request ...)) (validity V2 )))

Note that the subject of the ACL entry and the certificate does not need to be the same (a principal may request a certificate issued to another principal). The validity specifications V1 , and V2 may also differ. V1 indicates the validity for the request of the certificate and V2 indicates the validity for the authorization granted by the certificate.

6.5.2

Role Manager (RM)

The Role Manager (RM) manages the roles (mainly the role membership) by issuing name certificates and following a local role policy. It can also assign a role to another role defined by itself or by another RM. Thus allowing the definition of role hierarchies or the delegation of role membership management. Section 6.5.5 details how roles are assigned to mobile agents. Each RM has a local role policy which determines what roles does it manage. It also includes rules to determine if a given principal requesting a role membership has to be granted or not. This is done by using a membership-request, which is equivalent to an authorization-request, and specifies the name certificate requested. If we choose to describe the role policy as a SPKI/SDSI ACL, it is analogous to an authorization policy.

144


Now the subject of the SPKI/SDSI ACL entry is a principal or another role, and the authorization tag determines the role that the subject can have. An agent or principal, may belong to several roles. This is possible and adds a lot of flexibility to the system. Since the system only uses positive authorizations or permissions, it is not possible to find conflicting authorizations for the same agent.

6.5.3

Resource Controller (RC)

The Resource Controller (RC) main task is to control the access to a resource (data). It holds the master SPKI/SDSI key to access the resource, delegates authorizations to AMs, and verifies that an agent requesting access to the resource has a proper authorization. It delegates authorizations to one or more AM following a local authorization policy. Note that this policy is quite simple because the main authorization management is performed by the AM. For example, a RC controlling resource R1 may have the following policy: (acl (entry (subject AM1 ) (tag *) (validity V1 )) (entry (subject AM2 ) (tag data consumer(R1 )) (validity V2 )) ...)

This policy will delegate full control over the resource to AM1 and delegate the control over the authorization data consumer for resource R1 to AM2 .


6.5.4

145

Certificate Repository Manager (CRM)

The Certificate Repository Manager (CRM) implements and manages an SPKI/SDSI certificate repository, and provides services such as certificate chain discovery. For example, one agency may have one CRM to collect all the certificates issued by agents inside the agency. The CRM provides the repository and all the services needed to query, store or retrieve the certificates in the repository. It also provides a certificate chain discovery service. A principal can make a query to the CRM to find a specific certificate chain. This way, we solve the problems derived from certificate distribution and leave the task to perform chain discoveries to the CRM and not to the other principals. It decreases communication traffic, certificates do not need to travel from one principal to another, and reduces the task that generic principals need to perform. It is important to note that a distributed version of this module presents some problems mainly regarding the performance. Existing solutions, [FPP+ 01] or [LWM01], to provide distributed certificate chain discovery introduce limitations and complexity to the system.

6.5.5

Establishing Mobile Agents Role Membership

Since mobile agents cannot have private keys, we can not delegate authorizations to the mobile agent or make it member of a role. Our approach is to set as member of the role, a hash of the agent’s code. The subject of an SPKI/SDSI certificate and any SPKI/SDSI principal in general can be a public key, a hash of a public key, or a hash of an object in general[EFL+ 99a], [EFL+ 99b]. So a hash may be seen as a principal, subject of a certificate. In order to establish the role membership of a mobile agent we consider two different approaches. To show them, we use a simple example where a user Ku is member of the role physician defined by a Role Manager RM of the agency i, which has a resource controlled by a RC. The role physician allows its members to access the given resource in agency i. The user has a mobile agent with the local structure mi to be executed in agency i. The goal is to set the hash of mi as member of the role physician.

146


Approach A The RM makes member of the role physician a role (or group) defined by the user Ku , say agent. Then, the user Ku can make member of its role agent any hash of agent’s code. RM physician −→

Ku agent (issued by RM )

Ku agent

hash(mi )

−→

(issued by Ku )

Approach B The RM makes member of the role physician the user Ku . Then the users sends a request to the RM to set the agent code’s hash as member of the role. RM physician −→

Ku

(issued by RM )

RM physician −→

hash(mi ) (issued by RM under request of Ku )

The main idea is to exploit the flexibility provided by SPKI/SDSI in order to set the role of the agent. Approach A, is quite straightforward, gives the user full flexibility to manage the role Ku agent, and does not require any special mechanism or protocol. The user may add to the role any agent (or even user) she wants. The main problem with this approach is related to the accountability of the system. In e-commerce application there will be different degrees of trust between users. For example an hospital may trust an internal physician to manage its role agent, but a client from an external research center may not be so trusted. In the first case we will use Approach A, while in the second one we will use Approach B. This last approach requires and additional protocol, which is implemented as an Agent Communication Language Interaction Protocol [FIP00c]. It can be described in four steps: 1. The client sends an agent role assignment request (ara-request) to the role manager RM . Including mi and the role she wants to obtain for the agent. 2. The RM requests the CRM to verify the client’s role, and checks if she is member of the role requested in the ara-request. 3. If it succeeds, the RM computes the hash of mi and issues a name certificate such as:

6.6. CONCLUSIONS

147

RM physician −→ hash(mi ) with the hash of the code as the subject. In the last step, the RM stores the code mi , which may be used for further security audits. Note that this approach does not allow the user to manage the role and extend it to other agents. The user needs to send a request for each agent. Later, the agent arrives to agency i, it will send an access request to the RC controlling the resource. The RC just has to compute the hash of the code mi and check, through a request to the CRM, if the agent is member of a role authorized to access the resource. This last approach can be used to authorize directly an agent. If the operation is carried out by an authorization manager it can delegate an authorization directly to the agent hash. The agent does not need to belong to a role. This does not introduce any conflict or problem to the system, since it is fully supported by the SPKI/SDSI resolution and validation algorithms. Note that the authorizations associated to an agent may be determined by its role membership. This way, we can say that the agent will have dynamically assigned authorizations during its lifetime. If the authorizations associated with a role change, the authorizations related to the agent also change.

6.6

Conclusions

In this section we have presented MARISM-A, a secure mobile agent platform. MARISMA is intended to provide a suitable environment for the implementation of SoD applications. SoD applications are those that need to process huge quantities of distributed data. Mobile agent systems make it possible to send the code to process the data where the data is located. This way there is no need to centralize all the data processing, avoiding also the inconveniences of sending huge quantities of data across the network. The MARISM-A platform provides several security mechanisms, such as itinerary protection, secure communications, secure migration, etc. An important security

148


service, which needs to be properly addressed is the resource access control. This is specially important in the scenario proposed in SoD applications. We have presented a specific solution for access control in MARISM-A. This access control system is based on SPKI/SDSI and RBAC, which have been discussed in previous chapters. In the next chapter we give an overview of the implementation of the proposed access control system in the MARISM-A platform.

Chapter 7 Implementation of the MARISM-A Authorization Framework In this chapter we present the implementation of the authorization framework for MARISM-A described in Section 6.5.5.

7.1

General Overview

The implementation of the Authorization Framework for MARISM-A comprises a set of authorities: Authorization Manager (AM), Role Manager (RM), and Certificate Repository Manager (CRM). As we said in Section 6.5, the Resource Controller (RC) modules is just an AM with a simpler policy file, thus the RC is implemented as an AM. Each authority is implemented as a static JADE agent. The implementation is divided in two main components: • Java Authorization API for MARISM-A (JAM): it is an API that provides the basic functionality to the agents implementing the authorization authorities. • Agent-based Authorization system for MARISM-A (AAM): the JADE agents implementing the actual authorities: AM, RM, CRM, and RC. The implementation has been done using the Java Standard Edition version 1.4.2. In order to implement the SPKI/SDSI functionality we have used the JSDSI API 149

150

CHAPTER 7. IMPL. OF THE AUTHORIZATION FRAMEWORK

AAM JAM

MARISM−A

JSDSI

JADE3 J2SE−1.4.1

Figure 7.1: Architecture of the MARISM-A Authorization Framework.

(see Section 4.7.2). The JAM API provides an abstraction layer to the AAM. This allows to isolate the JSDSI API from the final implementation of the agents. That is, we could replace the JAM for another API based on another technology (other than SPKI/SDSI, as implemented by the JSDSI), just by changing the JAM module and keeping the public interfaces for the AAM. The implementation is presented as three main packages: • org.marisma.jam: implements the JAM component. • org.marisma.aam: implements the AAM component. • org.marisma.tools: provides basic tools for generating and manipulating test data, such as parsers for S-expressions. The implementation uses the following external packages: • JSDSI : the basic functionality for SPKI/SDSI (see Section 4.7.2). • Log4j : a logging API developed by the Apache Software Foundation. It is used to provide agents with a flexible and powerful logging system [Log]. It is licensed under the Apache Software License (ASL) version 1.11 , open source, and freely available. • JUnit: a regression testing framework used to implement unit tests [JUn]. Open source software licensed under the IBM’s Common Public License Version 0.52 . 1 2

http://www.apache.org/licenses/LICENSE http://oss.software.ibm.com/developerworks/oss/license-cpl.html

7.2. JAVA AUTHORIZATION API FOR MARISM-A

7.1.1

151

Distribution of credentials

An important issue, which affects the whole system design, is how are credentials (or certificates) distributed. In [Cán02] the author considers three possible distribution modes. They need to be considered considered in the request protocol. That is, when an agent A request access to a resource controlled by agent B: • push-calculation: A provides all needed credentials so B can verify the request. This implies that B must send the ACL or a reduced set of it to A. • push-asserts: in this case B is responsible for building the proof to verify the request, but it is A who sends all the needed credentials. A may provide credential under demand of B, so B does not need to reveal its ACL. • pull : here, B builds the proof and is responsible for retrieving all the credentials. Note that this classification corresponds also to the protocols proposed for the SKQML language (see Section 5.3.5). The authorization framework uses an approach similar to the pull distribution method. The agent B (Resource Controller ) is responsible of verifying the request and find all the available credentials to prove it. But the main task of finding proofs may relay in a third participant, the Certificate Repository Manager, who may provide completed proofs to agent B. In the next sections we will describe the two main components of the implementation and other interesting issues related to the implementation.

7.2

Java Authorization API for MARISM-A

The JAM component acts as an abstraction layer to isolate the JSDSI API. It implements the main functionality that is going to be used by the AAM. This way, JSDSI is completely transparent to the upper AAM layer. The design of the JAM is heavily influenced by the Distributed Credential Management System (DCMS) [Cán02]. The DCMS is a C++ API which uses the Common Data Security Architecture (CDSA) (see Section 4.7.1).

152


7.2.1

Authorities

Authorities, together with the repository manager, are the main components of JAM. The idea is that the upper layer should be able to easily instantiate any kind of authority and perform all the basic operations through the JAM. There are two types of authorities: authorization authority, and role authority. Both authorities extend an abstract class Authority with provides the common functionality. The main attributes of the Authority class are: • publickey and privatekey: holds the RSA pair of keys used as the identity of the authority. This keys are loaded from a Java keystore by the constructor of the class. • policy: the policy file of the authority. • Others: other attributes are used to generate certificates, there is one attribute for each field of the certificate. All attributes are declared private and accessed by typical accessors (getXX/setXX). The class provides methods to load a policy file and generate certificates. Figure 7.2 shows the basic structure of the authority classes.

Figure 7.2: JAM Authorities.

7.2. JAVA AUTHORIZATION API FOR MARISM-A

153

Each authority has an identity, which is its SPKI/SDSI identity as a principal. This identity is loaded by the constructor from a Java keystore file. The identity is a requirement of the authority, in other words, an authority cannot be instantiated without an identity. Note that the authorization authority is used to implement both the AM and the RC modules of the authorization framework.

7.2.2

Repository Manager

The other important component of the JAM is the repository manager. It is mainly provided by the CertRepManager class. The repository is represented as a Java Set of certificates. The class provides basic functions to manipulate and query the repository. Possibly one of the most important points of the JAM is how the repository manager finds an authorization proof. Normally, an authority will need to check if the request of a given principal can be authorized or not. To see how does this process works with JAM, imagine a RC receives an access request from a principal P . The RC needs to check whether P is currently authorized to access the resource given its own policy and the certificates stored in the repository. 1. The RC receives the access request from the principal P . It generates a challenge. The challenge has the form of a certificate and it is the actual proof to check. The issuer of the challenge is the RC and the subject is P . Now, RC needs to check if there is a direct path of delegation between the subject and the issuer of the challenge. 2. The RC sends the challenge and its own policy to the repository manger. 3. The repository manager tries to find the proof expressed in the challenge using the repository and the policy provided by RC. 4. Finally the repository manager notifies the results back to the RC.

154


Figure 7.3 shows and schema of the previous steps. Note that the challenge generation is done using the generateChallenge() method from the authority, and the proof checking with the checkProof() method of the repository manager.

Figure 7.3: Finding an authorization proof.

The main accessible methods of the repository manager are: • clearRepository: deletes all the certificates of the repository. • isRepositoryEmpty: returns true if the repository is empty, false otherwise. • addCertificate: appends a single certificate to the repository. • save: saves the whole repository in a file in S-expression format. • load: loads a new repository from a file. • toSexp: converts the repository to an S-expression.

7.3. AGENT-BASED AUTHORIZATION SYSTEM

155

• checkProof: checks a proof, by attempting to find a certification path for a given challenge and policy using the repository.

7.2.3

JAM Policy

Finally, the JAM API provides utilities for manipulating SPKI/SDSI policies. The JAMPolicy class provides a representation of the policy. It can be seen as a simple wrapper around the SPKI/SDSI ACL object provided by the JSDSI API. A policy is mainly an SPKI/SDSI ACL, and the class provides methods to manipulate the policy. This methods are normally accessed through the authority classes, and the programmer does not need to deal with them directly. It has a public interface to allow the extension of the framework. For instance, it may be interested to provide a visual utility to manipulate policies.

7.3

Agent-based Authorization system

The main functionality of the Agent-based Authorization system for MARISM-A (AAM) is described in Section 6.5. It mainly comprises the implementation of the four modules of the authorization framework (AM, RM, CRM, and RC) as JADE agents. Figure 7.4 shows the basic structure of the AAM agents. There is a class for each agent: AMAgent, RMAgent, CRMAgent, and RCAgent, extending the abstract class BasicAuthAgent. The main functionality implemented in the BasicAuthAgent is related with the initialization of the agent: load the agent properties, initialize the logger, register with the Directory Facilitator (DF) of the platform, etc.

7.3.1

Communication

The communication between agents is performed using FIPA Agent Communication Language and FIPA interaction protocols. Actually, all the message exchange between agents is a FIPA Request Interaction Protocol, with the standard communicative acts as shown in Figure 7.5.

156


Figure 7.4: AAM Agents.

The communication is based on requesting actions to the AAM agents. These actions are defined in an ontology called the MarismaAuthorizationOntology, which is provided in the org.marisma.aam.onto package. It includes functional actions such as issue-certificate (used to request the issue of a new certificate to the authorities), or check-proof (used to query the certificate manager for an authorization proof), and administrative actions. The administrative actions can be used to manage the AAM from external applications or from a GUI component of the agent.

7.3.2

Behaviors

All the tasks performed by AAM agents are implemented using JADE behaviors. Behaviors are the common way to implements agent tasks in JADE. More information on JADE Behaviors can be found in [BCTR03]. Each agent waits for incoming messages. If the message is part of a FIPA Request, and uses the MarismaAuthorizationOntology, the agent checks the action. If the agent can perform the action attempts to execute the corresponding task and follows on with the Request protocol. Figure 7.6 shows the basic structure of the main behaviors used to implement the

7.3. AGENT-BASED AUTHORIZATION SYSTEM

Initiator

157

Participant

request

refuse [refused] agree [agreed and notification necessary] failure

inform-done : inform [agreed]

inform-result : inform

Figure 7.5: FIPA Request Interaction Protocol.

AAM agent tasks. There are other less important behaviors used to execute specific tasks.

The RequestAuthBehaviour extends the JADE SimpleAchieveREResponder behavior, which provides the base for implementing a responder for the FIPA Request protocol. The RequestAuthBehaviour performs the basic operation of the agent, and for each kind of agent there is a specific behavior which implements the actions of the agent. For instance, there is a AMAgentBehaviour, which implements the actions of the AM agent.

158


Figure 7.6: AAM Behaviors.

7.4

Other implementation details and considerations

In this section we present some interesting implementation details and some considerations and conclusion about the implementation.

7.4.1

Agent properties

Each agent is associated with a properties file which describes configuration information such as how to retrieve the identity (RSA key pair) if the agent is an authority, etc. Currently JADE provides useful facilities to use properties files for agents, making it quite easy to implement it. In the AAM framework the class BasicAuthAgent loads the properties file for the agent. By default, the name of the properties file is the name of the agent class, for example for the AMAgent agent class the properties file is AMAgent.properties, but the name can also be specified as a parameter when the agent is executed.

7.4. OTHER IMPLEMENTATION DETAILS AND CONSIDERATIONS

7.4.2

159

Logging

We considered logging facilities a fundamental part of the Authorization Framework. AAM agents should had the ability to log messages in a flexible and easy way. Information from log messages can be used for auditory purposes, anomaly detection, etc. But it is also very useful for debugging, specially in multiagent systems, where the task of debugging can become very complex. The MARISM-A, and JADE platforms do not provide any kind of logging facility, so we considered external tools. We choose Log4j because it is possibly the most powerful logging framework for Java and at the same time it is quite easy to use. Note that currently (since version 1.4) the J2SE includes a logging API, which is strongly based on Log4j, but with less features. At initialization time each agent loads a properties file, one of this properties is the configuration file for the logger of the agent. Log4j allows a fine grained configuration of the logger through properties files. For instance one can specify where to store the logs: file, database, send them by email or by JMS (Java Messaging Service),etc.; the format of the log: plain text, XML, etc.; and how to store the information. Then, from each agent the programmer can call the logger and store a message for various verbosity levels (information, error, alert, etc.). Furthermore, all the loggers of the applications can be organized in a hierarchical manner which allows to inherit properties from one logger to another. As a conclusion we think that a mobile agent platform should provide logging facilities. The platform may log information about its functionality and offer a logging service for the agents.

7.4.3

Testing

We have perform unit tests during the development of the Authorization Framework. For the JAM component we used JUnit, which proved to be very useful and easy to use. On the other hand, testing the AAM component became more complex. We finally implemented the tests for the AAM from scratch, since it was to complex to integrate the JUnit framework with the JADE platform to test the agents classes and

160


components. An interesting topic of further study may be to consider how to integrate unit testing in multi agent programming, and more specifically in the JADE platform.

7.5

Conclusions

This chapter summarizes the main issues regarding the implementation of the access control system for the MARISM-A platform, which has been introduced in the previous chapter. We have described the context of the access control system. Mainly the MARISMA platform and the underlying JADE framework. And we have described the Authorization Framework modules and some implementation details. It is important to note that we have just given an overview of the implementation and not an exhaustive description of all the system.

Chapter 8 Conclusions In this dissertation we have presented our work on mobile agent systems and access control. The study revealed that access control in mobile agent systems is a hard problem. The mobility of code imposes some limitations, which makes the use of existing solutions in distributed systems access control very difficult. In Chapter 2 we have summarized an overview of access control theory, presenting three major approaches to solve the access control problem: MAC, DAC, and RBAC. We have also introduced some formal descriptions of models for each approach, and presented the limitations and advantages of each one. Mandatory policies (MAC) present the need for a central authority to set all the access control rules. In distributed systems such as mobile agents system the idea of a central authority involves a strong limitation. If we consider a corporate environment where several entities interact by sharing some resources, the idea of a central authority which regulates the access control is not feasible. Each entity will want to have control over its own resources, making discretionary policies (DAC) more appropriate. In DAC policies, a user owning a resource can set the rules to share the resource, and the whole system becomes more flexible and scalable. In a system with a huge number of users, it may also be desirable to be able to define these access rules and authorizations not only in terms of individual users, but also in terms of groups. We have seen that grouping users for access control purposes makes the access 161

162

CHAPTER 8. CONCLUSIONS

control management easier. This idea is somehow exploited by RBAC. In RBAC the authorizations and permissions are based on the role the users play within an organization. RBAC has gained lot of attention the last years both from the academia and the commercial communities, and appears as an interesting solution for the access control management in large distributed systems. We have reviewed some of the current efforts in access control in Chapter 3. As we have seen, X.509 provides some good support for implementing access control policies. The X.509 standard is used widespread in security products for authentication purposes. This makes X.509 a good candidate to implement access control systems, which can be integrated in existing security infrastructures. Using a certificate to store access control information has some interesting advantages. The information can be easily transmitted through unreliable networks, which is desirable in distributed systems where different users generate information, and there may be distributed sources of information. Using X.509 for access control normally implies a two steps process: authentication and authorization. That is, when a user accesses the system, the user is authenticated and then, based on the identity of the user, the authorization information can be retrieved. Another approach is to bypass the authentication step by using authorization-based solutions. In this case, the identity of the user is not directly relevant to the system. When a user request a resource, the system (or the access request verifier) just needs to know if the user has a proper authorization. Eliminating the authentication step makes the access control system simpler and easier to implement. By the other hand X.509 is always associated with the idea of a trusted third party (TTP) (both for authentication and for authorization) which creates the need for a strong trust relation between all the entities of the system and the TTP. Trust management systems such as KeyNote bind public keys directly to authorizations or permissions. Another interesting issue regarding trust management systems is that they do not normally assume the presence of a TTP. This is specially interesting in scenarios where several independent entities interact with each other.

163

Another important current research topic in access control is focused in XMLbased frameworks and languages. XML has become a de facto standard for representing and exchanging all kinds of digital information. In Chapter 3 we have seen SAML, an XML framework for exchanging authentication and authorization information. SAML is focused around the concept of assertion, which can be seen as an XML simplified counterpart of an X.509 certificate. Although SAML is currently an OASIS standard, its stage of development and adoption is still a bit premature, but may possibly play a key role in the next years. Following with XML, we have seen the XACML. XACML provides a standard language based on XML to specify access control policies. It does not directly address the problem of exchanging information and thus cannot be considered as certificatebased access control. We have included a short description due to its widespread relevance, and close relation to SAML. We have also described the main ideas behind the PERMIS server as an example of access control system, which makes use of certificate-based access control. PERMIS uses X.509 attribute certificates for authorization and X.509 public key certificates for authentication. An interesting feature of the PERMIS server is that, together with X.509, it uses an XML-based language to express policies. This policy language does not follow any standard, possibly because when the server was developed there was not such a standard. Today this language could have been XACML. We think that the authorization-based access control like the one used in KeyNote provides an interesting and novel approach for access control. In a complex distributed system such as a mobile agent system, we normally find applications where independent entities have to interact in some task. The use of a TTP may impose an artificial scenario, which does not corresponds to the actual needs of the application. By the other hand, as identities are not a requirement for the system the access control system and its implementation can be simplified. Although KeyNote introduced an interesting precedent for authorization-based access control we have focussed in a more mature technology: SPKI, presented in Chapter 4. By combining the concept of distribution of authorization and local names, SPKI/SDSI provides an interesting infrastructure to deal with authorizations

164


in distributed environments. We have seen in the previous chapter the benefits of this kind of authorizations frameworks for the implementation of access control systems. Although SPKI/SDSI provides an attractive approach towards access control it has some drawbacks, which have been discussed in Chapter 4. It presents limitations in the delegation model, delegation can only be constrained by a boolean value. The lack of good implementations in several languages also imposes limitations when considering the implementation of a system based on SPKI/SDSI. We chose SPKI/SDSI as the base technology to implement an access control system for our mobile agent platform MARISM-A. Despite the drawbacks of SPKI/SDSI, it provides an interesting and novel research field to explore the use of authorization, delegation, and local names in an access control system for distributed systems and precisely mobile agent systems. In Chapter 5 we have introduced the access control in mobile agents systems. We have described the basic notions of mobile agent systems, and their security related issues. Security is an important subject in mobile agent systems and at the same time a very complex problem. The specific characteristics of mobile agent systems, specially due to the mobility of code, makes it hard to make use of existing security solutions. We have described some of the existing solution to provide security infrastructures to support access control in mobile agent systems. While it is not an exhaustive description, we have focused on the most relevant solutions. These solutions, although they provide interesting approaches to solve the access control in mobile agent system, do not present a general solution. Furthermore, they normally do not provide enough flexibility or they are too complex to be implemented from a practical point of view. We have also presented MARISM-A, a secure mobile agent platform in Chapter 6. MARISM-A is intended to provide a suitable environment for the implementation of SoD applications. SoD applications are those that need to process huge quantities of distributed data. Mobile agent systems make it possible to send the code to process the data where the data is located. This way there is no need to centralize all the data processing, avoiding also the inconveniences of sending huge quantities of data across the network.

165

The MARISM-A platform provides several security mechanisms, such as itinerary protection, secure communications, secure migration, etc. An important security service, which needs to be properly addressed is the resource access control. This is specially important in the scenario proposed in SoD applications. We have presented a specific solution for access control in MARISM-A. This access control system is based on SPKI/SDSI and RBAC. Finally we have summarized in Chapter 7 the main issues regarding the implementation of the access control system for the MARISM-A platform, which has been introduced in the previous chapter. We have described the context of the access control system. Mainly the MARISM-A platform and the underlying JADE framework. And we have described the Authorization Framework modules and some implementation details. Some of the work described in this dissertation has been published in [NRB03, NRB02c, NRB02b, NRB02e, NRB02a, RNP+ 02, NRB02d, RLN+ 02] Future research Although we have proposed an interesting solution to access control for the MARISMA platform there are still some issues to be considered. One of the main issues to be addressed is to provide a good support for the end user. Our system may seem quite complex to manage for a general user without knowledge of SPKI/SDSI, authorizations, delegation, etc. Such a system should provide good interfaces for the end user, possibly graphic interfaces, abstracting the underlying complexities of the system. SPKI/SDSI provided a good base of study for our access control system, but as we have seen, it also presents some limitations. The use of other technologies or even the redefinition of a new one could overcome this limitations. During the study for this work we identified several interesting research topics, that can be explored in the future: • Delegation: although the concept of delegation in authorization frameworks and access control is not new, it is very limited. As we have seen, the delegation

166


in SPKI/SDSI presents several limitations. The X.509 standard also supports delegation, but currently there are no implementations of the delegation extensions of X.509. This is mainly due to the complexity that delegation adds to resolution algorithms. Taking an access control decision, when delegation is present, involves the consideration of several topics and can become very complex. A future line of research will be to study delegation from all possible perspectives, overcoming limitations and providing more flexibility, from formal models to designs and implementations. Finally it will be interesting to provide resolution algorithms which could be implemented in frameworks making use of existing technologies such as X.509 or XML. • Trust Negotiation: when two parties have to negotiate an access request there is always a lack o privacy imposed by some previous trust relation. Normally the verifier of the access request presents its access policy to the requester reveling information, which could be kept secret. Trust negotiation deals with the problem of negotiating access requests achieving the highest possible degree of privacy. It is a quite novel field in access control an introduces interesting issues. For instance, problems such as how can two parties establish a trust relation without knowing anything one from the other, and just by revealing the minimum information needed to negotiate the access control request. • Distributed certificate chain discovery: as we have seen, one of the problems we found when designing the access control system for MARISM-A was to consider how to provide a distributed certificate repository. Finding an authorization proof, when the certificates are distributed in several locations, becomes a very complex problem. Although this problem is specially hard in SPKI/SDSI mainly due to the indirections that can appear as a result of local names, the same problem also applies to other frameworks supporting delegation such as X.509. Currently most of the approaches to solve the problem are based on resource discovery techniques used in P2P (peer-to-peer) networks. The main problem we find with these solutions is its complexity and the difficulty to adapt them to existing scenarios.

167

• Authorization management in dynamic coalitions: we have seen that the use of authorization frameworks can be very useful in distributed systems such as mobile agent systems. This idea is beginning to be exploited by the Grid community. In fact some of the technologies presented in Chapter 3 have presence in Grid software toolkits. There is a lot of work to do in the use of authorizations for huge distributed systems were several communities can interact, make up coalitions, etc.

168


Bibliography [ACMR02] S. Ajmani, D. Clarke, C. Moh, and S. Richman. ConChord: Cooperative SDSI Certificate Storage and Name Resolution. In Proceedings of the 1st International Workshop on Peer-to-Peer Systems (IPTPS’02). Springer, March 2002. [ADG+ 92] R. Ahad, J. Davis, S. Gower, P. Lyngbaek, A. Marynowski, and E. Onuegbe. Supporting access control in an object–oriented database language. In Proceedings of Advances in Database Technology (EDBT ’92), volume 580 of LNCS, pages 184–200. Springer, March 1992. [AE00]

T. Aura and C. Ellison. Privacy and accountability in certificate systems. Technical report, Helsinki University of Technology Laboratory for Theorical Computer Science, 2000. Research Reports 61.

[Age]

Agent Tcl. http://agent.cs.dartmouth.edu/general/agenttcl.html. Department of Computer Science, Dartmouth College. Hanover, NH, USA.

[Ais03]

S. Aissi. Runtime environment security models. Intel Technology Journal, February 2003.

[Aja]

AJANTA,

mobile

agents

http://www.cs.umn.edu/Ajanta/home.html.

research Computer

project. Science

& Engineering, University of Minesota. [AJG99]

V. Atluri, S. Jajodia, and B. George. Multilevel Secure Transaction Processing. Kluwer Academic Publishers, 1999. 169

170

[App]

BIBLIOGRAPHY

Appel

Computer

Inc.

Apple

CDSA.

http://developer.apple.com/darwin/projects/cdsa. [ASF]

Apache HTTP server version 2.0 documentation. The Apache Sorfware Foundation, http://httpd.apache.org/docs-2.0.

[ASS]

Apache–SSL. http://www.apache-ssl.org.

[Aur98]

T. Aura. On the structure of delegation networks. In Proc. 11 th IEEE Computer Security Foundations Workshop, pages 14–26, Rockport, MA, June 1998. IEEE Computer Society Press.

[Aur99]

T. Aura. Distributed access-rights management with delegation certificates. Lecture Notes in Computer Science, 1603:211–236, 1999.

[Bal90]

R. W. Baldwin. Naming and grouping privileges to simplify security management in large databases. In Proc. IEEE Symposium on Research in Security and Privacy, pages 116–132, 1990.

[BBFS98]

E. Bertino, C. Bettini, E. Ferrari, and P. Samarati. An access control model supporting periodicity contraints and temporal reasoning. ACM Transactions on Database Systems, 23(3):231–285, September 1998.

[BCF+ 97]

J. F. Barkley, A. V. Cincotta, D. F. Ferraiolo, S. Gavrila, and D. R. Kuhn. Role based access control for the world wide web. In Proc. 20th NIST-NCSC National Information Systems Security Conference, pages 331–340, 1997.

[BCTR03] F. Bellifemine, G. Caire, T. Trucco, and G. Rimassa. JADE programmer’s guide. TILAB, 2003. [BDF02]

O. Bandmann, M. Dam, and B. Sadighi Firozabadi. Constrained delegation. In Proceedings of the IEEE Symposium on Research in Security and Privacy, pages 131–140, Oakland, CA, May 2002. IEEE Computer Society Press.

BIBLIOGRAPHY

[Bel73]

171

D. E. Bell. Secure computer system: A refinement of the mathematical model. Technical Report ESD-TR-278, vol.3, The Mitre Corp., 1973.

[BF85]

W. E. Boebert and C. T. Fergunson. A partial solution to the disretionary trojan horse problem. In Proc. National Computer Security Conference, 1985.

[BFIK99a] M. Blaze, J. Feigenbaum, J. Ioannidis, and A. Keromytis. The KeyNote trust-management system version 2. RFC 2704. The Internet Society, September 1999. [BFIK99b] M. Blaze, J. Feigenbaum, J. Ioannidis, and A. D. Keromytis. The role of trust management in distributed systems security. Lecture Notes in Computer Science, 1603:185–210, 1999. [BFL96]

M. Blaze, J. Feigenbaum, and J. Lacy. Decentralized trust management. In Proceedings of the IEEE Symposium on Research in Security and Privacy. IEEE Computer Society Press, May 1996.

[BFS98]

M. Blaze, J. Feigenbaum, and M. Strauss. Compliance checking in the PolicyMaker trust management system. In 2nd International Conference on Financial Cryptography. LNCS, Springer-Verlag, 1998.

[Bib77]

K. J. Biba. Integrity considerations for secure computer systems. Technical Report TR-3153, The Mitre Corp., 1977.

[BIK01a]

M. Blaze, J. Ioannidis, and A. D. Keromytis. Offline micropayments without trusted hardware. In International Conference on Financial Cryptography. LNCS, Springer-Verlag, 2001.

[BIK01b]

M. Blaze, J. Ioannidis, and A. D. Keromytis. Trust management for IPsec. In Proceedings of the Symposium on Network and Distributed Systems Security (NDSS 2001), San Diego, CA, February 2001. Internet Society.

172

[BL73a]

BIBLIOGRAPHY

D. E. Bell and L. J. LaPadula. Secure computer system: Mathematical foundations. Technical Report ESD-TR-278, vol.1, The Mitre Corp., 1973.

[BL73b]

D. E. Bell and L. J. LaPadula. Secure computer system: Unified exposition and multics interpretation. Technical Report ESD-TR-278, vol.4, The Mitre Corp., 1973.

[BN89]

D. F. C. Brewer and M. J. Nash. The chinese wall security policy. In Proc. IEEE Symposium on Security and Privacy, pages 206–214, 1989.

[BVFS98]

E. Bertino, S. De Capitani Di Vimercati, E. Ferrari, and P. Samarati. Exception-based information flow control in object-oriented systems. ACM Transactions on Information and System Security, 1(1):26– 65, November 1998.

[Cán02]

O. Cánovas. Propuesta de una Infraestructura de Clave P´ ublica y su Extensión Mediante un Sistema de Gestión Distribuida de Credenciales Basado en Delegación y Roles. PhD thesis, Universidad de Murcia, October 2002.

[CEE+ 01]

D. Clarke, J. Elien, C. Ellison, M. Fredette, A. Morcos, and R. L. Rivest. Certificate Chain Discovery in SPKI/SDSI. Journal of Computer Security, 9(4):285–322, 2001.

[CFL+ 99]

R. Scott Cost, Tim Finin, Yannis Labrou, Xiaocheng Luan, Yun Peng, Ian Soboroff, James Mayfield, and Akram Boughannam. Agent-baseed infrastructure for enterprise integration. In First International Symposium on Agent Systems and Applications, Palm Springs, California, 1999.

[CG02]

O. Cánovas and A. F. Gómez. A distributed credential management system for SPKI-based delegation system. In Proc. of the 1st Annual PKI Research Workshop, 2002.

BIBLIOGRAPHY

[Cha01]

173

R. Chandramouli. A framework for multiple authorization types in a healthcare application system. In 17th Annual Computer security Applications Conference (ACSAC), dec 2001.

[CO02a]

D. Chadwick and A. Otenko. The PERMIS X.509 role based privilege management infrastructure. In 7th ACM Symposium on Access Control Models and Technologies (SACMAT 2002), pages 135–140. ACM, June 2002.

[CO02b]

D. Chadwick and A. Otenko. RBAC policies in XML for X.509 based privilege management. In Security in the Information Society: Visions and Perspectives, IFIP TC11 17th International Conference on Information Security (SEC2002), volume 214 of IFIP Conference Proceedings. Kluwer, 2002.

[COB03]

D. Chadwick, A. Otenko, and E. Ball. Role-based access control with X.509 attribute certificates. IEEE Internet Computing, pages 62–64, March-April 2003.

[CPS03]

S. De Capitani di Vimercati, S. Paraboschi, and P. Samarati. Access control: principles and solutions. Software: Practice and Experience, 33(5), 2003. John Wiley & Sons.

[CS98]

R. Chandramouli and R. Sandhu. Role based access control features in commercial database management systems. In 21st National Information Systems Security Conference, oct 1998.

[CvdL02]

K. Cartrysse and J. C. A. van der Lubbe. An agent digital signature in an untrusted environment. In Proceedings of the 2nd International Workshop on Security in Mobile Multiagent Systems, pages 12–17, June 2002.

[CvHH+ 01] D. Connoly, F. van Harmelen, I. Horrocks, D. McGuinness, P. PatelSchneider, and Lynn Andrea Stein.

DAML+OIL (March 2001)

174

BIBLIOGRAPHY

Reference Description.

World Wide Web Consortium (W3C),

http://www.w3.org/TR/daml+oil-reference, 2001. [CW87]

D. D. Clark and D. R. Wilson. A comparison of commercial and military computer security policies. In Proceedings of the 1987 IEEE Symposium on Security and Privacy (SSP ’87), pages 184–195, Los Angeles, Ca., USA, April 1987. IEEE Computer Society Press.

[D’A]

D’Agents. http://agent.cs.dartmouth.edu/. Department of Computer Science, Dartmouth College. Hanover, NH, USA.

[DAM]

The Darpa Agent Markup Language. http://www.daml.org/.

[Dat95]

C. J. Date. An Introduction to Database Systems. Addison-Wesley, 6 th edition, 1995.

[Den76]

D. E. Denning. A lattice model of information flow. Communications of the ACM, 19(5):236–243, May 1976.

[DLMO02] E. Dawson, J. Lopez, J. Montenegro, and E. Okamoto. A new design of privilege management infrastructure for organizations using outsourced PKI. In Information Security Conference 2002, volume 2433 of Lecture Notes in Computer Science, pages 136–149. Springer Verlag, 2002. [DvH66]

J. B. Dennis and E. C. van Horn. Programming semantics for multiprogrammed computations. Communications of the ACM, 9(3):143–155, March 1966.

[EFL+ 98]

C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, and T. Ylonen. SPKI Examples. The Internet Society. Internet Draft, March 1998.

[EFL+ 99a] C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, and T. Ylonen. RFC 2693: SPKI Certificate Theory. The Internet Society, September 1999.

BIBLIOGRAPHY

175

[EFL+ 99b] C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, and T. Ylonen. Simple public key certificate. The Internet Society, July 1999. [Ell99]

C. Ellison. RFC:2692. SPKI Requirements. The Internet Society, September 1999.

[Emo]

Emorphia Ltd. FIPA-OS. http://fipa-os.sourceforge.net.

[FBK99]

D. F. Ferraiolo, J. F. Barkley, and D. R. Kuhn. A role-based access control model and reference implementation within a corporate intranet. ACM Transactions on Information and System Security, 2(1):34–64, February 1999.

[FGS94]

E. B. Fernández, E. Gudes, and H. Song. A model for evaluation and administration of security in object-oriented databases. IEEE Transactions on Knowledge and Data Engineering, 6(2):275–292, April 1994.

[FIP00a]

Foundation for Intelligent Physical Agent. FIPA ACL Message Representation in XML Specification, 2000.

[FIP00b]

Foundation for Intelligent Physical Agent. FIPA RDF Content Language Specification, 2000.

[FIP00c]

Foundation for Intelligent Physical Agents. FIPA Specifications. http://www.fipa.org, 2000.

[FK92]

D. Ferraiolo and R. Kuhn. Role-based access controls. In Proc. 15th NIST-NCSC National Computer Security Conference, pages 554–563, 1992.

[FPP+ 01]

E. Freudenthal, T Pesin, L Port, E Keenan, and V Karamcheti. dRBAC: Distributed role-based access control for dynamic coalition environments. Technical report, New York University, 2001.

[FSB02]

B. Sadighi Firozabadi, M. Sergot, and O. Bandmann. Using authority certificates to create management structures. Lecture Notes in Computer Science, 2467, 2002.

176

[GM84]

BIBLIOGRAPHY

J. A. Goguen and J. Meseguer. Unwinding and inference control. In Proc. IEEE Symposium on Security and Privacy, pages 75–86. IEEE Computer Society, 1984.

[Gon02]

L.

Gong.

Java

2

platform

security

architecture.

http://java.sun.com/j2se/1.4.2/docs/guide/security/spec/security-spec.doc.html, 2002. [Gui95]

C. Guilfoyle. Vendors of agent technology. UNICOM Seminar on Intelligent Agents and their Business Applications, November 1995.

[HRU76]

M. Harrison, W. Ruzzo, and J. Ullman. Protection in operating systems. In Communications of the ACM, pages 461–471. ACM, August 1976.

[Hu01]

Yuh-Jong Hu. Some thoughts on agent trust and delegation. In Proceedings of the fifth International Conference on Autonomous Agents, Montreal, Quebec, Canada, 2001.

[IKBS00]

S. Ioannidis, A. D. Keromytis, S. M. Bellovin, and J. M. Smith. Implementing a distributed firewall. In Proceedings of the 7th ACM Conference on Computer and Communications Security (CCS-00), pages 190–199, N.Y., November 2000. ACM Press.

[IKV]

IKV++. Grasshopper. The Agent Platform. Technical report, IKV++ GmbH, Berlin, 2000. http://www.ikv.de/products/grasshoper.

[Int]

Intel.

Intel

Common

Data

Security

http://www.intel.com/labs/archive/cdsa.htm.

Architecture. Intel Corpora-

tion. [ISO]

ISO. Database languages – SQL – part 2: Foundation (SQL/foundation). ISO International Standard. ISO/IEC 9075-2:1999.

[ITU00]

ITU-T.

ITU-T Recommendation X.509, The Directory: Public-key

and Attribute certificate frameworks. International Telecommunication Union, Geneva, 2000.

BIBLIOGRAPHY

[JAD]

177

TILAB, Telecom Italia Lab. JADE: Java Agent DEvelopment Framework. http://jade.cselt.it.

[JSD]

SourceForge. Project JSDSI. https://sourceforge.net/projects/jsdsi.

[JSSS01]

S. Jajodia, P. Samarati, M. L. Sapino, and V. S. Subrahmanian. Flexible support for multiple access control policies. ACM Transactions on Database Systems, 26(2):214–260, June 2001.

[JUn]

Junit.org. http://www.junit.org.

[JW98]

N. R. Jennings and M. J. Wooldridge, editors. Agent Technology: Foundations, Applications, and Markets. Springer-Verlag, 1998.

[Kar87]

P. A. Karger. Limiting the damage potential of discretionary trojan horses. In Proc. IEEE Symposium on Security and Privacy, pages 32–38, 1987.

[Lam74]

Butler W. Lampson. Protection. ACM SIGOPS Operating Systems Review, 8(1):18–24, 1974.

[LB73]

L. J. LaPadula and D. E. Bell. Secure computer system: A mathematical model. Technical Report ESD-TR-278, vol.2, The Mitre Corp., 1973.

[Log]

Log4j.

The

Apache

Jakarta

Project,

http://jakarta.apache.org/log4j. [Lun88]

T. Lunt. Access control policies: Some unanswered questions. In Proceedings of the Computer Security Foundations Workshop (CSFW ’88), pages 227–245, Washington - Brussels - Tokyo, June 1988. IEEE.

[LWM01]

Ninghui Li, William H. Winsborough, and John C. Mitchell. Distributed credential chain discovery in trust management: extended abstract. In Proceedings of the 8th ACM Conference on Computer and Communications Security, pages 156–165. ACM Press, November 2001.

178

[MB02]

BIBLIOGRAPHY

J. Mir and J. Borrell. Protecting general flexible itineraries of mobile agents. In Proceedings of ICISC 2001, LNCS 2288. Springer Verlag, 2002.

[MBB+ 98] D. Milojicic, M. Breugst, I. Busse, J. Campbell, S. Covaci, B. Friedman, K. Kosaka, D. Lange, K. Ono, M. Oshima, C. Tham, S. Virdhagriswaran, and J. White. MASIF: The OMG Mobile Agent System Interoperability Facility. In Proceedings of the 2nd International Workshop on Mobile Agents, volume 1477 of Lecture Notes in Computer Science, pages 50–67. Springer-Verlag, 1998. [McL85]

J. McLean. A comment on the ‘basic security theorem’ of Bell and LaPadula. Information Processing Letters, 20(2):67–70, February 1985.

[McL87]

J. McLean. Reasoning about security models. In IEEE Symposium on Security and Privacy, pages 123–131. IEEE, 1987.

[McL94]

J. McLean. Security models. In J. Marciniak, editor, Encyclopedia of Software Engineering. John Wiley & Sons, 1994.

[MIT]

MIT. The Chord Project. http://www.pdos.lcs.mit.edu/chord. Parallel and Distributed Operating Systems Group, Massachussetts Institute of Technology.

[MMN90]

C. J. McCollum, J. R. Messing, and L. Notargiacomo. Beyond the pale of MAC and DAC - defining new forms of access control. In Proceedings of the IEEE Symposium on Research in Security and Privacy, pages 190– 200, Oakland, CA, May 1990. IEEE Computer Society Press.

[Mor98]

A. Morcos. A Java Implementation of Simple Distributed Security Infrastructure. Master’s thesis, Massachusetts Institute of Technology, 1998.

[NC02]

S. Na and S. Cheon. Role delegation in role-based access control. In Proceedings of the seventh ACM Symposium on Access Control Models and Technologies (SACMAT 2002), pages 125–134, 2002.

BIBLIOGRAPHY

[NIS03]

179

NIST. Role based access control. Proposed voluntary consensus standard, April 2003. http://csrc.nist.gov/rbac/rbac-std-ncits.pdf.

[NMI]

NMI, National Science Foundation Middleware Initiative .

En-

terprise and Desktop Integration Technologies Consortium (EDIT). http://www.nmi-edit.org. [NRB02a]

G. Navarro, S. Robles, and J. Borrell. An access control method for mobile agents in Sea-of-Data applications. Upgrade. The European Journal for the Informatics Professional, III:47–51, December 2002.

[NRB02b]

G. Navarro, S. Robles, and J. Borrell. Adapted Role-based Access Control for MARISM-A usign SPKI certificates. In Proceedings of the 2th International Workshop on Security in Mobile Multiagent Systems, pages 35–42, June 2002.

[NRB02c]

G. Navarro, S. Robles, and J. Borrell. Role-based access control for ecommerce sea-of-data applications. In Information Security Conference 2002, volume 2433 of Lecture Notes in Computer Science, pages 102–116. Springer Verlag, September/October 2002.

[NRB02d]

G. Navarro, S. Robles, and J. Borrell. SPKI para el control de acceso a recursos en entronos de agentes móviles. In VII Reunión Espa˜ nola sobre Criptolog´ıa y Seguridad de la Información, pages 671–684, 2002.

[NRB02e]

G. Navarro, S. Robles, and J. Borrell. Un método de control de acceso para agentes móviles en aplicaciones Mar-de-Datos. Novatica. Revista de la Asociación de Técnicos de Informática, 160:18–22, 2002.

[NRB03]

G. Navarro, S. Robles, and J. Borrell. Assigning roles for access control in mobile agent applications. In Proceedings of the third IFIP Conference on E-commerce, E-bussines, and E-government (I3E), 2003. To Appear.

[OASa]

OASIS, Organization for the Advancement of Structured Information Standards. OASIS eXtensible Access Control Markup Language TC. http://www.xacml.org.

180

[OASb]

BIBLIOGRAPHY

OASIS, tured

Organization Information

for

the

Standards.

Advancement

of

Security

Services

StrucTC.

http://www.oasis-open.org/committees/security. [OAS02]

OASIS.

Assertions and Protocol for the OASIS Security Assertion

Markup Language (SAML) V1.0. OASIS Standard, November 2002. [OAS03]

OASIS. eXtensible Access Control Markup Language (XACML) Version 1.0. OASIS Standard, February 2003.

[OLW98]

J. K. Ousterhout, J. Y. Levy, and B. B. Welch. The Safe-Tcl Security Model. In Giovanni Vigna, editor, Mobile Agent Security, Lecture Notes in Computer Science No. 1419, pages 217–234. Springer-Verlag, 1998.

[Ovu94]

Intelligent agents: the new revolution in software. Ovum Report, 1994.

[OWL03]

OWL web ontology language overview. World Wide Web Consortium, candidate recommendation,

http://www.w3.org/TR/owl-features,

August 2003. [PER]

Project PERMIS. PERMIS. http://www.permis.org.

[RBKW91] F. Rabitti, E. Bertino, W. Kim, and D. Woelk. A model of authorization for next-generation database systems. ACM Transactions on Database Systems, 16(1):88–131, March 1991. [RFSL]

M. Rabi, T. Finin, A. Sherman, and Y. Labrou. Secure knowledge query manipulation language: a security infrastructure for agent communication languages. Technical report, University of Maryland Baltimore County.

[Riv97]

R. L. Rivest. S-expressions. Internet draft. The Internet Society, 1997.

[RLN+ 02]

S. Robles, I. Luque, G. Navarro, J. Pons, and J. Borrell. Plataforma segura para la ejecucin de agentes móviles con itinerario código y datos protegibles. In VII Reunión Espa˜ nola sobre Criptolog´ıa y Seguridad de la Información, pages 765–778, 2002.

BIBLIOGRAPHY

181

[RMAB02] S. Robles, J. Mir, J. Ametller, and J. Borrell. Implementation of Secure Architectures for Mobile Agents in MARISM-A. In Fourth Int. Workshop on Mobile Agents for Telecommunication Applications (MATA), volume 2521 of LNCS. Springer-Verlag, 2002. [RNP+ 02]

S. Robles, G. Navarro, J. Pons, J. Rifà, and J. Borrell. Mobile agents supporting secure GRID environments. In Euroweb 2002 Conference, pages 195–197. British Computer Society, December 2002.

[Rob03]

S. Robles. Mobile Agent Systems and Trust, a Combined View towards Secure Sea-of-Data Applications. PhD thesis, Universitat Autònoma de Barcelona, July 2003.

[RS98]

J. Riordan and B. Schneier. Environmental key generation towards clueless agents. Lecture Notes in Computer Science, 1419:15–24, 1998.

[RSL92]

J. Richardson, P. Schwarz, and L.Cabrera. CACL: Efficient fine-grained protection for objects. In OOPSLA’92 Conference on Object-Oriented Programming Systems, Languages, and Applications, pages 263–275, 1992.

[San90]

R. Sandhu. Separation of duties in computerized information systems. In Proceedings of the IFIP WG11.3 Workshop on Database Security, September 1990.

[San92]

R. Sandhu. The typed access matrix model. In Proceedings of the IEEE Symposium on Research in Security and Privacy, pages 122–136, Oakland, CA, May 1992. IEEE Computer Society, Technical Committee on Security and Privacy, IEEE Computer Society Press.

[San93]

R. Sandhu.

Lattice-based access control models.

IEEE Computer,

26(11):9–19, November 1993. [Sar92]

P. Sargent. Back to school for a brand new ABC. The Guardian, 12 March 1992.

182

[SC01]

BIBLIOGRAPHY

P. Samarati and S. De Capitani di Vimercati. Access control: Policies, models, and mechanisms. Foundations of Security Analysis and Design, 2001. LNCS 2171, Springer-Verlag.

[SCFY96]

R. S. Sandhu, E. J. Coyne, H. L. Feinstein, and C. E. Youman. Rolebased access control models. IEEE Computer, 29(2):38–47, February 1996.

[SD92]

H. Shen and P. Dewan. Access control for collaborative environments. In ACM Conference on Computer Supported Cooperative Work (CSCW’92), pages 51–58. ACM Press, 1992.

[Sha86]

M. Shapiro. Structure and encapsulation in distributed systems: The proxy principle. In Proceedings of the 6th International Conference on Distributed Computer Systems, pages 198–205. IEEE Press, May 1986.

[Shi95]

T. Shimomura. How Mitnick hacked Tsutomu Shimomura with an IP sequence attack. Usenet News Groups: comp.secuirty.misc, January 1995.

[SOM]

SOMA: rio

Secure

d’Informatica

Open Avanzata,

Mobile

Agent.

Università

Laboratodi

Bologna.

http://www-lia.deis.unibo.it/research/SOMA. [SS75]

J. H. Saltzer and M. D. Schroeder. The protection of information in computer systems. Proceedings of the IEEE, 63(9):1278–1308, September 1975.

[SSF99]

J. S. Shapiro, J. M. Smith, and D. J. Farber. EROS: a fast capability system. In Proceedings of the 17th ACM Symposium on Operating Systems Principles (SOSP’99), pages 170–185, December 1999.

[Sto81]

A. Stoughton. Access flow: A protection model which integrates access control and information flow. In Proc. IEEE Symposium on Security and Privacy, pages 9–18, 1981.

BIBLIOGRAPHY

[Sun01]

Sun

183

Microsystems.

authorization

service

Java (JAAS)

authentication reference

and guide.

http://java.sun.com/j2se/1.4.2/docs/guide/security/jaas/ JAASRefGuide.html, 2001. [Sun03]

Sun Microsystems. version 1.4.2.

Java 2 SDK, Standard Edition Documentation,

http://java.sun.com/j2se/1.4.2/docs/index.html,

2003. [TFM95]

C. Thirunavukkarasu, T. Finin, and J. Mayfield. Secret agents – A security architecture for the KQML agent communication lanaguage. In Intelligent Information Agents Workshop held in conjunktion with Fourth International Conference on Information and Knowledge Management CIKM’95, December 1995.

[TK98]

A. Tripathi and N. Karnik. Protected Resource Access for Mobile Agentbased Distributed Computing. In Proceedings of the 1998 ICPP Workshop on Wireless Networks and Mobile Computing, pages 144–153. IEEE Computer Society, August 1998.

[TK00]

A. Tripathi and N. Karnik. Delegation of Privileges to Mobile Agents in Ajanta. In First International Conference on Internet Computing, June 2000.

[TM02a]

H. K. Tan and L. Moreau. Certificates for mobile code security. In 17 th ACM Symposium on Applied Computing, 2002.

[TM02b]

H. K. Tan and L. Moreau. Extending execution tracing for mobile code security. In Proceeding of the 2nd International Workshop on Security in Mobile Multiagent Sustems, 2002.

[TMvR86] A. S. Tanenbaum, S. J. Mullender, and R. van Renesse. Using sparse capabilities in a distributed operating system. In Proceedings of the 6th International Conference on Distributed Computing Systems (ICDCS), pages 558–563, Washington, DC, 1986. IEEE Computer Society.

184

[Vit02]

BIBLIOGRAPHY

Giosuè Vitaglione.

JADE Tutorial. Security administratior guide.

TILAB, 2002. [WOR+ 74] K. G. Walter, W. F. Ogden, W. C. Rounds, F. T. Bradshaw, S. R. Ames, and D. G. Sumaway. Primitive models for computer security. Technical report, Case Western Reserve University, 1974. [ZOS03]

X. Zhang, S. Oh, and R. Sandhu. PBDM: A flexible delegation model in RBAC. In Prooceedings of the Eighth ACM Symposium on Access Control Models and Technologies (SACMAT 2003), pages 149–157, June 2003.

Appendix A Formal definition of RBAC This appedix summarizes the formal definition of the RBAC model as presented in [NIS03].

A.1

Core RBAC

• Basic elements: USERS, ROLES, OPS, and OBS (users, roles, operations, and objects). • User assignment relation (U A), many-to-many mapping between users and roles: U A ⊆ U SERS × ROLES. • Mapping of a role r ∈ ROLES onto a set of users: assigned users : (r : ROLES) −→ 2U SERS . Where: assigned users(r) = {u ∈ U SERS | (u, r) ∈ U A}. • Set of permissions (PRMS): P RM S = 2(OP S×OBS) . 185

186

APPENDIX A. FORMAL DEFINITION OF RBAC

• Permission assignment (P A), many-to-many mapping between permissions and roles: P A ⊆ P RM S × ROLES. • Mapping of a role r ∈ ROLES onto a set of permissions: assigned permissions(r : ROLES) −→ 2(P RM S) . Where: assigned permissions(r) = {p ∈ P RM S | (p, r) ∈ P A}. • Mapping of a permission p ∈ P RM S onto a set of operation associated with the permission: Op(p : P RM S) −→ {op ⊆ OP S}. • Mapping of a permission p ∈ P RM S onto a set of objects associated with the permission: Ob(p : P RM S) −→ {ob ⊆ OBS}. • The set of sessions: SESSION S. • Mapping of a session s ∈ SESSION S onto the corresponding user: session users(s : SESSION S) −→ U SERS. • Mapping of a session s ∈ SESSION S onto a set of roles: session roles(s : SESSION S) −→ 2ROLES . Where: session roles(s) ⊆ {r ∈ ROLES | (session users(s), r) ∈ U A}. • Permissions available to a user: avail session perms(s : SESSION S) −→ 2P RM S . Where: avail session perms(s) =

[ r∈session roles(s)

assigned permissions(r).

A.2. HIERARCHICAL RBAC

A.2

Hierarchical RBAC

A.2.1

General role hierarchy

187

• The inheritance relation (RH): RH ⊆ ROLES × ROLES defined as a partial order on ROLES, and denoted as º. Given two roles r1 , r2 ∈ ROLES, then r1 º r2 if and only if all permissions of r2 are also permissions of r1 , and all users of r1 are also users of r2 . • A mapping of a role r ∈ ROLES into a set of users in the presence of a role hierarchy: authorized users(r : ROLES) −→ 2U SERS . Where: authorized users(r) = {u ∈ U SERS | r 0 º r, (u, r 0 ) ∈ U A}. • A mapping of the role r ∈ ROLES onto a set of permissions in the presence of role hierarchy: authorized permissions(r : ROLES) −→ 2P RM S . Where authorized permissions(r) = {p ∈ P RM S | r 0 º r, (p, r 0 ) ∈ P A}. • Thus: r1 º r2 =⇒ authorized permissions(r2 ) ⊆ authorized permissions(r1 ), authorized users(r1 ) ⊆ authorized users(r2 ).

A.2.2

Limited role hierarchy

Limited role hierarchy adds the following constraint to general role hierarchy: • ∀r, r1 , r2 ∈ ROLES, r º r1 ∧ r º r2 =⇒ r1 = r2 .

A.3 A.3.1

Constrained RBAC Static Separation of Duty

Static Separation of Duty (SSD) is defined as a collection of pairs (rs, n), where rs is a set of roles, n ∈ N, n ≥ 2, of the form: SSD ⊆ (2ROLES × N). If role hierarchy is pressent SSD is defined in terms of authorized users, if there is no role hierarchy in the model it is defined based on assigned users.

188

APPENDIX A. FORMAL DEFINITION OF RBAC

• SSD without the presence of role hierarchies: ∀(rs, n) ∈ SSD, ∀t ⊆ rs : |t| ≥ n =⇒

\

assigned users(r) = ∅.

r∈t

• SSD in the presence of role hierarchies: ∀(rs, n) ∈ SSD, ∀t ⊆ rs : |t| ≥ n =⇒

\

authorized users(r) = ∅.

r∈t

A.3.2

Dynamic Separation of Duty

Dynamic Separation of Duty (DSD) is defined as a collection of pairs (rs, n), where rs is a set of roles, and n ∈ N, n ≥ 2, of the form: DSD ⊆ (2ROLES × N). • ∀rs ∈ 2ROLES , n ∈ N, (rs, n) ∈ DSD =⇒ n ≥ 2, |rs| ≥ n, and • ∀s ∈ SESSION S, ∀rs ∈ 2ROLES , ∀role subset ∈ 2ROLES , ∀n ∈ N, (rs, n) ∈ DSD, then role subset ⊆ rs, role subset ⊆ session roles(s) =⇒ |role subset| < n.