Policy Adaptation and Exchange
in Trust Negotiation
Bachelor thesis
by Denisa Ghita
Prof. Dr. Wolfgang Nejdl
Prof. Dr. Valentin Cristea
Dipl. Inf. Daniel Olmedilla
University “Politehnica” of Bucharest
Faculty of Automatic Control and Computer Science
&
L3S Research Center, Hannover University
Overview

Motivation

Policies

Trust Negotiation

Protune Language

Negotiation Framework

Conclusions
2
Motivation
Finding a Service Provider
http://www.ebookstore.com
3
Motivation
Registration & Private Information Disclosure
4
Motivation
Sensitive Information Disclosure
5
Motivation
Traditional Security (I)
Identity based Security
Requesters are identified at sign in and mapped
to permissions.
Alice may download file “U2-One.mp3”.
6
Motivation
Toward Security Based on Properties
Identity does not scale on the web
=>
Property based Security
Security decisions based only on properties
(proved via digital credentials).
Client is an employee of a certain company.
7
Motivation
Traditional security (II)
Unilateral Security
Only users must fulfill conditions and provide
information.
Client must unconditionally disclose credit card
information.
8
Motivation
Toward Bilateral Security
Bilateral Security
Users can also specify conditions that providers
must fulfill.
Negotiations with an agreement as a goal.
9
Policies
Security & Privacy
 Specify the behavior of a system => control
how decisions are taken and actions are
executed
 Service providers policies => how access to
services and resources can be gained
 Users policies => under what conditions
should credentials be disclosed
10
Policies
Characteristics
 No need to compile
 Not hard-coded
 Dynamic, can often change
 Must be understood by machines
 Managed by administrators/users
11
Trust Negotiation
Definition
Parties exchange credentials and policies in
order to establish the level of trust needed to
perform the transaction.
 Bi-directional process
clients may also specify policies
 Zero-knowledge base
interactions between strangers
 No need for third trusted party
no third party for match-making
12
Trust Negotiation
Policy-Driven Negotiations
Bob
Bookstore
Bob requests access to a resource
The bookstore discloses its policy for
the resource
Bob discloses his policy for Visa
The bookstore sends its BBB card
Bob discloses his Visa credit card
The bookstore grants access to the
resource
13
Trust Negotiation
Requirements
policy languages
tools to reason with policies
representation and storage of credentials
negotiation strategies
(semi-)automatic
agents acting on behalf of users
14
Protune Language
PROvisional TrUst NEgotiation
 Based on logic programming
 Declarative
 Rule-based language
[Id] H <- L1, L2,…, Ln.
 Dynamic features
• invoke calls to other systems (e.g.,
databases)
• describe actions to be executed
• generate explanations about elements
defined in the policy
15
Protune Language
Complex terms
 Users can define objects with attributes and
values
 E.g., credentials can be expressed as complex
terms
visacard[
type : ”creditcard”,
issuer : ”Visa”,
owner : ”Maria Ines”,
]
16
Protune Language
Decision Predicates
 Predicates that may be queried by other parties
• gain access to a resource/ a service
allow(access(”OnlineBooks”))
• obtain a credential
sign( bbbcard[
type : ”member”,
issuer : ”Better Business Bureau”,
owner : ”Maria Ines”,
])
17
Protune Language
State-query predicates
 integrate local information (e.g., users
profiles) in the policy
passwd( maria, airam)
 not everything needs to be stored in the policy
=> calls to external modules (e.g., databases)
 integration of legacy systems
in(
passwd(maria, Password),
database : query
(”select Password from Users
where User = ${maria}”)
).
18
Protune Language
Provisional predicates
 specify actions that are to be executed
• locally (e.g., log information to a file)
log(”log.txt”,”User ${User} registered.”)
• by peer (e.g, disclose a credential)
credential( context, studentcard[
type:”student ”,
issuer: ”Uni-Hannover”,
])
19
Protune Language
Abbreviation predicates
 define new concepts
 simplify the policy structure
allow(access(Resource)) : −
authenticate(User),
has_subscription(User,Resource).
authenticate(User) : −
declaration( ad, D[
username : User,
password : Password]),
passwd(User, Password).
20
Protune Language
Constraint predicates
 equality & dis-equality predicates
 “is”
