Security Policy Reconciliation in Distributed Environments Hao Wang, Somesh Jha, Miron Livny University of Wisconsin Patrick D. McDaniel AT&T Research

Security Policy Reconciliation in Distributed Environments

Hao Wang, Somesh Jha, Miron Livny

University of Wisconsin

Patrick D. McDaniel

AT&T Research

IEEE Policy 2004, Hao Wang 2

Policy Reconciliation

• To reconcile multiple policies among participants

Alice Bob

Session policy1. … 2. …

1. … 2. …3. …


Motivation—Secure Communication

SSH Protocol 1. SSH12. SSH2

1. SSH2

Encryption 1. AES-1281. 3DES

1. AES-128 1. 3DES

MAC 1. HMAC-SHA12. HMAC-MD5

1. HMAC-MD52. HMAC-SHA1

Compression 1. None2. Zlib

1. Zlib2. None

SSH Session

Server Policy Client Policy

Different preference

Different requirement

Different preference


Motivation—Resource Sharing

• Policy reconciliation also occurs in collaborative environments– E.g. GRID, Condor, SETI@Home– Policies may change frequently

InternetInternet

1.MUST authenticate1.Use PKI2.Use Kerberos

2.MUST encrypt all channels

1.Use AES-128

1.MUST authenticate1.Use Kerberos

2.MAY encrypt all channels

1.Use AES-128

1.MUST authenticate1.Use PKI2.Use Kerberos

2.MUST encrypt all channels

1.Use AES-1282.Use DES-1283.Use Blowfish-

1283.MAY use integrity

check1.HMAC-MD5

?

?


Recurring Theme

• Each site/host/user may have– Different security requirements– Different security preferences

• Session policy is dynamic

Internet

Internet



• To establish a provisioning session policy among participants

Alice Bob

ReconciliationEngine

Session policy1. … 2. …

1. … 2. …3. …


Problem Domain

• We deal with session provisioning policy– E.g. a secure session between two parties

• We do not deal with– Policy decisions– Policy constructions, transformations– Resolving policy conflicts

• Separation of policies and mechanisms– Our work provides the mechanism


Outline

• Motivation• Policy Representation using DAG• Policy Reconciliation• Implementation


Security Policy Reconciliation

• How to represent security policies– Need to capture dependencies within

each policy– Need to capture policy preferences

• How to reconcile security policies– Need to resolve policy preferences– Need to be efficient


Existing Approaches

• How to represent security policies– Flat– Do not address preferences– e.g. IPsec policy:

• Proposal 1: AH– Transform 1: HMAC-SHA– Transform 2: HMAC-MD5

• Proposal 2: ESP– Transform 1: 3DES with HMAC-SHA– Transform 2: 3DES with HMAC-MD5

• Proposal 2: PCP– Transform 1: LZS– Transform 2: Deflate

Proposal 1 may use one of the 2 listed

transforms

This policy offers 2

proposalsProposal 2 MUST use both ESP and

PCP; and there are two transforms

each for ESP and PCP.


Existing Approaches (cont.)

• How to reconcile security policies– Policies with preferences have not

been well addressed– Dependencies within policies are not

expressed explicitly– Generally a NP-complete problem

• Gong and Qian, 1994• McDaniel and Prakash, 2002


Our Contributions

• How to represent security policies – Use directed acyclic graph (DAG) to

represent policies• Concise• Capture dependencies among policy

components• Allow efficient reconciliation

– Handle policies with preferences


Our Contributions

• How to reconcile security policies – DAG model simplifies the problem– Policy is reconciled only once per

session– Reconcile policies with preferences– Polynomial time reconciliation– Supports multi-party reconciliation

• Current implementation supports two-party reconciliation


Policy Representation

• Graph model– Use Directed Acyclic Graph (DAG) S = (N,

E) called schema• N—set of nodes

– Each node is either an AND ( ) or an OR ( ) node– AND node == collection– OR node == decision

• E—set of edges

– A policy P = (S, C) is a sub-schema derived from S, where C is the condition function

– A policy instance is derived from P


Policy Schema

Integrity

root

Authentication Encryption

Kerberos PKI Password AES 3DES Blowfish HMAC

MD5 SHA1CBC

• Authentication– Kerberos– PKI (X.509)– Password

• Encryption– AES-CBC– 3DES-CBC– Blowfish-CBC

• Integrity– HMAC-MD5– HMAC-SHA1


Policy Schema & Policies

• The policy schema defines the blue print• Each site has its own security policy based

on the schema, i.e. sub-schema– Similar to database schema

Integrity

root


