Decentralized Access Control:

Overview

Deepak Garg

Foundations of Security and Privacy
Fall 2009

   
 What is Access Control?

“Access control” refers to enforcement 
mechanisms that control users' access to 
resources in computer systems

   
 Example: Access Control Via Locks
Alice

  The door controls access to the contents of the house
 
 Example: Access Control Via 
Passwords
Alice

Username: alice
Password:************

The website controls access to Alice's
account information
   
 Access Control: General Picture

Policy
Username: alice
Password:************

Request Reference
Principal to perform Monitor Resource
operation (Guard)

Enter house
Check bank balance

   
 Other Examples
● File System:
– Reference Monitor: Kernel
– Policy: rwxrwxrwx
● Gmail:
– Reference Monitor: Gmail's web server
– Policy: Allow access only with password
● ACM Digital Library:
– Reference Monitor: ACM's web server
– Policy: Allow access to CMU's members
   
 The Two Problems for the Guard
Policy

Request Reference
Principal to perform Monitor Resource
operation (Guard)

● Authentication: Identify the “Principal” making a request
● Authorization: Using policy decide whether or not to 
allow access
   
 Authentication and Authorization

Policy

Request Authentication Authorization

Principal to perform Who is requesting  Should Alice
operation access? be allowed access?

Yes

Reference Monitor

Resource
   
 Centralized vs Decentralized
● Centralized
– Think local files, operating system
– Requesting principal and reference monitor on one 
machine
– Policy is on the same machine
● Decentralized
– Think AFS, internet
– Principal and reference monitor may be separate 
(gmail, online bank accounts)
 
– Policy may be distributed (e.g., ACM Digital Library)
 
 Plan for the Lecture (and Next)
● Methods for authentication
● Representation of policy
– In line with code
– Access control matrices
– Access control lists
– Rule­based policies
● Policy distribution through certificates
● Public Key Infrastructures (PKIs)
   
 Authentication

   
 Authentication
● Identify which principal makes a request
● Issue 1: How do we name principals?
– Operating system: uid (users), pid (processes)
– Gmail: usernames
– Bank's website: account number
– Public keys
● Issue 2: Identify the principal in each request
– Usually based on some secret
   
 Authentication via Secrets
● Username and password based:
– Principal provides username and password
– Reference monitor (or authenticator) compares with 
an internal table
– Match => authenticate as username
● Challenge­response
– Reference monitor provides nonce to principal
– Principal signs nonce with private key
– Authenticate as owner of the verification key
   
 Authentication via Secrets
● Authentication with long­term secrets
– Principal and reference monitor exchange a shared 
secret ahead of time
– Every request signed/accompanied by secret is 
implicitly authenticated, e.g., cookie based logins 
(gmail)

Authentication is a well­studied problem
that is relatively easy to solve using 
secret keys or passwords
   
 Representation of Policies

   
 Centralized Policies
● Represent in Code
if (getuid() == 0)
    allow_access = true;
else if (getuid() > 1000)
    allow_access = false;
else 
...
● Mixes policy and its use
● Difficult to change or update policy
– Change millions of lines of code to change the uid 
 
of root from 0 to 1  
 Centralized Policies
● Represent in Code
if (getuid() == 0)
    allow_access = true;
else if (getuid() > 1000)
    allow_access = false;
else 
...
● Mixes policy and its use
● Difficult to change or update policy
– Change millions of lines of code to change the uid 
 
of root from 0 to 1  
 Centralized Policies
