[kmf-discuss] PSARC/2006/283 Certificate & PKCS#11 PAM module (pam_pkcs11)

[Huie-Ying Lee]

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