AMPol: Adaptive Messaging Policy

1
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
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
RMTA reality
SMTA wonderland
Recipient MUA bob_at_reality
Sender MUA alice_at_wonderland
Slide 06 of 18
8
Specifying the Policies
RMTA reality
SMTA wonderland
Recipient MUA bob_at_reality
Sender MUA alice_at_wonderland
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)
Slide 09 of 18
Fenton Thomas P.E.T.Mail, Voltage IBE Library
11
Policy Discovery

• Policy Advertisement
• Policy Merging
• Policy Query (Policy Query Protocol)

Slide 10 of 18
12
Policy Advertisement
RMTA reality
SMTA wonderland
Alice must sign packet Enforcement Point
wonderland
Recipient MUA bob_at_reality
Sender MUA alice_at_wonderland
Slide 11 of 18
13
Policy Merging
RMTA reality
SMTA wonderland
Dynamic Policy
Alice must sign packets Enforcement
Point wonderland Alice must use IBE
Enforcement Point reality Alice must solve
Hashcash Enforcement Point Bob
Recipient MUA bob_at_reality
Sender MUA alice_at_wonderland
Slide 12 of 18
14
Extension
RMTA reality
SMTA wonderland
Requires Extension for Hashcash
Recipient MUA bob_at_reality
Sender MUA alice_at_wonderland
Hashcash plugin
To bob_at_reality From alice_at_wonderland
Slide 13 of 18
15
Enforcement
RMTA reality
Check that packets are signed
SMTA wonderland
Check that packets are encrypted with IBE
Dynamic Policy Alice must sign packets
Enforcement Point wonderland Alice must use
IBE Enforcement Point reality Alice
must solve Hashcash Enforcement Point
Bob
Finally! --- Sincerely, Alice
Recipient MUA bob_at_reality
Sender MUA alice_at_wonderland
Check the Hashcash puzzle solution
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

• 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
20
Backup Slides
21
AMPol Policy Model
Backup Slide 01
22
WSEmail Case Study
Backup Slide 02