Subject: [kitten] Proposal: extension to GSS_Acquire/Add_cred_from()

From: Nico Williams <[email-masked]>
Date: Tue, 8 May 2012 16:28:38 -0500

Recap: Simo and I have a proposal to add three new functions dealing
with acquisition of creds from "credential stores" and storing
credentials into credential stores.  A credential store is a sequence
of key/value pairs where the keys are URNs and the value syntaxes
given by the keys.  Among the possible keys as "password file" and
such.

Simo intends to use these functions in a context where the key/value
pairs come from a configuration file.  It would be inappropriate to
allow passwords/keys/PINs/secrets of any kind to be encoded in a
configuration file, so he proposes that no URNs be provided by which
to pass secret values to the mechanism.

But I see a general replacement for gss_acquire_cred_with_password()
in these new functions and I don't want to either preclude such a use
or force apps to write secrets into temporary files.  At the same time
I completely agree that no secrets should be stored in configuration
files...

So I'd like to propose an extension to the GSS_Acquire/Add_cred_from()
functions such that the mechanism can tell if any secrets in the
cred_store are to be allowed or not.

Recall that the form of a cred store in the C bindings would be:

typedef struct gss_cred_store_element_struct {
    const char *urn;
    const char *value;
} gss_cred_store_element, *gss_cred_store_element_t;
typedef const struct gss_cred_store_element *gss_const_cred_store_element_t;

typedef struct gss_cred_store_struct {
    OM_uint32 count;
    gss_const_cred_store_element_t *elements;
} gss_cred_store, *gss_cred_store_t;
typedef const struct gss_cred_store_struct *gss_const_cred_store_t;

I can see several possible extensions for allowing secret values here.
 My preference would be to have a per-element flag field because it
that would allow the app/mech to distinguish the origin of each
element.

Perhaps cred stores should be opaque and should have accessor by which
to add key/value pairs, then the accesspor could have an argument
indicating the origin of the key/value pair.  If we wanted to have a
function for learning what the current cred store is then we'd need to
concern ourselves with memory management, and then the lessons of
gss_buffer_t and friends should push us to using an opaque object type
here!

I do realize that in order to use GSS_Acquire/Add_cred_from() as the
basis for a GSS-API interactive initial credential acquisition
interface we'd need a way to tell the app what cred store elements the
mechanism needs, and that perhaps this is not the best approach to a
generic initial cred acquisition API.  However, I also don't want to
make it harder to re-use the cred store functions later on if we
should want to use them as the basis of an interactive initial
credential acquisition API.

So my proposal, then, is to make the gss_cred_store_t into an opaque
type and to provide a constructor, a destructor, a function by which
to add elements, and a function by which to iterate elements, with
elements consisting of: key, value, flag, and one flag defined to
indicate that the value was obtained interactively or from an
appropriate store of secrets.

Comments?

Nico
--

---

From: Greg Hudson <[email-masked]>
Date: Tue, 08 May 2012 18:29:34 -0400

On 05/08/2012 05:28 PM, Nico Williams wrote:
> an extension to the GSS_Acquire/Add_cred_from()
[...]
>  My preference would be to have a per-element flag field
[...]
> Perhaps cred stores should be opaque and should have accessor
[...]
> make the gss_cred_store_t into an opaque
> to add elements, and a function by which to iterate elements

I think this is far too much complexity for the benefit.

I also think cred store parameters are probably not a good basis for
making initial credential acquisition work through GSS.  Conflating
"where credentials are stored" with "secrets you need to acquire
credentials" seems like a bad idea.  So, I disagree that we want to add
complexity in order to leave the door open to this.

---

From: Nico Williams <[email-masked]>
Date: Tue, 8 May 2012 17:48:09 -0500

> I think this is far too much complexity for the benefit.

If we ever want a GSS_Get_current_cred_store() we'll kick ourselves
for not having made cred_store opaque, as then we'll have all the same
memory management issues that we've had with gss_buffer_t.  So I
definitely think we should at least address that.

> complexity in order to leave the door open to this.

It's already done in this API.  I'd be OK with separating the two
types of things, but that will complicate things for Simo's proxy
project.

Nico
--