WS Based on Web Services Kevin Lux, Michael May, Nayan Bhattad University of Pennsylvania Carl A. Gunter University of Illinois Urbana-Champaign

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

3 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

4 WS Project Began at Penn with support from Microsoft Aim: use web services as a new foundation for as a way to improve security, flexibility, and integration Ongoing project at both UIUC and Penn Expanding to the AMPol Project

5 Basic Operation Distributed Components and Messages SD: Sender Domain SC: Sender Client SS: Sender Server RD: Receiver Domain RS: Receiver Server RC: Receiver Client Sample Messages

6 Applications Integrated instant messaging Workflow based on routed forms On-demand attachments Policy negotiation

7 Instant Messaging

8 Workflow Systems

9 On-Demand Attachments

10 Architecture Server Mail Transfer Agent (MTA) –Core –Plugin Client Mail User Agent (MUA) Overall aim: support for secure dynamic extensions Compare: active networks concept

11 MTA Core

12 MTA Plugins Server UML Server Plugins UML

13 Client MUA

14 Implementation WS 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.

15 WS Test-bed Machines: Pentium4 Network: 100Mb switched Ethernet Client Machines: 2.8GHz, 512MB RAM Server (S i ): 2.8GHz, 1GB RAM Database (S db ): 2.4GHz, 1GB RAM Internet Emulator (S e ): 2.8GHz, 512MB RAM

16 Parameters Each client will send 2000 requests to S i Operations: send message, list headers, retrieve message, delete message (each with equal chance) Sent messages include local recipient (a user on S i ) and an external recipient (a user on S e ). 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

17 Results 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

18 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

19 Proof Technique Reduce the complex and redundant messages –Eliminated headers, irrelevant to/from fields Choose a verifier that can evaluate protocol security –Used ProVerif by Bruno Blanchet Formalize the messages and parties for the verifier –Used TulaFale by MS Research –Compiled TulaFale scripts into ProVerif syntax Result was a smaller formal version in a machine checkable format –Lost injectiveness in the process of translating down since TulaFale cannot express timed nonces easily

20 Message Example First message is from the Sending Client to the Sending Server – text, attachment, destination address, user name –Everything is signed user name token method Abstractly –SC  SS: SS | (RC | RS) | Msg | Attachment Production and Destruction Rules in TulaFale predicate mkMsg1(SC:item, nonce:bytes, creation:string, attachment:string, string, TOuser:string, TOdom:string, Msg1:item, Msg1Signed:item) :- destUserAtDomain = UName(TOuser, TOdom), isUserTokenKey(TokSC, SC, nonce, creation, KeySC), Msg1 = Message1(TokSC, attachment, , destUserAtDomain), mkSignature(Sig, "hmacsha1", KeySC, Msg1 ), Msg1Signed = Sig Msg1. predicate isMsg1(Msg1Signed:item, SC:item, TOdom:string, TOuser:string, attachment:string, string, destUserAtDomain:item, Msg1:item) :- Msg1Signed = Sig Msg1, Msg1 = Message1(TokSC, attachment, , destUserAtDomain), isUserTokenKey(TokSC, SC, nonce, creation, KeySC), isSignature(Sig, "hmacsha1", KeySC, Msg1 ), destUserAtDomain = UName(TOuser, TOdom).

21 Result First pass at the formalization had errors –We ended up with a trivially true theorem Second pass was more careful –Each messages was checked for correctness and reachability Performance problems –ProVerif couldn’t handle such a large protocol –Blanchet created a version of ProVerif that skipped some extra parsing steps that were performed after the theorem was proved We finished with a theorem shown to be true, but without a derivation tree justifying the theorem –Would have made debugging hard –Future efforts will be made at making the prover more efficient

22 Summary Web service foundation for messaging (WS ) may address issues with flexibility, integration, and security. Designed architecture and built WS system on.NET. Studies show –Interesting applications –Useful theory –Satisfactory performance

23 Future Work AMPol: Adaptive Messaging Policy Effort to create messaging system where elements can adapt to policies with grace and security. Key architectural elements –Policy model –Policy discovery –System extension and policy merging