Project review: response sets

[Nico Williams]

On Thu, Jul 12, 2012 at 5:45 PM, Greg Hudson <ghudson at mit.edu> wrote:
> On 07/12/2012 03:02 PM, Nico Williams wrote:
>> This is not that different from the GSS cred store extension, in many
>> ways.
>
> Alright, let's take a look at this, accepting for the sake of argment
> that it's a good idea to use the cred store extension for initial
> authentication.  The differences I see are:
...

> 3. Cred store values are text blobs which are constructed by the caller
> and interpreted by the mech.  Response item values are binary contracts
> whose values are constructed by preauth mechs, mutated by the caller's
> (in the responder callback), and then interpreted by the preauth mech.
>
> To elaborate on the term "binary contract" in point 3: as currently
> envisioned, a responder item isn't necessarily just a blob of data that
> you could write out to disk and read back; it may be a complex structure
> involving pointers, and in some cases would even contain function
> pointers to be invoked by the responder callback.  It would be a fairly
> trivial change (although probably still unwelcome to Simo) to respecify
> cred store values as binary blobs, but a more significant change to make
> them into arbitrary binary contracts.

For the GSS interface they have to be strings.  Period.  The reason is
the proxy: neither the proxy client nor the proxy server need to know
anything about marshalling strings, but having binary objects would
require making the proxy client and server aware of all the URIs, and
would require changes and rebuilding (or a plugin interface) every
time someone comes up with a new key/value type.

I suppose no one will want to apply the same proxy concept to
pre-auth, so maybe this difference should stay and it just means that
the krb5 mechanism will have to have code to map all the URIs it knows
to binary objects.

If a GSS application needs to pass, say, PKCS#11 function pointers and
session/object handles, well, then how is that to be handled?  I would
say: apply the same proxy principle and have the application provide a
name for the objects that a different process can use to use them by
proxy.  The same can be done for pre-auth, with a simple shim that
works only in the same process (e.g., hex-encode non-string value
pointers).

PKCS#11 is a bit of a bad example because being so standard we could
just say: pass a PKCS#11 URI, pass in a PIN file, pass in the path to
a PKCS#11 DLL.  For other interfaces it may not be so simple.

> As currently designed, a connector between cred stores and responders
> would have to know about specific response items in order to be able to
> translate the names and values, and would bridge the push vs. pull
> interface mismatch by providing a responder callback which looks for the
> response items which it knows about and has corresponding cred store
> parameters for.

As I think about it now, it's not that big a deal.

> If we want more commonality and less glue code here, we could either try
> to make response sets more like cred stores or we could do the reverse.

Yes, I'd like us to consider this.  We may find reasons to change
neither; I'm OK with that.

>  I think making response sets more like cred stores would probably make
> more sense.  Specifically:
>
> * Response item keys become URIs.
>
> * Instead of arbitrary contracts, response items have question blobs and
> answer blobs.
>
> * Answer blobs can be pushed by the caller without having to provide a
> responder callback, via a generalization of krb5_get_init_creds_password.

Yes, I'd like that.  So I think the main thing left to do is to
consider what to do about things for which strings are a bad fit (see
my PKCS#11 example above).

Nico
--