prompter type question
Nicolas.Williams at sun.com
Mon Mar 22 18:24:59 EDT 2010
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.
> * 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.
> 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:
More information about the krbdev