Integrating Access Control with Intentional NamingMain GoalOverviewMotivationAccess ControlIntentional NamingSlide 8Security Extensions of INSThe Naïve SolutionA Scalable SolutionIntegration of Access Control KEY IDEASIntegration of Access ControlSlide 14System Architecture RevisitedScalable SolutionProxy-to-Proxy SecurityProxy-to-Router UpdatesStatusQuestions?Integrating Access Control with Intentional NamingSanjay RamanMIT Laboratory for Computer [email protected] 8, 2002With help from: Dwaine ClarkeMain GoalCreate an infrastructure to provide access-controlled resource discovery in dynamic networks that is scalable yet efficientOverview•Problem Description•Intentional Naming Introduction–Security extensions•Integration of Access Control•Security Advantages•Status•QuestionsMotivation•Consider a dynamic environment with many users and resources•Resources should be given the ability to restrict specific users / applications•Automatic discovery of accessible resourcesStudentDirectorDirector…ACLDirector…ACLK1 StudentsDirector…ACLK1 StudentsK1 TAsTADirector’s OfficeTATAStudent StudentUsage ScenarioAccess 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 accessUserUserUserResourceIntentional 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.eduINS DNSIntentional Namingrootservice locationprinter cameraname-recordlcsai-labspeakersmitNAME-TREESecurity 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 checkThe Naïve SolutionK21 Proxyrootservice locationprinter 1 printer 2 lcsai-labprinter 3 mitNAME-TREEIntentional Naming Service[service = printer [load = 2]]Printer 1ProxyUser AUser CPrinter 2ProxyUser DPrinter 3ProxyUser AUser BUser Bprinter1.lcs.mit.eduauthentication[user B]authentication[user B]authentication[user B]printer2.lcs.mit.eduprinter3.lcs.mit.edu<print><ok>A Scalable SolutionCricket ListenerWireless Comm. K21 Proxy{print to closest, least-loaded printer}Cricket BeaconK21 ProxyK21 ProxyIntentional Name Routerspulp.lcs.mit.edu{request}Printer ProxyProxy-to-proxysecurityK21Integration 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 requestIntegration of Access Controlrootservice locationprinter cameraname-recordlcsai-labspeakersmitACL1ACL2ACL3ACL1 ACL2 ACL3ACL1 ACL2 ACL3NAME-TREEResource-level ACLsName record resolutionPeriodic UpdatesConstructed ACLIntegration 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 authenticationSystem Architecture RevisitedK21 ProxyK21 ProxyK21 ProxyIntentional Name RoutersK21’s CertificatesK1 students K2 studentsK2 students Kc192.168.0.45{request}(*) K2 students KcK1 students K2 studentsPrinter ProxyProxy-to-proxysecurityTransitive Closure of K21’s Certificates(*) K1 students KcCricket ListenerWireless Comm. {print to closest, least-loaded printer}Cricket BeaconK21Scalable SolutionK21 Proxyrootservice locationprinter 1 ACL1printer 2 ACL2lcsai-labprinter 3 ACL3mitNAME-TREEIntentional Naming Service[service = printer [load = 2]]&& [Relevant Certificates]Printer 1ProxyUser AUser CPrinter 2ProxyUser DPrinter 3ProxyUser AUser BUser Bauthentication[user B]printer3.lcs.mit.edu<print><ok>ACL1 ACL2 ACL3Proxy-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 unusableProxy-to-Router Updates•Resource status updates–Periodic Event–Flooding concerns•Update messages must be secure and authentic–DoS attacksResource Proxyuser Auser Buser CINS RouterRevocation of User BTriggered UpdatePeriodic 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
View Full Document
Unlocking...