Project review: response sets

Dmitri Pal dpal at
Fri Jul 13 18:53:23 EDT 2012

On 07/13/2012 06:45 PM, Nico Williams wrote:
> On Fri, Jul 13, 2012 at 5:25 PM, Dmitri Pal <dpal at> wrote:
>> Who is going to interact with the connected OTP token or a token
>> embedded into the hardware like TPM?
>> Do you expect it to be the code under the Kerberos library?
> Yes.  That's what Solaris' pam_krb5 does, for example.  It prompts the
> user for which token to use and then for the PIN for it (well, the
> application does the prompting, pam_krb5 just drives it).  But then it
> passes the result to the library through krb5_get_init_creds options.
>> Those interactions are usually hardware and vendor specific.
>> I do not think we want to embed it into the Kerberos library.
> For smartcards, TPMs, and other PK tokens I very much expect libkrb5
> to do this.  I especially expect the app to NOT do it.
> I'm not sure about OTPs though.  I'm open to the possibility that
> there's no other way but to have the app talk to the OTP tokens.  But
> so far I don't see why.
>> 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.

> Nico
> --
> _______________________________________________
> krbdev mailing list             krbdev at

Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.

Looking to carve out IT costs?

More information about the krbdev mailing list