a model for access negotiations in dynamic coalitions himanshu khuranavirgil gligor ncsa, university...

A Model for Access Negotiations in Dynamic Coalitions

Himanshu Khurana Virgil GligorNCSA, University of Illinois University of

Maryland

June 14, 2004 2

Outline

Characteristics of Dynamic Coalitions

Coalition Infrastructure for Integrated Security Services

Negotiation of Coalition Resources A Model and a Negotiation Language Examples of Resource-negotiations

June 14, 2004 3

Coalitions

Collaborative Environments Formed to achieve a common objective by sharing

resources e.g., commercial research and development, health

care, airline route management, public emergency response

teams, military joint task forces Shared Resources – objects, applications, services

Diverse membership Multiple, autonomous domains of security policy

administration Overlapping but not identical member interests

June 14, 2004 4

Dynamic Coalitions

Dynamic changes of membership Member join / departure at any time after coalition

creation/setup membership duration can be lower than current

time to set up a coalition (e.g., weeks, months) Member join / departure must not require new

coalition creation from scratch

Dynamic Sharing of Coalition Resources Achieved by distribution of access permissions for

resources Based on resource-sharing agreements, or common

access states

June 14, 2004 5

Coalition Infrastructure for Integrated Security Services

Resource Management Services Common view of coalition operations (intuitive graphical

interface) Access policy administration of shared applications

Certificate Services Distribution/revocation of Identity and Attribute certificates

Secure Group Communication Services Reliable multicast communication Group key management

Joint Administration Services Authorize member access to jointly owned resources Consensus-based access policy administration

June 14, 2004 6

Components Providing Security Services

Domain 1

CA

User

Identity Cert.

UsersResources

PermissionsLocal Policies

RBACTool(Role

Control Center)

Public-KeyAcc CA

AttrCerts

Sec. GroupComm.

Domain 2

CA

User

Identity Cert.

UsersResources

PermissionsLocal Policies

RBACTool(Role

Control Center)

Public-KeyAcc CA Attr

Certs

Sec. GroupComm.

RBAC Tool(RCC)

Coalition Attribute Authority (AA) Coalition Resource Server

WebServer

AppO Jointly

Owned

CommonAccessState

Import

Joint Administration

SharedAccess_CA

Negotiator Negotiator

Negotiate

Coalition ResourceManagement Toolkit

SharedAccess_CA

Negotiator Negotiator

June 14, 2004 7

Negotiating Access to Coalition Resources

Domain 1 Domain 2

NegotiateCommon Access State

- is agreed on by all domains- satisfies neg. constraints

Internet

Europe – South AsiaEurope – Australia

U.S. – EuropeU.S. - North AfricaU.S. – South America

Global Negotiation Constraint: Share only weekend routes

Local Neg. Constraint: does not wish to share U.S. – South America routes unless it can get access to Europe – Australia routes

June 14, 2004 8

Related Work Winsboro et al. and Seamons et al.,

“Automated Trust Negotiation” Problem: Clients and servers for e-business may not trust

each other Need for trust establishment via exchange of sensitive

credentials Goal: Develop a trust negotiation strategy and architecture

for trust negotiation

Research differences: Does not address resource negotiation

Client

Access Request Access Authorization Rule

Access Request; Credentials

Reply

Server

. . . . . .

June 14, 2004 9

Need for Negotiation Tools: Save Time and Reduce

Errors

Negotiation is time-consuming Number of objects is large; e.g., a route sharing coalition

may include tens of route types, each with tens of specific flights

Number of negotiation rounds may be large

Negotiation is error-prone When size of coalition is large – tens of domains sharing

hundreds of resources E.g., an international coalition of civilian and military

organizations responding to international crises

Negotiation process is repetitive

June 14, 2004 10

Negotiating Common Access States Multiple Times

Domain join Re-negotiate common access state to satisfy new objectives

Shared accesses to new and existing coalition resources

Voluntary domain departure Cannot withdraw jointly administered resources Re-negotiate common access state for two reasons

Continued administration of jointly owned resources Withdrawal of resources essential to coalition objectives

