AMPol: Adaptive Messaging Policy Raja N. Afandi, Jianqing Zhang, Munawar Hafiz, Carl A. Gunter Computer Science Department, University of Illinois Urbana-Champaign Dec 05, 2006 Presentation 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 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 rules –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 18

Our Contribution New Case Study - WS extension with novel features Dynamic Extension - Policy Extension - System Extension Multi-node operations - Message Sender, Recipient and Multiple Intermediaries Slide 03 of 18

WS WS 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 05 Slide 04 of 18

AMPol Adaptive Messaging Policy (AMPol) is an SOA for policy adaptation in messaging systems such as , instant messaging, etc. Instantiates three components: Policy model, Policy discovery, Enforcement and Extension Extends WS with modest changes to underlying system Illustrates benefits to adaptive policies Slide 05 of 18

Problem Scenario SMTA wonderland RMTA reality Sender MUA Recipient MUA To: From: Slide 06 of 18

Specifying the Policies SMTA wonderland RMTA reality Sender MUA Recipient MUA To: From: 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 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 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 Slide 09 of 18

Policy Advertisement Policy Merging Policy Query (Policy Query Protocol) Policy Discovery Slide 10 of 18

Policy Advertisement SMTA wonderland RMTA reality Sender MUA Recipient MUA Merged Static Receiving Policy of reality domain Alice must use IBE Enforcement Point: reality Alice must solve Hashcash Enforcement Point: Bob Merged Static Sending 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 18

SMTA wonderland RMTA reality Sender MUA Recipient MUA Policy Merging Dynamic Policy To: From: 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 18

Extension Requires Extension for Hashcash SMTA wonderland RMTA reality Sender MUA Recipient MUA To: From: Hashcash plugin Slide 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 SMTA wonderland RMTA reality Sender MUA Recipient MUA Slide 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 18

EE Sub-components Slide 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 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 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- for Health Alerts 5.Learn More: Slide 18 of 18

Backup Slides

AMPol Policy Model Backup Slide 01

WS Case Study Backup Slide 02