Project review: response sets

Nathaniel McCallum npmccallum at redhat.com
Fri Jul 13 17:05:37 EDT 2012


On Fri, 2012-07-13 at 15:48 -0500, Nico Williams wrote:
> On Fri, Jul 13, 2012 at 2:56 PM, Nathaniel McCallum
> <npmccallum at redhat.com> wrote:
> > 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
> 
> I see.
> 
> > 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.
> 
> I do think it follows that the pre-auth plugin should do the
> validation.  I don't think it follows that we must use void * instead
> of char *.

In fact, it does. The "answer" is definitely non-trivial. It is NOT
simply a password. A typical reply looks like this (assuming a bunch of
relevant data is generated by the plugin and not the application):
1. Which token was used. This is an index into the question array.
2. The token (format validated)
3. The pin
4. Flags

The only way to do a blob would be to provide marshaling of the data
type for both the plugin and all applications. The client should also
verify the token. So at the bare minimum, the application would need to
referenced shared code for marshaling and verification. A binary
interface makes the most sense here.

Also, it makes no sense to separate the question from the answer so that
you can provide an answer without the question. In OTP, for example, the
question is almost always required to generate a proper answer. The most
common reason for this is selecting a compatible tokeninfo. This could
be worked around with some intelligent code in the plugin. However,
there is no way to work around a challenge provided to a hardware token.
You simply can't provide the answer without the challenge itself.

I also think providing an arbitrary interface with no question-answer
segregation future-proofs for more complex preauth plugin work.

Nathaniel



More information about the krbdev mailing list