Involuntary domain departure Re-negotiate common access state to exclude departing

domain

June 14, 2004 11

Examples of Negotiation Constraints

Constraints can be global or local Global constraints: known by all member domains Local constraints: may remain private to some member

domains Resource based constraints

Cost-based constraints: Total profit > 2 * total cost Least-privilege constraints: For common application choose

one that requires access to least number of objects Permission based constraints

Obligation: All domains must have access to jointly owned app

Separation-of-duty: No role can perform all operations Cardinality: No role can have > n members

Negotiation Language NL extends RCL2000

June 14, 2004 12

Elements of Common Access State (CAS)

Domain 1 Domain 2 Domain k…

Coalition Authority

Objects, ApplicationsOperations

Roles,Permissions

Users


Roles,Permissions

Users


Roles,Permissions

Users

Jointly OwnedObjects & Apps,

Operations

Roles,Permissions

Joint Administration

ForeignUserEnrollment

User Enrollment

• CAS allows all domains to - have a common view of coalition operations - execute shared applications and access shared objects

June 14, 2004 13

An Example of Common Access State Negotiation

Coalition Objective: Share 6 route types among 3 domains(Route type corresponds to sets of departure/destination pairs such as

U.S. – Europe, Europe – Asia, etc.) Sharing implies granting access permissions to execute

route applications such as reservations, billing, advertising, etc.

Jointly administer auditing application to enforce pricing policies

E.g., travel routes across multiple domains, frequent flyer miles

Global Negotiation Constraints: Share all unique route types Share common route types based on least privilege principle

June 14, 2004 14

Constraint specification in NL

Constraints in NL DU is a list of all coalition users: DU = {D1U, D2U, D3U}

For each route typei

Domi = {D1, …, D3} list of domains that have typei

Ni = {nroutes1, …, nroutes3} no. of routes in each domain’s route type

(i) length(Domi) = 1 typeij

objects(permissions(roles(DU-DjU)))) where domain Dj Domi

(ii) length(Domi) > 1 list_min(Ni, Nij) typeij

objects(permissions(roles(DU-DjU))))

where domain Dj Domi, Nij is the jth element of list Ni

June 14, 2004 15

Routes Controlled and Desired before Negotiation

Domain 1

Domain 2 Domain 3

1(5)

4(8)

5(4)

6(7)

1(5)

2(6)

4(9)

3(2)

2(4)

1(7)

5(3)

4(6)

Legenda

(b)a – Route typeb – No. of Routes in route type

a(b)

DomainX

X wants route type a

After Negotiation: Domain D1 shares routes {1, 6}, Domain D2 shares routes {3}, Domain D3 shares routes {2, 4, and 5}

June 14, 2004 16

Example 1: State TransitionsD1FUA = {}, D2FUA = {}, D3FUA = {}

D2Prop = {D1 (1, 6), D2 (3), D3 (2, 4, 5)}, JResPropose shared resources

CD = {D1, D2, D3}Join Coalition

CC = {GC}Define Neg. Constraints

CRes = D1: (1, 4, 5, 6), D2: (1, 2, 3, 4), D3: (1, 2, 4, 5)Add domain Resources

D2PVote = {Yes, Yes, Yes} Vote on Proposal

NCR = {D1 (1, 6), D2 (3), D3 (2, 4, 5)}, JRes Declare Shared Resources

CCOM = {RD1_1, RD1_6, RD2_3, RD3_2, RD3_4, RD3_5, JR}Add Roles

CCOM = {(UD3_user1: RD1_1, RD1_6, RD2_3)}Add User-Role Relations

D1FUA = {RD1_1: (UD2_user1, UD3_user3)}, HISCommit

JRes = Audit App, JR, JP, JPA, JOPAdd Jointly Owned Resources

June 14, 2004 17

Example 2: Jointly owned resources with SOD and obligation constraints

Coalition Objective: Domains D1, D2, and D3 will jointly administer access to a web server that manages jointly owned applications 1, 2 and 3

Operations allowed: read, append, audit

Global Negotiation Constraints (i) Every role with audit permissions for any application

