Re: MEMORY credential cache interop between Heimdal and MIT?

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

On Wed, 15 Aug 2007 16:30:41 -0400
Jeffrey Altman <jaltman@secure-endpoints.com> wrote:

> Michael B Allen wrote:
> > [I'm CC'ing kitten because I think this is probably the #2 issue with
> > GSSAPI for me.]
> > 
> > On Wed, 15 Aug 2007 12:16:53 -0700
> > "Henry B. Hotz" <hotz@jpl.nasa.gov> wrote:
> > 
> >>> Is there a way to make the MEMORY credential cache work in such a
> >>> mixed Heimdal/MIT setting?
> >>>
> >>> Many thanks,
> >> I seriously doubt it, but if someone can say how I'd be really  
> >> interested.
> > 
> > The memory ccache is hanging off of a private symbol called mkt_head
> > which is specific to the Heimdal libraries. No doubt MIT's has something
> > similar but neither library has access to the others memory keytab chain.
> > 
> > This is actually a fundamental problem with authentication mechanisms in
> > general. It get's into the issue of how to manage credentials. Currently
> > Kerberos uses disk files. That is clumsy and in some cases downright
> > insecure. I have personally concluded that the proper solution is for
> > the OS to provide a secure storage mechanism where a library can put
> > arbitrary data that can by accessed using a key such as a simple number
> > or preferably a string (e.g. 'krb5:MEMORY:') that may be accessed ONLY
> > by the same pid or by a descendant (i.e. the storage is inherited).
> > 
> > I'm not sure if this can be done entirely in userspace but if it could
> > that would be an interesting project. Then you could have MEMORY: ccache
> > and keytab interoperability and get around a lot of ugly environment
> > variable / file hacks.
> > 
> > Mike
> 
> Kitten is inappropriate because your issue is with mechanism
> implementation and not the GSS API.

Hi Jeffrey,

GSSAPI needs a way for users to specify a credential store. The in-memory
credential store issue has implications on that.

Also, I'm a little disappointed with your position. GSSAPI is used almost
exclusively by applications to implement Kerberos authentication. So even
though Kerberos isn't mentioned in the kitten charter, the decisions
you make here greatly affect the performance of Kerberos capable
applications.

> MEMORY ccaches are per process.  Are you really attempting to mix both
> Heimdal and MIT kerberos within the same process?

Absolutely. I didn't start this thread.

Imagine a web server DSO module that implements HTTP authentication using
Heimdal. Other libraries that can initiate Kerberos authentication such
as PostgreSQL, cURL and LDAP are may be linked with MIT Kerberos. So
how does one write a web script that uses the Heimdal authenticated web
client's credential to authenticate with another tier using one of the
modules linked with MIT Kerberos? If you put the delegated credential
into a ccache file owned by the web server, worker processes have access
to all credentials which is a potential security hazard. It would be
superior to place credentials into storage that is properly protected
by the OS (e.g. by process group, by secret key, by something in the
users security context, etc).

All of this should be considered when designing an API for credential
management.

Mike

-- 
Michael B Allen
PHP Active Directory Kerberos SSO
http://www.ioplex.com/