ampol: adaptive messaging policy raja n. afandi, jianqing zhang, munawar hafiz, carl a. gunter...

AMPol: Adaptive Messaging Policy

Raja N. Afandi, Jianqing Zhang, Munawar Hafiz, Carl A. Gunter

Computer Science Department,

University of Illinois Urbana-Champaign

Dec 05, 2006Dec 05, 2006Presentation DatePresentation Date

Adaptive Policy

• Large scale systems often have diverse policies– Many administrative domains– Difficult or impossible to impose a uniform policy

on all participants (“Global standards make the system brittle” – Alan Karp)

• Support for non-functional (QoS) features such as security and reliability breaks the interoperability of the system – Constraints may change frequently

Slide 01 of 18Slide 01 of 18

Strategy

• Service Oriented Architectures (SOAs) based on Web services offer a promising platform

• Basic strategy: responder advertises WS-based policy, initiator adapts dynamically

• Basic architecture based on three components– Policy model describes declarative domain-specific policy r

ules

– Policy discovery governs how to publish, find, and merge policies

– Extension and Enforcement (EE) provides means to add capabilities and enforce policies


Our Contribution

• New Case Study - WSEmail extension with novel features

• Dynamic Extension - Policy Extension

- System Extension

• Multi-node operations - Message Sender, Recipient and Multiple Intermediaries


WSEmail

• WSEmail: Internet messaging based on Web services

• Uses XML, SOAP, XMLDSIG, WS-Policy, etc. rather than SMTP, IMAP, POP, S/MIME, etc.

• Improves security, flexibility, integration

Lux May Bhattad Gunter ICWS 05Lux May Bhattad Gunter ICWS 05 Slide 04 of 18Slide 04 of 18

AMPol

• Adaptive Messaging Policy (AMPol) is an SOA for policy adaptation in messaging systems such as email, instant messaging, etc.

• Instantiates three components: Policy model, Policy discovery, Enforcement and Extension

• Extends WSEmail with modest changes to underlying system

• Illustrates benefits to adaptive policies


Problem Scenario

SMTAwonderland

RMTAreality

Sender MUAalice@wonderland

Recipient MUAbob@reality

To: bob@realityFrom: alice@wonderland


Specifying the Policies

SMTAwonderland

RMTAreality




Egress policy of Wonderland

Ingress policy of Reality

Ingress policy of Bob

Egress policy of Alice

Alice must not sent .bmp extensions

Alice must use encryption

All messages must be signed


Policy Model

• The policy constructs should be distinct, modular and extensible

• Static policy and dynamic policy• Supports

– Meta-specification for policy enforcement– Rule prioritization to resolve conflicts– Public vs. private rules

• Domain specific policy rules: APES– Attachment– Payment– Encryption– Signature


APES

• Attachment. Types of attachments allowed in mail messages.

Example: No .pif extension file can be attached. • Payment. Type of cost imposed on message senders. Example: A message sender must solve an RTT (Reverse Turing Test)

Puzzle.

• Encryption. Type of Encryption Mechanism. Example: 3DES encryption is used.

• Signature. Type of Signature Mechanism. Example: Messages are signed with SHA-1 Hash.

Novel Technologies supported by our policy model * Hashcash * Reverse Turing Test (RTT) * Identity Based Encryption (IBE)

Fenton Thomas P.E.T.Mail, Voltage IBE Library Fenton Thomas P.E.T.Mail, Voltage IBE Library Slide 09 of 18Slide 09 of 18

• Policy Advertisement• Policy Merging• Policy Query (Policy Query Protocol)

Policy Discovery


Policy Advertisement

SMTAwonderland

RMTAreality



Merged StaticReceiving Policy of reality domain

Alice must use IBE Enforcement Point: reality

Alice must solve Hashcash Enforcement Point: Bob

Merged StaticSending Policy of wonderland domain

Alice must sign packet Enforcement Point: wonderland

Egress policy of Wonderland

Egress policy of Alice

Ingress policy of Reality

Ingress policy of Bob

Alice must sign packet Enforcement Point: wonderland




SMTAwonderland

RMTAreality



Policy Merging

Dynamic Policy


Static sending policy of wonderland domain

Static receiving policy of reality domain

Alice must sign packets Enforcement Point: wonderland




Extension

Requires Extension for Hashcash

SMTAwonderland

RMTAreality




Hashcash plugin


Enforcement

Finally!--- Sincerely, Alice

Dynamic Policy

Alice must sign packets Enforcement Point: wonderland



Check that packets are signed

Check that packets are encrypted with IBE

Check the Hashcash puzzle solution

SMTAwonderland

RMTAreality




Enforcement and Extension

• Policy Framework– Extracts the policy conformance and enforcement logic into

independent and dynamically pluggable extensions

– Core policy engine is generic enough to process many complex constraints

– Unlike WS-Policy framework in which assertions are domain specific and any new addition requires an update to core policy engine

• Extension Framework – Manages extensions

– Have policies to control the download and execution of extensions

– Download plug-ins from secure third-party plug-in server


EE Sub-components


Summary

• End-to-end solution for supporting non-functional (QoS) policies

• Reference architecture for adaptive middleware for messaging systems

• Application of this middleware for email system based on Web services

• Validation of proposed approach through a case study

• Addresses gaps in prior work:– Multi-node operation

– Dynamic extension


Current and Future Work

1. Semantic Web QoS (AMPol-Q)

2. Policy Merging (Based on Defeasible Logic)

3. Attribute Based Messaging (ABM)

4. WS-Email for Health Alerts

5. Learn More: http://seclab.cs.uiuc.edu/ampol


http://seclab.cs.uiuc.edu/ampol

http://seclab.cs.uiuc.edu/ampol

Backup Slides

AMPol Policy Model

Backup Slide 01Backup Slide 01

WSEmail Case Study

Backup Slide 02Backup Slide 02

ampol: adaptive messaging policy raja n. afandi, jianqing zhang, munawar hafiz, carl a. gunter...

Documents

extensiblestatic policy

uniform policy

policy adaptation

wsbased policy

messaging systems

wonderlandrecipient

internet messaging

instant messaging