Upload
veronica-oneal
View
217
Download
0
Tags:
Embed Size (px)
Citation preview
WSEmailEmail Based on Web Services
Kevin Lux, Michael May, Nayan BhattadUniversity of Pennsylvania
Carl A. GunterUniversity 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 UMLServer 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
Stc
TestCoordinator
X.509 Certificate Authentication
Se
Windows 2003 Web Edition
Si
Windows 2003 Web Edition
DNS, User Authentication
DNS, User Authentication,
DB Storage
Windows 2003 Server Standard
Edition
T1
T3
T2
T4
Client MachinesWindows XP Pro
UserNameand
PasswordAuthentication
Sdb SQL Server 2000 Enterprise Edition (SP3a)
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: .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– 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 TulaFalepredicate 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