198
edits
Security Policy: Difference between revisions
Jump to navigation
Jump to search
m
no edit summary
mNo edit summary |
mNo edit summary |
||
| Line 148: | Line 148: | ||
In each of the following services, since there is only one role, the user has access to '''ALL''' the services mediated by the application (for both client and server products). Routines have been specified for each service and denoted whether or not they are '''public''', meaning that they require no authentication to utilize, or '''private''', meaning that authentication must be provided prior to the routine being utilized. This model allows a type of '''safety state''' by allowing a NSS user to logout (thus disallowing any access to private services) without ending the session, and then log back in to re-authenticate private services rendered by the cryptographic module. All public and private services are listed in the following table: | In each of the following services, since there is only one role, the user has access to '''ALL''' the services mediated by the application (for both client and server products). Routines have been specified for each service and denoted whether or not they are '''public''', meaning that they require no authentication to utilize, or '''private''', meaning that authentication must be provided prior to the routine being utilized. This model allows a type of '''safety state''' by allowing a NSS user to logout (thus disallowing any access to private services) without ending the session, and then log back in to re-authenticate private services rendered by the cryptographic module. All public and private services are listed in the following table: | ||
[http://wiki.mozilla.org/Section_C_Table_II Table II. Services ] | |||
==Bypass Capabilities== | |||
This section is applicable when NSS is invoked in FIPS mode. | |||
==Access Control Policy== | |||
The access control policy enforced by the cryptographic module must be sufficiently precise, and of sufficient detail to allow the operator and testers to know what security relevant data items the operator has access to while performing a service, and the modes of access he or she has to these data items. Also, the testers and operator must be able to know if and how the kinds of data items accessible changes when the service is invoked from each role in which it can be invoked. | |||
to | |||
=== Security Relevant Data Items === | |||
Security relevant data items consist of data types used for Certificate Storage and Retrieval, Digital Signatures, Encryption/Decryption, Generic Containers, Hashing, Key Generation, PKCS #5 Password-Based Encryption, PKCS #12 Personal Information Exchange, Private Key Storage and Retrieval, Pseudorandom Number Generation, and SSL Session ID Cache (Secret Management). | |||
All security relevant data items are identified by category, type, name, and description in the following table: | |||
[http://wiki.mozilla.org/Section_C_Table_III Table III. Security Data Items ] | |||
=== Service Relationships to Security Relevant Data Items Matrix === | |||
[http://wiki.mozilla.org/Section_C_Table_IV Table IV. Service Relationships ] | |||
== Means of Access == | |||
Prior to execution of the Client or Server products, the Security Libraries are stored on disk in compiled binary form. NSS relies on Discretionary Access Controls (DAC) to protect the binary image from being tampered with. | |||
== Zeroization == | |||
Within the Security Libraries, there are a number of explicit zeroization steps that are taken to clear the memory region previously occupied by a private key or password. In summary, private keys are not stored in plaintext. Any key material that has been unwrapped for use is zeroed once the use is complete. The function used to both zero and free memory used by private key material is PORT_ZFree(). | |||
== Role-based Authentication == | |||
Since all NSS-based products utilize role-based authentication, and all products use a single-role mechanism referred to above as a NSS User, authentication shall always be required upon initializing the FIPS Cryptographic Module. This is true of all NSS-based client and server products, and shall be handled via the PKCS #11 mechanism of required authentication. | |||
== Identity-based Authentication == | |||
This section is not applicable to NSS since it is only applicable to products attempting to be certified to security level three or four. | |||
== Results of FIPS 140-2 Level 2 Maintenance Validation of NSS 3.11.5 == | |||
== Results of FIPS 140-2 Level 1 Maintenance Validation of NSS 3.11.5 == | |||
== Platform List == | |||