CS590UAccess Control: Theory and Practice

Lecture 21 (April 11)Distributed Credential Chain

Discovery in Trust Management

2

What is RT?

RT is a family of Role-based Trust-management languages

Publications on RT Li, Winsborough & Mitchell: “Distributed Credential Chain

Discovery in Trust Management”, CCS’01, JCS’03 Li, Mitchell & Winsborough: “Design of a Role-Based Trust

Management Framework”, S&P’02 Li & Mitchell: “Datalog with Constraints: A Foundation for Trust

Management Languages”, PADL’03 Li & Mitchell: “RT: A Role-based Trust-management

Framework”, DISCEX’03 Li, Winsborough & Mitchell: “Beyond Proof-of-compliance:

Safety and Availability Analysis in Trust Management”, S&P’03, JACM’05

3

RT0: An Example

1. StateU.stuID Alice2. ABU.accredited StateU3. EPub.university ABU.accredited4. EPub.student EPub.university.stuID5. EPub.spdiscount EPub.student

EOrg.preferred6. EOrg.preferred ACM.member7. ACM.member Alice

Together, the seven credentials prove that Alice is entitled to EPub’s spdiscount

4

RT0: Concepts and Credentials Concepts:

Entities (Principals): A, B, D Role names: r, r1, r2 , ... Roles: A.r, B.r1, ... e.g., StateU.stuID

Credentials: A.r e Type-1: A.r D Type-2: A.r B.r1

Type-3: A.r A.r1.r2 e.g., EPub.studentEPub.university.stuID

Type-4: A.r B1.r1 B2.r2 ... Bk.rk

5

RT0 and SDSI 2.0 SDSI 2.0 (The SDSI part of SPKI/SDSI

2.0) has arbitrarily long linked names, e.g.,

A.r1.r2.....rk, which can be broken up by introducing new role names

RT0

has intersection (type-4 credentials) is thus more expressive than SDSI 2.0

algorithms for RT0 can be used for SDSI 2.0

6

Goal-directed Chain Discovery

Three kinds of queries and algorithms for answering them:1. Given A.r, determines its members

– The backward search algorithm

2. Given D, determines the set of roles that D is a member of– The forward search algorithm

3. Given A.r and D, determines whether D is a member of A.r– The Bi-direction search algorithm

7

Credential Graph GC

Nodes: A.r and e for each credential A.r e in C

Credential edges: e A.r for each credential A.r e in C

Summary edges: B.r2 A.r1.r2 if there is a path from B to A.r1

D A1.r1 … Ak.rk if there are paths from D to each Aj.rj

Reachability in the credential graph is sound and complete wrt. the set semantics of RT0

8

An Example Credential Graph

StateU.stuID

EPub.university

ABU.accredited

StateU

Alice

ACM.member

EOrg.preferredEPub.university.stuID

EPub.studentEPub.spdiscount

EPub.student EOrg.preferred

Credential

Summary

Key

9

The Forward Search Algorithm (Overview)

Starts with one entity node Constructs a proof graph Each node in the graph stores its solutions:

roles that this node can reach (is a member of ) Maintains a work list of nodes need to be processed Algorithm Outline:

keep processing nodes in the work list until it is empty

10

Forward Search In Action

ABU.accredited

0: Alice

StateU.stuIDStateU.stuID

EPub.student

3: ABU.accredited2: StateU

6: EPub.university

1: StateU.stuID

ABU.accredited

EPub.universityEPub.university EPub.university

EPub.student

7: Epub.university.stuID

9: EPub.student

EPub.student EPub.student

1. StateU.stuID Alice

2. ABU.accredited StateU

3. EPub.university ABU.accredited

4. EPub.student EPub.university.stuID

5: ABU 8: EPub

4: ABU.accredited.stuID

11

The Backward and Bi-direction Search Algorithms (Overview)

The backward algorithm differs from the forward algorithm in that: each node stores outgoing edges, instead of

incoming ones each node stores entities that can reach it,

instead of roles that it can reach the processing of a node is different

traversing the other direction

The bi-direction search algorithm combines backward search and forward search

12

Backward Search In Action

2: EPub.student4: EPub.university.stuID

6: EPub.university8: ABU.accredited9: StateU

StateU StateU StateU

10: StateU.stuID

0: EPub.spdiscount 1: EPub.student EOrg.preferred

3: EOrg.preferred5: ACM.member7: Alice

Alice

Alice

Alice

AliceAlice

Alice Alice

Alice Alice

13

Worst-Case Complexity

Backward: time O(N3+NM), space O(NM) N is the number of rules M is the sum of the sizes of all rules,

A.r f1fk having size k, other credentials have size 1

Forward: time O(N2M), space O(NM) However, this is goal oriented, making it

much better in practice

14

Why Develop These Algorithms?

The queries can be answered using logic programs however, this requires collection of all

credentials in the system The backward algorithm is a goal-directed

top-down algorithm The forward algorithm is a goal-directed

bottom-up algorithm Distributed discovery requires combination

of both

15

Distributed Storage of Credentials

Example:1. EOrg.preferred ACM.member2. ACM.member Alice

Who should store a credential? either issuer or subject

