Re: MEMORY credential cache interop between Heimdal and MIT?

[Michael B Allen <miallen@ioplex.com>]

On Thu, 16 Aug 2007 18:16:58 +0200
Love Hörnquist Åstrand <lha@kth.se> wrote:

> > The problem of a secure credential store can be separated into a few
> > independent concepts.
> >
> >  1. How storage is acquired is independent from the format of it's  
> > content
> >     [1].
> >  2. How storage is acquired is independent from the access control  
> > logic
> >     used to protect it.
> >  3. The format of storage content is independent from the access  
> > control
> >     logic used to protect it.
> >
> > That divides the problem into three parts which is considerably  
> > easier.
> >
> > Storage implementations might be based on one of the following:
> >
> >  o mmap(MAP_ANON)
> >  o Linux in-kernel keychain support
> >  o CCAPI on OSX or Windows
> >  o Windows LSA Routines
> >  o Disk file
> 
> Also add Heimdal's KCM and samba's winbindd (that today uses a FILE:
> but if there was a IPC mechanism, it could store it internally).
> 
> 
> > Note that these may not guarantee a complete implementation. Using
> > mmap will not allow spawned processes (as opposed to forked) to access
> > credentials that the access control logic would otherwise grant access
> > to. Using a disk file for Kerberos credentials would effectively be a
> > stub implementation that just called existing ccache routines. But the
> > point is that the storage implementation has been parameterized.
> >
> > Access control implementations might be based on one of the following:
> >
> >  o Process ID based logic
> >  o Windows ACL
> >  o UNIX file access control based in uid
> >  o Environment variable "secret" a la ssh-agent
> 
> Its good to be able to control access control based on the process-tree,
> and only enviroment variables supports that. But I wouldn't call  
> using env
> variables to provide security a very secure solution.

Hi Love,

The goal is not complete security. The goal is to parameterize storage,
access control and format so that implementations can use whatever
the host has to offer. The default behavior could be a pass-through
FILE cc implementation in which case we're no worse off than we were
yesterday. But it would be possible to introduce an implementation that
was relatively secure at a later time (e.g. an OS extension that used
in-kernel access control, encrypted memory, ... etc).

> > Again, you might not get a bullet proof implementation. An  
> > implementation
> > might use an environment variable set when a login shell was created
> > to pass a "secret" to spawned processes. Anyone with knowledge of the
> > secret is granted access to the credential store.
> >
> > Formats of object in storage is specific to the applications using it.
> > For Kerberos it seems a credential format exists. The ccache file  
> > format
> > may not be officially standardized but it is understood by both  
> > Heimdal
> > and MIT.
> 
> FILE cc needs to extended to support more features, so while it might
> be a good idea to use them in the short term, long term is would lock
> us in to old format.

Well if the format can be parameterized as I claim then migration to
a new binary format for Kerberos credentials should be possible while
maintaining binary compatibility.

Mike