Re: [OT] Re: GGF's extensions to GSS in Public Comment

On Tue, Apr 06, 2004 at 10:19:12AM -0500, Douglas E. Engert wrote:
> There seams to be a more underlying problem here, and that is how 
> to store credentials to be used by the kernel for uses like 
> NFSv4, AFS, DFS or even IPSEC. The problem gets tied in with what AFS 
> and DFS call a Process Authentication Group (PAG) which is a way of 
> associating processes which share credentials in the kernel.  
> 
> Nico appears to be arguing that there is a credential store capability
> that a process is running under that gssapi needs to be able to store into,
> where as the GGF is saying, there is not such a credential store
> and each mechanism has its own way to store credentials and a process may 
> have multiple sets of credentials available, and that gssapi needs to
> be able to store delegated credentials in such a way that they can be used
> by gss_acquire_cred in a child process. These are not inconsistent, see below. 

[...]
> The GGF gss_export_cred returns a string suitable to be used by putenv.
> But this does not mean that it has to be a file name, it is a URL that can be
> used by the gssapi in subsequent processes to locate credentials.
> On a system where credentials are handled by a credential manager, the URL could 
> even be ignored.  

Doug, this does not address the issues with the use of environment
variables in GSS_Export_cred().

> I don't think we are that far apart. We need to look at the larger picture of
> how credential management can be done by the operating system, so credentials
> can be used by the kernel as well as used by the application. We also need
> to realize that an application may be using multiple credentials for its
> own purposes i.e. SSL, TCP where the kernel isn't involved at all. 

GSS_Store_cred() does not care what sort of credential store you're
storing into -- GSS_Store_cred() assumes there's a "current" credential
store available when it is called.

> We need for gssapi to be able address both needs.   

I think GSS_Store_cred() + GSS_Get/Set_current_cred_store() proposal
covers both needs.  The GSS_Get/Set_current_cred_store() proposal needs
more text to cover this, but I'm convinced it can cover your needs.

If you don't care about the user-land+kernel vs. user-land-only
distinction then GSS_Store_cred() may be all you need.

Nico
-- 
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email protected]