563.3 Secure Web Services (SWS)

1. 563.3 Secure Web Services (SWS) Carl A. Gunter University of Illinois Fall 2007

2. Today’s Web • Designed for applications involving human interactions • Intended purpose • Information sharing: a distributed content library • Enabled B2C e-commerce • Non-automated B2B interactions • How did it happen? • Built on very few standards: http + html • Simple interaction model: very few assumptions • Result was ubiquity

3. What’s Next? • Improve machine-to-machine protocols to enable more automation. • Use a readily-extensible foundation. • Build in security from the start. • Overcome limits to widespread web deployment of Corba, DCOM, etc.

4. Strategy: use XML as a foundation for both infrastructure and application formats. Build a stack of XML-based processing layers. Create XML-based security mechanisms that integrate with existing approaches (e.g. X.509). Web Services

5. Typical Web Service Components

6. Web Services Architecture UDDI Universal Description, Discovery, and Integration • Services are listed in a directory of services on the Internet WSDL Web Services Description Language • They are defined in terms of the formats and ordering of messages SOAP Simple Object Access Protocol • Clients and servers exchange SOAP messages XML • These are represented in XML HTTP etc. • And sent using a convenient protocol

7. XML • Extensible Markup Language • Meta-language for markups • Puts semi-structured data into text files: - easy to read - unambiguous - extensible - platform-independent

8. Sample XML Example <?xml version=“1.0” encoding=“…”?> <msg:message from=“id” to=“id” xmlns:msg=“URI” xmlns:po=“URI”> <msg:text> Hi please bill to the following address </msg:text> <msg:item> <po:po id=“123”> <po:billto> <po:company> Skateboard </po:company> <po:street> One Warehouse Park </po:street> <po:city> Boston </po:city> </po:billto> </po:po> </msg:item> </msg:message>

9. XML Declaration <?xml version=“1.0” encoding=“…”?> • <?xml ?> the XML declaration • Not required, but typically used • Attributes include: • Version • Encoding – the character encoding

10. XML Element <msg:message from=“id” to=“id” xmlns:msg=“URI” xmlns:po=“URI”> <msg:text> Hi please bill the following </msg:text> <msg:item> <po:po id=“123”> … </po:po> </msg:item> </msg:message>

11. XML Attribute <msg:message from=“id” to=“id” xmlns:msg=“URI” xmlns:po=“URI”> … <po:po id=“123”> … </po:po> </msg:message> • XML Attribute • Describes additional information about an element • <tag key=”value”> text</tag>

12. XML Namespaces <msg:message from=“id” to=“id” xmlns:msg=“URI” xmlns:po=“URI”> … </msg:message> • Namespaces • Not mandatory, but useful in giving uniqueness to an element • Declared using the xmlns:name= “value”

13. SOAP • An XML envelope for XML messaging • Headers + body • SOAP is “transport independent” • Supports both messaging and RPC SOAP Envelope SOAP Header : encoding, authentication, transaction information, etc. SOAP Body SOAP Body Block : parameters, return values, etc SOAP Fault

14. SOAP Message Example <?xml … ?> <SOAP-ENV:Envelope xmlns:SOAP-ENV=“URI” > <SOAP-ENV:Header> <t:Transaction xmlns:t=“URI” SOAP-ENV:mustUnderstand=“1” > 12345 </t:Transaction> <p:Priority xmlns:p=“URI”> Very High </p:Priority> </SOAP-ENV:Header> <SOAP-ENV:Body> “XML Document” </SOAP-ENV:Body> </SOAP-ENV:Envelope>

15. AMPol Project • Adaptive Messaging Policy Project concerns next-generation messaging systems with improved security, flexibility, and integration. • Principal activities • WSEmail • Dynamic policy adaptation • Attribute-Based Messaging (ABM)

16. AMPol Principal Activities • WSEmail • Dynamic policy adaptation • Attribute-based messaging

17. Internet Email • Based on a collection of protocols • SMTP, POP, IMAP, S/MIME • Evolved over a vast installed base • Shortcomings • Flexibility • Security • Integration

18. Approaches to Improvement • Make incremental changes and overlays for the existing protocols • Redesign the system from a low level • Example: instant messaging • Create a design from another high-level foundation • Example: use HTTP and SSL

19. Began at Penn with support from Microsoft Aim: use web services as a new foundation for email as a way to improve security, flexibility, and integration Ongoing project at both UIUC and Penn Applications Instant messaging Routed forms On-demand attachments Theory Using Proverif and TuleFale Performance .NET implementation on a small testbed WSEmail Project Lux May Bhattad Gunter 05

