Project review: response sets

Nico Williams nico at
Fri Jul 13 13:17:24 EDT 2012

On Fri, Jul 13, 2012 at 9:39 AM, Nathaniel McCallum
<npmccallum at> 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

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


More information about the krbdev mailing list