prompter type question

[Nicolas Williams]

On Tue, Mar 23, 2010 at 11:51:41AM -0700, Jeffrey Hutzelman wrote:
> --On Tuesday, March 23, 2010 12:31:09 PM -0400 Greg Hudson
> <ghudson at mit.edu> wrote:
> >Can I have a bit more information about what Sun's pam_krb5
> >implementation wants to do with the prompt types?  We can probably add
> >these three once I understand the need for them.
> 
> I don't speak for Sun, but...

... you did a good job :)

> It's important that PAM modules be able to distinguish prompts for
> multiple things from each other, so that they can correctly
> associate prompts with previously-collected replies when retrying an
> operation after a conversation function returns PAM_CONV_AGAIN.
> 
> In addition, as the PAM framework's ability to pass
> previously-entered responses between modules improves, it is
> important for PAM modules to be able to tell what a prompt is for,
> so they can convey it correctly to other modules.  It would be bad
> to record the answer to a PIN prompt as if it were a password; we
> have recently discussed the implications of such confusion.

+1

Will needs to distinguish PIN from password at all costs, and the
current preauth promt type does do that, but he also 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).

(Where would a cached PIN come from you ask?  Well, it might come from
pam_pkcs11 via "PAM data" some day, or from the application, via the
PAM_AUTHTOK item, if it had asked for one for some reason.)

(PAM's conversation scheme is somewhat limited.  In a GUI world we could
use a more comprehensive conversation facility, and if we had such a
thing we'd probably have a stronger need for the requested krb5 gic
prompt type distinctions.)

Nico
--