pkinit preauth plugin issue

[Jeffrey Hutzelman]

--On Monday, February 15, 2010 01:23:48 PM -0600 Will Fiveash 
<William.Fiveash at Sun.COM> wrote:

> On Mon, Feb 15, 2010 at 01:31:25PM -0500, Jeffrey Hutzelman wrote:
>> --On Sunday, February 14, 2010 09:35:28 PM -0700 Shawn M Emery
>> <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.
>>
>> I don't think it's inappropriate to configure a system to permit use of
>> either passwords or tokens, or that doing so should automatically result
>> in  pam_krb5 conflating PINs and passwords.  For example, we've been
>> looking  for some time at setting things up so that help desk staff can
>> log in on  untrusted user machines using smart cards, to avoid
>> compromising their  passwords, but users can still log in with a
>> password.
>
> That can be accomplished via this pam.conf stack:

Well, no, it requires quite a bit of work throughout our infrastructure, 
which is well beyond the scope of this discussion.  The point is, there are 
reasonable configurations that involve both passwords and PINs, and the 
argument that any one using both deserves to lose holds no water.


> Note that pam_authtok_get's function is to prompt for and set the PAM
> auth token/password item.  When pam_krb5 with pkinit is stacked above
> pam_authtok_get pam authtok isn't set so the user is prompted for a PIN
> if a the pkinit preauth plugin finds an object that requires login in
> order to access the cert/priv key.  If there is not object or the login
> doesn't succeed the evaluation proceeds to pam_authtok_get and pam_krb5
> tries password based krb auth.

A nice theory, but using PAM_AUTHTOK for both passwords and PINs is asking 
for trouble.  Unfortunately, the original PAM API design just isn't quite 
flexible enough for this case.

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

And I stand by this.  Even "pam_krb5 with pkinit" should not assume that 
whatever is left around in PAM_AUTHTOK is a PIN, unless the person writing 
the PAM configuration has explicitly told it that.  Individual modules 
should not make assumptions about what the rest of the stack looks like; 
that violates modularity.