> > 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.
Having made an attempt to read this, I remain unconvinced that
the documentation is adequate for anyone but an expert in the
area. Indeed co-packaging the docs is good and should be done.
> > 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.
I disagree that this should be postponed. Saying a single customer
is happy with the implementation (do they have an IDR?) doesn't
make it architecturally correct. If the code is currently doing
certificate validation (and CRL or OCSP processing), it seems
a straight forward factoring of the code. Waiting for phase 2
likely means changes to pam.conf as well as updating the code.
> > 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."
Hummm, I guess I've read too much into the materials:
"I'm using this old case number as other ARC cases reference
this case number as a requirement for EOF removal of some old
smartcard functionality."
"hylee at bula$exec login
Please insert your smart card or enter your username.
login: hylee
Smart card inserted.
Welcome Sun Metaslot!
Smart card password: XXXXXX"
Should the prompts (presumably) from pam_pkcs11 not imply
use of a "smart card"?
>
> > 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.
Of course. And it is this project's responsibility to give
sufficient guidance. IMO, that is architectural -- how does
this fit with the other account authorities Solaris ships. IMO,
as single statement:
"add the pam_pkcs11.so module to the /etc/pam.conf file as below:
login auth sufficient pam_pkcs11.so"
doesn't expose the architecture of pam_pkcs11 fits with Unix
or Kerberos (or LDAP bind) account authorities. Is this
provided elsewhere in the case materials that I may have missed?
> 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 guess I'm missing some understanding here. I thought pkinit
as part of pam_setcred() wasn't an if, but was in the immediate
plan. In any case I'm confused. If the home directory is not
kerberized, where does pam_pkcs11 go in the stack? From 2,
it sounds like pam_krb5 obsoletes pam_pkcs11. If that's the case,
what's the compelling architectural reason to not combine forces
and deliver a pam_krb5 that does it all rather than a pam_pkcs11?
It seem that pam_pkcs11 will need to be removed from pam.conf
when pam_krb5 replaces it? Or is it that in addition to Unix,
Kerberos (and LDAP bind), a new account authority based on pkcs11
access to certificates is being proposed? I guess I can
understand this if pam_pkcs11 is a replacement for pam_smartcard
(which the case now says it isn't -- though I personally want to
be able to support it as a replacement).
> I will add a couple of examples into the pam_pkcs11.5 man page.
IMO, they are architectural relevant and I don't see them
in the materials.
Gary..
