prompter type question

[Will Fiveash]

On Wed, Mar 24, 2010 at 07:26:12AM -0400, Greg Hudson wrote:
> 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.

Yes, the "continue" prompt type would be useful for my adding a "insert
smart card" prompt in the pkinit plugin.

> 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").

I see what you are saying in regards to something like our pam_krb5
which is passing a prompter bridge function info libkrb5 and is
examining the prompt_type passed in when the pkinit calls the prompter
function.  If pam_krb5 were to try to set a PAM PIN item (that currently
does not exist) there would be ambiguity as you point out since only the
pkinit plugin has access to the specifics of slot and token for which
the PIN prompt was issued.  Since our PAM does not currently define a
PAM PIN item this is not an immediate issue for me.  What would be
useful however is to define message types that be unambiguously mapped by
the pam_krb5 prompter bridge to these PAM message styles:

/*
 * msg_style defines the interaction style between the
 * scheme and the application.
 */
#define PAM_PROMPT_ECHO_OFF     1       /* Echo off when getting response */
#define PAM_PROMPT_ECHO_ON      2       /* Echo on when getting response */
#define PAM_ERROR_MSG           3       /* Error message */
#define PAM_TEXT_INFO           4       /* Textual information */

The latter two styles do not require any user input.  Note that Solaris
pam_krb5 is using krb5_prompt hidden field to determine whether the PAM
msg style is PAM_PROMPT_ECHO_OFF or PAM_PROMPT_ECHO_ON.

Beyond that these are the current set of Solaris PAM item defines:

/* Items supported by pam_[sg]et_item() calls */
#define PAM_SERVICE     1               /* The program/service name */
#define PAM_USER        2               /* The user name */
#define PAM_TTY         3               /* The tty name */
#define PAM_RHOST       4               /* The remote host name */
#define PAM_CONV        5               /* The conversation structure */
#define PAM_AUTHTOK     6               /* The authentication token */
#define PAM_OLDAUTHTOK  7               /* Old authentication token */
#define PAM_RUSER       8               /* The remote user name */
#define PAM_USER_PROMPT 9               /* The user prompt */
#define PAM_REPOSITORY  10              /* The repository to be updated */
#define PAM_RESOURCE    11              /* Resource management info */
#define PAM_AUSER       12              /* The authenticated user name */

It may be that pam_krb5 may want to set one of these items based on the
prompt reply or use one of them to set reply data to return to the
preauth plugin that is calling the prompter bridge function.

In general I can understand your caution about adding more krb prompt
type defines.  Personally, I will have to think more about this before I
can offer more concrete advice.

-- 
Will Fiveash
Oracle
http://opensolaris.org/os/project/kerberos/
Sent from mutt, a sweet text MUA.