Links

Home

Results

People

Publications

Software

Open Policy Language

An obvious issue that needs to be addressed is the form of the policy language that is used in the type system to express security policies. The problem is that any policy language will inevitably (and in fact fairly quickly) run into applications for which is it inadequate. For example, the JIF language incorporates a policy language based on sets of access control lists (ACLs), augmented with a form of delegation of principal rights. An obvious extension to consider for the JIF policy language is some form of role- based access control, including some notion of delegation of role-based rights. But even if one just considers the extension with role-based access control, there are many variations on RBAC that could be added. The RT family of languages by Li et al is a good candidate for such a policy language, since it appears to be the closest to a “universal” language for distributed RBAC (i.e., with delegation). But there are numerous variations in the RT family, and presumably more variations still to be proposed. Furthermore there are new policy languages being constantly proposed that go beyond RBAC and delegation, such as policy languages where principals share control of access to resources.

Rather than committing to a single policy language for all applications, an “end-to-end” approach would allow individual applications to define their own policy languages, or to choose from a library of possible policy languages. Rather than committing to a particular policy language in the type system, instead arbitrary policy languages could be loaded, as abstract data types, on a per-application basis. This approach has been used successfully in the past, in several applications: logical frameworks for theorem-proving environments, certified compilation environments and proof-carrying code, and proof- carrying authentication.

As part of the Jeddak project, we have been exploring an approach that combines two avenues of study:

  1. Type-based cryptographic operations that used typed APIs to relate the operations to the security properties they are intended to enforce across networks.
  2. Frameworks for defining languages and logics, particularly the approach of proof-carrying authentication.

As a demonstration of this approach, we have considered a particular policy language implemented as a library in such a framework. The policy language in question is chosen because it has two disparate implementations, involving quite different sets of cryptographic operations. This demonstrates the wisdom of moving the implementation of the policy language out of the language itself and into libraries. Not only does it appear impractical to expect a single universal policy language that will satisfy the needs of all applications, but it is also questionable if there is a single universal implementation of a policy language that matches all applications.

The policy language we consider is role-based cascaded delegation, which provides a limited form of role-based delegation motivated by the practicalities of distributed applications. In our framework, we can describe this as an abstract data type:

ccd1

One implementation of RBCD in our framework is using conventional delegation chains:

ccd2

Delegation chains carry a performance cost due to checking of the signatures in the credential chain. Hierarchical certificate-based encryption has been proposed as a way to avoid this checking and re-checking of credential chains, by allowing signatures to be composed. We can also model an HCBE implementation of RBCD in our framework:

ccd3

ccd4

This experiment demonstrates the applicability of our approach to open policy language implementations. Future work will address the use of this approach to ensure end-to-end security properties in distributed applications.