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