Conditional prompting with PKINIT preauth
Greg Hudson
ghudson at MIT.EDU
Tue May 28 11:57:09 EDT 2013
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.
More information about the Kerberos
mailing list