Integrating Access Control with Intentional Naming

Sanjay RamanMIT Laboratory for Computer Science

sraman@mit.edu

January 8, 2002

With help from: Dwaine Clarke

Main Goal

Create an infrastructure to provide access-controlled resource discovery in dynamic networks that is scalable yet efficient

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

Student

DirectorDirector

…

ACL

Director

…

ACL

K1 Students

Director

…

ACL

K1 Students

K1 TAs

TA

Director’s Office

TA

TA

Student Student

Usage Scenario

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

UserUser User

Resource

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

INS DNS

Intentional Namingroot

service location

printer camera

name-record

lcsai-labspeakers mit

NAME-TREE

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

The Naïve Solution

K21 Proxy

root

service location

printer 1 printer 2 lcsai-labprinter 3 mit

NAME-TREE

Intentional Naming Service

[service = printer [load = 2]]

Printer 1Proxy

User A

User C

Printer 2Proxy

User D

Printer 3Proxy

User A

User B

User Bprinter1.lcs.mit.edu

authentication[user B]

authentication[user B]

authentication[user B]

printer2.lcs.mit.eduprinter3.lcs.mit.edu

<print>

<ok>

A Scalable Solution

Cricket Listener

Wireless Comm.

K21 Proxy

{print to closest, least-loaded printer}

Cricket Beacon

K21 Proxy

K21 Proxy

Intentional Name

Routers

pulp.lcs.mit.edu

{request}

Printer Proxy

Proxy-to-proxysecurity

K21

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

Integration of Access Controlroot

service location

printer camera

name-record

lcsai-labspeakers mitACL1 ACL2 ACL3

ACL1 ACL2 ACL3

ACL1 ACL2 ACL3

NAME-TREE

Resource-level ACLs

Name record resolution

Periodic Updates

Constructed ACL

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

System Architecture Revisited

K21 Proxy

K21 Proxy

K21 Proxy

Intentional Name

Routers

K21’s Certificates

K1 students K2 students

K2 students Kc

192.168.0.45

{request}

(*) K2 students Kc

K1 students K2 students

Printer Proxy

Proxy-to-proxysecurity

Transitive Closure of K21’s Certificates

(*) K1 students Kc

Cricket Listener

Wireless Comm.

{print to closest, least-loaded printer}

Cricket Beacon

K21

Scalable Solution

K21 Proxy

root

service location

printer 1 ACL1

printer 2 ACL2

lcsai-labprinter 3 ACL3

mit

NAME-TREE

Intentional Naming Service

[service = printer [load = 2]]&& [Relevant Certificates]

Printer 1Proxy

User A

User C

Printer 2Proxy

User D

Printer 3Proxy

User A

User B

User B

authentication[user B]

printer3.lcs.mit.edu

<print>

<ok>

ACL1 ACL2 ACL3

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

Proxy-to-Router Updates

• Resource status updates– Periodic Event– Flooding concerns

• Update messages must be secure and authentic– DoS attacks

Resource Proxy

user Auser Buser C

INS Router

Revocation of User B

Triggered Update

Periodic Update

{increase in load}

{revoke user B}

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?