pam_krb5 with PKINIT from Heimdal and MIT

[Russ Allbery]

I tried to trim people who I know are on krbdev already; apologies if
anyone is still getting multiple copies of this mail.

Douglas E Engert <deengert at anl.gov> writes:
> Jeffrey Hutzelman wrote:

>> That's not how PAM works.  It is up to individual PAM modules to
>> request that the application prompt the user for a username, password,
>> or other data.  The framework provides a mechanism (the PAM_USER and
>> PAM_AUTHTOK items) for caching and reusing the previously-entered
>> username and/or password when appropriate, but it is up to individual
>> modules to decide when to do this.  For many modules, this behavior is
>> controlled by the pam_first_pass and pam_try_first options.

> I understand that it can be done the other way. Its just that in most
> distributions its done with using the same authtok.

In Debian and Red Hat, this is completely configurable and if you just add
pam_krb5 to the stack without telling it to use an existing password, it
will prompt separately and ignore any existing password.  So I'm not sure
that your perception of what most distributions are doing is really
correct.  It's up to how the user configures PAM.

> Solaris 10 goes so far as to use pam_authtok.so to prompt for
> "Password:" before any of the individual modules do.

I think this is unique to Solaris.

> It practice, even on non-Solaris systems, what the user sees is
> "Password:" and has no idea which password this is referring
> too. Multiple "Password:" prompts could be a failed first password, with
> try_first_pass and a second chance, or a second pam module prompting.

This is actually intentional in pam_krb5 for security reasons.  There are
security concerns about exposing the account name for which a password is
being prompted; this is not necessarily already known to an attacker
depending on how PAM is being used.  There was a bug filed against the old
Debian package explicitly asking for this behavior.  (And in addition,
some broken ssh clients can only handle "Password:" as a prompt from a
remote sshd and will fail with any other prompt.)

pam_krb5 doesn't yet support expose_account, but it's on my to-do list to
implement.  The current prompt will remain the default, but if
expose_account was specified, pam_krb5 will instead defer all password
prompting it needs to do to the Kerberos library, which will use a more
verbose prompt that includes the principal name.

For the PKINIT case with PINs, I agree that the prompt should be something
different than "Password:".  In that case, I also think that any existing
authentication token should be ignored, rather than attempted as a PIN;
attempting an existing saved authentication token as a PIN will almost
always fail, given how people currently use PAM.

> The pam_krb5-2.4 for example will use "Password: " and will do
> pam_set_item(ctx->pamh, authtok, pass); just in case it is not the
> Kerberos password.

It does this not just in case it's not the Kerberos password, but also for
the use of other modules later (the password change module, for example).

> What I am asking is the vendors like, RedHat, Sun, Debian to look at
> these other pam issues while looking at the pam_krb5 and Kerberos
> pre-auth and change the default behavior such that it is obvious to the
> user what "Password:" is being requested, as well as recognize that
> smart card readers with pin pads can't use the "Password:" prompt.

I'm not willing to change the "Password:" prompt by default for the
reasons given above, but I'm certainly willing (and intend) to add an
option to allow more informative prompts.  I certainly agree with the
latter half of your statement.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>