Conditional prompting with PKINIT preauth

[Greg Hudson]

On 05/27/2013 05:05 PM, Russ Allbery wrote:
> This is guaranteed to *not* be set for such things as a PKINIT PIN or an
> OTP code?

Correct.  It's only used by the get_init_creds_password AS key function.
 Things like a PKINIT PIN would use KRB5_PROMPT_TYPE_PREAUTH (although
in some cases, I believe you get a null type array instead).

> 1. There's definitely a need to configure which preauth mechanisms you
>    want to use at the granularity of the PAM configuration.

Point taken.

> At least at first glance, I'm not seeing how this is related to this
> particular problem of choosing preauth types based on PAM context,
> although it certainly seems like a nicer prompter interface.

Because the responder communicates exactly what kind of preauth value is
being prompted for in a machine-readable way, you can to some extent
control the preauth types by controlling what prompts you allow.  It's
not complete control, because a preauth mech can succeed without
prompting (PKINIT with an unprotected private key, OTP with a connected
token), but it's a facility we already have which lets you get close.

We can add an API for directly controlling what preauth mechanisms are
allowed, but there are a bunch of details to work out, so it may take a
while.