[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MEMORY credential cache interop between Heimdal and MIT?

[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.


Michael B Allen
PHP Active Directory Kerberos SSO