Re: Exporting gssapi context, take two

["Douglas E. Engert" <deengert@anl.gov>]

Kevin Coffman wrote:
> 
> > > 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
> > caller.
> 
> 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?

Could be. It sounds like there is a more general problem here if you
are calling mech specific routines and are also using some type of
mechglue. Your application needs to treat the cred handle and contxt handle
as opaque, and the mech specific routine should have no knowledge of the 
mechglue layer. So your approach of adding a gss_set_allowable_enctypes
at the mechglue layer is not so bad. Maybe a a set of glue functions or macros 
for the cred and context handle would make sense. 

 gss_cred_id_t gss_glue_map_context(gss_cred_id_t cred);

  returns the cred, or returns the cred from the glue union_cred. 

then ues it like: krb5_gss_set_allowable_enctypes(*minor,
			gss_glue_map_context(cred)....  

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

Yes, either way is not pretty. 

> 
> _______________________________________________
> krbdev mailing list             krbdev@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev

-- 

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