prompter type question
ghudson at MIT.EDU
Wed Mar 24 07:26:12 EDT 2010
To avoid misinterpretation, let me make sure the context is clear:
* Nico proposed three new prompt types directly related to Will's work:
> - insert-token
> - enter-PIN
> - enter-PIN-on-the-smartcard's-PIN-pad
* I asked what pam_krb5 would do with the information provided by using
one of these three new prompt types.
* Jeff suggested, "it would be bad to record the answer to a PIN prompt
as if it were a password." As Nico mentioned, this is already handled
by the existing preauth prompt type. Jeff also later said, "[the
client] might be some kind of indirection or automation," which Nico
pointed out is too general of an answer.
* Nico said:
> Will [...] needs to distinguish "insert token" (in response to which
> the module should NOT send a PIN) from "enter PIN", and, ideally, we
> should have at least a different prompt for "enter PIN" vs. "enter PIN
> on your token's PIN pad" (again, the module should not respond to such
> a prompt with a cached PIN).
* Will said:
> Yes, what Nico and Jeffrey write is correct. In addition there is a
> situation where our pam_krb5 module must restrict what is prompted
> for (it must not prompt for a password, this is left to the
> pam_authtok_get module).
Let me explain why I'm being so picky about specific use cases. Numeric
prompt types are a limited and poorly defined form of structured
information. If we ask for "a PIN," we can't say what device we want
the PIN for, which means pam_krb5 can't really return a cached PIN
without possibly giving us one for a different device (which we know can
be harmful due to token lockout). I do not want to create a soup of
prompt types under different conceptions of what a prompt type means,
only to find out later that they are inadequate for any productive
Currently, I can understand wanting to distinguish between "do something
and tell me when you're done" and "give me some information." That's
why I'm happy to add a "continue" prompt type, which I think would serve
for either "insert token" or "enter PIN on external device." A caller
can use this to decide whether to expect string input from the user or
just a button press.
I have not yet been told what pam_krb5 might productively do with the
more specific knowledge that some PIN is needed (vs. just an unspecified
piece of preauth-related input), or what external user action is
requested (vs. just "ask the user to do this piece of text and tell me
when the user says it's done").
More information about the krbdev