● Access control matrices                 [Lampson'71]
– Function: Principals x Resources ­> Permissions

Alice Bob
foo.txt rw r
/usr/bin/emacs rwx rx

/afs/user/Alice/bin
● Access control lists
Alice: rldwika
– Store relevant policy with object Bob: rl
All users: l

   
 Decentralized, Rule­Based Policies
● In web­based applications, and in ERM, parts of 
policies are often rule­based and decentralized
● E.g., Acess to the ACM Digital library
– ACM's statement: If university U has a 
Decentralized

subscription, and M is a member of U, then M 
has free access
Rule
– ACM's statement: CMU has a subscription
– CMU's statement: Alice is a CMU student
– Result: Alice has free access to ACM Digital 
  Library  
 Decentralized Policies

Server1 Server2 Server3

Policy1 Policy2 Policy3

Request Reference
Principal to perform Monitor Resource
operation (Guard)

● There is a delegation of trust (e.g., ACM ­> CMU)

   
Comparison of Policy Representation

In line with code
Difficulty of programming

Difficulty of training

Formal Rigor

Flexibility
Access control matrices/lists

Rule­based, decentralized

   
 Policy Distribution
Through Certificates

   
 Decentralized Policy Distribution
● Individual administrators (e.g., CMU and ACM) 
represent policies in certificates
● Certificate = statement + digital signature
● Certificates are also called credentials

Alice is a member of CMU
Signed
For all U, M. CMU
((U has a subscription) and
(M is a member of U))
imply (M has free access)
CMU has a subscription
Signed
ACM Signed
ACM
   
 Example of Distributed Access
Download paper.pdf ACM

Prove that you are a
member of CMU

Inference:
paper.pdf Check certificate.
Certificate missing!
Inference:
Allow access

   
CMU
 Certificate Verification and Inference
Download paper.pdf ACM
Certificate verification 
Prove that you are a
member of CMU and inference are 
very important

Inference:
Certificate verification 
paper.pdf Check certificate.
Certificate missing!
Policy rules and facts  Inference:
Allow access
are authentic

Inference
Deduce permissions
from rules and facts

   
CMU
 Issue 1: Policy Languages
● What language is used to write policy 
statements and infer permissions from them?
For all U, M.
((U has a subscription) and
(M is a member of U))
imply (M has free access)
● Principled approaches: Signed
ACM
– Declarative Languages
● E.g., RT, SecPAL, 
Cassandra, Binder Next lecture
– Logics
 
● E.g., ABLP, GP, BL  
 Issue 2: Search for Credentials
● How are relevant credentials collected at the 
reference monitor (e.g., ACM)?
– Collect based on request and known policy; often 
called credential or certificate chain discovery
[Clarke et al, Li et al]
– Requester (e.g., Alice) collects and provides to 
reference monitor
We'll make 
this assumption
● Choice depends on application (Details in next
    lecture)
 Issue 3: From Keys to Identities
● How are credentials checked?
● Reference monitor must verify signatures on 
them (to eliminate fake credentials), and make 
sure they are signed by expected individuals' 
keys.
● How is the mapping from keys to individuals' 
identities determined?
– Public key infrastructures 

   
 Summary of Decentralized Policies
● Policy statements (rules, facts) are created by 
different individuals
● Statements are placed in certificates, which are 
signed
● At the time of access, relevant certificates must 
exist at the reference monitor; they are verified
● Inference is performed over the statements in 
the relevant certificates, to allow or deny access

   
 Public Key Infrastructures

   
 Public Key Infrastructure: Overview
● Public Key Infrastructure (PKI) is a framework 
(methods, protocols, formats, programs) for:
– Generating private, public key pairs (optional)
– Distributing public keys (essential)
– Creating certificates, signing them, and verifying 
them (optional)
● Standards: X.509, PGP, SDSI/SPKI
● Implementations: Verisign, GnuPG, OpenSSL

   
 The Three Components of a PKI
● Programs for (private, public) key­pair 
generation Standard cryptography

● Distribution of public keys:
– Establish trustworthy mappings from public keys to 
principals (individuals)
Rest of the lecture

● Formats to represent text, binary certificates; 
programs to sign and verify them Implementation level
   
details
 Problem: Map Keys to Principals
● The problem with naïve distribution:
– Alice generates a (private, public) key­pair
– Distributes public key it on the internet
– Mallory (the bad one!) takes public key; gives to 
ACM as her key
– ACM believes that every signature made by Alice is 
made by Mallory

When should ACM trust a (key, principal) mapping given to it?

   
 PKI with Certifying Authority
● A central, certifying authority (CA) trusted by 
everyone certifies keys
● CA's public key is known to everyone, say 0xa
● CA signs associations (public key, principal) 
with its private key only after it verifies that this 
is the case
● CA's certificate manifests trust in the mapping
● E.g., X.509 (standard); VeriSign (commercial)
   
 Example: Certifying Authority
ACM

Signed Check certificate
0xa with 0xa.
Okay, 0xb ­> Alice

Certify 0xb CA
Public key (0xa);
Well­known

Signed
0xa Key map: (0xb, Alice)
Signed
0xa
   
 PKI with Web of Trust
● No CA; trusted peers certify keys (web of trust)
● Example
– ACM knows CMU's public key
– CMU certifies (0xb, Alice)
– If ACM trusts CMU, then CMU's certificate 
will imply that ACM trusts the map 0xb ­> 
Alice
– Alice may now certify Bob's key, etc.
● E.g., PGP (standard); GNUPG (implementation)
   
 Example: Web of Trust
ACM

Signed Check certificate
0xa with 0xa.
Okay, 0xb ­> Alice

Certify 0xb Trusts
CMU
Public key (0xa)

Signed
0xa Key map: (0xb, Alice)
Signed
0xa
   
 PKI with Local Names
● In a Web of Trust, peers (e.g., CMU) are trusted to 
name others
● What if namespaces are distinct? ACM and CMU may 
not call the same person Alice
● If CMU (0xa) certifies (0xb, Alice), then ACM should 
not believe 0xb ­> Alice
● Instead, ACM believes 0xb ­> CMU.Alice
● CMU.Alice is a name that represents the principal 
whom CMU calls Alice
● E.g., SPKI
   
 Example: Local Names
ACM

Signed Check certificate
0xa with 0xa.
Known: 0xa ­> CMU
So, 0xb ­> CMU.Alice

Certify 0xb Partial trust
CMU
Public key (0xa)

Signed
0xa Key map: (0xb, Alice)
Signed
0xa
   
 Summary of PKI
● PKI with certifying authority
– Trusted authority certifies (key, principal) maps
– Most common model
● PKI with web of trust
– Trusted peers certify (key, principal) maps
● PKI with local names
– Allow disjoint namespaces; learn associations up to 
relative names
   
 Take­Home Points
● A reference monitor decides whether to allow access
– Authentication: Who is requesting access?
– Authorization: Does the policy imply access?
● Decentralized policies are often rule­based; 
represented with certificates
● For each request, the reference monitor must:
– Collect and verify relevant certificates
– Infer permissions from the certificates
● Reference monitor must know mapping from public 
keys to individuals' identities – use a PKI