1. Integrating Access Control with Intentional Naming Sanjay Raman MIT Laboratory for Computer Science sraman@mit.edu January 8, 2002 With help from: Dwaine Clarke

2. Main Goal Create an infrastructure to provide secure, access-controlled resource discovery in dynamic networks using intentional naming

3. Overview Problem Description Intentional Naming Introduction –Security extensions Integration of Access Control Security Advantages Status Questions

4. Motivation Consider a dynamic environment with many users and resources Resources should be given the ability to restrict specific users / applications Automatic discovery of accessible resources

5. Usage Scenario K2 StudentK1 StudentDirector … ACL Director … ACL K1 Students Director … ACL K1 Students K2 Students K1 StudentK2 Student K1 Student

6. Access Control Useful mechanism in guarding access to resources Security Model Suitable for dynamic environments Each resource maintains a list of referencing a set of valid keys –Granting, delegating, revoking authorizations –user/application does not know accessibility of resource without explicitly attempting access User

7. Intentional Naming Resource discovery and service location system for dynamic networks Uses a simple language based on attributes and values to identify resources Language used to describe the desired resource –Applications describe what they are looking for, not where to find it [building = lcs [floor = 2 [service = printer [load = 4]]] pulp.lcs.mit.edu INSDNS

8. Security Extensions of INS INS is a naming service; designed to be a layer below security –No built-in mechanism to implement access control –Cannot explicitly reject requests from unauthorized users Extend INS to provide access control decisions Application should find best resource to which it has access –Increases scalability and performance –Costly to perform full authentication and authorizations checks

9. The Naïve Solution K21 Proxy root servicelocation printer 1printer 2lcsai-labprinter 3mit N AME -T REE Intentional Naming Service [service = printer [load = 2]] Printer 1 Proxy User A User C Printer 2 Proxy User D Printer 3 Proxy User A User B printer1.lcs.mit.edu authentication [user B] authentication [user B] authentication [user B] printer2.lcs.mit.edu printer3.lcs.mit.edu

10. A Scalable Solution Wireless Comm. K21 K21 Proxy {print to closest, least-loaded printer} Cricket Listener K21 Proxy Intentional Name Routers pulp.lcs.mit.edu {request} Printer Proxy Proxy-to-proxy security

11. Integration of Access Control KEY IDEAS Store ACL as attribute-value pair on each resource proxy INS routers maintain dynamic name-trees –Propagate ACLs up the tree when they are modified –“OR” (  ) ACLs at each parent node Access Control decisions made during traversal –Name-Lookup algorithms will eliminate resources based on membership in intermediate ACLs

12. Integration of Access Control root servicelocation printercamera name-record lcsai-lab speakers mit ACL 1 ACL 2 ACL 3 ACL 1  ACL 2  ACL 3 N AME -T REE Resource-level ACLs Name record resolution Periodic Updates Constructed ACL

13. Integration of Access Control Proxy performs transitive closure of its certificates and sends appropriate rules to INS with request INS processes request by pruning name-tree and making access decisions INS returns best accessible address Proxies perform Proxy-to-Proxy protocol with full authentication

14. System Architecture Revisited K21 Proxy Intentional Name Routers K21’s Certificates K 1 students  K 2 students K 2 students  K c 192.168.0.45 {request} (*) K 2 students  K c K 1 students  K 2 students Printer Proxy Proxy-to-proxy security Transitive Closure of K21’s Certificates (*) K 1 students  K c Wireless Comm. K21 {print to closest, least-loaded printer} Cricket Listener

15. Proxy-to-Proxy Security SPKI/SDSI Model Protocol does not have to be repeated in order to determine access privileges –INS will return the address of a resource you are guaranteed access to –ACL check should succeed the first time Enhances scalability of automation system –Previous model would be unusable

16. Proxy-to-Router Updates Access revocation and delegation Resource status updates –Periodic Event –Flooding concerns One-way messages must be secure and authentic –DoS attacks Resource Proxy user A user B user C INS Router Revocation of User B Triggered Update Periodic Update {increase in load} {revoke user B}

17. Status Implementation of system is underway Performance evaluation –Tradeoff: overhead in creating “OR”ed versus ACL checks –State inconsistency in boundary cases Goal: integrate with existing automation system –Scale system to a large number of nodes

18. Questions?