A is B =>
checks whether A and B are
instantiated to the same value
 “ground”
ground(Arg) => checks whether the
argument given is
instantiated
21
Protune Language
Metapolicy
contains metadata about the policy
specifies how the policy should be handled
E.g, policies may contain private information
• needed for reasoning
• must not be disclosed to the other party
 general syntax
[Id].attribute : value :− L1,...,Ln.
Predicate(Arg1, ..., Argn).attribute : value
:− L1,...,Ln.
22
Protune Language
Metapolicy Examples
passwd( User, Password).sensitivity: private.
log( File, Message).action:
’echo ’+Message+’ > ’+File.
log( File, Message).evaluation: immediate
:- ground(File), ground(Message).
register(Url).explanation:
”Register as new user at ${Url}”.
23
Protune Language
Metapolicy Attributes & Values
Attribute
Domain
Values
type
literals
decision_predicate,
state_predicate,
provisional_predicate,
abbreviation_predicate,
constraint_predicate
sensitivity
rules, literals
public , private
evaluation
provisional_predicates
immediate, deferred
state_predicate
action
provisional_predicates
script language
actor
provisional_predicates
self, peer
explanation
rules, literals
natural language
statement
24
Negotiation Framework
Interaction
Client
Service Provider
M0
Pc, Σc
Ps, Σs
M1
P = local policy
Σ = state
…..
Mn-1
Mn
Mi = ( P`, C)
P`= policy
C = credentials
25
Negotiation Framework
Peer processes (I)
 Policies are written in Protune
 Reasoning with policies requires an inference
engine (e.g., Prolog)
• Protune-Prolog translators for policies
and metapolicies
• Processing a policy = Filtering the policy
(e.g, protecting private information in the
policy)
 Policies are exchanged in the Protune
representation
26
Negotiation Framework
Peer processes (II)
Local
policy
(Protune)
ProtuneProlog
Translator
Client
request
Filtering
module
PrologProtune
Translator
Filtered
policy
(Protune)
27
Negotiation Framework
Protune-Prolog Translators (I)
 verify that policies are according to the
Protune (Prolog) grammar and translate them
in the Prolog (Protune) representation
 translators do not change the semantics of the
policy
 uses BNF productions
 implemented in JavaCC
28
Negotiation Framework
Protune-Prolog Translators (II)
[Id]Head :- L1, ...,Ln.
=>
rule(Id,Head, [L1, ...,Ln]).
[Id].Attr:Val : −L1,...,Ln.
=>
metarule(id, Attr(Id, Val), [L1,...,Ln]).
Head.Attr:Val : −L1,...,Ln.
=>
metarule(pred, Attr(Head, Val), [L1,...,Ln]).
Id[Attr1 : Val1, ..., Attrn : Valn]
=>
complex_term(Id, Attr1, Val1), ...,
complex_term(Id, Attrn, Valn).
29
Negotiation Framework
Protune-Prolog Translators (III)
[Id]allow( release( scard[
owner:“Maria”,type:“student”,
issuer:“Uni-Hannover”])):- L1, ...,Ln.
=>
rule(Id, allow(release(scard)), [L1, ...,Ln]).
rule(Id,complex_term(scard,owner,“Maria”),[L1, ...,Ln]).
rule(Id,complex_term(scard,type,“student”),[L1, ...,Ln]).
rule(Id,complex_term(scard,issuer,
“Uni-Hannover”),[L1, ...,Ln]).
30
Negotiation Framework
Policy Filtering
Bob
Bookstore
allow(download(“book.pdf”)).
allow(download(Resource)) ←
public(Resource).
‘book.pdf’
is not public
blurred(
)
What does authenticated
means?
blurred(
shared predicates
allow(download(Resource)) ←
authenticated(User),
hasSubscription(User).
authenticated(User) ←
credential(C),
C.type:’id’.
)
authenticated(User) ←
declaration([ user=User,
password=P ]),
passwd(User,P).
hasSubscription(‘Alice’).
hasSubscription(‘John’).
passwd(‘Alice’,’$1234ab3’).
passwd(‘John’, ‘8%%&ca’).
31
Policy Filtering
Relevant rules
policies contain general access control information, need to be
adapted for each client request
rules relevant for the client request are selected
allow(download(Resource)):public(Resource).
allow(access(Resource)) : −
authenticate(User),
has_subscription(User,Resource).
authenticate(User) : −
declaration( ad,
D[username : User,
password : Password]),
passwd(User, Password).
32
Policy Filtering
Partial evaluation
 information needs to be integrated in the
policy
 the policy must be instantiated
• credentials given by the other party
• results of executed actions
• results of calls to external modules
authenticated(maria) ←
declaration( ad,
D[user=maria, password=airam ]),
passwd(maria,airam).
33
Policy Filtering
Execute actions
 actions ready for execution are selected from
the policy => literal L
L.type : provisional_predicate.
L.evaluation : immediate.
L.actor : self.
 actions results are stored in the state
 if an action fails then the rule does not hold
not_revoked(creditcard).
34
Policy Filtering
Blurring
 policy may contain sensitive information necessary for
reasoning but which should hidden to the other party
 sensitive information in the policy must be blurred
 blurring = not giving the definition
passwd(User,Password).
=> blurred(predicate1( User, Password)).
log( File, Message).
=> blurred(predicate2( File, Message)).
 complete blurring if needed
not_blacklisted(C).
=> blurred1.
35
Policy Filtering
Peer actions
 actions that must be executed by the other
party = provisional predicates with actor peer
 peer actions are prefixed with a „do“ and sent
to the other party
allow(access(Resource)):do(register(“http://www.books.com/
register.php”)).
do(register(Url)).action:register_as_client(Url).
do(register(Url)).explanation:”You must
register as client at ${Url}”.
36
Policy Filtering
Explanations
 explanations defined for predicates and rules
in the policy are sent to the other party
 explanations are human understandable
statements
 blurred predicates may be explained
blurred(predicate1(maria,airam)).
predicate1(User,Password).explanation:
”The ${Password} is checked if it
matches that of ${User}.”
37
Policy Filtering
Rename Predicates
 usually name of predicates in the policy are
meaningful
 abbreviation predicates and state predicates
must be renamed
authenticate(User) => predicate1(User)
trusted_company( Company) =>
predicate2( Company).
38
Negotiation Framework
Filtering steps
Selecting relevant
rules
Partial evaluation
Selecting relevant
rules
Selecting relevant
rules
Blurring private
information
Selecting relevant
rules
Execute actions
Add information to
the policy
Partial evaluation
Anonymize
predicates
39
Negotiation Framework
Filtering module
for each
client request
a new session
is created
Filtering Module
Session
Local Policy
Client
Request
Filtering
process
State
Relevant
rules
the filtering
process for
the client
request is
done within
the session
40
Negotiation Framework
Interface to the filtering module
start_session( +SId, +Request)
add_to_state( +SId, +Literal)
filter_policy1( +SId, -ActionList)
Control
Module
filter_policy2( +SId,
+ActionResults, -ActionList)
Filtering
Module
filter_policy3( +SId)
41
Negotiation Framework
Credential Selection
 a filtered policy may
specify different
methods for getting
access to a resource/ a
service
Or
declaration(
ad, D[
user:U,
And
password:P])
credential(
cc, C[type:
creditcard,
issuer:’Visa’])
register(
‘http://www.
books.com/
register.php’)
 clients must identify
all the alternatives
they have and choose
the one it fits them
best
different strategies
(e.g, cautious ,fast)
42
Conclusions
Trust Negotiation
 Users may write their own policies
 Policies and credentials are exchanged
during negotiations
 Policies must be filtered before disclosing
them to the other party.
 Agents act on behalf of users to establish
trust
43
Conclusions
Thesis Contribution
• Extension of Protune syntax and specification
of its Prolog representation
• Extension of the filtering process applied on
policies and its implementation
• Development of Protune-Prolog translators for
policies and metapolicies
• Specification and implementation of the
interface for the filtering module
• Started work on credential selection
44
Thank you!
[(Questions & Answers) | Comments]*
45
Descargar

Slide 1