Re: Exporting gssapi context, take two

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

Nicolas Williams wrote:
> 
> On Wed, Apr 28, 2004 at 01:46:55PM -0500, Douglas E. Engert wrote:
> > Sam Hartman wrote:
> > >
> > > In a side discussion with Nico, he indicated that he wants the
> > > mechanism not to depend on special interactions with the glue layer.
> > >
> > > We may have incompatible requirements.  I'll send out a message later
> > > today exploring the space of possible options.
> >
> > One option is to define in the gssapi revised standards a routine
> > to return the underlying mech specific handle for the cred.
> >
> >  gss_get_mech_cred(OM_uint32 *minor,
> >                    const gss_cred_id_t oldcred,
> >                    gss_cred_id_t *mechcred,
> >                    gss_OID *mech)
> >
> > When implemented by a mech it would do *mechcred = oldcred;
> >
> > When implementred by a glue layer, it would call the underlying
> > mech's version of this routine, passing as the oldcred what it does
> > now with other other routines that need a cred.
> >
> > A application which needed to call a mech specific routine like
> > krb5_gss_*  that needed the cred, would first call gss_get_mech_cred
> >
> > Thus the application would work with or without a glue layer(s), and the
> > mech specific routine would always get the mech version of the cred.
> 
> There's three types of extensions we need to consider: generic,
> mechanism-specific and platform/implementation-specific.
> 
> Generic extensions should be based on generic extension objects defined
> by IETF (or other) specifications and identified by OIDs
> (runtime-typing, if you will).

I agree. And I really don't like the use of the mech specific interfaces. 
As it makes it harder to use arbitrary mechanisms if the application still
has to link in mech specific routines.  Although I don't see how one could
mandate not allowing them. There will be some cases that are missed.  

We should try and learn form experience and try and get a list of all the 
known mech specific routines that have ever been used! We might find
that many of these could be handled by new generic routines. The saving
of the delegate credential is a prime example.

> 
> I think the interfaces to mechanism-specific-but-platform-independent
> extensions should be platform-independent.  This is not a slam dunk
> argument for the runtime-typing approach (as I'm sure that Sam will
> point out), but it's a pretty good argument, I think.
> 
> And while this gss_get_mech_<object>() approach can work, whether the
> result is platform/inplementation-independent will depend on the
> interfaces that operate on the mechanism objects.  Also, the mechglue
> layer should do object handle validation and save the mechanisms the
> trouble of doing it too, but your proposal means that the mechanisms
> should do handle validation too.

But there may not be a mechglue layer, therefore each mech needs to 
do all the checks. 

> 
> I still prefer the other approach; I may end up compromising on this
> eventually, but I want to hear more about why one way is better than the
> other.
> 
> > There would be one of these routines for the context too.
> 
> Since the API and SPI correspond there are actually three objects you
> might want to do this for: names, creds, security contexts.

I forgot the names. Any others? 

> 
> > (It could be written to return the cred directly, ands thus could be used
> > in a macro.)
> 
> Use of macros for this sort of thing affects the ABI, so, no.  (See
> recent CAT WG list archives for more on this.)
> 
> Nico
> --

-- 

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