pkinit preauth plugin issue

[Will Fiveash]

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

> 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.
http://opensolaris.org/os/project/kerberos/
Sent from mutt, a sweet ASCII MUA