Nicolas Williams wrote: Thank you for the valuable review input, please see my response below.
> On Tue, Jan 08, 2008 at 11:10:15AM +0000, Darren J Moffat wrote: >> ========================================== >> The pam_pkcs11 module overview >> ========================================== >> The pam_pkcs11 module is a PAM authentication module for PKCS#11 token >> libraries. This module allows a user to login a system that supports PAM, >> using a certificate and its dedicated private key stored in a PKCS#11 token. >> >> This pam_pkcs11 module supports any PKCS#11 token library, however, it >> is typically used by a Smart-card PKCS#11 token. >> >> The original source of this module is provided by opensc-project.org. >> The latest version is 0.6.0 which supports only the authentication service. >> It does not support pam_setcred, pam_acct_mgmt, or other services. > > Why no pam_acct_mgmt? The module checks that the cert is not expired/ > revoked... > The pam_pkcs11 module from opensc-project.org doesn't support pam_acct_mgmt currently, so it is not supported in this case. If this function is critical to have, we can request OPENSC and work with them to add this function in the future release. The module does check if the cert is expired or revoked in the pam_authenticate() function based on the pam_pkcs11 configuration. >> For more information, see http://www.opensc-project.org/pam_pkcs11 >> >> ========================================================= >> The pam_pkcs11 authentication/verification procedure >> ========================================================= >> The authentication and verification procedure is as following: >> >> Step 1: Find all certificate/private_key pair in the PKCS#11 token >> >> Step 2: Find the certificate/private_key pair that matches the user >> >> For each pair of the certificate and its associated private key > > If PAM_USER is not set when pam_pkcs11:pam_sm_authenticate() is invoked, > will it set PAM_USER, and if so, which cert will be used to derive the > username? (see more below) > The pam_pkcs11:pam_sm_authenticate() function will prompt the user for the username. It will set PAM_USER, after it found a matching certificate in the PKCS11 keystore. This function will loop all the certificates in the PKCS11 keystore to find the certificate that matches the user based on the mapping creteria specified in the configuration. The first matched one is the chosen one. > The pam_pkcs11.conf manpage mentions parameters that shouldn't be needed > on Solaris: > > | # Do not prompt the user for the passwords but take them from the > | # PAM_ items instead. > | use_first_pass = false; > | > | # Do not prompt the user for the passwords unless PAM_(OLD)AUTHTOK > | # is unset. > | try_first_pass = false; > | > | # Like try_first_pass, but fail if the new PAM_AUTHTOK has not been > | # previously set (intended for stacking password modules only). > | use_authtok = false; > > Or perhaps the token PIN should be seen as distinct from the AUTHTOK, in > which case that might require at least one parameter. > The password that it tries to get is actually the token PIN. I agree with you that these 3 arguments should not be needed, although they are presented in the OpenSC/pam_pkcs11.conf configuration example file, because this module will always need to prompt for the token PIN. > Also, if the home directory of the PAM_USER is on secure NFS, what > happens when the metaslot is used? Will the module find any smartcards? > Or will it fail? > Not very clear about the first question, so I will answer the 2nd one only for now and the short answer is "yes, this module will find the smartcard." When metaslot is used, a user can specify the persistent keystore by using the cryptoadm command or the METASLOT_OBJECTSTORE_SLOT environment variable. To use the smartcard as the keystore, first of all, a smartcard pkcs11 libary should be installed into the cryptographic framework (libpkcs11). Then the administrator uses the cryptoadm command or env variable to set the smartcard token as the metaslot persistent storage. The pam_pkcs11 module runs on top of libpkcs11, so it will find the smartcard token. This is actually a cryptographic framework feature. A smartcard token is treated as same as any other token under the libpkcs11 framework. Because there is no smartcard pkcs11 library available at the moment, I use softtoken for testing. SunRay folks are porting the OpenSC library (a smartcard PKCS11 library from opensc-project.org ) to Solaris. Once they are ready, we can really test this route. Please note that this case doesn't depend on any smartcard PKCS11 library. >> [...] >> >> ========================================== >> Deliverables: >> ========================================== >> Pam_pkcs11 module: >> >> /usr/lib/security/pam_pkcs11.so >> >> (Note: will support both 32bit and 64 bit versions.) >> >> Non-built-in Mapper modules: >> >> /usr/lib/pam_pkcs11/ldap_mapper.so >> /usr/lib/pam_pkcs11/opensc_mapper.so >> /usr/lib/pam_pkcs11/openssh_mapper.so > > Given that the mapper objects are volatile, how might these paths be > handled on upgrade if and when the cert->user mapping facility moves > into KMF? > The pam_pkcs11 project is a porting project, requested by UBS. Since the source of the pam_pkcs11 module is from a third party which we don't have control at all and the OpenSC library (the smartcard library from OpenSC) will depend on this module, I think we will be better off to leave this pam_pkcs11 module alone (keep using its own modules instead of changing it to use future KMF stuff). > Presumably the openssh and opensc mappers can only check that a given > cert maps to a given PAM_USER (since they cannot search all users' home > directories), and cannot derive a PAM_USER from a cert (whereas the > 'generic' and 'subject' mappers could do both). > > Will the 'ldap' mapper support the use of SASL/GSSAPI/Kerberos to > authenticate to the directory? > No. > Will the 'ldap' mapper support the use of the native LDAP configuration > instead of having to repeat that in pam_pkcs11.conf (when the DIT > containing these mappings is also the same as the native LDAP DIT)? > No. > Looking at the description of the 'ldap' mapper I see it can only really > support verification that a cert corresponds to a PAM_USER, not > derivation of a PAM_USER from a cert, and it appears to require storing > the entire cert in LDAP (as opposed to a fingerprint, or subject name, > or list of subjectAltNames). This being a third-party open source PAM Right. > module I think this is reasonable, but could we open RFEs in this area? > Yes, we can request OPENSC to support this in the future. > The 'krb' mapper should specify a realm name, no? Or is it formatting a > principal name of the form <PAM_USER>@<default-realm> and then comparing > it to the krb5 princname subjectAltName? > I havn't tested this part yet. Will get back to you when I have more info. > The pam_pkcs11.conf manpage in the materials refers to > /usr/lib/opensc-pkcs11.so and so on as well... This should be cleaned > up. > OK, will clean it up. >> (Note: will support both 32bit and 64 bit versions.) >> >> [...] >> >> Sample Mapfiles and script: >> >> /etc/security/pam_pkcs11/digest_mapping.example >> /etc/security/pam_pkcs11/subject_mapping.example >> /etc/security/pam_pkcs11/mail_mapping.example >> /etc/security/pam_pkcs11/make_hash_link.sh > > The above are not in the materials. > Right. Will fix this. I have requested Darren to put them to the materials directory, as I don't have write permission. >> Utility commands: >> >> /usr/lib/pam_pkcs11/pkcs11_inspect >> /usr/lib/pam_pkcs11/pklogin_finder >> /usr/lib/pam_pkcs11/pkcs11_eventmgr >> >> (Note: will support both 32bit and 64bit versions.) > > Shouldn't we already have pkcs11_inspect-like functionality in > pktool(1)? > This pkcs11_inspect command is a debugging tool for the pam_pkcs11 module, which is very different from pktool(1). It basically prints out the mapping data for each mapper specified in the pam_pkcs11 configuration file. This command is quite useful when a user is configuring the mapper list. > How will pkcs11_eventmgr be used? > The program is very simple, it periodically calls pkcs11 get_slot_info to find the # of slots. If number > 0, then state = card_present, otherwise, state = card_not_present. if state is changed, then print out the message. It doesn't seem very useful to me though. >> [...] >> >> Run: >> ------------------------------------------------------------------------ >> 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 >> Last login: Wed Sep 12 15:10:29 from comforter >> Sun Microsystems Inc. SunOS 5.11 snv_65 October 2007 >> ------------------------------------------------------------------------ >> >> Note that the "Smart card password" is the Solaris softtoken keystore >> password. > > So each token type can have its own prompt? > The prompt will be the same basically. Currently, the source uses "smart card" to prompt. Thanks, Huie-Ying
