1. 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

2. 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

3. 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

4. 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 18

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

6. 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 18

7. Problem Scenario SMTA wonderland RMTA reality Sender MUA alice@wonderland Recipient MUA bob@reality To: bob@reality From: alice@wonderland Slide 06 of 18

8. Specifying the Policies SMTA wonderland RMTA reality Sender MUA alice@wonderland Recipient MUA bob@reality To: bob@reality From: 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 18

9. 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

10. 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

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

12. Policy Advertisement SMTA wonderland RMTA reality Sender MUA alice@wonderland Recipient MUA bob@reality 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

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

14. Extension Requires Extension for Hashcash SMTA wonderland RMTA reality Sender MUA alice@wonderland Recipient MUA bob@reality To: bob@reality From: alice@wonderland Hashcash plugin Slide 13 of 18

15. 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 alice@wonderland Recipient MUA bob@reality Slide 14 of 18

16. 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

17. EE Sub-components Slide 16 of 18

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 18

19. 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/ampolhttp://seclab.cs.uiuc.edu/ampol Slide 18 of 18

20. Backup Slides

21. AMPol Policy Model Backup Slide 01

22. WSEmail Case Study Backup Slide 02