Re: SEC_ERROR_LIBRARY_FAILURE too vague of an error message
Robert Wagner wrote: Let me see if I am following you here... if you have more than one slot in your environment then you'll have modules declared in secmod.db... A module may contain multiple slots. All the slots for a certain type of device will typically be in one module. A module corresponds to a device driver, typically. and the secmod.db directives correlate to dynamically loaded libraries... Right. one library is loaded for each module. those libraries will install their own contextual password callback. No. The application installs the password callback. PKCS#11 modules are not supposed to do UI, at least not through the host system. If the device has some kind of PIN input, e.g. a little keypad, then the module can use it, but otherwise the application is supposed to handle UI. Thus my application should install a password callback if and only if it is using the internal slot and/or key as the other modules solicit their password in their own way. I think you always should install the password callback. Note that the password callback function doesn't necessarily need to do UI. It just needs to return a password to the caller. -- Nelson Bolyard Netscape Communications (subsidiary of AOL) Disclaimer: I speak for myself, not for Netscape
Re: SEC_ERROR_LIBRARY_FAILURE too vague of an error message
Please, please, please, please don't think that I am not grateful for your suggestion but how would I have known to do what you're suggesting? There was no way to know. Beyond using NSS for SSL, actual documentation for NSS is scarce. That is primarily why I try to answer the questions directly in this newsgroup. Reason: PK11_DoPasswordCheck is not in the public functions documented at: http://www.mozilla.org/projects/security/pki/nss/ref/nssfunctions_33.html The documented way of handling Passwords is to define the PK11_SetPaswordFunc() to handle password callbacks and just call NSS. Passwords for tokens that need to be authenticated are handled through this callback. Also, be sure that you are using the correct slot. there are two internal slots, the database slot and the crypto slot, the latter does not have a password. The slot I am using is fetched by a call to PK11_GetInternalSlot(); That returns the internal crypto slot. PK11_GetInternalKeySlot() returns the internal database token, which does have a password on it. NOTE: if you do this, your application will only work with the internal token. The more correct way would be to allow the password callback to happen automatically, or to authenticate to all tokens at startup by calling PK11_GetAllTokens, then loop over the list calling PK11_Authenticate. BTW even in this case you need to define your Password callback function, PK11_Authenticate() just forces the authentication to happen. After some grepping through NSS I haven't found PK11_DoPasswordCheck. Should that be just PK11_DoPassword? Doh! That's what I get for trying to do this from memory. The actual function you want is PK11_Authenticate(). Sorry. Hope this helps. bob
Re: SEC_ERROR_LIBRARY_FAILURE too vague of an error message
Robert Relyea [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... Please, please, please, please don't think that I am not grateful for your suggestion but how would I have known to do what you're suggesting? There was no way to know. Beyond using NSS for SSL, actual documentation for NSS is scarce. That is primarily why I try to answer the questions directly in this newsgroup. Reason: PK11_DoPasswordCheck is not in the public functions documented at: http://www.mozilla.org/projects/security/pki/nss/ref/nssfunctions_33.html The documented way of handling Passwords is to define the PK11_SetPaswordFunc() to handle password callbacks and just call NSS. Passwords for tokens that need to be authenticated are handled through this callback. Also, be sure that you are using the correct slot. there are two internal slots, the database slot and the crypto slot, the latter does not have a password. The slot I am using is fetched by a call to PK11_GetInternalSlot(); That returns the internal crypto slot. PK11_GetInternalKeySlot() returns the internal database token, which does have a password on it. NOTE: if you do this, your application will only work with the internal token. A configuration source supplies my application with the token's name with the default set to use PK11_GetInternalSlot otherwise I grab the configuration's requested token via PK11_FindSlotByName. The more correct way would be to allow the password callback to happen automatically, or to authenticate to all tokens at startup by calling PK11_GetAllTokens, then loop over the list calling PK11_Authenticate. BTW even in this case you need to define your Password callback function, PK11_Authenticate() just forces the authentication to happen. Let me see if I am following you here... if you have more than one slot in your environment then you'll have modules declared in secmod.db... and the secmod.db directives correlate to dynamically loaded libraries... those libraries will install their own contextual password callback. Thus my application should install a password callback if and only if it is using the internal slot and/or key as the other modules solicit their password in their own way. Am I close? Robert After some grepping through NSS I haven't found PK11_DoPasswordCheck. Should that be just PK11_DoPassword? Doh! That's what I get for trying to do this from memory. The actual function you want is PK11_Authenticate(). Sorry. Hope this helps. bob
Re: SEC_ERROR_LIBRARY_FAILURE too vague of an error message
You should call the PK11_DoPasswordCheck() and register the password callback. Calling PK11_CheckUserPassword is only for use within your callback if you are trying to handle protected pin path devices. Also, be sure that you are using the correct slot. there are two internal slots, the database slot and the crypto slot, the latter does not have a password. bob Robert Wagner wrote: I have a working client/server application that is using NSS 3_3_1_RTM. One check my application does is verify if the password supplied is correct. After I initialize and configure all of NSS, my application calls PK11_CheckUserPassword. PK11_CheckUserPassword returns with SEC_ERROR_LIBRARY_FAILURE regardless if the password is correct or not. PK11_CheckUserPassword accepts two arguments: slot and password. Both arguments are viable before the call is made. Yet if I ignore the failure, everything else works fine (assuming the password is correct). The question is why is NSS happy but PK11_CheckUserPassword isn't? TIA, Robert
Re: SEC_ERROR_LIBRARY_FAILURE too vague of an error message
Robert, Robert Wagner wrote: I have a working client/server application that is using NSS 3_3_1_RTM. One check my application does is verify if the password supplied is correct. After I initialize and configure all of NSS, my application calls PK11_CheckUserPassword. When you call PK11_CheckUserPassword, are you using the NSS internal database as a token, or an external token (eg. smartcard) ? PK11_CheckUserPassword returns with SEC_ERROR_LIBRARY_FAILURE regardless if the password is correct or not. PK11_CheckUserPassword accepts two arguments: slot and password. Both arguments are viable before the call is made. Yet if I ignore the failure, everything else works fine (assuming the password is correct). Is it possible that you have some other piece of code in your program that logs you in to the token ? The question is why is NSS happy but PK11_CheckUserPassword isn't? Possibly it is a bug in the PKCS#11 module you are using. Look at pk11err.c, specifically the implementation PK11_MapError() . This will show you the error codes returned from the token that end up mapping to SEC_ERROR_LIBRARY_FAILURE . This mapping is done so the higher levels of code in NSS can take proper action based on categories of errors. You could set a breakpoint within PK11_MapError to see the exact PKCS#11 error code returned from the module.
