The IKE daemon allows a stack to be defined as a network security services (NSS) client. When a stack is defined as an NSS client, the IKE daemon uses at least one network security service on behalf of that stack. Network security services are provided by an NSS server. An NSS server provides a certificate service and a remote management service. For details about the configuration of an NSS server, see Network security services.
The certificate service of the NSS server is used to create and verify digital signatures on behalf of an NSS client. Certificates for stacks that are configured to use the NSS certificate service must be on the key ring of the NSS server. For details about configuring the IKE daemon to use the NSS certificate service, see Step 5: Setting up the IKE daemon for digital signature authentication (optional).
The remote management service of the NSS server enables the IP filter rules and Security Associations of an NSS client to be monitored and managed from the system on which the NSS server is executing. For details about using the ipsec command to monitor and manage NSS clients, see z/OS Communications Server: IP System Administrator's Commands. For details about using the IPSec NMI to monitor and manage NSS clients, see z/OS Communications Server: IP Programmer's Guide and Reference.
The NSS server does not need to be on the same system as the IKE daemon. The location of the NSS server is specified by the NetworkSecurityServer parameter and optionally by the NetworkSecurityServerBackup parameter of the IkeConfig statement. For additional details about the IkeConfig statement, see z/OS Communications Server: IP Configuration Reference
The NssStackConfig statement in the IKE daemon configuration file is used to define a stack as an NSS client. The ServiceType parameter of the NssStackConfig statement identifies what network security services are to be used by a stack. When a ServiceType value Cert is specified, the NSS certificate service is used. When a ServiceType value RemoteMgmt is specified, the NSS remote management service is used. The ServiceType parameter can be specified multiple times. For complete details about the NssStackConfig statement, see z/OS Communications Server: IP Configuration Reference.
When a stack is configured to use the NSS remote management service, the NSS server can send the IKE daemon a request to switch between default IP filter policy and IP security filter policy. To change filter sets, the IKE daemon creates or deletes a specific marker file that the stack accesses. This marker file is the same marker file that is created or deleted by the ipsec command when the ipsec -f reload or ipsec -f default IP filter options are specified locally without the -z option. For details about the marker file, see z/OS Communications Server: IP System Administrator's Commands.
The ClientName parameter of the NssStackConfig statement associates an NSS client name with a stack. This is the name by which the NSS server knows the stack. The UserId parameter of the NssStackConfig statement associates the NSS client name with a user ID defined on the NSS server's system. The NSS server uses both the client name and user ID when checking SERVAUTH profiles to verify that an NSS client is authorized to request a specific action. For details about SERVAUTH profiles checked by the NSS server, see Network security services.
The AuthBy parameter of the NssStackConfig statement defines how the user ID associated with a stack that is acting as an NSS client is to be authenticated. This user ID can be authenticated using a password or a PassTicket. When a PassTicket is used, the application key is stored in the local external security manager database.
To store the application key in the local external security manager database, the secure signon function must be enabled and a PTKTDATA profile must be created. This key must be associated with an application ID of the NSSD. For specific information about enabling the secure signon function and defining profiles to be used by the single signon function, see z/OS Security Server RACF Security Administrator's Guide.
The following command is an example of a RACF® command that you can issue to store the application key for the NSS server and NSS clients:
RDEFINE PTKTDATA NSSD SSIGNON(KEYMASKED(E001193519561977)) UACC(NONE)Figure 1 shows a partial configuration for the IKE daemon on system SYSTEMA. The NetworkSecurityServer parameter on the IkeConfig statement specifies that the IKE daemon is configured to use network security services from an NSS server that is listening on IP address 9.1.1.1. One NssStackConfig statement is shown. The ClientName parameter associates stack STACK1 with an NSS client name SYSTEMA_STACK1. This is the name by which the NSS server knows this stack. The UserId parameter associates the client name with the user ID A1S1. The A1S1 user ID must be defined on the NSS server's system. Both the client name and user ID are used by the NSS server when verifying the authorization of an NSS client. The multiple ServiceType parameters indicate that the IKE daemon uses both the NSS certificate service and the NSS remote management service.
The IKE daemon requires that communication with the NSS server be protected using AT-TLS. During the AT-TLS handshake, the NSS server provides a certificate that can be used to authenticate its identity. The IKE daemon examines this certificate and verifies that the identity in the certificate matches the identity specified on the NetworkSecurityServer parameter of the IkeConfig statement.
The IKE daemon does not perform any SERVAUTH checks when processing an IPSec monitoring request or an IPSec management request from the NSS server. The NSS server performs SERVAUTH checks to make sure that the requester of an IPSec monitoring or management request is authorized. For details about the SERVAUTH requirements imposed by the NSS server, see z/OS Communications Server: IP Programmer's Guide and Reference.
The IKE daemon does perform a SERVAUTH check for the EZB.NETMGMT.sysname.sysname.IKED.DISPLAY profile when processing a local NMI request to display information about current NSS client state. For additional details, see z/OS Communications Server: IP Programmer's Guide and Reference.