Integrating Access Control with Intentional Naming

1
Integrating Access Control with Intentional Naming

• Sanjay Raman
• MIT Laboratory for Computer Science
• sraman_at_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

Usage Scenario
Directors Office
TA
TA
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

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

INS
DNS
building lcs floor 2 service
printer load 4
pulp.lcs.mit.edu
8
Intentional Naming
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
User B
K21 Proxy
11
A Scalable Solution

Cricket Beacon
K21 Proxy
K21 Proxy
K21 Proxy
K21
Proxy-to-proxy security
request
print to closest, least-loaded printer
Printer Proxy
pulp.lcs.mit.edu
12
Integration of Access ControlKEY 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
Constructed ACL
Periodic Updates
Resource-level ACLs
Name record resolution
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

Cricket Beacon
K21 Proxy
K21 Proxy
K21 Proxy
K21
Proxy-to-proxy security
request
print to closest, least-loaded printer
Printer Proxy
K21s Certificates
K1 students ? K2 students
K2 students ? Kc
Transitive Closure of K21s Certificates
K1 students ? K2 students
192.168.0.45
() K2 students ? Kc
() K1 students ? Kc
16
Scalable Solution
Intentional Naming Service
NAME-TREE
root
service
location
User B
ACL1 ? ACL2 ? ACL3
K21 Proxy
printer 1 ACL1
printer 2 ACL2
lcs
ai-lab
printer 3 ACL3
mit
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

revoke user B
Resource Proxy
INS Router
Triggered Update
Periodic Update
increase in load
Revocation of User B
19
Status

• Implementation of system is underway
• Performance evaluation
• Tradeoff overhead in creating ORed versus ACL
  checks
• State inconsistency in boundary cases
• Goal integrate with existing automation system
• Scale system to a large number of nodes

20
Questions?