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 access-controlled resource discovery in dynamic networks that is scalable yet efficient

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. StudentDirector … ACL Director … ACL K1 Students Director … ACL K1 Students K1 TAs TA Director’s Office TA Student Usage Scenario

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

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. Intentional Naming root servicelocation printercamera name-record lcsai-lab speakers mit N AME -T REE

9. 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 check

10. 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

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

12. 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 K21 Proxy performs transitive closure of its certificates and sends appropriate rules to INS with request

13. 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

14. Integration of Access Control 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

15. 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 Cricket Listener Wireless Comm. {print to closest, least-loaded printer} Cricket Beacon K21

16. Scalable Solution K21 Proxy root servicelocation printer 1 ACL 1 printer 2 ACL 2 lcsai-labprinter 3 ACL 3 mit N AME -T REE Intentional Naming Service [service = printer [load = 2]] && [Relevant Certificates] Printer 1 Proxy User A User C Printer 2 Proxy User D Printer 3 Proxy User A User B authentication [user B] printer3.lcs.mit.edu ACL 1  ACL 2  ACL 3

17. Proxy-to-Proxy Security SPKI/SDSI Model Protocol does not have to be repeated in order to determine access privileges –ACL check should succeed the first time (2 boundary cases) Protocol can be used with very little change to INS architecture Protocol follows end-to-end argument Enhances scalability of automation system –Previous model would be unusable

18. Proxy-to-Router Updates Resource status updates –Periodic Event –Flooding concerns Update 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}

19. 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

20. Questions?