WSEmail Email Based on Web Services

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 see
  http//wsemail.ws
• 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

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 is C .NET-managed code created with
  MS Visual Studio
• 68 interfaces
• 343 classes
• 30 projects
• 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
Parameters

• 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

17
Results

• Average latency for client .274 sec / msg
• Rate of 1786 msg / min at server
• 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 for clients with messages
  of similar size
• Benchmark UW Parkside peak server 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
• 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(SCitem, noncebytes,
  creationstring, attachmentstring, emailstring,
  TOuserstring, TOdomstring, Msg1item,
  Msg1Signeditem) -
• destUserAtDomain UName(TOuser, TOdom),
• isUserTokenKey(TokSC, SC, nonce, creation,
  KeySC),
• Msg1 Message1(TokSC, attachment, email,
  destUserAtDomain),
• mkSignature(Sig, "hmacsha1", KeySC,
  Msg1),
• Msg1Signed Sig Msg1.
• predicate isMsg1(Msg1Signeditem, SCitem,
  TOdomstring, TOuserstring, attachmentstring,
  emailstring, destUserAtDomainitem, Msg1item)
  -
• Msg1Signed Sig Msg1,
• Msg1 Message1(TokSC, attachment, email,
  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 couldnt 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