It is not reasonable to require that all credentials are stored by issuers, or, all are stored by subjects.

AliceEPub

StateUABU

3. ABU.accredited StateU

1. COE.stuID Alice4. EPub.university ABU.accredited5. EPub.student

EPub.university.stuID

Who stores these statements?

2. StateU.stuID COE.stuID

COE

17

Traversability of Edges and Paths (con’d)

StateU.stuID

Alice

EPub.university.stuID

EPub.student

EPub.university

ABU.accredited

StateU

Backward(Issuer stored)

Forward(Subject stored)

Key

Confluent

An edge B.r2 A.r1.r2 has the same

traversability as B A.r1

18

How to Ensure that Every Path is Confluent?

Goal: using constraints local to each credential to ensure that every path is confluent

Approach: give each role name a traceability type introduce a notion of well-typed credentials

Main idea: by requiring consistent storage strategy at role

name level, we guarantee chains using well-typed credentials are confluent

19

Types of Role Names

A role name has two types: Issuer side:

issuer-traces-all issuer-traces-def issuer-traces-none

Subject side: subject-traces-all subject-traces-none

AliceEPub

StateUABU

3. ABU.accredited StateU

1. COE.stuID Alice

4. EPub.university ABU.accredited5. EPub.student

EPub.university.stuID

A Typing Scheme

2. StateU.stuID COE.stuID

COE

21

Agreement on Types and Meaning of Role Names

An approach inspired by XML namespaces Use an Application Domain Specification

Document (ADSD) to define a vocabulary Each role has a storage type

Credentials have a preamble Which defines vocabulary identifier to

correspond to an ADSD When using a role name, add a vocabulary

identifier as prefix

22

Benefits of the Storage Type System

Guarantees that chains of well-typed credentials can be discovered

Enables efficient chain discovery by telling the algorithm whether forward or backward search should be used for an intermediate query

Communicates the application domain knowledge to the algorithm

Design of A Role-based Trust-management Framework

Ninghui Li, John C. Mitchell & William H. WinsboroughIEEE S&P 2002

24

Features of the RT family of TM languages

Expressive delegation constructs Permissions for structured resources A tractable logical semantics based on

(Constraint) Datalog Strongly-typed credentials and vocabulary

agreement Efficient deduction with large number of

distributed policy statements Security analysis

25

Expressive Features (part one)

I. Simple attribute assignment StateU.stuID Alice

II. Delegation of attribute authority StateU.stuID

COE.stuID

III. Attribute inferencing EPub.access EPub.student

IV. Attribute-based delegation of authorityEPub.student EPub.university.stuID

26

Expressive Features (part two)

V. Conjunction EPub.access EPub.student

ACM.member

VI. Attributes with fields StateU.stuID (name=.., program=.., …) Alice EPub.access StateU.stuID(program=“graduate”)

VII. Permissions for structured resources e.g., allow connection to any host in a

domain and at any port in a range

27

The Languages in the RT Framework

RT0: Decentralized Roles

RT1: Parameterized Roles

RTT : for Separation of Duties

RTD: for Selective Use of Role memberships

RT2: Logical Objects

RTT and RTD can be used (either together or separately) with any of the five base languages: RT0, RT1, RT2, RT1

C, and RT2C

RT1C: structured resources

RT2C: structured resources

28

RT1 = RT0 + Parameterized Roles

Motivations: to represent attributes that have fields, e.g., digital ids,

diplomas relationships between principals, e.g.,

physicianOf, advisorOf role templates, e.g., project leaders

Approach: a role term R has a role name and a list of

fields

29

RT1 (Examples) Example 1: Alpha allows manager of an

employee to evaluate the employee: Alpha.evaluatorOf(employee=y)

Alpha.managerOf(employee=y)

Example 2: EPub allows CS students to access certain resources:EPub.access(action=‘read’, resource=‘file1’)

EPub.university.stuID(dept=‘CS’)

30

RT T: Supporting Threshold and Separation-of-Duty

Threshold: require agreement among k principals drawn from a given list

SoD: requires two or more different persons be responsible for the completion of a sensitive task want to achieve SoD without mutual exclusion,

which is nonmonotonic Though related, neither subsumes the other RT T introduces a primitive that supports

both: manifold roles

31

Manifold Roles

While a standard role is a set of principals, a manifold role is a set of sets of principals

A set of principals that together occupy a manifold role can collectively exercise privileges of that role

Two operators: ⊙, ⊗ K1.R1 ⊗ K2.R2 contains sets of two distinct

principals, one a member of K1.R1, the other of K2.R2

K1.R1 ⊙ K2.R2 does not require them to be distinct

32

RTT (Examples)

Example 1: require a manager and an accountant K.approval K.manager K.accountant members(K.approval) {{x,y} | x K.manager, y

K.accountant}

Example 2: require a manager and a different accountant K.approval K.manager K.accountant members(K.approval)

{{x,y} | x y, x K.manager, y K.accountant}

33

RTT (Examples)

Example 3: require three different managers K.approval K.manager K.manager

K.manager members(K.approval) {{x,y,z} | x y z

K.manager}

34

Next Lecture Database Access Control Review of the course