Project review: response sets

[Dmitri Pal]

On 07/13/2012 03:56 PM, Nathaniel McCallum wrote:
> 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.

The more can be done within the library and less by the applications
using it the better will be the adoption so I agree with Nathaniel's
approach.
I remember how painful it is to to do this validation for some of the
OTP use cases (New pin in particular) so it is better to implement it
once and right and provide a validation function than have applications
to do it themselves or have to package a special library.

> Nathaniel
>
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/