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