Date post: | 03-Jan-2016 |
Category: |
Documents |
Upload: | nora-atkins |
View: | 213 times |
Download: | 0 times |
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
Objects, ApplicationsOperations
Roles,Permissions
Users
Objects, ApplicationsOperations
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 23
NL Syntax
op ::= | | (math) op::= + | - | * | exp | modsize ::= | 1 | … | N comp ::= | | | | | set ::= DnU | DnR | DnOP| DnOBJ | DnP | DnApp| JR | JOP| JOBJ| JApp| JP |
DnCR| DnCP| DnCU| CCR| CCP| CCU
(math) set ::= N | L function (fn.) ::= user | roles | permissions | operation | object | application | OE | AO(math) function :: = successor | minimum | maximum | List_min | List_max |
member | length | sumlist
Statement = (Expression Expression) Statement
Expression = Token comp (Token, size, set1 | set2 | … | setn )
Token = Term1 | Term2 | … | Termm
Term = Clause op Clause op … Clause, fn.(fn….(Clause), fn.(fn. …(Clause) op fn.(fn. …(Clause) op … fn.(fn. …(Clause)
Clause = OE/AO(OE/AO … (set)
June 14, 2004 24
RFOPL Syntax
op ::= | | (math) op::= + | - | * | exp | modsize ::= | 1 | … | N comp ::= | | | | | set ::= DnU | DnR | DnOP| DnOBJ | DnP | DnApp| JR | JOP| JOBJ| JApp| JP |
DnCR| DnCP| DnCU| CCR| CCP| CCU
(math) set ::= N | L function ::= user | roles | permissions | operation | object | application | OE | AO(math) function :: = successor | minimum | maximum | List_min | List_max |
member | length | sumlist
Statement = x1, x2, …, xn: (Expression Expression) Statement
Expression = Token comp (Token, size, set1 | set2 | … | setn )
Token = Term1 | Term2 | … | Termm
Term = Clause op Clause op … Clause, fn.(fn….(Clause), fn.(fn. …(Clause) op fn.(fn. …(Clause) op … fn.(fn. …(Clause)
Clause = variable xi, set – variable xi
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