Fw: Kerberos MIT on Solaris

[Will Fiveash]

On Tue, Aug 24, 2010 at 08:48:05AM -0500, Douglas E. Engert wrote:
> 
> 
> On 8/23/2010 7:17 PM, Will Fiveash wrote:
> > On Mon, Aug 23, 2010 at 03:46:31PM -0500, Will Fiveash wrote:
> >> On Mon, Aug 23, 2010 at 01:41:22PM -0700, Russ Allbery wrote:
> >>> Will Fiveash<will.fiveash at oracle.com>  writes:
> >>>
> >>>> Well, libkrb5 is supported in Solaris 10, however (as noted),
> >>>> Solaris libgss != MITKC libgssapi_krb5
> >>>> in regards to interfaces.  Really though, the point of libgss is to
> >>>> insulate a caller from the specifics of security mech used.  If the
> >>>> caller needs to do krb specific things then it should link with libkrb5.
> >>>
> >>> Assuming that your API split between libkrb5 and the GSSAPI interface is
> >>> similar to that in MIT, I don't believe there's any function in libkrb5
> >>> that is a substitute for gss_krb5_ccache_name.  But maybe on Solaris you
> >>> moved that function to libkrb5?
> >>
> >> It isn't supported in Solaris yet.
> 
> It may not have been supported, because Solaris does not use the concept of
> session based ticket caches, but instead tries to use the uid based cache
> in all cases. (Thus why would you ever need a gss_krb5_cache_name?)
> This is the same issue over  which I have argued with Nico for years, with
> sshd and login insisting on using /tmp/krb5cc_<uid> where as on other
> vendor's login and sshd will allow the use of multiple caches for the
> same uid.  That is why I had to write a pam_krb5_cache to trick sshd
> into using a session based cache. login/gdm are still stuck with using
> the default.

We (the Solaris krb dev. team) recognize that session based ccaches are
useful.  On the other hand Solaris has supported NFS sec=krb5* for a
long time with an implementation that requires a standard ccache name.
Supporting both NFSsec and session based ccaches in Solaris is more
complex than just supporting session based ccaches.  It is however on
our to-do list.

> > I'll expand on this a bit more.  Solaris libgss presents a security
> > mechanism neutral API whereas libgssapi_krb5 does not as evidenced by
> > the function name gss_krb5_ccache_name.  While I can understand why such a
> > function exists, it still violates the basic point of the GSS-API.
> 
> Or it points out the lack of functionality in the GSS-API. The gss_store_cred
> was a step in direction  of generic, but still did not allow the application
> to direct under what name the credentials would be stored.

No doubt there are proposals to extend the GSS-API (see
draft-ietf-kitten-gssapi-naming-exts-08.txt).  I will refrain from
making more comments about the appropriateness of extending the GSS-API
to allow a caller to specify the ccache name until I can study this
issue more.

-- 
Will Fiveash
Oracle
http://opensolaris.org/os/project/kerberos/
Sent using mutt, a sweet text based e-mail app: http://www.mutt.org/