Network security services for the IPSec discipline

The network security services (NSS) server provides a set of network security services for the IPSec discipline. These services include a certificate service and a remote management service. The certificate service and remote management service are used by NSS IPSec clients. When an NSS IPSec client uses the certificate service, the NSS server creates and verifies digital signatures on the behalf of the NSS IPSec client. The need to store certificates and keying information at the client, which might be in a less secure zone of the network, is eliminated. When an NSS IPSec client uses the remote management service, the NSS server routes IPSec network management interface (NMI) requests to that NSS IPSec client, which enables the NSS IPSec client to be managed remotely. The NSS IPSec client provides the NSS server with responses to these requests.

You can configure the IKE daemon to act as an NSS IPSec client on behalf of multiple TCP/IP stacks. Each stack appears as a separate NSS IPSec client to the NSS server. Use the -z option on the ipsec command or use the IPSec NMI to manage NSS IPSec clients that use the remote management service provided by the NSS server. For details about using the ipsec command to manage NSS IPSec clients, see z/OS Communications Server: IP System Administrator's Commands. For details about using the IPSec NMI to manage NSS IPSec clients, see z/OS Communications Server: IP Programmer's Guide and Reference.

An NSS IPSec client requires a SAF user ID on the NSS server system. To use the services provided by the NSS server, this user ID must have read access to specific SERVAUTH resource profiles. The following SERVAUTH resource profiles apply to an NSS IPSec client:

• EZB.NSS.sysname.clientname.IPSEC.CERT

  This profile authorizes an NSS IPSec client to access the IPSec certificate service of the NSS server.

• EZB.NSS.sysname.clientname.IPSEC.NETMGMT

  This profile authorizes an NSS IPSec client to use the IPSec remote management service of the NSS server. The IPSec remote management service of the NSS server enables an NSS IPSec client to be managed by the NSS server.

• EZB.NSSCERT.sysname.mappedlabelname.HOST

  This profile authorizes an NSS IPSec client to access a personal certificate or a site certificate on the key ring of the NSS server. A profile entry is required for each personal certificate or site certificate associated with an NSS IPSec client. The certificates are used during a phase 1 security association negotiation that uses the digital signature mode of authentication.

• EZB.NSSCERT.sysname.mappedlabelname.CERTAUTH

  This profile authorizes an NSS IPSec client to access a CERTAUTH certificate on the key ring of the NSS server. A profile entry is required for a CERTAUTH certificate that is connected to the key ring of the NSS server if the following conditions are true:

  • That certificate's label is configured on the CaLabel parameter of a RemoteSecurityEndpoint statement within the IPSec policy definitions for an NSS IPSec client. For details about the RemoteSecurityEndpoint statement, see z/OS Communications Server: IP Configuration Reference.
  • An NSS IPSec client wants to include information about the corresponding certificate authority (CA) to a remote security endpoint. The information is part of the default set of CAs sent when the CaLabel parameter is not specified on the matching RemoteSecurityEndpoint statement.

For additional details about the definition of these profiles, see Network security services.

The following SERVAUTH resource profiles apply when you use the -z option of the ipsec command or the IPSec NMI to manage NSS IPSec clients:

• EZB.NETMGMT.sysname.clientname.IPSEC.DISPLAY

  This profile authorizes a user ID to issue the ipsec command with the -z option to obtain information about an NSS IPSec client, or to make IPSec NMI requests to obtain information about an NSS IPSec client.

• EZB.NETMGMT.sysname.tcpname.IPSEC.CONTROL

  This profile authorizes a user ID to make IPSec NMI requests to modify the IPSec state of a local stack.

• EZB.NETMGMT.sysname.clientname.IPSEC.CONTROL

  This profile authorizes a user ID to issue the ipsec command with the -z option to modify the IPSec state of an NSS IPSec client, or to make IPSec NMI requests to modify the IPSec state of an NSS IPSec client.

• EZB.NETMGMT.sysname.sysname.NSS.DISPLAY

  This profile authorizes a user ID to issue the ipsec command with the -x option or to make IPSec NMI requests to obtain information about an NSS server. This profile also authorizes a user ID to issue the nssctl command to make NMI requests to obtain information about an NSS server.

For additional details about the definition of the profiles to use the ipsec command to manage NSS IPSec clients, see z/OS Communications Server: IP System Administrator's Commands. For additional details about the definition of the profiles to use the IPSec NMI to manage NSS IPSec clients, see z/OS Communications Server: IP Programmer's Guide and Reference.

The following SERVAUTH resource profile applies when the -w option of the ipsec command or the IPSec NMI is used to display information about an IKE daemon's NSS IPSec clients:

• EZB.NETMGMT.sysname.sysname.IKED.DISPLAY

  This profile authorizes a user ID to issue the ipsec command with the -w option or make IPSec NMI requests to obtain information about an IKE daemon's NSS configuration.

For additional details about the definition of this profile to use the ipsec command to manage NSS IPSec clients, see z/OS Communications Server: IP System Administrator's Commands. For additional details about the definition of this profile to use the IPSec NMI to manage NSS IPSec clients, see z/OS Communications Server: IP Programmer's Guide and Reference.

Before accessing an IPSec network security service, an NSS IPSec client must present a valid credential. A valid credential consists of the user ID representing the NSS IPSec client and a valid password or PassTicket. For additional information about using a PassTicket, see z/OS Security Server RACF Security Administrator's Guide.

Certificates and private keys that represent an NSS IPSec client are stored on a single SAF key ring. The NSS server must have access to the certificates on this key ring. The private key associated with a certificate is never sent to the NSS IPSec client. When an NSS IPSec client uses the authentication mode of a digital signature, the NSS server creates a digital signature on the client's behalf. Before the NSS server accesses a personal certificate to create a digital signature on behalf of an NSS IPSec client, the NSS server verifies that the NSS IPSec client is authorized to use that certificate (and its associated private key) by checking the EZB.NSSCERT.sysname.mappedlabelname.HOST profile.

Certificates of certificate authorities that are supported by NSS IPSec clients must also be stored on this single key ring. The NSS server provides NSS IPSec clients with information about certificate authorities to which the client has access. The NSS IPSec client advertises certificate authority information to its peer when digital signature mode is used for authentication. The EZB.NSSCERT.sysname.mappedlabelname.CERTAUTH profile identifies which certificate authorities an NSS IPSec client can advertise to its IKE peers. For information about this profile name, see NSS server certificate label naming considerations.

Figure 1 shows an example of the IKE daemon acting as an NSS IPSec client for a single TCP/IP stack. The IKE daemon's configuration file identifies which network security services are to be used by a stack, as well as the information about the NSS server from which these services are to be obtained. If the NSS certificate service is enabled for a stack, the IKE daemon uses this service during a phase 1 negotiation when a digital signature mode of authentication is used. If the NSS IPSec remote management service is enabled for a stack, the IKE daemon responds to management requests initiated from the NSS server.

The example in Figure 1 is a trivial example involving one TCP/IP stack acting as an NSS client. As shown in Figure 2, the NSS server can provide services to many NSS clients. The IKE daemon on a z/OS® system can act as an NSS client for up to eight TCP/IP stacks (that is, one for each stack running on that system). Multiple IKE daemons can simultaneously access network security services. These IKE daemons do not have to be within the same sysplex as the NSS server.