Rolesandservices

This is a draft document.

Specification of Roles

A series of security libraries represent the cryptographic module which present the same application programmer interface (API ) to client and server products utilizing NSS. There are minor variations, listed in the module interfaces description, but these do not break the following definition of roles. The NSS cryptographic module utilizes a single role approach -- this role is a combination of both the User Role and the Cryptographic Officer Role, and will be referenced below as NSS User . A NSS User utilizes secure services, and is also responsible for making decisions related to retrieval, updating, and deletion of keys from their key database. This is true for both client and server products. For multiple user products, like the HTTP Server, the server still operates in this single role paradigm, under a single identity.

Authentication Policy

The NSS cryptographic module utilizes Role-Based Authentication - An operator who is allowed to use the cryptographic module must perform an authentication sequence using information unique to that operator (individual password) to perform sensitive services using the cryptographic module. Role-based authentication is utilized to safeguard a users private key information. However, Discretionary Access Controls (DAC) are used to safeguard all other NSS User information (e.g., the Public Key Certificate database). An NSS User may use a product (e.g. Netscape Navigator) without establishing a personal private key -- e.g., they may utilize SSL 3.0 Server Authentication without having a private key established. However, to enable SSL on the server products, a private key and public key certificate are required to enable secure services. An individual password is required in order to start the server -- this password is used to decrypt the private key.

Specification of Maintenance Roles

This section is not applicable to the NSS cryptographic module since it does not have a Maintenance Role.

Multiple Concurrent Operator Roles and Services

Since NSS-based applications always operate under a single role, under a single identity, no separate concurrent processes take place within an NSS-based application. In the case of separate threads of execution within the same process, NSS's threading model consists of a shared data segment with separate stack instances, and does not allow threads to leak insecurity into or out of the given process. Further, since a thread is not a separate process, and all threads of a given process live within the confines of that process, then all threads are subject to the same security imposed on the process itself.

Specification of Services

1. The vendor documentation shall fully describe each service including its purpose and function. Possible services may include, but not be limited to, the following: Cryptographic operations such as encryption, decryption, message integrity, digital signature generation, digital signature verification, and other operations that require the use of cryptography.
2. Key management operations such as key and parameter entry, key generation, key output , key archiving, key zeroization, and other key management functions.
3. Cryptographic management functions such as audit parameter entry and setting, alarm handling and resetting, and other cryptographic management functions.
4. Performance of operator-selectable self tests, such as cryptographic algorithm tests, software/firmware tests , critical functions tests, statistical random number generator tests, or any additional tests that can be initiated by an operator.

The vendor documentation shall specify, for each service, the service inputs, corresponding service outputs, and the authorized role or roles in which the service can be performed. Service inputs shall consist of all data or control inputs to the module that initiate or obtain specific services, operations, or functions. Service outputs shall consist of all data and status outputs that result from services, operations or functions initiated or obtained by service inputs. The vendor may supply a matrix that displays the services that can be performed in each role.

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: