Re: KITTEN: IETF 75 - 76

[Martin Rex <[e-mail]>]

Nicolas Williams wrote:
> > > 
> > > Sure.  An iterator following the same design principles as
> > > gss_display_status() would look like:
> > > 
> > > OM_unit32 gss_list_default_cred_names(
> > > 	OM_uint32 *minor_status,
> > > 	gss_name_t  *name,
> > > 	int	    *more
> > > );
> > 
> > That call looks somewhat restricted to me.
> 
> It is.  It should be sufficient however.  (Here name would be an MN.)

An MN means that it refers to a singular identity/name in one
particular namespace, it does _not_ imply a single mechanism (oid) only.

A Kerberos principal is going to be an MN for the rfc1964/rfc4121 mech OID,
for the pre-rfc1964 mechoid and for the IAKERB mechoid.

But I would NOT want to require the name to be an MN here!

> 
> If you care about specific mechs you could then call gss_add_cred() with
> each name output by gss_list_default_cred_names() and inquire the
> result.

gss_add_cred() is completely broken by design (unfortunately it was
too late in the process when I complained about this brokenness).

gss_add_cred() can only add components, and it begins either with
a default credential (one that gss_acquire_cred() would create when
given a GSS_C_NO_OID_SET list of mechanism OIDs), or with an
explicitly supplied credential.

So if you want to create a credential with a single mech_oid,
you can NOT use gss_add_cred() for that purpose, you MUST use
gss_acquire_cred() with a gss_OID_set containing that one mech_oid
instead.


> 
> > How about something like this:
> > 
> > OM_uint32 gss_list_default_cred_names(
> > 	OM_uint32    * minor_status,
> > 	gss_name_t   * name,
> > 	gss_OID_set  * mech_oids,
> > 	int          * is_default,
> > 	OM_uint32    * cred_context
> > );
> 
> What's "cred_context"?  Would that correspond to the 'more' argument in
> my variant?

Yup.  similar to rfc-2744 definition of gss_display_status, where
there is a "OM_uint32 * message context" parameter. 


> 
> But yes, it'd be quite useful (though not strictly necessary) to output
> a mech OID set and is_default.  As long as only mech OIDs that are all
> in the same family (and therefore have the same MN/exported name token
> forms) are allowed to appear in mech_oids.

I do not want to require that the returned name is an MN (because this
would take away the possibility for the gssapi mechanism to select/negotiate
the best common mechanism and _require_ the user to perform an a-priori
conscious selection.

Thinking about it, I would actually want to add two more function
parameters:
       OM_uint32    * lifetime,
       gss_bufFer_t   descriptive_message,


to allow application writer to show additional information in
selection UIs that they show to users.  :)


-Martin