Project review: response sets

[Nathaniel McCallum]

On Fri, 2012-07-13 at 12:17 -0500, Nico Williams wrote:
> On Fri, Jul 13, 2012 at 9:39 AM, Nathaniel McCallum
> <npmccallum at redhat.com> wrote:
> > On Thu, 2012-07-12 at 18:45 -0400, Greg Hudson wrote:
> >> * 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.
> >
> > I don't like either of these for one important reason: the responder
> > interface as it stands can specify callback functions to validate the
> > input data. In OTP for instance we definitely want to validate the data
> > provided and provide intelligent errors for the UI.
> 
> Note that unless the KDC tells the client how to validate any one
> input or the other then it makes little difference whether the
> validation code is in the pre-auth plugin or in the application (or,
> more likely, in utility functions provided by the library to the
> application).  Unless we want to remain open to the possibility of
> adding validation information to the pre-auth protocols later on.  Do
> we?  I'm not sure.  I'm leaning to "no".  But let's explore that
> possibility.
> 
> Here's one scheme I'm imagining:
> 
>  - a new pre-auth type that is used by the client to communicate its
> locale to the KDC
>  - a new pre-auth type that is used by the KDC to communicate
> localized instructions and/or error information to the user
>  - no user input validation in the library or application, instead the
> KDC can tell the user what they did wrong.
> 
> Note that there's no N-strikes problem with this: if the OTP entered
> has invalid content then there's no need to actually bump failed
> attempts counters.
> 
> Other schemes might include a PA by which the KDC sends regexps for
> validating user inputs.  I'm not sure I like that, but it's feasible.
> 
> Or the KDC could send HTML w/ JavaScript...  why not?  sure, that's
> not really great on a tty (though not exactly infeasible either), and
> maybe I don't care about ttys (well, I do, for myself, but we live in
> a GUI world).

In the case of OTP, the KDC does in fact tell the client how to validate
the data. If we follow the proposed modifications to the response set
interface, you will require marshaling for every plugin and every
application. You would also have to distribute a separate library for
every plugin's client validation. I think that the current approach is
the simplest and the most flexible.

Nathaniel