Re: [kitten] Clarification of gss_add_cred() behavior

[Benjamin Kaduk <[e-mail]>]

On Thu, 19 Mar 2015, Nico Williams wrote:

> On Thu, Mar 19, 2015 at 08:20:18PM -0400, Benjamin Kaduk wrote:
> > On Thu, 19 Mar 2015, Nico Williams wrote:
> > > GSS_C_NO_NAME.  But then I can never use GSS_Add_cred() to acquire a
> > > signle-element credential, and I must always use GSS_Acquire_cred() for
> > > that (which is lame for several reasons).
> >
> > Perhaps I'm just being slow today, but could you say more about what these
> > reasons for lameness are?
>
> Sure:
>
>  - the need to construct an OID set of one OID is lame (this is easy
>    when one has only one or known-fixed-at-compile-time number of OIDs,
>    but it's still lame)
>
>  - minor_status is not associated with any mechanism per the specs,
>    though one hopes that for the one-OID case minor_status is specific
>    to that one mechanism, but if we're going to be as literal as we can
>    in reading the spec, then this point is correct and
>    GSS_Acquire_cred() is lame
>
>  - fewer informative outputs (initiator and acceptor lifetime rec)
>
>    (admittedly this one is not a big deal)
>
> The second is the real killer.  It's one of the reasons given for the
> addition of GSS_Add_cred().  And if we interpret the spec as you
> propose, we can't have this feature.  This is one reason to think that
> the spec is self-inconsistent.

Thanks.
Yeah, that definitely counts as "lame" :)

> Other reasons to think the spec is self-inconsistent:
>
>  - No information or pseudo-code or code is given showing how to
>    iteratively construct credential handles.  It probably wasn't thought
>    through.
>
>    But if the case of input_cred_handle == GSS_C_NO_CREDENTIAL &&
>    desired_name != GSS_C_NO_NAME is interpreted as I propose, then it's
>    trivial to iteratively construct a credential handle.
>
>  - It makes no sense anyways to ignore a non-default desired_name when
>    the input_cred_handle is GSS_C_NO_CREDENTIAL, not in light of the
>    fact that GSS_C_NO_NAME is how one refers to the default credential
>    in GSS_Acquire_cred() calls.
>
>  - In some places input_cred_handle is described as optional.  Well, but
>    GSS_C_NO_CREDENTIAL -> ignore desired_name means there's no real way
>    to signal "I'm not providing an input cred handle", therefore it's
>    either not optional, or the text I say is wrong is wrong.

I will need to find a chunk of time to digest all of the relevant pieces
of 2743; it may not happen until after Dallas.

> The RFC text I quoted as broken does not reflect reality for an
> implementation of the C bindings that I could check.  I don't think
> anyone is proposing to implement the text I quoted.  That leaves three
> choices:
>
>  - file an erratum
>  - publish an update
>  - do nothing (anyone who runs into this will hopefully find this thread)
>
> I will not be submitting an I-D to update the RFCs just for this.  If we
> have no consensus for an erratum, and no one else volunteers for the
> update, then it's the third choice: do nothing.

I really hope it doesn't end up as "do nothing", but time will tell.

-Ben