pkinit preauth plugin issue

[Sam Hartman]

>>>>> "Jeffrey" == Jeffrey Hutzelman <jhutz at cmu.edu> writes:

    Jeffrey> --On Sunday, February 14, 2010 09:35:28 PM -0700 Shawn M
    Jeffrey> Emery
    Jeffrey> <Shawn.Emery at sun.com> wrote:

> On 02/14/10 10:13 AM, Jeffrey Hutzelman wrote:
>> --On Wednesday, February 10, 2010 01:51:36 PM -0600 Will Fiveash
    >>> <William.Fiveash at sun.com>  wrote:
    >>> 
    >>> 
    >>>> The problem I'm dealing with is that pam_krb5 when configured
    >>>> to use PKINIT may find PAM_AUTHTOK set and if that is the case
    >>>> I was informed* that pam_krb5 should assume that is the PIN and
    >>>> pass that to the pkinit preauth plugin.
    >>>> 
    >>> That sounds like a really bad idea, for the same reason --
    >>> conflating PIN's and passwords is a recipe for lockouts.
    >>> 
    >> 
> I brought up the same concern in the design review, but I finally
    >> relented and stated that if an administrator had configured PAM
    >> in this manner with the ability to use hard tokens on the same
    >> system then they deserve accelerated lockouts.

    Jeffrey> I don't think it's inappropriate to configure a system to
    Jeffrey> permit use of either passwords or tokens, or that doing so
    Jeffrey> should automatically result in pam_krb5 conflating PINs and
    Jeffrey> passwords.  For example, we've been looking for some time
    Jeffrey> at setting things up so that help desk staff can log in on
    Jeffrey> untrusted user machines using smart cards, to avoid
    Jeffrey> compromising their passwords, but users can still log in
    Jeffrey> with a password.

    Jeffrey> If an administrator wants pam_krb5 to assume passwords are
    Jeffrey> PINs, that's fine.  Make them set a module option that does
    Jeffrey> that.  Don't make it the default.

Jeff, I completely agree with what you're saying above.  However, let's
make sure that we're not playing shoot the messenger here.  Sun has an
internal design process that has reached a decision about the behavior
of Sun's pam_krb5 module.

The purpose of this list is to look at design and development of MIT
Kerberos.  That Sun internal design discussion has interesting
implications for MIT Kerberos: we need to provide a mechanism to feed a
PIN into pkinit.  I think we've hashed those out and come to agreement.

It happens that a lot of people here (including the two of us) disagree
with what Sun proposes to do with their PAM module.  That's fine; we can
bring that concern to Sun.

However, let's not get so carried away with doing so that we discourage
Sun or any other vendor from bringing the Kerberos aspects of their
designs here even if they believe the Kerberos community may disagree
with aspects of the overall design.  I.E. Let's make sure we don't cause
this to drag out sufficiently that Will regrets working with us on this
issue.