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

Slide 02 of 18Slide 02 of 18

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

Slide 03 of 18Slide 03 of 18

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

Slide 05 of 18Slide 05 of 18

Problem Scenario

SMTAwonderland

RMTAreality

Sender MUAalice@wonderland

Recipient MUAbob@reality

To: bob@realityFrom: alice@wonderland

Slide 06 of 18Slide 06 of 18

Specifying the Policies

SMTAwonderland

RMTAreality

Sender MUAalice@wonderland

Recipient MUAbob@reality

To: bob@realityFrom: alice@wonderland

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

Slide 07 of 18Slide 07 of 18

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

Slide 08 of 18Slide 08 of 18

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

Slide 10 of 18Slide 10 of 18

Policy Advertisement

SMTAwonderland

RMTAreality

Sender MUAalice@wonderland

Recipient MUAbob@reality

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

Alice must use IBE Enforcement Point: reality

Alice must solve Hashcash Enforcement Point: Bob

Slide 11 of 18Slide 11 of 18

SMTAwonderland

RMTAreality

Sender MUAalice@wonderland

Recipient MUAbob@reality

Policy Merging

Dynamic Policy

To: bob@realityFrom: alice@wonderland

Static sending policy of wonderland domain

Static receiving policy of reality domain

Alice must sign packets Enforcement Point: wonderland

Alice must use IBE Enforcement Point: reality

Alice must solve Hashcash Enforcement Point: Bob

Slide 12 of 18Slide 12 of 18

Extension

Requires Extension for Hashcash

SMTAwonderland

RMTAreality

Sender MUAalice@wonderland

Recipient MUAbob@reality

To: bob@realityFrom: alice@wonderland

Hashcash plugin

Slide 13 of 18Slide 13 of 18

Enforcement

Finally!--- Sincerely, Alice

Dynamic Policy

Alice must sign packets Enforcement Point: wonderland

Alice must use IBE Enforcement Point: reality

Alice must solve Hashcash Enforcement Point: Bob

Check that packets are signed

Check that packets are encrypted with IBE

Check the Hashcash puzzle solution

SMTAwonderland

RMTAreality

Sender MUAalice@wonderland

Recipient MUAbob@reality

Slide 14 of 18Slide 14 of 18

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

Slide 15 of 18Slide 15 of 18

EE Sub-components

Slide 16 of 18Slide 16 of 18

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

Slide 17 of 18Slide 17 of 18

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

Slide 18 of 18Slide 18 of 18

Backup Slides

AMPol Policy Model

Backup Slide 01Backup Slide 01

WSEmail Case Study

Backup Slide 02Backup Slide 02