Re: [kitten] Clarification of gss_add_cred() behavior

[Nico Williams <[e-mail]>]

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.

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.

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.

Nico
--