Subject: Re: [kitten] PGSSAPI, take two

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 24 Mar 2011 10:47:29 -0400

On Thu, 2011-03-24 at 03:08 -0500, Nico Williams wrote:
> A few years ago there was a proposal for a "PGSSAPI" where GSS
> functions were augmented with an additional caller context argument.
> I then proposed overloading the minor_status argument, but no one
> liked that.  Later I proposed a GSS-APIv3, but that won't happen
> anytime soon.  Then Love proposed just adding an additional context
> argument to a small handful of new functions.
> 
> I'm starting to think that we need so badly to add such this feature
> (caller contexts) to the API real soon.

What problem are you trying to solve?

-- Jeff

---

From: Nico Williams <[email-masked]>
Date: Fri, 25 Mar 2011 11:59:17 -0500

> What problem are you trying to solve?

A set of problems that keeps coming up, ALL related to layered
software.  The layered software context is: one process with two or
more uses of the GSS-API, one or more of which is buried in various
libraries (or plugins to libraries), and where two or more of those
need different mechglue or mechanism configurations.  The layered
software problem has become rather pervasive in recent years.  Anyone
with experience with Apache, PAM, LDAP, and so on can attest to this.

The layered software problem is related to DLL Hell, except that we
need not have two or more GSS-API implementations involved here.  And
no, it's not a good idea to address the layered software problem by
resorting to DLL Hell :) (i.e., have multiple distinct GSS
implementations so that each layered use of the GSS-API can get its
own GSS implementation).

In the original PGSSAPI proposal the poster needed to be able to
configure the mechglue differently so that they could have different
providers for the same mechanism in two consumers of the GSS-API in
the same process.

In more recent cases there are desires to specify policy that must be
passed to the provider.  For example, enctype policy, though there are
many other example policies.  Sam et. al. seem likely to resort to all
sorts of credentials options type extensions to address some of these.
 But in most if not all cases it would suffice to have the policy
stored in a file (or whatever, just not specified in detail in the API
itself) and then name this policy to the API.  My modest proposal
achieves that and allows the application code (well, the GSS-API
consumer) to remain quite simple.

In the GSS-APIv3 prototype I started on and abandoned a couple of
years ago I had a caller context handle as an input to all functions
(and no minor_status, that being subsumed into the caller context
handle), and a variety of functions by which one could profile the
mechglue/mechanisms via this caller context.  I think such a thing
would still be useful, but it's obviously way too late to the market,
which motivates me to pursue something much simpler now as a bandaid.

Nico
--