434043 - problem with islogin delay check in the pkcs 11 wrapper layer

Status: NEW

(NSS :: Libraries, defect, P2)

Description

[Rob Crittenden]

If you initialize NSS, set FIPS mode, authenticate to the token and do an NSS_Shutdown() the token either isn't logged out or the login delay timer isn't reset. I'm not sure which.

This can be seen if you loop over init/fips/auth/access cert/shutdown. It will work the first time and fail all subsequent times when accessing the certificate.

This works fine when not in FIPS mode.

Comment 1

[Rob Crittenden]

Attachment: Sample program that demonstrates the issue

This program just loops over initializing and shutting down NSS, trying to find a certificate in between. It works fine when the -f flag is not included but fails when it is.

A sample run is:

$ fips -d alias -n Server-Cert -c password -f
Initializing NSS round 0 in alias
Enabling FIPS mode
Shutdown successful.

Initializing NSS round 1 in alias
Enabling FIPS mode
Error in function PK11_FindKeyByAnyCert: -12285

$ fips -d alias -n Server-Cert -c password  
Initializing NSS round 0 in alias
Shutdown successful.

Initializing NSS round 1 in alias
Shutdown successful.

Initializing NSS round 2 in alias
Shutdown successful.

Initializing NSS round 3 in alias
Shutdown successful.

Initializing NSS round 4 in alias
Shutdown successful.

Comment 2

[Wan-Teh Chang]

The behavior of the FIPS mode login rate limiting code is that
FC_Login does PR_Sleep(loginWaitTime) before failing with an incorrect
password.  When the password is correct, it doesn't call PR_Sleep.
So this bug should have nothing to do with the FIPS mode login rate
limiting code.

Comment 3

[Robert Relyea]

This is not a FIPS token bug. The problem isn't with the Sleep in FIPS mode, but the fact login is required for the operation in FIPS mode. The problem is in islogin delay check in the pkcs 11 wrapper layer.

Comment 4

[Sandeep Cavale]

I wanted to know if the logged problem is same as that discussed in this thread below:
http://www.nabble.com/SSL-Certificate-not-found-while-starting-apache-with-mod_nss-td21330548.html

We are trying to configure mod_nss with a Sun Cryptographic Accelerator on a Solaris machine (NSS version we tried to use was 3.12.3) and I see in the Apache error log it is similar to what was seen in the discussion above. Besides this, it seems that this bug is crashing our accelerator card (I have logged this issue with the Sun support team, as this shouldn't have caused the card to crash in the first place) But I'd like to know if this bug (raised for 3.11.7) is valid for 3.12.3 as well..

Is there any workaround here for this issue? This problem seems to happen irrespective of whether I use "Sun Metaslot" or the softtoken...