Project review: response sets

Nico Williams nico at
Tue Jul 17 12:42:16 EDT 2012

On Fri, Jul 13, 2012 at 5:53 PM, Dmitri Pal <dpal at> wrote:
> On 07/13/2012 06:45 PM, Nico Williams wrote:
>>> It is perfect opportunity to offset it to intermediary like SSSD or
>>> similar software for other platforms.
>> Well, I can see that SSSD might want to tell libkrb5/whatever plugin
>> what PKCS#11 implementation to use to talk to a smartcard, say --
>> that's quite fair.  For OTPs this may be different because perhaps
>> there's no standard API to access hardware OTPs (again, please excuse
>> my ignorance).
> I would agree with you 100% if all that would have been standardized in
> the same way as smart cards but the technology is not there.
> By assuming that libkrb5 would be in charge of all these methods from
> get go we are creating a barrier for adoption. This of a third party
> app. One case they can do everything in their tree and another they have
> to get the code to be a part of the libkrb5.
> I would rather let the app do it and then when the prompter
> implementations mature move them under library over time.

I've thought long and hard about this over the weekend.  My conclusion
is that you're conflating two things in this API that you should not
want to conflate: user interaction, and hardware interaction. I don't
want those two things conflated.  Note that I'm not saying that
conflating things is always bad, I'm saying it's generally suspect,
and definitely bad in this case.

You say that there's no standard interface to hardware
challenge/response and OTP hardware tokens, and that you do not want
to develop such a thing, but... your application (SSSD) is going to
have a big switch that... implements a token framework anyways!
There's nothing wrong, IMO, with having an experimental framework for
token interaction here, just as long as you do not so tightly bind it
into user interaction.

Consider PKINIT and hardware tokens.  The same issues come up, but no
one ever proposed having the app do the interaction with
smartcards/tokens to sign or decrypt with private keys!


More information about the krbdev mailing list