Subject: [kitten] Alternative design (Re: We need a GSS_C_CHANNEL_BOUND_FLAG)

From: Nico Williams <[email-masked]>
Date: Tue, 19 Feb 2013 12:13:36 -0600

I've thought about this over the weekend.

I think a better design would be to distinguish between "credential
options" and "context options".  An indication that the application
understands the new ret_flag would be a context option.

There's two ways I can think of setting arbitrary context options: a)
set them on credential handles, or b) have a function to create
"empty" security contexts to be passed to
GSS_Init/Accept_sec_context().

I prefer (a) for the abstract API and the C bindings, but could be
convinced to go with (b) (which is utterly natural for the Java
bindings).

The functions to be added then would be GSS_Set_context_option() and
possibly GSS_Get_context_option().  If we go with (b) we might need an
empty security context   constructor, though we might also conflate
construction into GSS_Set_context_option() (we have precedent for this
in GSS_Add_cred()).

Following recent tradition we'd use URNs instead of OIDs.

This extension really is necessary.  Consensus would be nice to have
on some design.

Please comment.  Thanks,

Nico
--

---

From: Greg Hudson <[email-masked]>
Date: Tue, 19 Feb 2013 14:57:42 -0500

On 02/19/2013 01:13 PM, Nico Williams wrote:
> have a function to create

After discussing this idea with Tom, I like it and wish GSSAPI had
started out this way.  If we had blank context constructors from the
beginning, then:

* gss_init_sec_context and gss_accept_context could have had far fewer
parameters.  Instead, if you wanted to provide an unusual argument like
time_req, you would set an option on the blank context before
establishing the context.

* Extensions like gss_set_neg_mechs and gss_krb5_set_allowable_enctypes
wouldn't have needed to abuse GSS creds.

Of course, we can't get rid of anything old at this point.

> possibly GSS_Get_context_option().

Do we really need to standardize generic mutators for context options?
Can we instead standardize a new function every time we want to add a
new kind of context option?  I don't really like OID/buffer or
URI/buffer dispatches.

For this purpose, we could probably define GSS_Set_context_flags() and
perhaps GSS_Get_context_flags(), where the flags are in the req_flags
namespace.  We'd have to decide what happens if you set flags on a blank
context and then call GSS_Init_sec_context; simplest is to or the
context flags into the call's req_flags.

---

From: Nico Williams <[email-masked]>
Date: Tue, 19 Feb 2013 14:41:53 -0600

> started out this way.  If we had blank context constructors from the

I too wish the GSS-API had been like this from the beginning.  Note
that the Java bindings were like this from the beginning.

> establishing the context.

Yes.

> wouldn't have needed to abuse GSS creds.

I'm not sure about set_neg_mechs -- I could go either way on that one.

The allowable enctypes (or any cryptographic profiling) absolutely
needs to be a credentials type option: so the application can know a
priori what credentials meet the desired requirements!  Think of a
named cryptographic profile extension... you'll want to acquire
credentials that can meet the desired profile.

> Of course, we can't get rid of anything old at this point.

No, but we can replace it and deprecate the old stuff.

> new kind of context option?  I don't really like OID/buffer or

Per-option functions means more build-time feature discovery; or more
use of non-standard run-time discovery techniques (weak symbols,
dlsym(), ...).  That strikes me as a bit of a PITA.  Whereas with
URN/URI/OID + buffer type extensions there's a single extension to
detect at build time, and the run-time detection of supported options
need not rely on any non-standard functionality.

I could live with per-option functions.  But first I think I'd like to
see what the rest of the WG thinks of this.  Perhaps there really is
no need for run-time feature tests?

> context flags into the call's req_flags.

Ah, see, already you don't really want per-option functions -- you're
proposing aggregating those that can be handled as a set of flags.  :)

Thanks for the thoughtful comments!

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 21 Feb 2013 13:50:29 -0600

Any further comments?  It'd be nice to have consensus going into
Orlando.  It should be easy to get consensus on this.

Also, I think this should be a WG work item.  Pretty please dear
chairs?  Thanks!

Nico
--