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. ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
