Download reality Alice must solve Hashcash Enforcement

AMPol: Adaptive Messaging Policy
Raja N. Afandi, Jianqing Zhang, Munawar Hafiz,
Carl A. Gunter
Computer Science Department,
University of Illinois Urbana-Champaign
Presentation Date
Dec 05, 2006
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
- WSEmail extension with novel features
• Dynamic Extension
- Policy Extension
- System Extension
• Multi-node operations
- Message Sender, Recipient and Multiple Intermediaries
Slide 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 05
Slide 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 18
Problem Scenario
RMTA
reality
SMTA
wonderland
To: bob@reality
From: alice@wonderland
Sender MUA
alice@wonderland
Recipient MUA
bob@reality
Slide 06 of 18
Specifying the Policies
All messages must be signed
SMTA
wonderland
Egress policy of
Wonderland
Alice must not sent .bmp extensions
Egress policy
of Alice
RMTA
reality
Ingress policy
of Reality
Ingress policy
of Bob
Alice must use encryption
To: bob@reality
From: alice@wonderland
Sender MUA
alice@wonderland
Recipient MUA
bob@reality
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 Discovery
• Policy Advertisement
• Policy Merging
• Policy Query (Policy Query Protocol)
Slide 10 of 18
Policy Advertisement
Alice must sign packet
Enforcement Point: wonderland
Alice must use IBE
Enforcement Point: reality
Egress
policy of
Wonderland SMTA
wonderland
Alice
IBEHashcash
Alicemust
mustuse
solve
Enforcement
Point:
reality
Enforcement
Point:
Bob
Merged Static
Receiving Policy of
reality domain
Alice must sign packet
Enforcement Point: wonderland
Alice must solve Hashcash
Merged Static
Enforcement Point: Bob
Egress
policy of
Alice
Sender MUA
Sending
Policy
of
alice@wonderland
wonderland domain
RMTA
reality
Ingress
policy of
Reality
Ingress
policy of Bob
Recipient MUA
bob@reality
Slide 11 of 18
Policy Merging
RMTA
reality
SMTA
wonderland
Static sending policy
of wonderland domain
Static
receiving
policy of
reality
domain
Dynamic Policy
Alice must sign packets
Enforcement Point: wonderland
Alice must use IBE
Enforcement Point: reality
Sender MUA
alice@wonderland
Alice must solve Hashcash
Enforcement Point: Bob
Recipient MUA
bob@reality
To: bob@reality
From: alice@wonderland
Slide 12 of 18
Extension
RMTA
reality
SMTA
wonderland
Requires Extension
for Hashcash
Sender MUA
alice@wonderland
To: bob@reality
From: alice@wonderland
Recipient MUA
bob@reality
Hashcash plugin
Slide 13 of 18
Enforcement
Check that packets
are signed
Check that packets are
encrypted with IBE
SMTA
wonderland
Dynamic Policy
RMTA
reality
Alice must sign packets
Enforcement Point: wonderland
Alice must use IBE
Enforcement Point: reality
Alice must solve Hashcash
Enforcement Point: Bob
Sender MUA
alice@wonderland
Finally!
--- Sincerely, Alice
Recipient MUA
bob@reality
Check the Hashcash
puzzle solution
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 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
Current and Future Work
1.
2.
3.
4.
5.
Semantic Web QoS (AMPol-Q)
Policy Merging (Based on Defeasible Logic)
Attribute Based Messaging (ABM)
WS-Email for Health Alerts
Learn More: http://seclab.cs.uiuc.edu/ampol
Slide 18 of 18
Backup Slides
AMPol Policy Model
Backup Slide 01
WSEmail Case Study
Backup Slide 02