V. Ghini, G. Lodi, N. Mezzetti, F. Panzieri Department of Computer Science University of Bologna

1. Trust Issues In TAPAS V. Ghini, G. Lodi, N. Mezzetti, F. Panzieri Department of Computer Science University of Bologna

2. Summary • Definitions: • Security Domains • Trust • Trust Basis • Trust in TAPAS Platform • A Practical Example • Security in ENS

3. Definitions (1/2) • TAPAS Environment can be seen as a set of security domains: • Security Domain (SD) • A set of one (or more) Platform Domain(s) (e.g., ASP, SSP, ISP in auction example). • Platform Domain (PD) • An instance of TAPAS architecture; it can host several application containers. • Application Domain (AD) • The set of containers relative to the same application (can span over several PDs and SDs).

4. Definitions (2/2) • Trust: • Informally, we say “Alice Trusts Bob in environment E” if there is a set of policy rules defined in E that regulate interactions between them.

5. Trust Basis • Trust Assumptions: • in a security domain, TAPAS platforms trust each other; • in a platform domain, Application Containers: • Are mutually distrustful; • Trust the Tapas Platform; • SLAs enforce trust relationships among ACs and PDs. • in an application domain, containers trust each other; • otherwise there is mutual distrust: • In this case relationships must be possible by means of authentication and fair exchange protocols.

6. Trust Management Systems • Policy Maker and KeyNote: • Assertional policy description languages; • Specify what a public key is authorized to do. • RBAC: • Allow to assign privileges to roles • Scalability; • OASIS.

7. Trust in TAPAS Platform (1/3) • TAPAS requires a high level Policy Description Language • to allow specification of basic trust relationships • Expressibility; • it should support trust delegation to manage trust in AD across SDs: • PDs belonging to different SDs mutually distrust each other. • PDL is a part of Trust Management System • implemented in TMS module of the platform: • Flexibility: • Dynamical trust relationships; • Scalability;

8. Trust in TAPAS Platform (2/3) • OASIS: • Trust management system developed by Opera group: • Extends the model of Role Based Access Control: • OASIS servers name their clients in terms of roles; • OASIS scales well because access rights are associated with roles rather than individual principals; • Services specify policy for role-entry in RDL (Role Definition language); • Delegation is addressed by appointments.

9. Trust in TAPAS Platform (3/3) • OASIS: • To use a service, clients present credentials for entering a named role: • The service checks the credentials against the RDL policy specification: • RDL is a formal logic based on Horn clauses so a service proves the correctness of its clients' credentials. • If successful, the client is issued a role membership certificate (RMC): • dynamically maintained, principal-specific capability. • The client presents the RMC with each service invocation.

10. Trust in TAPAS Platform (4/4) • OASIS: • Can be extended to support dynamical trust • Reputation tokens can be realized by appointments or trust values can be embedded in RMC.

11. A practical example (1/3) • Online auction example: • Using OASIS to model the policy, auction server could enforce a policy based on two different roles: • Seller: • View of items he/she sells, history of bidding and the best bid, but not any detail about buyers; • Buyer: • View of items he/she is bidding for, each one with the current best bid, information about location of the item and delivery details, but not any detail about sellers;

12. A practical example (2/3) Setting up the Application Domain: • Auctioneer logs on the ASP TAPAS platform and creates a new AD by presenting a SLA • He/she gets also a RMC as a member of the platform domain; • To request services and resources to other providers (e.g., SSP, ISP) TAPAS platform grants the application a set of appointments • other TAPAS platforms can have a proof of delegation; • If presented credentials are verified and compliant with other platforms local policies then the new application containers are reserved.

13. A practical example (3/3) Buyer and Seller RMCs: • A client that successfully logs on the application gets a buyer RMC; • A buyer that successfully places one item in the auction is granted a seller appointment that expires at the end of that item’s auction; • Presenting buyer RMC and a valid seller appointment, the buyer is granted the seller RMC;

14. Security in ENS • ENS should encapsulate security issues: • Advertisement and subscription of events within the application domain or within a particular security domain. • OASIS allows an elegant solution, addressing the issue with appointments. • It should be impossible for a malicious party to monitor event history of a security domain he/she doesn’t belong to.

15. Future Work and References • Future Work: • Extending OASIS to manage a dynamical form of trust relationship; • Study a way to integrate security issues in ENS. • References • [tapas01] TAPAS: Description of Work. • [oasis01] J.Bacon, K. Moody, W. Yao, “Access Control in the Use of Widely Distributed Services”, Middleware 2001, LNCS 2001.