PolicyMaker
PolicyMaker Presentation
PolicyMaker: “?”



Aim:- An attempt to solve the need to find a suitably
trustworthy copy of the public-key of someone with
whom one wants to communicate.
A language / tool in the development of services
whose main goal is privacy and authenticity.
A unified approach to specifying and interpreting
security policies, credentials, and relationships that
allows direct authorization of security-critical actions
Vishwas Patil, TIFR.
PolicyMaker Presentation
2/16
PolicyMaker: General Principles

Unified mechanism:- provides a common language for policies,
credentials, and relationships.

Flexibility:- succinctness, the framework accommodates the PGP &
X.509 certificates with trivial modifications.

Locality of control:- avoids the monolithic hierarchy of certifying
authorities.

Separation of mechanism from policy:- credentials
verification mechanism does not depend on credentials themselves or
the semantics of the applications that use them.
Vishwas Patil, TIFR.
PolicyMaker Presentation
3/16
PolicyMaker: Approach
1. Obtain certificates, verify signature, determine public2.
3.
4.
5.
6.
key of original signer.
Verify that certificates are unrevoked.
Find trust-path from certifiercertificate.
Extract name from certificates.
Database look-up for NameAction mapping.
Determine whether requested action is legal
according to local policy and then proceed.
Vishwas Patil, TIFR.
PolicyMaker Presentation
4/16
PolicyMaker: Approach Continued

Steps 1, 2, 3, 4 can be supported by a PKI.

nameactions mapping can represent as much of a
security risk as keynames, yet certificates don’t
help the application map names to actions.

trust management engine:- accepts requests,
certificates, local policy and satisfies steps 5 and 6.
Vishwas Patil, TIFR.
PolicyMaker Presentation
5/16
PolicyMaker: Approach Continued

PolicyMaker binds public-keys to predicates that
describe the actions they are trusted to sign for.

PolicyMaker’s ability to express security credentials
and policies without requiring the application to
manage a mapping between personal identity &
authority is especially convenient in systems that
include anonymity as a security requirement.
Vishwas Patil, TIFR.
PolicyMaker Presentation
6/16
PolicyMaker: Approach Continued

PolicyMaker provides ways to express conditions
under which an individual or an authority is trusted
and conditions under which trust may be deferred.

PolicyMaker allows implementations of standard
security policies and credentials developed for one
application to be reused in others.
Vishwas Patil, TIFR.
PolicyMaker Presentation
7/16
PolicyMaker: Architecture




Separates generic mechanism from applicationspecific policy.
It accepts as input a set of local policy statements,
a collection of credentials, and a string describing
a proposed trust action.
On evaluation of policy statements and credentials,
it can return either yes / no or additional restrictions
that would make the proposed action acceptable.
Can be integrated with application or run separately.
Vishwas Patil, TIFR.
PolicyMaker Presentation
8/16
PolicyMaker: Architecture Continued




Policies & credentials are defined in terms of
predicates (filters), associated with public-keys.
filters accept/reject action descriptions based on
what the holders of corresponding secret keys are
trusted to do.
In case of deferred trust, the extent to which trustedthird-parties are trusted can be specified.
Credentials themselves may also contain filters that
limit the actions their holder is trusted to perform.
Vishwas Patil, TIFR.
PolicyMaker Presentation
9/16
PolicyMaker: Architecture Continued




The form of action descriptions (action strings) is not
determined by or known to the system itself.
It is up to the application to generate & interpret the
strings and up to the filters to accept / reject them.
An application calls PolicyMaker after it has
composed an action string and determined the auth.
identifier from which the requested action originated.
PolicyMaker then determines whether the action
string is permitted according to the local policy and
credentials.
Vishwas Patil, TIFR.
PolicyMaker Presentation
10/16
PolicyMaker: Language




Basic function of a PolicyMaker system is to process
queries.
A query is a request to determine whether a
particular public-key (or their sequence) is permitted
to perform a particular action according to local policy
e.g. key1, key2,…… keyn REQUEST ActionString
ActionString are application-specific and their
semantics is determined by the applications that
generate and interpret them.
Vishwas Patil, TIFR.
PolicyMaker Presentation
11/16
PolicyMaker: Language






PolicyMaker processes queries based on trust
information contained in assertions.
assertions confer authority on keys.
Each assertion binds a predicate (filter) to a
sequence of public-keys (authority structure).
e.g. Source ASSERTS AuthorityStruct WHERE Filter
Source indicates the source of the assertion.
AuthorityStruct specifies the public-keys to whom
the assertion applies.
Vishwas Patil, TIFR.
PolicyMaker Presentation
12/16
PolicyMaker: Language Continued


Each assertion states that the assertion source trusts
the public-keys in the authority structure to be
associated with action strings that satisfy the filter.
Types of assertions: Certificates (signed assertions)
 Policies (unsigned) – just a special case of certificates.

On any given system, the set of local policies forms
the “trust root” of the machine and defines the
context under which all queries are evaluated
Vishwas Patil, TIFR.
PolicyMaker Presentation
13/16
PolicyMaker: Query Semantics



A query is a request for information about the trust
that can be placed in a particular (sequence of)
public key(s).
A PolicyMaker system must have at least one policy
assertion before it can process queries.
To process a query, the PolicyMaker system must
find a chain v1  v2  ···  vt in D (in which the
vertices => keys / policy sources & arcs => filters) in
which v1 is a local policy source and vt = k.
Vishwas Patil, TIFR.
PolicyMaker Presentation
14/16
PolicyMaker: Examples
policy
ASSERTS
pgp:”xyz123”
WHERE
PREDICATE=regexp:”
(From: vtp) &&
(Organization: PKI
Labs)”;
Vishwas Patil, TIFR.
pgp:”xyz123” REQUESTS
“From: vtp
Organization: PKI
Labs”;
pgp:”xyz123” REQUESTS
“From: bob
Organization: RSA
Labs”
PolicyMaker Presentation
15/16
PolicyMaker: Discussion


Advantages / Disadvantages
Evaluation: simplicity, expressiveness, generality,
extensibility
Vishwas Patil, TIFR.
PolicyMaker Presentation
16/16