Gary Winiger wrote:
Thank you for the valuable review input, please see our response below.
>> Man pages and other supporting material is in the materials subdir of
>> the case.
>
> The documentation has come a long way since I last saw this.
> Thanks. I've still not completed an understanding of
> the opensc-project.org/pam_pkcs11/pam_pkcs11.html doc, so I
> expect I may not grasp the whole thing yet. However, a few
> comments and questions:
>
> I wanted to point out that this work is a continuation of the
> work our Summer Intern, Brendan O'Connor, started working with
> Huie Ying. I promised him I'd add him to the interest and
> have in the IAM file.
>
> Nits:
> * I presume when pam_pkcs11.5.sunman get's delivered into the
> /usr/share/*/man tree it will be just .5. If not I'd like
> to understand the precedence for the sunman suffix.
Yes.
> * The man pages are missing ATTRIBUTES sections.
Will fix.
> * The DESCRIPTION of pkcs11_inspect and pkcs11_find still
> refer to pam_pkcs11(8). The SEE ALSOs refer to pam_pkcs11(5)
> as I'd expect, modulo the sunman thing above.
>
Will fix.
> Questions:
> 1) pam_pkcs11(5) refers to opensc-project.org/pam_pkcs11/pam_pkcs11.html
> for administrator documents. How is this project going to keep
> in sync with the community? IMO, it would be appropriate to have
> sufficient documentation within the Solaris docs areas so the
> community docs are secondary to the Sun docs delivered for a
> particular release. It would seem appropriate to have that
> documentation as part of this case.
>
Yes, we can take all OPENS/pam_pkcs11 online documents and place them
in the /usr/share/doc/pam_pkcs11 directory and ship with the product.
> 2) Huie Ying answered that the commuity version doesn't support
> pam_acct_mgmt(). This seems like a common oversight and a
> violation of the separation of authentication from account
> validation that is part of the PAM architecture. I would think
> that certificate validation (and CRL processing) would be
> part of account validation. Why shouldn't that be and why
> shouldn't Sun contribute that to the community?
>
This is a valid point. Since UBS requested this port and they are happy with
the current pam_pkcs11 implementation, this case has merit to integrate as is.
We will work with the upstream community to add the functionality as a separate
pam_acct_mgmt() entry point.
> 3) What changes has Sun made (beyond sample configuration file
> changes)? Are these being contributed back to the community?
>
I have made some changes to make it built and ran on Solaris. We will
contribute
these changes back to the unstream community.
> 4) Given that this is intended to replace the EOLed pam_smartcard,
> I don't see sufficient Sun documentation (at least from what's
> in this case) to guide me through how to use pam_pkcs11 to
> replace pam_smartcard. I would have expected at least that
> much detail as pam_smartcard was equivalent to a "Committed"
> interface in the past and its use more or less well documented
> in Sun documentation.
> P.S. I'm looking forward to the removal of the closed pam_smartcard
> and the project private interfaces in libpam that are there to
> support pam_smartcard ;-)
>
I have discussed with Darren about this. And here is our response:
"This case alone does not give us a functional replacement for pam_smartcard.
Another future case that provides a smartcard plugin to the crypto framework is
needed together with this case since this case has no smartcard functionality
it is all done via the PKCS#11 layer."
> 5) To me, the documentation is unclear as to how to properly
> configure pam.conf to use pam_pkcs11. Saying "add the
> pam_pkcs11.so module to the /etc/pam.conf file as below:
> login auth sufficient pam_pkcs11.so"
> seems inadequate. Where should it be put in the default
> delivered login stack?
>
> login auth requisite pam_authtok_get.so.1
> login auth required pam_dhkeys.so.1
> login auth required pam_unix_cred.so.1
> login auth required pam_unix_auth.so.1
> login auth required pam_dial_auth.so.1
>
> How does it interact with other possible changes for
> Kerberos in addition to Unix authentication?
> Should it be stacked below pam_authtok_get?
>
How to properly configure pam.conf to use pam_pkcs11 really depends on what
behavior that
an admin wants. The pam_pkcs11 entry can be placed above or below
pam_authtok_get/pam_unix_auth
depending on the site needs.
As for the interaction with Kerberos, I discussed this with Glenn Barry (a
kerberos engineer) and
we conclude that
1. If the home directory is kerberized, then the pam_krb5.so module (current
version)
should place before the pam_pkcs11.so module.
2. If pam_krb5.so is enhanced to support PKINIT and a new pam_krb5.so entry
exists in the pam.conf file,
then a "pam_pkcs11.so" module stacked below probably is redundent,
because the new pam_krb5.so
module should have check the certificate status and verify with private
key already.
I will add a couple of examples into the pam_pkcs11.5 man page.
Thanks,
Huie-Ying
