Fw: Kerberos MIT on Solaris

[Douglas E. Engert]

On 8/27/2010 10:59 AM, vir vir wrote:
> Hi,
>
> On Solaris  9 with MIT 1.8.2 version
> when I use ktutil
> and then try ktutil:  addent -password -p username at ADS.IU.EDU -k 1 -e rc4-hmac

Sounds like the Solaris 9 ktutil in in your path before the MIT 1.8.2
version.

>
> I got an error saying the addent Unknown request "addent"
> Do you know why I don't have support for addent on Solaris 9?
> On Solaris 10 everything works fine
> Thanks.
>
> --- On Tue, 8/24/10, Will Fiveash<will.fiveash at oracle.com>  wrote:
>
>
> From: Will Fiveash<will.fiveash at oracle.com>
> Subject: Re: Fw: Kerberos MIT on Solaris
> To: "Douglas E. Engert"<deengert at anl.gov>
> Cc: krbdev at mit.edu
> Received: Tuesday, August 24, 2010, 12:49 PM
>
>
> 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.
>

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444