Re: multi-mechanism gssapi

[Luke Howard <lukeh@PADL.COM>]

>One of the other issues with the application calling mechanism-specific
>APIs has to do with passing of the context or cred. If there is a mechglue
>it will most likely have defined its own structure for the contect or
>cred, which contain pointers to the underlying context or cred for all
>the mechanisums it is fronting. The mechglue would then take care of
>passing the correct context or cred. But if the application bypasses the
>mechglue what does it pass for the contect or cred?
>
>How do you plan on handling this?

We solved this using the GGF API to punch through the glue context.
eg.

OM_uint32
gss_krb5_compat_des3_mic(OM_uint32 *minor_status, gss_ctx_id_t ctx, int on)
{
    char buf[1];
    gss_buffer_desc value;

    buf[0] = on ? 1 : 0;
    value.length = 1;
    value.value = buf;

    return gss_set_sec_context_option(minor_status,
                                      &ctx,
                                      GSS_KRB5_COMPAT_DES3_MIC_X,
                                      &value);
}

>Your example of getting the name of the credentials store is one that
>the GSI ran into. Rather then calling mech specific routines the
>GGF GSSAPI extensions added the  generic gss_export_cred that  could return
>a handle to the  stored credentials, suitable to be used with putenv. i.e.
>With Kerberos it would return  "KRB5CCNAME=FILE:/tmp/krb5cc_uid" or whatever
>is the handle for the cache. With the GSI it would return "X509_USER_PROXY=/tmp/..."

NOted, but not yet implemented.


-- Luke

--