Trust and security in decentralised distributed systems

1. Trust and security in decentralised distributed systems Paul Kearney Security Research Centre (Acting Head)

2. Why the agent and web services communities should work together • I will • give an overview of the current situation regarding web service security • argue that MAS should build upon a web-service-based platform rather than duplicating effort • argue that trust and security for web services would benefit from ideas and techniques from the agent world. • Platform and message syntax from web services, semantics and ‘intelligence’ from agents

3. Agents, web services and me • Agents + speech acts • Involved in early days of FIPA (at Sharp) • Eurescom P907: MESSAGE • AOSE methodology, AO modelling language • Eurescom P1106 • B2B Framework merging generic eBusiness (e.g. ebXML, RosettaNet) with TMF eTOM • PJK: security case study + semantics • Web Services security (message level) • TrustCoM FP6 project • Trust, Security and Contract management framework for dynamic Virtual Organisations

4. Service oriented architecture (SOA) • SO application = collection of coarse grained, loosely coupled ‘services’ • Service = computational entity exposing ‘operations’ via abstract, high level interface • black box, subject to certain ‘behavioural expectations’ • WSDL: operation = input message and / or output message type + 0 or more fault message types • 4 op patterns: Input -> output; output -> input; input only; output only • wrt a particular operation, a service plays a provider or client role • Discovery (at run time) => dynamic binding • Service is an autonomous message processing system •  ‘agent’

5. A network of SOAP nodes Intermediate node Intermediate node MQ SMTP HTTP Ultimate receiver Ultimate sender

6. The new (XML-based) protocol stack Collaboration level Conversation level Transaction level Basic message pattern level:one-way, synchronous request-response, asynchronous request-response Message level: SOAP + extensions Transport / connection: HTTP, FTP, MQ Series, ... ...

7. Basic architectural building blocks • Web services: • originators and ultimate destinations for messages • primarily process the body of the message • Intermediate nodes • message processing elements in the message path • XML Firewalls, XML ‘routers’, Axis Handlers • can check and block or pass a message (generate a fault) • modify the header and/or redirect • Mainly interestedin signing/checking signatures, inserting / checking / replacing tokens and other header elements • could call services from intermediate nodes.

8. State of the art in web service security • Except in simple situations, it is difficult to provide end-end security via transport layer mechanisms (HTTPS / SSL) alone. Need message level security. • Growing consensus on conceptual building blocks for message level security. • ‘Foundation’ specifications firming up (XML Encryption, XML Signature, WS-Security, SAML, ...), but still fluid, vendor implementation patchy and interoperability doubtful. Further layers of specification need to be added. • You can implement message level security, but need to establish local conventions. Vision of carefree, open interoperability still some way off. (Not just due to security).

9. Web Services Security building blocks • public key cryptography and digital certificates • digital signatures used to bind elements of the message and assure integrity • encryption of messages for message confidentiality (where required) • use of security software tokens carried in message header to communicate ‘claims’ • use of trusted identity service to issue authentication tokens • policy-based access control

10. The emerging WS security model (IBM/MS) Deals with issues of crossing ‘trust domains’ -- pretty vague Introduces security contexts and security context tokens • Language for asserting requirements on msg features • confidentiality • integrity • token • visibility • header • age To do with requesting, issuing and checking tokens • XML encryption (msgconfidentiality) • XML DSIG (msg integrity) • Tokens: claims From MS/IBM WS security roadmap

11. … and the other lot: Liberty + SAML • Project Liberty / Liberty Alliance • Federated identity management • Security Assertion Mark-up Language (SAML) • OASIS standard • XML-based language for making ‘assertions’ about security • Assertion • a statement made by an ‘authority’ • can be signed to identify authority reliably • if you trust the authority, you tend to trust the truth of the statement • can be time-stamped, etc., to establish bounds to validity • Defines three types of assertion • Authentication • Authorisation • Attribute and correspond query and response messages • Authentication assertion: • states what checks have been done to authenticate an identity claim • So, there seems to be a fair consensus on the basic model

12. PPP - another TLM Commitmentsrequestsservices Principals Semantic model Securityservices + handlers Securityservices + handlers Signatures and tokens Processes Applicationservices Applicationservices SOAP Messages Tomcat + Axis Tomcat + Axis Platform HTTPS/SSL

13. Web service • View a WS as providing managed access to a resource • Simple transaction types: • request that an operation is performed on a resource (and return result) • request information about service (or resource?) • notification • WS has an owner (e.g. an enterprise) • WS acts on behalf of a ‘legal entity’ (user, enterprise, etc.) • can have ‘pure client’ WSs that only represent their agent in interactions with other WS (I.e. no associated resource) • WS runs on a platform

14. Declarative semantics • For message body • speech acts concerning operations on and information about encapsulated resource and other topics of conversation • For tokens / claims • claims about parties to message / transaction • Claim • assertion + id of authority • trust in authority  tendency to belief assertion • assertion  speech act • statement of belief, commitment, intention, etc.

15. Security decisions Web Service <Message from WS1 -> WS2 <Request on behalf of User A <Perform operation X on Resource Y/> />/> • Check message signature to ensure from trusted source and unaltered • Subject of request? (Operation? Resource?) • Claimed identity of requester (A)? • Verify identity claim (Is request really on behalf of A?) • Is A permitted to perform X on Y? Is the message genuine? (Authentication) Is the request permitted?(Authorisation) Operations on resources managed by WS

16. Validation and policy dialogues Policy dialogues Verify tokens Issue tokens Token services • Check based on info carried with the message (tokens) • direct evidence • explicit assertion by authority • implicit assertion by authority (e.g. ticket)

17. Security architecture Company 1 Company 2 Policy management service Policy management service Policy management service Trust and mediationservices Security service (e.g. PDP) Security service (e.g. PDP) Handler chains (PEPs) Client service Target service

18. Transmits FIPA / KQML message Maps to appropriate XML standard Interprets as speech act Transmits SOAP / WS message Implicit speech acts agent agent Invokes message service

19. TrustCoM project (http://www.eu-trustcom.com/) • EU FP6, started February this year • framework for trust, security and contract management in dynamically-evolving virtual organisations. • enable secure collaborative business process management and sharing in an on-demand, self-managed, dynamic value-chains of businesses and governments. • leverage Web Services, Grid technologies and protocols for inter-enterprise interactions • Partners: • BT, SAP, BAE Systems, Microsoft, IBM, ATOS ORIGIN (S-SEMA) • CCLRC, SICS, HLRS, NRCCL, SINTEF • ETH, IC, KCL, U. Milano, U. Salford

20. Summary • Agents and web services are addressing similar problems in similar ways • Web Services provide a layer on which agents can build • Agents / AI provide semantics + machinery for intelligent processing of messages • Have indicated how speech acts can give semantics WS messages and security claims • Web Services standards are being adopted and used: if agent community tries to compete (vs. augment) it will lose

21. Questions?