Re: [kitten] Clarification of gss_add_cred() behavior

[Nico Williams <[e-mail]>]

Here's what I want (and which I always thought was a possible way to use
gss_add_cred()):

    /*
     * Build a cred handle one elment-at-a-time.
     *
     * Here some_name is a gss_name_t value other than GSS_C_NO_NAME,
     * and some_mech is a gss_OID value other than GSS_C_NO_OID.
     */
    maj = gss_add_cred(&min, GSS_C_NO_CREDENTIAL,
                       some_name, some_mech,
                       GSS_C_INITIATE, GSS_C_INDEFINITE, 0,
                       &new_cred,
                       NULL, NULL, NULL);
    if (maj == GSS_S_COMPLETE) {
        /* Yes!  I have a cred handle for {some_mech, some_name}! */
        ...

        /*
         * Now I can gss_add_cred() more elements to the brand-new
         * new_cred, one element-at-a-time.
         */
        maj = gss_add_cred(&min, new_cred, some_name, other_mech,
                           GSS_C_INITIATE, GSS_C_INDEFINITE, 0,
                           NULL, NULL, NULL, NULL);
        ...
    }

This would be a handy use-case when the caller wants to initiate a
security context as the same initiator principal as a previous time, and
with the same mechanism (think: SSHv2 re-key exchange with GSS), which
is useful when one wants to re-delegate a fresh credential for the same
initiator principal to some target.

Now, the text in RFCs 2743 and 2744 as to what happens when
input_cred_handle == GSS_C_NO_CREDENTIAL means that my some_name
desired_name must get ignored in the above code, which makes the above
not feasible at all.

But it's worse than that: I can't even use gss_add_cred() to get a
single-mechanism element credential handle if I don't already have one.
It means I can't really use gss_add_cred() without also first using
gss_acquire_cred().  Using gss_acquire_cred() at all is obnoxious when
you have a single mechanism that you want a credential for.

With the text as-is the only real use of gss_add_cred() is to function
as a would-be gss_duplicate_cred() when you ask for an
output_cred_handle.  But it's a rather difficult-to-use cred handle dup
function...

Nico
-- 

On Wed, Mar 18, 2015 at 09:52:02PM -0500, Nico Williams wrote:
> I think the answer is that this text in RFC2743 section 2.1.4, page 39:
> 
>    If GSS_C_NO_CREDENTIAL is specified as input_cred_handle, a non-NULL
>    output_cred_handle must be supplied.  For the case of
>    GSS_C_NO_CREDENTIAL as input_cred_handle, GSS_Add_cred() will create
>    the credential referenced by its output_cred_handle based on default
>    behavior.  That is, the call will have the same effect as if the
>    caller had previously called GSS_Acquire_cred(), specifying the same
>    usage and passing GSS_C_NO_NAME as the desired_name parameter
>    (thereby obtaining an explicit credential handle corresponding to
>    default behavior), had passed that credential handle to
>    GSS_Add_cred(), and had finally called GSS_Release_cred() on the
>    credential handle received from GSS_Acquire_cred().
> 
> and the corresponding and matching text in RFC2744 section 5.3, are
> subtly wrong.  [...]