Project review: response sets

[Greg Hudson]

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:

1. The cred store is a push interface with no pull support; the
responder is a pull interface with no push support.  (Of course you can
push through a pull interface; it's just more awkward.  You can't do the
reverse at all.)

2. The cred store keys are URIs; the responder keys are uncoordinated C
strings.  This is a pretty trivial difference, easily resolved by
specifying that responder keys should be URIs.

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.

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.

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.
 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.