pkinit preauth plugin issue
hartmans at MIT.EDU
Tue Feb 16 05:16:31 EST 2010
>>>>> "Jeffrey" == Jeffrey Hutzelman <jhutz at cmu.edu> writes:
Jeffrey> --On Sunday, February 14, 2010 09:35:28 PM -0700 Shawn M
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
More information about the krbdev