Re: [kitten] Clarification of gss_add_cred() behavior

[Nico Williams <[e-mail]>]

On Thu, Mar 19, 2015 at 07:57:20PM +0000, Viktor Dukhovni wrote:
> On Thu, Mar 19, 2015 at 03:50:22PM -0400, Benjamin Kaduk wrote:
> 
> > >     2. For this interface to be useful, the initial state one must
> > >        be able to start with an empty credential handle and build up
> > >        from there.  This presumably is specified via a NULL input
> > >        credential, and still the same name for which one wants
> > >        creds.
> > 
> > There is GSS_Acquire_cred to obtain the first credential element.
> 
> So I believe that you're saying that gss_add_cred() not intended to
> be able to add the *first* credential element.  That is:
> 
>     1. Always call gss_acquire_cred() with a singleton mechanism
>        set (to get the first mechanism) and desired name.
> 
>     2. Then, as appropriate, call gss_add_cred() for any *additional*
>        mechanisms.
> 
> This makes the API more unpleasant to use, [...]

Decidedly more unpleasant.

BTW, nowhere in RFCs 2743 and 2744 does it say that the minor_status
output of GSS_Acquire_cred() corresponds to the one mechanism in
desired_mechs when there is just one mechanism in it.

But clarifying which mech the minor_status is for is one of the reasons
given for GSS_Add_cred()'s very existence.

Another reason given for GSS_Add_cred() is to support iterative
construction of credential handles, but no mention is made of having to
use GSS_Acquire_cred() to acquire a seed handle.

>                                     [...], but sounds plausibly
> consistent with the text...

I'm not sold on that yet.  First, see above as to spec self-inconsistencies.

Second, implementations seem to disagree:

 - MIT -> input_cred_handle == default -> allocates a new cred, honors desired_name;
 - Illumos -> same as MIT;
 - Heimdal -> input_cred_handle == default -> error;
 - GNU GSS -> not implemented, returns GSS_S_UNAVAILABLE;
 - gsskrb5 (Martin's SSPI shim) -> not implemented, returns GSS_S_FAILURE;

 - Illumos kgss (for RPCSEC_GSS) implements an unused kgss_add_cred() by calling
   up to gssd, which calls the one described above;

 - FreeBSD kgss (ditto) does not implement gss_add_cred() (nor kgss_add_cred());

 - Linux kernel gss: does not implement any GSS functions dealing with creds,

but clearly the behavior you (Viktor) and I prefer cannot be surprising:
because if gss_add_cred() does anything other than fail, then it's doing
what you and I want.

Second, the "pleasant" behavior is clearly better.  Sure, one can't rely
on it, but then, neither could one rely on the default credential
behavior, and that behavior always errors out in Heimdal, GNU, and
gsskrb5.

Incidentally, are there other implementations to check?  I don't think
so.  I think I've checked all the open-source ones (even "PGSSAPI",
which also doesn't implement gss_add_cred()).  I know of none that are
not open source other than Solaris' (whose lineage is the same as
Illumos').

Nico
--