Proposal: extension to GSS_Acquire/Add_cred_from()
Nico Williams <nico <at> cryptonector.com>
2012-05-08 21:28:38 GMT
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
--
_______________________________________________
Kitten mailing list
Kitten <at> ietf.org
https://www.ietf.org/mailman/listinfo/kitten
RSS Feed