1. Newcastle uopn Tyne, 5 - 6 September 2002 V. Ghini, G. Lodi, N. Mezzetti, F. Panzieri Department of Computer Science University of Bologna

2. Newcastle uopn Tyne, 5 - 6 September 2002 2 Summary Definitions: –Security Domains –Trust Trust Basis Trust in TAPAS Platform A Practical Example Security in ENS

3. Newcastle uopn Tyne, 5 - 6 September 2002 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. Newcastle uopn Tyne, 5 - 6 September 2002 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. Newcastle uopn Tyne, 5 - 6 September 2002 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. Newcastle uopn Tyne, 5 - 6 September 2002 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. Newcastle uopn Tyne, 5 - 6 September 2002 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. Newcastle uopn Tyne, 5 - 6 September 2002 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. Newcastle uopn Tyne, 5 - 6 September 2002 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. Newcastle uopn Tyne, 5 - 6 September 2002 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. Newcastle uopn Tyne, 5 - 6 September 2002 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. Newcastle uopn Tyne, 5 - 6 September 2002 12 A practical example (2/3) Setting up the Application Domain: 1.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; 2.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; 3.If presented credentials are verified and compliant with other platforms local policies then the new application containers are reserved.

13. Newcastle uopn Tyne, 5 - 6 September 2002 13 A practical example (3/3) Buyer and Seller RMCs: 1.A client that successfully logs on the application gets a buyer RMC; 2.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; 3.Presenting buyer RMC and a valid seller appointment, the buyer is granted the seller RMC;

14. Newcastle uopn Tyne, 5 - 6 September 2002 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. Newcastle uopn Tyne, 5 - 6 September 2002 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.