CS590U Access 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 RT 0 : An Example 1. StateU.stuID  Alice 2. ABU.accredited  StateU 3. EPub.university  ABU.accredited 4. EPub.student  EPub.university.stuID 5. EPub.spdiscount  EPub.student  EOrg.preferred 6. EOrg.preferred  ACM.member 7. ACM.member  Alice Together, the seven credentials prove that Alice is entitled to EPub’s spdiscount

4 RT 0 : Concepts and Credentials Concepts: Entities (Principals): A, B, D Role names: r, r 1, r 2,... Roles: A.r, B.r 1,... e.g., StateU.stuID Credentials: A.r  e Type-1:A.r  D Type-2:A.r  B.r 1 Type-3:A.r  A.r 1.r 2 e.g., EPub.student  EPub.university.stuID Type-4:A.r  B 1.r 1  B 2.r 2 ...  B k.r k

5 RT 0 and SDSI 2.0 SDSI 2.0 (The SDSI part of SPKI/SDSI 2.0) has arbitrarily long linked names, e.g., A.r 1.r r k, which can be broken up by introducing new role names RT 0 has intersection (type-4 credentials) is thus more expressive than SDSI 2.0 algorithms for RT 0 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 G C 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.r 2  A.r 1.r 2 if there is a path from B to A.r 1 D  A 1.r 1  …  A k.r k if there are paths from D to each A j.r j Reachability in the credential graph is sound and complete wrt. the set semantics of RT 0

8 An Example Credential Graph StateU.stuID EPub.university ABU.accredited StateU Alice ACM.member EOrg.preferred EPub.university.stuID EPub.student EPub.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.stuID EPub.student 3: ABU.accredited 2: StateU 6: EPub.university 1: StateU.stuID ABU.accredited EPub.university EPub.student 7: Epub.university.stuID 9: EPub.student EPub.student 1. StateU.stuID  Alice 2. ABU.accredited  StateU 3. EPub.university  ABU.accredited 4. EPub.student  EPub.university.stuID 5: ABU8: EPub4: 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.student 4: EPub.university.stuID 6: EPub.university8: ABU.accredited9: StateU StateU 10: StateU.stuID 0: EPub.spdiscount 1: EPub.student  EOrg.preferred 3: EOrg.preferred5: ACM.member7: Alice Alice

13 Worst-Case Complexity Backward: time O(N 3 +NM), space O(NM) N is the number of rules M is the sum of the sizes of all rules, A.r  f 1  f k having size k, other credentials have size 1 Forward: time O(N 2 M), 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.member 2. 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.

Alice EPub StateU ABU 3. ABU.accredited  StateU 1. COE.stuID  Alice 4. EPub.university  ABU.accredited 5. 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.r 2  A.r 1.r 2 has the same traversability as B  A.r 1

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

Alice EPub StateU ABU 3. ABU.accredited  StateU 1. COE.stuID  Alice 4. EPub.university  ABU.accredited 5. 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. Winsborough IEEE 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 authority EPub.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 RT 0 : Decentralized Roles RT 1 : Parameterized Roles RT T : for Separation of Duties RT D : for Selective Use of Role memberships RT 2 : Logical Objects RT T and RT D can be used (either together or separately) with any of the five base languages: RT 0, RT 1, RT 2, RT 1 C, and RT 2 C RT 1 C : structured resources RT 2 C : structured resources

28 RT 1 = RT 0 + 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 RT 1 (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: ⊙, ⊗ K 1.R 1 ⊗ K 2.R 2 contains sets of two distinct principals, one a member of K 1.R 1, the other of K 2.R 2 K 1.R 1 ⊙ K 2.R 2 does not require them to be distinct

32 RT T (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 RT T (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