pkinit preauth plugin issue

Will Fiveash William.Fiveash at
Tue Feb 16 15:38:19 EST 2010

On Tue, Feb 16, 2010 at 05:16:31AM -0500, Sam Hartman wrote:
> >>>>> "Jeffrey" == Jeffrey Hutzelman <jhutz at> writes:
>     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.

Actually, the design review was held in the open on
kerberos-discuss at and the same issues were raised there
however, in the end, the opinion of the Solaris architectural review
members that participated was that if PAM_AUTHTOK was set then pam_krb5
with the pkinit option on was to use that as a PIN.  Issues that people
have with this should be raised on kerberos-discuss at

> 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.

While I don't mind various issues being raised I would prefer the
conversation not get off topic too much.  It does look like the more
recent messages to this thread are on the topic of providing a PIN/other
non-password interface to preauth plugins which is why I started this
thread so I'm happy.

Will Fiveash
Sun Microsystems Inc.
Sent from mutt, a sweet ASCII MUA

More information about the krbdev mailing list