Access Control Meets Public Key Infrastructure, Or: Assigning Roles to Strangers

Amir Herzberg,

Yosi Mass,

Joris Mihaeli,

Dalit Naor

and Yiftach Ravid

Summary:

The authors seek to build a web of trust system (Trust Establishment) that allows parties to establish trust relationships based on certificates of reference. In this system, trust is established in a “grass roots” manner meaning that there is not central root to the system. Presenting certificates that satisfy the rules specified in the trust establishment policy can verify an entity. The certificates themselves do not have any kind of access decisions; they merely present attributes of the entity requesting a resource. (Principal of Separation of Users from Authorization)

Within the TE system, there are 3 types of entities: owners – define the access policies for a resource; subject- an entity requesting access to a resource and issuers- issuers certificates to either subjects or other issuers.

The TE system has two mechanisms for handling missing certificates. The certificate presented by an entity can have a special attribute that is a pointer to additional certificates. This will work well when the entity wants these certificates to be found. In the case of negative certificates, the owner of the resource can supply a list of places to look for additional certificates. The certificate collector is responsible for locating the missing certificates either by looking in the database, or crawling the web to the repositories.

Trust Policy Language (TPL) – used to map entities to roles

Role:

· Group of entities that can represent specific organizational units,

· Has one or more rules defining how a certificate holder can become a member.

· Requesting entity only needs to satisfy one of the rules in order to join

Special features of TPL:

• Repeat attribute in the Inclusion Tag- allows writer to easily specify how many instances of a certificate must be available. Cuts down on the complexity of the rules
• Depth attribute in the inclusion tag – allows writer to specify the length of certificate chains allowed
• Exclusion tag – for negative certificates – need to define where to look for negative certificates in the Repository tag

Issues/Questions:

• Do you have to have the same public key for all certificates belonging to the same entity?
• Where do you put negative certificates? Who will want to host the negative information?
• Who verifies the repositories? How do you know that the certificates there belong to the same person?

Pros:

<contributed by Greg Koenig>

• Design

o The design is based on industry standards such as XML. I view this as positive for two reasons. First, it allows an existing, proven technology to be used rather than reinventing technology. Second, it allows existing tools to be leveraged against creating an implementation of the design.

o The system described in the paper "extends" existing security infrastructure but does not "depend" on it. This would enable the system described in the paper to be used much more readily than if it required organizations to completely discard existing solutions.

o The paper describes a nice orthogonal design in which the data in a certificate is separated from the security policy. As the authors of the paper explain, a certificate authority cannot always know in advance what authorizations a certificate will be used to grant or deny, so they propose a system that separates the authentication problem from the authorization problem. In my opinion, this is an important characteristic.

• Implementation
• They have one. It is easy to propose a system on paper, but actually implementing it often reveals areas that need further thought. They may not have a system that incorporates several different certificate formats, but they at least have something that they can use to demonstrate that their ideas do, in fact, work.

<contributed by Prasad Naldurg>

• The major contribution of the authors (IMO) is their proposal to tie in rust Management with RBAC.
• The authors discuss a bottom-up strategy to build a web-of-trust that des not rely on a global infrastructure and is therefore easier to set up ad deploy.
• The authors provide a syntax and semantics (partial in the case of full (L) to express the relationships between roles and public key certificates. They use XML to describe the syntax and Prolog for the semantics. Using general purpose languages adds to the usability of their solution. The authors also integrate their design into web browsers.
• The authors define a generic format or profile to accommodate for different types of certificates, adding flexibility and facilitating interoperability.
• They incorporate negative certificates in their design to reflect real-world situations.

Cons:

<contributed by Amir Behgooy>

• Flaws in the web-of-trust model
• e.g. If a trusted person, does a malicious act and certifies an unauthorized person.
• Loops
• Negative certificates haven't been clearly explained and can't be implemented in an efficient manner.
• What if a trusted person certifies someone who has received a negative certificate from another trusted person?
• Inheritance won't work

• Certificate management involves a lot of overhead (certificates expire, have to be renewed, updated...)
• Trust establishment is not widely accepted yet. Role Based Access Control (RBAC) systems have been receiving more acceptance so far.