Research directions
Problem• Access policy: specification and enforcement
Approach• Tractable subsets of first-order logic
Accomplishments• Policy languages, algorithms, demo applications
Transitions to Industry• Collaboration, start-up, students to industry,
industrial visitor to Stanford Continuing efforts
• Interface w/commercial approaches: XrML, EPAL, P3P
• Policy development environment: algorithms, tools
Policy at site A may govern resources at site B
Protect distributed resources with distributed policy
Distributed Access Control
PolicyResource
PolicyResource
PolicyResource
ID
Decentralized Policy Example
AliceEPub
StateU is a university
Alice is a student
Grants access to university students
Trusts universities to certify students
Trusts ABU to certify universities
StateUABU
Policy Combination
Build policy templates• Policy 1: Generic hospital/clinic policy• Policy 2: Additional decisions for this clinic
Coalitions• Policy 1: Your company• Policy 2: Another company that makes a
business deal with you
Policy lifecycle issues
Requirements capture• What should the policy say?
Development• Adapt standard modules; build new ones; combine
Evaluation• Does the policy say what we want?
– Analysis Testing Debugging
Compliance• Can the policy be enforced by info system?
Maintenance• Change as needed as requirements evolve
Policy Language and Deduction
Specification• State policy succinctly and directly• Confident that policy captures intention
Enforcement• Deduction, proof of compliance
Manage policy lifecycle• Policy development tools• Safety and availability analysis
Core Issue
SPYCE Approach
Tractable subsets of first-order logic• Datalog
– If-then patterns without function symbols or negation
– Standard database query formalism
• Constraint Datalog– Constraints based on constraint domains– Hierarchies, intervals, discrete sets
• Polarity-restricted FOL (“Lithium”)– Allows function symbols, negation– Supports modular combination of policies
General policy form
A policy statement has the form: x1,…, xm (Condition
(+/-) Permitted(principal, privilege))
where• Condition is a conjunction of literals;• principal is individual [HW] or group [LM]• privilege can be action [HW] or group [LM]
Yale Feigenbaum, Li
Cornell Halpern, Weissman
Stanford Li, Mitchell, …
Role-based Trust-management (RT)
RT0: Decentralized Roles
RT1: Parameterized Roles
RTT : for Separation of Duties
RTD: for Selective Use of Role memberships
RT2: Logical Objects
RTT and RTD can be used (either together or separately) with any of the five base languages: RT0, RT1, RT2, RT1
C, and RT2
C
RT1C: structured resources
RT2C: structured resources
[Li, Mitchell, Winsborough , …]
Recall example
AliceEPub
StateU is a university
Alice is a student
Grants access to university students
Trusts universities to certify students
Trusts ABU to certify universities
StateUABU
Example RT0 credentials
1.StateU.stuID Alice2.ABU.accredited StateU3.EPub.university ABU.accredited4.EPub.student
EPub.university.stuID
5.EPub.access EPub.student
Together, five statements prove Alice is entitled to access
Distributed Policy
AliceEPub
StateU
ABUABU.accredited
StateU
COE.stuID AliceEPub.university ABU.accreditedEPub.student
EPub.university.stuID
StateU.stuID COE.stuID
COE
Privacy
Policy• Companies state privacy policy on web site• This is legally binding
Outsourcing and coalitions• Many companies outsource specific
functions• Partners may not have same privacy policies• Partners may have conflicting business
objectives
Web Architecture and Privacy
Database
SystemApplication
Application
Application
Enterprise
Portal
Policy! Enforcement?
Who cares about privacy?
Companies with P3P policy• P3P policy makes promise to customers• Company is legally obligated to comply
Organizations facing compliance• Healthcare, financial institutions• Government
Companies with customer assets• “Privacy” means that customer assets are not
compromised• Banks must preserve secrecy of customer
SSN
JetBlue information flowSource: A Anton
JetBlue info collected by OpenSkies is shared info with Torch Concepts.Torch combined JB info with data from Acxiom, has no stated privacy policy.
EPAL Concepts
Condition, ruling, obligations• If condition then outcome• Outcome = ruling obligations• Ruling = { yes, no, don’t care}• Obligations: actions that must occur
Examples• If employee owns the file then yes• If anyone accesses data then don’t care and log the request
IBM privacy language
Policy Combination
Denied
Permitted Permitted
Denied
Permitted
Denied
=+ OK
Denied
Permitted Permitted
Denied
Permitted
Denied
=+??
Policy language design space
Permitonly
Permit / Deny
Resolve contradiction
Can be contradictory
EPAL
Ordered
EPAL order priority
Intuitive ?• Need to give exception before general
case– Birds can fly– Penguins cannot fly
Efficiency• Cannot evaluate sub-policies in parallel
Scalability• How to combine separate sub-policies?
Some examples
Unreachable If male then yes If female then no If manager then no
Inapplicable If manager then yes If VP then no If male then no
Ineffective If VP then {run} If manager then {run, jump}
Redundant If manager then {run, jump} If VP then {run}
A policy editor could detect these situations Big problem: combination of EPAL policies may not be EPAL policy
Datalog As A Foundation
Natural• Security policy statements are if-then rules
Precise• Declarative and widely-understood semantics
Tractable• No function symbols tractability• Efficient goal-directed evaluation procedures
Available technology• Extensive Datalog research in LP and DB
Better: Constraint Datalog
Why constraints: • Datalog cannot easily express permissions
about structured resources and ranges
What is Constraint Datalog• Special form of CLP; query language for
Constraint DB
A Constraint Datalog rule: • R0(x0) :- R1(x1), ..., Rn(xn), (x0, x1, …, xn)
– x0, x1, …, xn are tuples of variables
is a constraint in all the variables
Example Policy with Constraints
A grants to B the permission to• connect to hosts in the domain “stanford.edu” • at port 80,
• valid from time t1 to t3 , and
• allows B to further delegate
grantConnect(A, B, h, p, v) :-
h edu,stanford, p=80, v [t1, t3]
grantConnect(A, x, h, p, v) :- grantConnect(B, x, h, p, v), h edu,stanford, p=80, v [t1, t3]
Useful Constraint Domains
Tree domains: • Path expressions a1,a2 , ,ak
– E.g., pub,software for /pub/software
• Primitive constraint: x=y or x a1, ,ak, where {=, <, , , }
Range domains:• Primitives: x=y, x=c, or, x (c1 , c2)
Discrete domains with finite sets:• Primitive constraint: x=y, x {c1,c2 , ,cj}
RT Accomplishments
RT language design RT deduction, trust negotiation
• Fast distributed deduction, constraints
Comparative analysis: KeyNote, SPKI 2.0 Safety and availability analysis
• HRU undecidability => RT poly-time, NP, Pspace
Sample applications• August scheduling, UStorIt file sharing, ATN, …
Transitions• IBM privacy, InnerPresence, NTT DoCoMo, Hitachi
Implementation Status
Java inference engine for RT0
Preliminary version of RTML• an XML-based Encoding of RT statements• XML Schemas and parser exist
Applications• U-STOR-IT: Web-based file storage and
sharing• August: A Distributed Calendar Program• Automated Trust Negotiation Demo by NAI• TNT Trust Negotiation architecture at BYU
Architecture design for policy-based portal site
Portal site
Web service
invoke service
return results(customized by General Policy)
User Service Provider
access
AuthenticationAuthority
AttributeAuthority(A)
Bob’s Policy(A)-Bob.Address <- CA-Bob.Job <- Student…
General Policy -Discount <- Student…
Web service
AttributeAuthority(B)
Policy DecisionAuthority
Bob’s Policy(B)-Bob.MembershipPoint <- high…
invoke service
return results(customized by Bob’s Policy(B))
AttributeAssertion
AuthenticationAssertion
Bob’s Policy(A)-Bob.Address <- CA-Bob.Job <- Student…
federated ID
User doesn’t have a federated ID
User has a federated ID
Role-based Trust Management
(TM)language
(SOAP)
(SOAP)
(SAML)
(SAML)
UDDIRegistry
register
register
discover
discover
create
(UDDI)(UDDI)
Policy DecisionAuthority
AttributeAuthority(B)
AttributeAuthority(A)
AuthenticationAuthority
Credential Chains
(Liberty Alliance)
Hitachi
Open Problems
Evaluation• Complete study of EPAL
Extend RT languages• Denying policies – for policy combination• Obligations
Distributed enforcement algorithms Policy lifecycle tools
• Safety analysis, resolve conflicts in policy combination
• Enforcement policy Advertised policy?
Critical Infrastructure Protection
Many critical infrastructures, national and DoD-specific, are decentralized
Data sharing essential for operation, but data compromise can be catastrophic
Research Question: How to share data safely, using policies that are easy to formulate, enforce, maintain
Approach: diffuse trust management
Assuring Software Quality
Technology applicable to managing process interaction • Process A delegates rights to process B
– For limited purpose, limited time, limited locations
• Fine-grained control of process actions• Works for diffuse systems that escape
normal controls imposed by localized OSs Diffuse principle of least privilege
DoD Impact
Dynamic coalitions• Partial sharing based on partial trust
Joint Vision 2010 / Joint Vision 2020 of “Network Centric” operations• Can use policy to push data,
overcome network bandwidth limitations
• Right data to right place at right time
Plans
Applications and Transitions• Work with XrML developers on language and
algorithm • IBM Privacy Project
– Extend RT algorithms to EPAL, P3P applications
• Pursue commercial and DOD applications• Larger policy sets, Network policies
Generalize results: RT Datalog PFOL Improve implementation: RT0 Datalog PFOL Policy development environment and tools
• User interface, XML-format, interoperability• Testing methodology, analysis methods
Automated Trust Negotiation
Credentials may contain sensitive information• need protection just as other resources• deduction must be interactive
The Trust Target Graph (TTG) protocol• supports RT0, which has delegation
• supports distributed discovery of statements• supports Ack policies, which also protects against
unauthorized leakage of attribute information
Cryptographic protocols for ATN• Oblivious Signature-Based Envelope (OSBE)
August: Distributed Calendar
Users define groups, maybe interdependent
Each user has a calendar and can specify policy which determines• who is allowed to view each part of the
user's calendar • who is allowed to add an activity of a
certain kinds at a certain time