Kerberos PKI Password AES 3DES Blowfish

HMAC

MD5 SHA1

Integrity

root


Kerberos PKI AES 3DES

HMAC

MD5 SHA1Schema Policy sub-schema

CBC CBC


Policy Schema & Policies

Integrity

root



HMAC

MD5 SHA1

Integrity

root


Kerberos PKI AES 3DES

HMAC

MD5 SHA1Schema Policy sub-schema

CBC CBC

Integrity

root


Kerberos AES

HMAC

MD5Policy instance 1

CBC

Integrity

root


PKI 3DES

HMAC

MD5Policy instance 2

CBC


Policies May Have Preferences

• Each user/host/site has its own preferences – Either due to design or requirements– E.g. A may consider Kerberos to be the

preferred authentication algorithm over PKI; while B prefers PKI

• A policy P with preference: (S, C, Pref)– Pref(n): partial order function for each node


Policy With Preferences

Integrity

root


Kerberos PKI Password AES 3DES Blowfish HMAC

MD5 SHA1CBC

• Authentication1. Kerberos2. PKI (X.509)3. Password

• Encryption1. AES-CBC2. 3DES-CBC3. Blowfish-CBC

• Integrity1. HMAC-MD52. HMAC-SHA1

1 2 3

1 2

3 11 2

1 1 1


Policy With Preferences

Kerberos PKI

Password

• Policy 1:– Authentication

1.Kerberos or PKI2.Password Kerberos

PKI

Password

• Policy 2:– Authentication

1.Kerberos2.PKI3.Password

• Use partial ordering to express preferences


Outline

• Motivation• Policy Representation using DAG• Policy Reconciliation• Implementation



• Assumptions– A common policy schema shared by

participants– Custom policy schemas for different

participants

• Goals– A common policy schema for the participants– Reconciled once per session– Must handle preferences


Policy Construction

Sub-schema A

Sub-schema B

Integrity

root



HMAC

MD5 SHA1Schema

CBC

Integrity

root



HMAC

SHA1CBC

Integrity

root


Kerberos PKI Password AES Blowfish

HMAC

MD5 SHA1CBC


Reconciling Preferences

Kerberos PKI

Password

Kerberos

PKI

Password

Sub-schema A

Sub-schema B

Integrity

root



HMAC

SHA1CBC

Integrity

root



HMAC

MD5 SHA1CBC

1 1 2 1 2

1 2

1 2 3 1 2 3

1


Policy Reconciliation With Preferences

root

Authentication

Kerberos PKI

root

Authentication

Kerberos Password

Sub-schema B

Kerberos PKI

Password

Kerberos

PKI

Password

Password PKI

root

Authentication

Kerberos

Reconciled Policy Schema

PKI Password

Kerberos

PKI

Password

Preference APreference A Preference BReconciled Preference

Sub-schema A

1 1 2 1 2 3 1 2 3



SHA1Reconciled Policy CBC

Sub-schema A

Sub-schema B

Integrity

root



HMAC

Integrity

root



HMAC

1 1 2 1 2

1 2

1 2 3 1 2 3

1

Integrity

root



HMAC

1 2 3 1 2

1

SHA1CBCMD5 SHA1CBC


Policy Instantiation

Reconciled Policy

Integrity

root

AuthenticationEncryption

Kerberos AES HMAC

SHA1Policy Instance 1 CBC

Integrity

root

AuthenticationEncryption

Kerberos BlowfishHMAC

SHA1Policy Instance 2 CBC

Kerberos

PKI

Password

AES-CBC

Blowfish-CBC

Most preferred Instance

SHA1CBC

Integrity

root



HMAC

1 1 2 1 2

1


Policy Reconciliation—Summary

Schema

Policy Reconciliation Engine

Policy Instance Policy Instance Policy Instance

Policy sub-schema Policy sub-schemaPolicy sub-schema

ReconciledPolicy Schema


Implementation

• Policy Reconciliation Engine (PRE)– See

http://www.cs.wisc.edu/~hbwang/PRE/tr1499.pdf for details

– Code available at http://www.cs.wisc.edu/~hbwang/PRE

• Integrated with Condor, a high-throughput, distributed system– http://www.cs.wisc.edu/condor


Conclusion

• We demonstrated a graph-based algorithm for policy reconciliation– Exposes the structure of policies– Is concise and efficient– Handles policies with preferences– Models dependencies within each

policy

Documents

Security Policy Reconciliation in Distributed Environments Hao Wang, Somesh Jha, Miron Livny University of Wisconsin Patrick D. McDaniel AT&T Research