Re: [kitten] Clarification of gss_add_cred() behavior

[Benjamin Kaduk <[e-mail]>]

On Thu, 19 Mar 2015, Viktor Dukhovni wrote:

> On Thu, Mar 19, 2015 at 02:48:44PM -0400, Benjamin Kaduk wrote:
>
> > > I think this must have been a drafting error.  It's obvious to me, but
> > > maybe someone has a very different opinion as to this (Martin?).
> >
> > But a GSS credential can only represent a single identity ("entity", see
> > 1.1.1.1)!  Identities are represented by (non-mechanism) names, so it is
> > not clear to me that this is a drafting error.  If you know what name you
> > want credentials for, you should use it.
>
> The situation as I understand it is as follows.
>
>     1. gss_add_cred() is intended to build a credential handle
>        *incrementally*, adding credentials one mechanism at a time.
>        Either for a default name, or for an explicit name that
>        agrees with any previous credentials in the input handle.

Well, I am not sure that it makes sense to try to do this for the default
name (but see below).

>     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.

>     3. So how are the desired "name" and "mech" used when going
>        from no creds (NULL input handle) to a handle with a first
>        credential element?

A GSS_C_NO_CREDENTIAL input handle is not a representation of no creds,
but rather a request to start from the default credentials.  The default
credentials must have some name associated with them, but we don't
(necessarily?) know what that name is.  My reading is that the only
reliable way to request the name associated with the default credentials
is to pass GSS_C_NO_NAME and not try to explicitly name the default
identity.  Now, maybe implementing this by completely ignoring the
supplied desired_name is not very friendly, but it makes some amount of
sense to me.

>     4.  The text says that a default credential handle is implicitly
> 	constructed with GSS_C_NO_NAME, and we add to that!  But what
> 	if the acquired default credential has a conflicting name, and
> 	potentially already has elements for the same or other mechanisms?

I think that the attempt to add the new credential must fail.

In general, if one is going to be doing anything with the default
credentials, one has to only use the default credentials.  If there are
other credentials in play, only the specific (known) credentials should be
used, to the exclusion of the default credentials.

> 	What is that text really trying to say, and why?

I guess my reading has the issue that if my reading is correct, why would
they have mentioned the GSS_C_NO_CREDENTIAL case at all for GSS_Add_cred.



Nico says:
> The problem is the spec effectivel says that when input_cred_handle ==
> GSS_C_NO_CREDENTIAL then desired_name is ignored.  This seems like a
> mistake.

My reply is that GSS_C_NO_CREDENTIAL means the default credentials which
in turn means the default name.  There's no use for an explcit name when
the default name is being used.

-Ben