pkinit preauth plugin issue
William.Fiveash at sun.com
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 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
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.
Sun Microsystems Inc.
Sent from mutt, a sweet ASCII MUA
More information about the krbdev