Exporting gssapi context, take two

[Nicolas Williams]

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

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.

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