[15637] in Kerberos_V5_Development
Re: prompter type question
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Mar 24 07:37:41 2010
From: Greg Hudson <ghudson@mit.edu>
To: Will Fiveash <will.fiveash@oracle.com>
In-Reply-To: <20100323202941.GB14765@sun.com>
Date: Wed, 24 Mar 2010 07:26:12 -0400
Message-ID: <1269429972.7493.499.camel@ray>
Mime-Version: 1.0
Cc: MIT Kerberos Dev List <krbdev@mit.edu>,
Nicolas Williams <nicolas.williams@sun.com>,
"jhutz@cmu.edu" <jhutz@cmu.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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
purpose.
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").
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
