Check out the new USENIX Web site. next up previous
Next: DisCFS over NFS Up: DisCFS Design Previous: System Architecture

Access Control in DisCFS

  Generally speaking, access control systems check whether a proposed action conforms to policy. An administrator specifies actions as a set of name-value pairs, called an action attribute set. Policies written in the KeyNote assertion language either accept or reject action attribute sets that the system presents to the policy engine (non-binary results are also possible). An administrator can break up policies and distribute them as credentials, which are signed assertions that he can send over a network. A local policy can then refer to the credentials when making its decisions. The credential mechanism allows for arbitrarily complex graphs of trust, in which credentials signed by several entities are considered when authorizing actions, as seen in Figure 2. An administrator can handle group-based access simply by issuing the appropriate credentials to all the group members. Furthermore, an administrator can create sub-groups at any level in the hierarchy.


  
Figure 2: Delegation in KeyNote, starting from a set of trusted keys. The dotted lines indicate a delegation path from a trusted public key (the administrator's) to the user making a request. If all the credentials along that path authorize the request, it will be granted. Intermediate credentials can only refine the authority granted to them (i.e., they can never allow a request that was denied by policy).
\begin{figure}
\begin{center}

\epsfig {file=policymaker.eps,width=3in}
\end{center}\end{figure}


  
Figure 3: Credential granting user miltchev (as identified by his public key, in the Licensees field) access to directory testdir. The 1024-bit keys and signatures in hex encoding have been omitted in the interest of readability.
\begin{figure*}
\begin{verbatim}
Authorizer: ''<Administrator's Public Key\gt''
...
 ...stdir''
signature: ''<Signature by Administrator\gt''\end{verbatim}\end{figure*}


  
Figure 4: Credential by user miltchev granting (delegating) user sotiris access to directory testdir for one day. Again, the keys and signatures have been omitted in the interest of readability.
\begin{figure*}
\begin{verbatim}
Authorizer: ''<Miltchev's Public Key\gt''
Licen...
 ... ''testdir''
signature: ''<Signature by Miltchev\gt''\end{verbatim}\end{figure*}

Figures 3 and 4 show two credentials that form part of a delegation chain in our system. The administrator issues a credential to user miltchev granting access to a particular directory. User miltchev then grants user sotiris access to the same directory during November 6, 2002. KeyNote allows this delegation because the authority granted to user sotiris is a subset of the authority of user miltchev . Notice that users are identified only by their public keys.

The advantage of using DisCFS is that an administrator no longer needs to have a priori knowledge of the user base. Thus, the system does not need to store information about every person or entity that may need to retrieve a file. DisCFS also provides its users with the ability to propagate access to the files by passing on (delegating) their rights to other users. In this way, users pass credentials rather than passwords, allowing the system to associate access requests with keys and to reconstruct the authorization path from the administrator to the user making the request (and thus grant access). The system may not know that Bob is trying to get at a file, but can log that key B (Bob's key) was used and that key A (Alice's key) authorized the operation. The administrator can then use this audit trail to validate that the access request follows the appropriate usage policy. Note that a user can at most pass on the privileges she holds (there is no rights amplification); furthermore, the user can choose to delegate only a subset of her privileges, e.g., access only to a specific file in the user's directory.


next up previous
Next: DisCFS over NFS Up: DisCFS Design Previous: System Architecture
Stefan Miltchev
4/8/2003