gss_accept_sec_context failing after getting service ticket using service name and password

[Michael B Allen]

On Sun, 28 May 2006 22:36:39 -0400
Sam Hartman <hartmans at mit.edu> wrote:

>     >> > Is there a way > to convert from krb5_creds to gss_cred_id_t?
>     >> 
>     >> No, there isn't.
>     >> 
>     >> For Solaris Nevada we're looking at adding a mechanism-specific
>     >> gss_acquire_cred_from_ccache() GSS-API extension.
> 
>     Michael> At some point don't you just want to punt and use opaque
>     Michael> types? Using an import/export or inquire_by_oid kind of
>     Michael> interface implies the result can be represented in a
>     Michael> serialized form which is somewhat annoying.
> 
> 
> We've discussed this with regard to a similar issue in the kitten
> working group and concluded that at least for things we want to
> standardize, we always want to guarantee there is a serialized form.

Hi Sam,

For concepts that are shared by all implementations of authentication
mechanisms (e.g. credentials) a normalized interface is desireable
because there are fewer mechanism specific cases. Sure I agree with
that. But the ccache is not one of those concepts. Nor is a Windows PAC
or a session key used for protocol specific signing. GSSAPI works fine
if you're in the steady state (you have credentials) but there are a
number of issues associated with acquiring and managing credentials. If
you try to represent every concept of every mechanism the GSSAPI will
be overspecified. IMHO.

Having accessors that evaluate to opaque types does not reduce the
effectiveness of existing or yet to be conceived normalized APIs. So
why not provide them?

And realize that marshalling data to and from byte arrays is no different
from returning an opaque type except that byte arrays can only represent
primative types and they require needless allocation and copying.

Mike