Conditional prompting with PKINIT preauth
rra at stanford.edu
Mon May 27 17:05:25 EDT 2013
Greg Hudson <ghudson at MIT.EDU> writes:
> In the prompter, you can call krb5_get_prompt_types() to get an array of
> types for each prompt. (It may return NULL in some cases.) If the
> prompt type is KRB5_PROMPT_TYPE_PASSWORD, then you know you're being
> asked for the password.
This is guaranteed to *not* be set for such things as a PKINIT PIN or an
> This should allow you to (1) disable password prompting when use_pkinit
> is set, and (2) store the password when try_pkinit is set and the
> library falls back. Is this sufficient?
Not completely, although it certainly gets me closer. It doesn't allow
disabling any other authentication method (such as OTP), which is what
use_pkinit is defined to do.
> More generally, I'm not sure the pam_krb5 module ought to be driving the
> decision to use PKINIT. For Heimdal it may be necessary to make PKINIT
> go at all, but MIT krb5 tries to control preauthentication from within
> libkrb5 and the KDC, so that new mechanisms can be added via loadable
I certainly understand why that approach is more attractive. However, I
think there are two problems with that general philosophy when it comes to
1. There's definitely a need to configure which preauth mechanisms you
want to use at the granularity of the PAM configuration. For example,
console logins may require a hardware smart card, but ssh
authentications clearly can't (but may result in fewer privileges).
You don't necessarily want to use the same authentication mechanisms
for GDM and IMAP. And so forth. krb5.conf is generally system-global.
2. PAM needs to know when the account password is being entered so that it
can support the normal semantics of the PAM stack, for good or for ill.
> That said, we do have this in 1.11:
> (See also http://k5wiki.kerberos.org/wiki/Projects/Responder) However,
> it won't be integrated properly with PKINIT until 1.12.
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.
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the Kerberos