[OpenAFS-devel] Re: [security-discuss] Re: [OpenAFS] Hardware Grants from Sun

[Nicolas Williams]

On Mon, Feb 26, 2007 at 02:33:06PM -0500, Jeffrey Hutzelman wrote:
> On Sunday, February 25, 2007 04:21:45 PM -0600 Nicolas Williams 
> <Nicolas.Williams@sun.com> wrote:
> 
> >A while back I designed such an API, which I called the generic
> >credential store API (GCS-API) that provides a way to get a handle to
> >the current credential store for a given thread, process, session or
> >user, a way to associate a credential store handle with a thread,
> >process, session or user, a way to list the credentials references in a
> >store, and so on.
> 
> Note that while you can do that, it doesn't actually answer AFS's need, 
> which goes beyond merely storing credentials.  We also have to be able to 
> associate a PAG(*) with cached connection state and access control data, 
> which is threaded through other data structures in a way we can't easily 
> change for each platform.  That means it's necessary for each PAG to 
> actually have a unique, long-lived, unforgeable identifier.

The putative GCS-API uses a PAG -- a locally unique, 64-bit,
no-reusable, unforgeable ID.

> (*) "PAG" is short for "Process Authentication Group".  Some people are 
> apparently confused about what this means, so I thought I'd try to clarify 
> up front -- a PAG is a set of processes, not a place to store credentials. 
> AFS does track credentials on a per-PAG basis, but the essential thing we 
> need from an OS is not a credential store; it's a way to obtain the 
> identifier for the PAG to which a given process belongs.

The point of the API in question is not that it stores credentials but
that it allows credentials for more than one mechanism to be associated
with a PAG -- the problem, as I see it, with OpenAFS PAGs is the way
they are used: too closely linked to Kerberos.

Nico
--