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

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. 

I think that the older DCE/DFS tried to address both of these situations,
i.e. having Kerberos credentials available for use by applications and by 
DFS via the kernel and PAGs. They did this by constraining the the 
KRB5CCNAME to be a file in /opt/dcelocal/var/security/dcecreds/krb5cc.XXXXXXXX
I may have the exact location wrong, but the idea is it was a well known 
location with XXXXXXXX being the DFS PAG number. This allowed DFS in the kernel
to use the dced process (or some helper process of the kernel) to get 
additional kerberos tickets to be used in the kernel. (I believe on AIX
each thread could have its own PAG, but my memory could be failing.) 

AFS did not have this problem, as the AFS token in the kernel was only acquired
once and there was no need for the kernel to need to acquire additional tokens
using credentials stored outside of the kernel. 

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.  

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. 
We need for gssapi to be able address both needs.   


Nicolas Williams wrote:
> 
> On Tue, Apr 06, 2004 at 01:19:08AM -0400, Jeffrey Altman wrote:
> > There is one cache associated with the LSA session.
> > A process or thread can create a new cache which is not
> > associated with the session.  However, it would be
> > inappropriate to use an environment variable in this case.
> >
> > Within the context of a logon session a krb5_ccache name is unique.
> > There is no guarantee that the krb5_ccache name will be unique across
> > the entire system.   Using an environment variable would certainly
> > fail in any situation in which you either had a single process (a
> > multi-threaded
> > server) in which each thread must maintain its own cache reference
> > or where the processes exist in different logon session spaces.  For example
> > a user process communicating with a daemon process.
> 
> You have just proven one of my points.  Thank you.  Perhaps this was not
> so off-topic after all :)
> 
> 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]

-- 

 Douglas E. Engert  <[email protected]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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]