PolicyMaker

1. PolicyMaker

2. 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.

3. 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.

4. PolicyMaker: Approach • Obtain certificates, verify signature, determine public-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.

5. 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.

6. 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.

7. 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.

8. PolicyMaker: Architecture • Separates generic mechanism from application-specific 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.

9. 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 trusted-third-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.

10. 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.

11. 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. • ActionStringare application-specific and their semantics is determined by the applications that generate and interpret them. key1, key2,……keyn REQUESTActionString Vishwas Patil, TIFR.

12. 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 indicates the source of the assertion. • AuthorityStruct specifies the public-keys to whom the assertion applies. SourceASSERTS AuthorityStruct WHEREFilter Vishwas Patil, TIFR.

13. 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.

14. 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.

15. policy ASSERTS pgp:”xyz123” WHERE PREDICATE=regexp:” (From: vtp) && (Organization: PKI Labs)”; pgp:”xyz123” REQUESTS “From: vtp Organization: PKI Labs”; pgp:”xyz123” REQUESTS “From: bob Organization: RSA Labs” PolicyMaker: Examples Vishwas Patil, TIFR.

16. PolicyMaker: Discussion • Advantages / Disadvantages • Evaluation: simplicity, expressiveness, generality, extensibility Vishwas Patil, TIFR.