Nicolas Williams wrote: Thank you for the suggestions and etc. For most of issues brought up by Gary yesterday, I will address them later after I have a chance to discuss with Darren first. However, I would like to share my thoughts now about a couple of items.
>>>> 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"? > > I'm not on the i-team, but I suspect that the example is using the > softtoken as though it were a smartcard, and pam_pkcs11 doesn't know > that it isn't really. > Yes, that's exactly the situation. Although the pam_pkcs11 module supports any PKCS#11 tokens, it is typically used by a Smart-card PKCS#11 token. This might be the reason that the pam_pkcs11 module includes "Smart card" in their prompts, I guess. To resolve the confusion when a user uses softtoken or others as the keystore, we can remove the "Smart Card" words from the prompts in the pam_pkcs11 source. > Of course, if the softtoken lives on an NFS share accessed w/o sec=krb5i > or p, then there are some security considerations... Even if secure NFS > or local home directories are used there's the issue of how much control > the user should be given over how to authenticate them (but then, ssh > already allows users to do that with pubkey userauth). > > A knob for controlling whether the softtoken can be used by pam_pkcs11 > would be useful. Control over where the softtoken lives would be good > also (IIUC the only way to do that is through the SOFTTOKEN_DIR > environment variable, but that's not good enough for a PAM module). > Glad that you brought this up. This is really a serious problem and I also found out the exact issue last Friday. I have a solution for it. I'm coding it and will test it with softtoken. Once the solution is successfully tested and reviewed, I will contribute it back to the OPENSC community. My solution is to replace the "slot_num" entry in the pam_pkcs11.conf configuration file with a "slot_info" entry. For example, if the pam_pkcs11 is configured to use the Solaris softtoken, then the slot_info entry will look like slot_info = "Sun Crypto Softtoken" At the runtime, the pam_pkcs11 module will find the slot with the same slot information first, then will call C_GetTokenInfo() to see if the token is presented or not. If the token is presented, then the operation will continue on that token. Otherwise, the operation will return an error immediately. Note that we can not use "token_info" for this case, because each person will have his/her own smartcard token and a token will be presented only when a smartcard is inserted into the card reader. For the softtoken situation, the token will be in the default location, home directory for a regular user. Huie-Ying