20. Application: Integrated IM

21. Application: Routed Forms

22. Implementation • WSEmail implemented over .NET framework with Web Services Enhancement (WSE) • Messages stored on SQL Server 2000 • Version 1.0 has • 68 interfaces • 343 classes • 30 projects • C# .NET-managed code created with MS Visual Studio • DNS SRV records used for routing.

23. WSEmail Test-bed Machines: Pentium4 Network: 100Mb switched Ethernet Client Machines: 2.8GHz, 512MB RAM Server (Si): 2.8GHz, 1GB RAM Database (Sdb): 2.4GHz, 1GB RAM Internet Emulator (Se): 2.8GHz, 512MB RAM

24. Each client will send 2000 requests to Si Operations: send message, list headers, retrieve message, delete message (each with equal chance) Sent messages include local recipient (a user on Si) and an external recipient (a user on Se). Test coordinator holds test parameters that clients receive and parse Message database is pre-populated with a few entries Test coordinator signals test start Clients non-deterministically pick an action to perform, based on upon test parameters Parameters

25. Average latency: .274 sec / msg Rate of 1786 msg / min Client machines sent 36.4MB and received 369.4MB Test took 1824 sec to execute Benchmark comparison to SMTP on our machines showed .170 sec / msg with messages of similar size Benchmark UW Parkside peak usage figures were 1716 msg / min Performance Results

26. Theory • On Demand Attachments Protocol • Nine messages, four parties • Complex messages • Want to prove that receiving an attachment means it was sent by the sender in the from field

27. AMPol Principal Activities • WSEmail • Dynamic policy adaptation • Attribute-based messaging

28. Policy Adaptation • Large-scale systems often cannot operate under a uniform policy • Scalability can be aided by allowing parties to express policies that must be satisfied in interactions • Apply this idea to messaging systems to achieve adaptive messaging policy • Case study for email based on WSEmail Afandi Zhang Hafiz Gunter 06

29. Architectural Components • Policy Model • What policies can be expressed • Our instantiation: AMPL and APES (Attachments, Payment, Encryption, Signature) • Policy Discovery • Policy merging • Policy Query Protocol (PQP) • Extension and Enforcement • Conformance • Extension • Enforcement

30. Policy Architecture RMTA SMTA Egress Policies Merged Policies Ingress Policies Client Policies Recipient Sender

31. Policy Architecture RMTA SMTA Merged Policies Recipient Sender

32. Policy Architecture RMTA SMTA Egress Policies Ingress Policies Client Policies Recipient Sender Plug in Server

33. AMPol Principal Activities • WSEmail • Dynamic policy adaptation • Attribute-based messaging

34. Problem Confidentiality of sensitive messages sent to groups Unwanted messages sent to over-broad groups Approach Target messages based on recipient attributes Create recipient lists dynamically Objectives Design that is easy to deploy Efficient implementation Attribute-Based Messaging Bobba Fatemieh Khan Gunter Khurana 06

35. Scenarios Address all faculty going on sabbatical next term Address all the people working on security related projects in an organization Address all TeraGrid system administrators Address doctors in the tri-state area who have expertise in a specific kind of operation Challenges User attribute assimilation and query User privacy Access rights Inter-domain messaging Attribute mapping Privacy policy AAA Scenarios and Challenges

36. Data Services Data Services Attr. DB Attr. DB Domain B Legacy Databases Legacy Databases ABM Server ABM Server Inter Domain ABM over Web Services To: Mgr@DomA && Mgr@DomB MTA MTA Regular E-mail (SMTP) Architecture Domain A

38. ACSAC 2006 Security Analysis • Problem • open to replay attacks • Solution • MTA configured with SMTP authentication • with additional message specific checks

39. ACSAC 2006 Experimental Setup • Measured • latency over regular e-mail • with and without access control • latency of Policy Specialization • Setup • up to 60K users • 100 attributes in the system • 20% of attributes common to most users • 80% of attributes sparsely distributed

40. ACSAC 2006 Results

41. ACSAC 2006 Results Continued… Policy Specialization Latency

42. ACSAC 2006 Other Considerations • Privacy • of sender and receivers • of ABM address • Usability • user interfaces

43. Conclusions • Crossroads for important technology advances • Adaptive policies • Web services (“Service Oriented Architectures”) • Formal models and verification for security protocols • Messaging systems • Critical in their own right • Good domain for developing and applying core advances