Integrating Access Control with Intentional Naming Sanjay Raman

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

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

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

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

Usage Scenario ACL Director … Director K 2 Student K 1 Student K 2 Student ACL Director K 1 Students K 1 Student … ACL Director K 1 Students K 2 Students …

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

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 INS [building = lcs [floor = 2 [service = printer [load = 4]]] DNS pulp. lcs. mit. edu

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

The Naïve Solution Intentional Naming Service NAME-TREE root [service = printer [load = 2]] service User B K 21 Proxy location printer 1. lcs. mit. edu printer 2. lcs. mit. edu printer 3. lcs. mit. edu <ok> authentication [user B] printer 1 printer 2 printer 3 Printer 1 Proxy Printer 2 Proxy Printer 3 Proxy User A User C User D User A User B <print> mit ai-lab lcs

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

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

Integration of Access Control Constructed ACL 1 ACL 2 ACL 3 NAME-TREE root service ACL 1 ACL 2 ACL 3 location Periodic Updates printer camera speakers ACL 1 ACL 2 ACL 3 mit ai-lab lcs Resource-level ACLs name-record Name record resolution

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

System Architecture Revisited Cricket Listener Wireless Comm. K 21 Proxy K 21 {request} {print to closest, least-loaded printer} Intentional Name Routers K 21’s Certificates Proxy-to-proxy security Printer Proxy K 1 students K 2 students Kc Transitive Closure of K 21’s Certificates K 1 students K 2 students (*) K 2 students Kc (*) K 1 students Kc 192. 168. 0. 45

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

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

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

Questions?