prompter type question

[Nicolas Williams]

On Mon, Mar 22, 2010 at 06:13:51PM -0400, Greg Hudson wrote:
> * The prompters in the krb5 tree (prompter_posix, KIM, KfW) either don't
> care about the prompt type at all, or only care whether it's a password
> prompt.  (KIM wants to save the password in some cases, while KfW treats
> an empty password as a cancellation request by the user).

True.  There's no good reason for the prompt types in the first place
_other than_ pam_krb5 (or moral equivalent) as far as I can tell.  But
boy do we need prompt type information in pam_krb5!

> * As usual, with no API docs, we're stuck trying to guess at our
> compatibility guarantees.  Would third-party prompter invocations get
> confused by prompter types which didn't exist before?  If so, is it
> their fault or ours?

Those would be the other pam_krb5 implementations, which are few enough
that we can coordinate.  We could always add a gic opt to negotiate the
use of new ones, but mostly I'd say "break them".

> * Warning messages are currently displayed by invoking the prompter with
> a banner value and no prompts--which means there is no associated prompt
> type.  So a prompt type for warning messages is probably unnecessary.

Ah, I forgot about that.

> * A prompt type for error messages doesn't make sense to me; I would
> expect plugins to just return an error code and possibly use
> krb5_set_error_message() to better explain it, rather than invoking the
> prompter to display an error message.

Ok.

> * Before we get into enumerating all of the possible bits of information
> a preauth mechanism might need to retrieve, I'd want to think a bit
> about what we are trying to enable prompters to do with that
> information, whether it's okay to keep expanding the set as time goes
> on, and whether we envision using this interface to retrieve non-textual
> input such as biometric data.

Sure.  I gave a list that we can start to reason from.  As for
biometrics, like smartcard PIN pads, I think we'd want the prompt to be
one that tells the user what to do, but also the prompter that needs to
know (pam_krb5's) what this prompt is about (enter-pin,
enter-pin-on-token-pad, touch-fingerprint-reader, ...).

> * If we decide it's okay to expand the set of prompt types now, we can
> presumably do so again later--that is, we don't have to add prompt types
> no one has expressed a need for just to avoid adding more later.

Indeed.

> Following that argument, a conservative option is to add a prompt type
> for requesting only a continue/cancel indication, and no actual data.
> That would allow a GUI prompt for "insert token" to avoid having a
> pointless (and misleading) text entry field.

Yes, but the prompter may still need to know what this is about.

> To summarize my position:
> 
> * I am okay with using KRB5_PROMPT_TYPE_PREAUTH as Sam suggests.

Clearly it's OK to use it.  But using it doesn't solve Will's problem.

> * I can see value in adding KRB5_PROMPT_TYPE_CONTINUE if no one thinks
> it is likely to create compatibility issues.
> 
> * I am reluctant to add a bunch of new prompt types just because we
> happen to be touching the list and want it to be more complete.

There's a set of prompt types that are specific to PKINIT that would
greatly help Will now:

 - insert-token
 - enter-PIN
 - enter-PIN-on-the-smartcard's-PIN-pad

Nico
--