Certificate-Based Authorization Policy in a PKI Environment.
M. R. Thompson et al.
TISSec, November 2003


Setting: Research collaboratory with stakeholders and users from
different administative domains.  Kerberos an option, but is complex
when setting up cross-authenticated realms.  Establishing trusted CA
relationships in a PKI environment among several sites might also be
complex, but trust is given by individual resource provider rather than
whole site.

Idea: The authors describe a means for resource stakeholders to define
access control policies using X.509 certificates.  Their system, Akenti,
is designed so that only the basic policy information is stored at the
access point of a resource - i.e., the stakeholder's identity certs and
URL's of their use-policy certs.  This allows for a decentralized means
of controlling access, and doesn't require all controlling parties to
have access to the resource's server.

Assumptions: X.509 certs and SSL/TLS connection protocols are used to
securely authenticate users requesting resources - i.e., there are CAs
set up which initialize accounts, verify identities, issue certificates
and cross-authenticate with other CAs.  (I.e., most of the real
mechanism is already in place).

Basic Operation: Given the above assumptions, they have a 'pull' model
for verifying authorizations.  User contacts a 'resource gateway' (or
Policy Enforcement Point (PEP)) requesting access to a some resource and
providing their identity (X.509) cert.  PEP asks trusted Akenti server
(Policy Decision Point (PDP)) if user has access.  PDP finds all
relevent certs, verifies, and returns answer to PEP.  This pull model
allows user to make requests over standard TLS connections since only
his identity cert needs to be sent.

Specifying policies: three types of certificates for specifying policies
(1) policy certificates - includes stakeholders, acceptable CAs, URLs of
use-policy certificates, and possible URLs of where to find attribute
certs
(2) use-condition certs - each stakeholder must create at least one,
contains constraints which specify required attributes of a user and
principles that can attest to these attributes.
(3) attribute certs - contains attribute-value pair and principle to
whom it applies, must be signed by authority given in use-condition cert

Resources can be grouped into realms, both flat and hierarchical, not
very clear on how this should operate.

They provide a couple tools for helping make root policy certificates.

They built this into an Apache model and have the SSL module include the
identity certs when establishing a connection, and then showed with a
couple of experiments on an intranet with a couple stakeholders and a
couple attributes that not too much overhead is involved, especially
when certs are cached (duh).