1 / 34

CS590U Access Control: Theory and Practice

CS590U Access Control: Theory and Practice. Lecture 21 (April 11) Distributed Credential Chain Discovery in Trust Management. What is RT?. RT is a family of Role-based Trust-management languages Publications on RT

sani
Download Presentation

CS590U Access Control: Theory and Practice

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 2

  3. RT0: An Example • StateU.stuID  Alice • ABU.accredited  StateU • EPub.university  ABU.accredited • EPub.student  EPub.university.stuID • EPub.spdiscount  EPub.student  EOrg.preferred • EOrg.preferred  ACM.member • ACM.member  Alice • Together, the seven credentials prove that Alice is entitled to EPub’s spdiscount 3

  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.studentEPub.university.stuID • Type-4: A.r  B1.r1 B2.r2 ... Bk.rk 4

  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 5

  6. Goal-directed Chain Discovery • Three kinds of queries and algorithms for answering them: • Given A.r, determines its members • The backward search algorithm • Given D, determines the set of roles that D is a member of • The forward search algorithm • Given A.r and D, determines whether D is a member of A.r • The Bi-direction search algorithm 6

  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 7

  8. EPub.spdiscount EPub.student EPub.university EPub.student  EOrg.preferred ABU.accredited EPub.university.stuID EOrg.preferred StateU ACM.member StateU.stuID Alice An Example Credential Graph Key Credential Summary 8

  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 9

  10. 4: ABU.accredited.stuID 7: Epub.university.stuID 1: StateU.stuID 9: EPub.student 8: EPub 5: ABU 2: StateU 3: ABU.accredited 6: EPub.university Forward Search In Action StateU.stuID  Alice ABU.accredited  StateU EPub.university  ABU.accredited EPub.student  EPub.university.stuID EPub.student 0: Alice StateU.stuID StateU.stuID EPub.student EPub.student EPub.student ABU.accredited ABU.accredited EPub.university EPub.university EPub.university 10

  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 11

  12. Backward Search In Action 7: Alice 5: ACM.member 3: EOrg.preferred Alice Alice Alice 0: EPub.spdiscount 1: EPub.student  EOrg.preferred Alice Alice Alice 10: StateU.stuID 2: EPub.student 4: EPub.university.stuID Alice Alice Alice 9: StateU 8: ABU.accredited 6: EPub.university StateU StateU StateU 12

  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  f1fk 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 13

  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 14

  15. Distributed Storage of Credentials • Example: • EOrg.preferred  ACM.member • 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. 15

  16. Who stores these statements? Alice EPub 1. COE.stuID  Alice 4. EPub.university  ABU.accredited 5. EPub.student  EPub.university.stuID COE 2. StateU.stuID  COE.stuID 3. ABU.accredited  StateU StateU ABU

  17. EPub.student EPub.university.stuID EPub.university Backward (Issuer stored) StateU.stuID Key ABU.accredited Forward (Subject stored) Alice StateU Confluent Traversability of Edges and Paths (con’d) An edge B.r2 A.r1.r2 has the same traversability as B  A.r1 17

  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 18

  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 19

  20. A Typing Scheme Alice EPub 1. COE.stuID Alice 4. EPub.university ABU.accredited 5. EPub.student EPub.university.stuID COE 2. StateU.stuID COE.stuID 3. ABU.accredited StateU StateU ABU

  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 21

  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 22

  23. 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 distributedpolicy statements • Security analysis 24

  25. Expressive Features (part one) • Simple attribute assignmentStateU.stuID  Alice • Delegation of attribute authority StateU.stuID  COE.stuID • Attribute inferencing EPub.access  EPub.student • Attribute-based delegation of authority EPub.student  EPub.university.stuID 25

  26. Expressive Features (part two) • Conjunction EPub.access  EPub.student  ACM.member • Attributes with fields • StateU.stuID (name=.., program=.., …)  Alice • EPub.access  StateU.stuID(program=“graduate”) • Permissions for structured resources • e.g., allow connection to any host in a domain and at any port in a range 26

  27. The Languages in the RT Framework RT0: Decentralized Roles RTD: forSelective Use of Role memberships RTT : forSeparation of Duties RT1: Parameterized Roles RT2: Logical Objects RT1C: structured resources RT2C: structured resources RTT and RTD can be used (either together or separately) with any of the five base languages: RT0, RT1, RT2, RT1C, and RT2C 27

  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 28

  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’) 29

  30. RTT: 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 30

  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 31

  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} 32

  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} 33

  34. Next Lecture • Database Access Control • Review of the course 34

More Related