Exporting gssapi context, take two
kwc at citi.umich.edu
Tue Apr 27 12:55:54 EDT 2004
> > I've run into a couple of issues implementing the krb5_gss_set_allowable
> > _enctypes() function.
> > First, the call to gss_acquire_cred, to get the cred handle, is going
> > through the mechglue layer which returns a handle to the mechglue's
> > union_cred, not a Kerberos cred handle. This requires a glue function
> > for set_allowable_enctypes() to translate from the union_cred handle to
> > the Kerberos handle.
> Are you saying that the krb5_ specific code is calling gss_acquire_cred?
> It should not have to do this, as internal to the mech the cred should
> be available. gss_init_sec_context has to do something similiar, so
> look at the code to see how it gets the cred if its not supplied by the
The krb5 specific code in my application (gssd) was calling
gss_acquire_cred then krb5_gss_set_allowable_enctypes.
I could call krb5_gss_acquire_cred directly instead (since
I'm already calling a mech-specific routine). I'll try that.
Is that reasonable?
> If this in needed at the gss level, it should then be part of the
> standard. Then you also have to deal with what how other mechs deal
> with encrypt types.
Yeah, I was trying to avoid this.
More information about the krbdev