1 / 23

WSEmail Email Based on Web Services

WSEmail Email Based on Web Services. Kevin Lux, Michael May, Nayan Bhattad University of Pennsylvania Carl A. Gunter University of Illinois Urbana-Champaign. Internet Email. Based on a collection of protocols SMTP, POP, IMAP, S/MIME Evolved over a vast installed base Shortcomings

mattd
Download Presentation

WSEmail Email Based on Web Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Internet Email • 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. WSEmail Project • 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 • 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 • 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.

  15. 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

  16. 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

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

  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 • Email 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, email:string, TOuser:string, TOdom:string, Msg1:item, Msg1Signed:item) :- destUserAtDomain = UName(TOuser, TOdom), isUserTokenKey(TokSC, SC, nonce, creation, KeySC), Msg1 = Message1(TokSC, attachment, email, destUserAtDomain), mkSignature(Sig, "hmacsha1", KeySC, <list>Msg1</>), Msg1Signed = <env>Sig Msg1</>. predicate isMsg1(Msg1Signed:item, SC:item, TOdom:string, TOuser:string, attachment:string, email:string, destUserAtDomain:item, Msg1:item) :- Msg1Signed = <env>Sig Msg1</>, Msg1 = Message1(TokSC, attachment, email, destUserAtDomain), isUserTokenKey(TokSC, SC, nonce, creation, KeySC), isSignature(Sig, "hmacsha1", KeySC, <list>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 (WSEmail) may address issues with flexibility, integration, and security. • Designed architecture and built WSEmail 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

More Related