must have at least one user as a member from each domain (obligation)

(ii) No role can perform all operations on any jointly owned application (per-role Op SOD)

June 14, 2004 18

Example 2: Jointly owned resources with SOD and obligation constraints

Constraints in NL DU is a list of all coalition users: DU = {D1U, D2U,

D3U}

CCOP1 = {audit}, CCOP2 = {read, append, audit}, CCApp = {1, 2, 3}

(i):|operations(OE(JR), OE(CCApp)) CCOP1| |users (OE(JR)) OE(DU)| 1

(ii):|operations(OE(JR), OE(CCApp)) CCOP2| < |CCOP2|

June 14, 2004 19

Example 2: State Transitions

D1FUA = {JR1: (UD1_user1, UD2_user2, UD3_user3)}

CCOM = {UD1_user1, UD2_user2, UD3_user3}

NCR = {D2Prop}

D2PVote = {Yes, Yes, Yes}

D2Prop = {JRes}

JRes = D1: (1), D2: (2), D3: (3), JR, JP, JOP, JPA

Commit

Add Users

Declare Negotiated Resources

Vote on Proposal

Propose Shared Resources

CC = {GC}

Add Coalition Resources

CD = {D1, D2, D3}

Add Neg. Constraints

Join Coalition

{D1FUA} = , {D2FUA} = , {D3FUA} =

June 14, 2004 20

State Transition Model Overview

Model elements derived from CAS, negotiation process

State Variables record state of system

State Invariant defines a secure state

State Transition Rules are conditioned on satisfaction of state invariants

Resource negotiations completely represented as a sequence of state transitions

June 14, 2004 21

Satisfaction of Constraints and Model Security

State transitions require satisfaction of constraints

All NL statements have an RFOPL equivalent RFOPL statements can be represented as Horn

Clauses; i.e., Prolog can be used as a sound resolution procedure for constraint verification

Show that model supports necessary security formulations

Start in secure state & apply secure transition end in secure state

Move from secure state to secure state there exist secure transitions between these two states

June 14, 2004 22

QUESTIONS ?

June 14, 2004 25

Negotiation Language – Candidates

Language Expressiveness Ease of UseResolution

Procedure

RCL2000 Very Good

Very Good Limited

(Partially modeled in UML, OCL and Prolog;)

Tower Very Good

(Suited for object-oriented systems)

Good Poor

ASL Very Good Poor

(knowledge of logic structures)

Good

(proof logic is implementable)

Ponder Limited

(suited for object-oriented systems)

Good.

(some know. of logic structures)

Good.

(deployment is discussed )

June 14, 2004 26

Verifying Satisfaction of Constraints

Deductive databases D can be implemented in Prolog

Statements of the form A F (all var universally quantified)

Integrity constraint W: closed formula Query Q: F (all var universally quantified) D satisfies W if W is a logical consequence of D

Soundness of Query evaluation Every computed answer for D Q is a correct

answer

Constraint satisfaction Using query W

June 14, 2004 27

Joint Administration of Access Policies

Joint Creation:Coalition AttributeAuthority

(AA)

Joint AccessRequest

ThresholdAttributeCertificate

CA3

Admin_D3

Domain 3

ID Cert.

Coalition Web Server

CA2

Admin_D2

Domain 2

ID Cert.

CA1

Admin_D1

Domain 1

ID Cert.

ACLObject O

ACL write

CoalitionWeb

Server

ObjectO

June 14, 2004 28

Joint Administration of Access Policies

Shared public key for the coalition AA All domains create AA’s public key while retaining

shares of the private key Signatures with shared key requires application of joint

signature algorithm Trust liabilities minimized as all domains have to be

compromised to obtain private key

Coalition Authority(AA)

Domain 1 Domain 2 Domain 3

Public Key K

Private key K1-1 Private key K2

-1 Private key K3-1

K1-1 + K2

-1 + K3-1 = K-1

K is published and trusted by Web Server

a model for access negotiations in dynamic coalitions himanshu khuranavirgil gligor ncsa, university...

Documents