Top Secret Certificate definition for NSS and AT-TLS

Products

Top Secret

Issue/Introduction

Convert RACF digital certificate setup commands for NSS and AT-TLS to Top Secret from IBM Redbook;

"IBM z/OS V2R2 Communications Server TCP/IP Implementation Volume 4 Security and Policy-Based Networking (sg248363)"

Resolution

Certificate definition for NSS and AT-TLS

First, examine the CA certificate definition that is shown in Example 9-1. This certificate is the self-signed CA certificate with which we sign our SITE certificate for the NSS daemon.

Example 9-1

racdcert certauth gencert
subjectsdn( o('IBM Corporation')
ou('ITSO Certificate Authority')
C('US'))
NOTBEFORE(DATE(2008-11-10))
NOTAFTER(DATE(2012-11-11))
keyusage(certsign)
withlabel('CS19 ITSO CA1')
setropts raclist(DIGTCERT) refresh
racdcert certauth list(label('CS19 ITSO CA1')

TSS GENCERT(CERTAUTH) DIGICERT(itsoca) SUBJECTN(‘o=”IBM Corporation” ou=”ITSO Certificate Authority” C=”US”’) NBDATE(11/10/28) NADATE(11/10/28) KEYUSAGE(CERTSIGN) LABLCERT('CS19 ITSO CA1')

TSS LIST(CERTAUTH) DIGICERT(itsoca)

Next, examine the shared SITE certificate that we used for several servers, such as FTP and TN3270, on behalf of SSL/TLS. We decided to use the same SITE certificate to represent the NSS server during the SSL/TLS flows.

Example9-2 shows the JCL that we used to create the NSS server certificate.

Example 9-2   SITE certificate for SSL/TLS communication between NSS server and client

racdcert site gencert subjectsdn(cn('ITSO.IBM.COM')   -
o('IBM Corporation')                          -
ou('ITSO CS19 Shared SITE')                   -
C('US'))                                      -
NOTBEFORE(DATE(2008-11-11))                    -
NOTAFTER(DATE(2012-11-11))                     -
withlabel('CS19 ITSO SharedSite1')            -
signwith(certauth label('CS19 ITSO CA1')
racdcert site list(label('CS19 ITSO SharedSite1'))

TSS GENCERT(CERTSITE) DIGICERT(itsosite) SUBJECTN(‘CN=”ITSO.IBM.COM” o=”IBM Corporation” ou=”ITSO CS19 Shared SITE” C=”US”’) NBDATE(11/10/28) NADATE(11/10/28) KEYUSAGE(CERTSIGN) LABLCERT('CS19 ITSO SharedSite1') SIGNWITH(CERTAUTH,itsoca)

TSS LIST(CERTSITE) DIGICERT(itsosite)

Example9-3 shows the JCL that we used to create the key ring for AT-TLS and to attach the certificates to that key ring.

racdcert ID(TCPIP) ADDRING(SharedRing1)
racdcert ID(TCPIP) CONNECT(CERTAUTH                   -
LABEL('CS19 ITSO CA1')             -
RING(SharedRing1)                  -
USAGE(CERTAUTH)
racdcert ID(TCPIP) CONNECT(SITE                       -
LABEL('CS19 ITSO SharedSite1')     -
RING(SharedRing1)                  -
DEFAULT                            -
USAGE(PERSONAL)
setropts raclist(DIGTRING) refresh
setropts raclist(DIGTCERT) refresh
racdcert listring(SharedRing1) id(TCPIP)

TSS ADD(TCPIP) KEYRING(shrring1) LABLRING(SharedRing1)

TSS ADD(TCPIP) KEYRING(shrring1) RINGDATA(CERTAUTH,itsoca) USAGE(CERTAUTH)

TSS ADD(TCPIP) KEYRING(shrring1) RINGDATA(CERTSITE,itsosite) USAGE(PERSONAL) DEFAULT

TSS LIST(TCPIP) KEYRING(shrring1)

IKED certificate definition for NSS client

To create the key ring for the NSS server and connect the required certificates to NSSD’s key ring, complete the following steps:

Review the JCL in Example 9-4, which shows how we exported the NSS client’s certificate to a data set. Remember to name a password for this operation. It is used again later when you import the certificate.

RACDCERT ID(IKED) EXPORT(LABEL('IKE Daemon on SC32')) - DSN('CS02.CERT.EXPORT32') -
FORMAT(PKCS12DER) -
PASSWORD('security')

TSS EXPORT(CERTSITE) DIGICERT(itsosite) DCDSN('CS02.CERT.EXPORT32') FORMAT(PKCS12DER) PKCSPASS('security')

Examine the JCL that we used to delete the certificate from the RACF database that is shown in Example 9-5

racdcert ID(IKED) delete -
(label('IKE Daemon on SC32'))
setropts raclist(facility) refresh
racdcert ID(IKED) list(Label('IKE Daemon on SC32'))

TSS REMOVE(CERTSITE) DIGICERT(itsosite)
TSS LIST(CERTSITE) DIGICERT(itosite)

Import the certificate with its private key back into the RACF database, but associate it with the user ID of NSSD, as shown in Example 9-6.

RACDCERT ID(NSSD) ADD('CS02.CERT.EXPORT32') -
WITHLABEL('IKE Daemon on SC32') TRUST -
PASSWORD('security')
setropts raclist(facility)    refresh

TSS ADD(CERTSITE) DIGICERT(itsosite) DCDSN('CS02.CERT.EXPORT32') LABLCERT('IKE Daemon on SC32') TRUST PKCSPASS('security')
Create the NSSD key ring and add the NSS Client certificate and private key to the NSSD key ring, as shown in Example 9-7

racdcert ID(NSSD) ADDRING(NSSD_keyring)
racdcert ID(NSSD) CONNECT(LABEL('IKE Daemon on SC32')
RING(NSSD_keyring)
USAGE(PERSONAL)
setropts raclist(DIGTRING) refresh
setropts raclist(DIGTCERT) refresh
racdcert listring(NSSD_keyring) id(NSSD)

TSS ADD(NSSD) KEYRING(itsoring) LABLRING(NSSD_keyring)
TSS ADD(NSSD) KEYRING(itsoring) RINGDATA(CERTSITE,itsosite) USAGE(PERSONAL)

TSS LIST(NSSD) KEYRING(itsoring)

Add the CA Certificates that have signed the certificates of the NSS Client’s VPN partners to the NSSD key ring, as shown in Example 9-8. Example 9-8 Adding the CA certificates to the NSSD key ring.

racdcert ID(NSSD) CONNECT(CERTAUTH                   -
LABEL('My Local Certificate Authority')
RING(NSSD_keyring)
USAGE(CERTAUTH))
setropts raclist(DIGTRING) refresh
setropts raclist(DIGTCERT) refresh
racdcert listring(*) id(nssd)

TSS ADD(NSSD) KEYRING(itsoring) RINGDATA(CERTAUTH,itsoca) USAGE(CERTAUTH)
TSS LIST(NSSD) KEYRING(itsoring)

9.2.6 Configuring authorizations for NSS

Create a user ID for the NSSD started task and associate it with a required UID of 0.

ADDUSER TCPIP DFLTGRP(TCPGRP) OMVS(UID(0) HOME(‘/))
RDEFINE STARTED NSSD.* STDATA(USER(NSSD))
SETROPTS RACLIST(STARTED) REFRESH
SETROPTS GENERIC(STARTED) REFRESH

TSS ADD(TCPIP) UID(0) HOME(‘/’) GROUP(TCPGRP) DFLTGRP(TCPGRP)

TSS ADD(STC) PROCNAME(NSSD) ACID(NSSD)

Permit the NSSD user ID to SYS1.PARMLIB, as shown in the following example:

PERMIT SYS1.PARMLIB ID(NSSD) ACCESS(READ)

Define the key ring controls for the NSS client certificates, as shown in the following example:

RDEFINE FACILITY IRR.DIGTCERT.ADD UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.ADDring uacc(NONE)
RDEFINE FACILITY IRR.DIGTCERT.CONNECT uacc(NONE)
RDEFINE FACILITY IRR.DIGTCERT.GENREQ uacc(NONE)
RDEFINE FACILITY IRR.DIGTCERT.GENCERT uacc(NONE)

TSS ADD(owningacid) IBMFAC(IRR.)
Define the key ring controls for the NSS client certificates, as shown in the following example:

RDEFINE FACILITY IRR.DIGTCERT.ADD UACC(NONE)
RDEFINE FACILITY IRR.DIGTCERT.ADDring uacc(NONE)
RDEFINE FACILITY IRR.DIGTCERT.CONNECT uacc(NONE)
RDEFINE FACILITY IRR.DIGTCERT.GENREQ uacc(NONE)
RDEFINE FACILITY IRR.DIGTCERT.GENCERT uacc(NONE)

TSS ADD(owningacid) IBMFAC(IRR.) Already done in previous step.

Permit the administrator user IDs that will administer key ring access to the following facility classes. The users CS01 through CS06 belong to the RACF group SYS1, as shown in the following example:

PERMIT IRR.DIGTCERT.ADD CLASS(FACILITY) ID(SYS1) ACC(CONTROL)
PERMIT IRR.DIGTCERT.ADDRING CLASS(FACILITY) ID(SYS1) ACC(UPDATE)
PERMIT IRR.DIGTCERT.CONNECT CLASS(FACILITY) ID(SYS1) ACC(CONTROL)
PERMIT IRR.DIGTCERT.GENCERT CLASS(FACILITY) ID(SYS1) ACC(CONTROL)
PERMIT IRR.DIGTCERT.GENREQ CLASS(FACILITY) ID(SYS1) ACC(CONTROL)
PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ID(SYS1) ACC(CONTROL)
PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ID(SYS1) ACC(UPDATE)
SETROPTS RACLIST(FACILITY) REFRESH

TSS PER(SYS1) IBMFAC(IRR.DIGTCERT) ACC(CONTROL)
Permit the NSSD user ID to have READ access to the key rings that it owns and to the key rings that it does not own, as shown in the following example:

PERMIT IRR.DIGTCERT.LIST CLASS(FACILITY) ID(NSSD) ACC(CONTROL)
PERMIT IRR.DIGTCERT.LISTRING CLASS(FACILITY) ID(NSSD) ACC(UPDATE)
SETROPTS RACLIST(FACILITY) REFRESH

TSS PER(NSSD) IBMFAC(IRR.DIGTCERT) ACCESS(CONTROL)

Tip: In our scenarios, NSSD owns the NSSD key ring for the IPSec (IKED) clients. For this key ring, NSSD requires only READ access. However, our scenarios also require access to the AT-TLS key rings, which are owned by the user ID of TCPIP. Therefore, the NSSD user ID requires CONTROL and UPDATE access to the IRR.DIGTCERT.LIST and IRR.DIGTCERT.LISTRING facility classes respectively, as shown in our examples.
Permit the NSSD user ID to the BPX.DAEMON facility class, as shown in the following example:

PERMIT BPX.DAEMON CLASS(FACILITY) ID(NSSD) ACCESS(READ)
setropts raclist(facility) refresh

TSS PER(NSSD) IBMFAC(BPX.DAEMON ) ACCESS(READ)
If you chose to implement secured signon for the NSS client’s user ID with passtickets, follow the instructions for passticket authorization as described in z/OS Communications Server: IP Configuration Guide, SC27-3650. In our scenario, we elected to use a simple password authentication for our NSS client user IDs; therefore, we skipped this step.
If you chose to implement RACF certificate name filtering for an NSS XML client, follow the instructions for certificate name filtering as described in z/OS Communications Server: IP Configuration Guide, SC27-3650. In our scenario, we chose not to map x.500 distinguished names to a RACF ID; therefore, we skipped this step. Tip: The next implementation steps require that you authorize SERVAUTH access to the NSS client. Each NSS discipline and its service requires a different set of SERVAUTH authorizations, as shown in the following examples:

IPSec Certificate Service
EZB.NSS.sysname.symbolic_clientname.IPSEC.CERT
IPSec Network Management Service
EZB.NSS.sysname.symbolic_clientname.IPSEC.NETMGMT
XML Appliance SAF Access Service EZB.NSS.sysname.symbolic_clientname.XMLAPPLIANCE.SAFACCESS

NSS IPSec (IKED) client

To authorize an NSS IPSEC (IKED) client, complete the following steps:

Create a user ID for the NSS client. In our scenario, we decided named the IPSec client NSS32A. The client’s password is NSSPASS. Example 9-10 shows the JCL that we used to create this user ID. Example 9-10 IPSec (IKED) client user ID and password generation

ADDUSER NSS32A PASSWORD(NEW2DAY) +
NAME('ID for Comm Server') +
OWNER(HAIMO) UACC(READ) DFLTGRP(SYS1) +
AUTHORITY(JOIN) GRPACC +
OMVS(AUTOUID HOME(/u/nss32a) PROGRAM(/bin/sh))

TSS CREATE(NSS32A) NAME('ID for Comm Server') DEPT(dept) PASSWORD(NEW2DAY)

TSS ADD(NSS32A) UID(?) HOME(/u/nss32a) OMVSPGM(/bin/sh)

TSS ADD(NSS32A) PROFILE(SYS1)

TSS ADD(NSS32A) GROUP(omvs_group_acid) DFLTGRP(omvs_group_acid)

CONNECT NSSXML GROUP(SYS1) OWNER(HAIMO) AUTHORITY(JOIN) +

UACC(ALTER)

TSS ADD(NSSXML) PROFILE(SYS1)

TSS ADD(NSSXML) GROUP(omvs_group_acid) DFLTGRP(omvs_group_acid)

ALU NSSXML PASSWORD(NSSPASS) NOEXPIRED
PASSWORD USER(NSS32A) NOINTERVAL

TSS REPLACE(NSSXML) PASSWORD(NSSPASS,0)

ADDSD     'NSS32A.**' UACC(NONE) OWNER(NSS32A)
SETROPTS REFRESH RACLIST(TSOPROC ACCTNUM TSOAUTH)

TSS ADD(owningacid) DSN(NSS32A.)

Permit this user ID to a new class that is created with the commands that are shown in Example 9-11. This class is used for the NSS Certificate Services.

Example 9-11 Authorizing user IDs to new SERVAUTH class for NSS

RDEFINE SERVAUTH EZB.NSS.SC33.SC32_TCPIPA.IPSEC.CERT UACC(NONE)
PERMIT EZB.NSS.SC33.SC32_TCPIPA.IPSEC.CERT CLASS(SERVAUTH) ID(NSS32A) ACCESS(READ)
SETROPTS RACLIST(SERVAUTH) REFRESH
SETROPTS GENERIC(SERVAUTH) REFRESH

TSS ADD(owningacid) SERVAUTH(EZB.)

TSS PERMIT(NSS32A) SERVAUTH(EZB.NSS.SC33.SC32_TCPIPA.IPSEC.CERT) ACCESS(READ)

This class uses the following syntax:

EZB.NSS.<NSSD MVS System ID>.<NSS Client Symbolic Name>.CERT

Design and diagram this scenario carefully and assign meaningful naming conventions to it. You need a class for each client. Alternatively, you can wildcards, but
you lose some granularity and control when using wildcards.

NSS has a second capability beyond Certificate Services called IPSec management. Therefore, permit the NSS client user ID and the user ID of the NSS administrator to a new SAF class that is created with the commands that are shown in Example 9-12. This class is used for the NSS Network Management Services.

Example 9-12   Authorizing user IDs to new SERVAUTH facility class for NSS

RDEFINE SERVAUTH EZB.NSS.SC33.SC32_TCPIPA.IPSEC.NETMGMT UACC(NONE)
PERMIT EZB.NSS.SC33.SC32_TCPIPA.IPSEC.NETMGMT CLASS(SERVAUTH) ID(NSS32A) ACCESS(READ)
SETROPTS RACLIST(SERVAUTH) REFRESH
SETROPTS GENERIC(SERVAUTH) REFRESH

TSS PERMIT(NSS32A) SERVAUTH(EZB.NSS.SC33.SC32_TCPIPA.IPSEC.NETMGMT) ACCESS(READ)

Note that the syntax of this second class is similar to the syntax for Certificate Services. However, there is an extra IPSEC segment. This SERVAUTH class uses the following syntax:

EZB.NSS.<NSSD MVS System ID>.<NSS Client Symbolic Name>.IPSEC.NETMGMT

Define an unique SERVAUTH class resource profile for each NSS client. One of the fields in it is composed of the label name of the NSS client’s IKE certificate. This resource grants access by the client to its own IKE certificate, even though that IKE certificate resides at the NSS server site. You need to verify the label on that certificate, so use a RACF command to list the contents of the IKE key ring that contains the certificate assigned to the TCPIPA NSS client, as shown in Example 9-13. Example 9-13 RACDCERT LISTRING(NSSD_keyring) ID(NSSD) Digital ring information for user NSSD…

Example 9-14 shows our definition. Example 9-14

SERVAUTH Resource profile for NSS client’s CA certificate

RDEFINE SERVAUTH EZB.NSSCERT.SC33.IKE$DAEMON$ON$SC32.HOST UACC(NONE)

PERMIT EZB.NSSCERT.SC33.IKE$DAEMON$ON$SC32.HOST CLASS(SERVAUTH) ID(NSS32A) SETROPTS RACLIST(SERVAUTH) REFRESH
SETROPTS GENERIC(SERVAUTH) REFRESH

TSS PER(NSS32A) SERVAUTH(EZB.NSSCERT.SC33.IKE+DAEMON+ON+SC32.HOST)

Notice the unusual syntax of the certificate label field in the SERVAUTH and PERMIT definitions. Because our label contains lowercase characters, we need to ensure that our SERVAUTH definitions are created with uppercase characters. Furthermore, because our label contains blanks, we need to represent those blanks with dollar signs ($). Such a representation of a label is called a mapped label name. A mapped label name imposes the following strict requirements: – All lowercase alphabetics in a label name must be converted to uppercase.

– Certain characters in a certificate label must be mapped to the dollar sign ($).

The following characters are affected by this rule:

– Asterisk (*)

– Percent sign (%)

– Ampersand (&)

– Blank

Tip: We ran the RDEFINE and the PERMIT statements from the TSO ISPF environment. As a result, even if we entered the label in lowercase, our definitions were successful because TSO converts the alphabetics to uppercase automatically.

For more information about mapped label names, see z/OS Communications Server: IP Configuration Guide, SC27-3650.

Build another profile for the CA certificate that has signed the NSS client’s certificate. We know from a previous display that this label is My Local Certificate Authority, as shown in Example 9-15.

Example 9-15
SERVAUTH Resource profile for NSS client’s certificate authority certificate
RDEFINE SERVAUTH EZB.NSSCERT.SC33.MY$LOCAL$CERTIFICATE$AUTHORITY.CERTAUTH UACC(NONE)
PERMIT EZB.NSSCERT.SC33.MY$LOCAL$CERTIFICATE$AUTHORITY.CERTAUTH CLASS(SERVAUTH) ID(NSS32A) ACC(READ)
SETROPTS RACLIST(SERVAUTH) REFRESH SETROPTS GENERIC(SERVAUTH) REFRESH

TSS PER(NSS32A) SERVAUTH(EZB.NSSCERT.SC33.MY+LOCAL+CERTIFICATE+AUTHORITY.CERTAUTH) ACCESS(READ)

Note again the dollar signs ($) in the mapped label name, which represent the blanks in the certificate label of the CA certificate. The syntax is similar to previous syntax, as shown in the following examples:– EZB.NSSCERT.<NSSD MVS System ID>.<NSS Client CA Certificate Label>.CERTAUTH – EZB.NSSCERT.<NSSD MVS System ID>.<mappedlabelname>.CERTAUTH Hints: Consider the following points: To avoid having to insert dollar signs ($) into mapped label names, avoid the use of the following characters when creating RACF certificates:
– Asterisk (*)
– Percent sign (%)
– Ampersand (&)
– Blank
Define more SERVAUTH resources to allow remote users to monitor (DISPLAY) or manage (CONTROL) NSS Clients, as shown in Example 9-16.

Example 9-16 Resource to monitor and manage NSS clients remotely
RDEFINE SERVAUTH EZB.NETMGMT.SC33.SC32_TCPIPA.IPSEC.CONTROL
RDEFINE SERVAUTH EZB.NETMGMT.SC33.SC32_TCPIPA.IPSEC.DISPLAY
PERMIT EZB.NETMGMT.SC33.SC32_TCPIPA.IPSEC.CONTROL CLASS(SERVAUTH) ID(CS01, CS02,CS03,CS04,CS05,CS06,CS07,CS09,CS10) ACC(READ)
PERMIT EZB.NETMGMT.SC33.SC32_TCPIPA.IPSEC.DISPLAY CLASS(SERVAUTH) ID(CS01, CS02,CS03,CS04,CS05,CS06,CS07,CS09,CS10) ACC(READ)
setropts generic(servauth) refresh
setropts raclist(servauth) refresh

TSS PERMIT(CS01) SERVAUTH(EZB.NETMGMT.SC33.SC32_TCPIPA.IPSEC.CONTROL) ACCESS(READ)

TSS PERMIT(CS02) SERVAUTH(EZB.NETMGMT.SC33.SC32_TCPIPA.IPSEC.CONTROL) ACCESS(READ)

TSS PERMIT(CS03) SERVAUTH(EZB.NETMGMT.SC33.SC32_TCPIPA.IPSEC.CONTROL) ACCESS(READ)

TSS PERMIT(CS04) SERVAUTH(EZB.NETMGMT.SC33.SC32_TCPIPA.IPSEC.CONTROL) ACCESS(READ)

TSS PERMIT(CS05) SERVAUTH(EZB.NETMGMT.SC33.SC32_TCPIPA.IPSEC.CONTROL) ACCESS(READ)

TSS PERMIT(CS06) SERVAUTH(EZB.NETMGMT.SC33.SC32_TCPIPA.IPSEC.CONTROL) ACCESS(READ)

TSS PERMIT(CS07) SERVAUTH(EZB.NETMGMT.SC33.SC32_TCPIPA.IPSEC.CONTROL) ACCESS(READ)

TSS PERMIT(CS08) SERVAUTH(EZB.NETMGMT.SC33.SC32_TCPIPA.IPSEC.CONTROL) ACCESS(READ)

TSS PERMIT(CS09) SERVAUTH(EZB.NETMGMT.SC33.SC32_TCPIPA.IPSEC.CONTROL) ACCESS(READ)

TSS PERMIT(CS10) SERVAUTH(EZB.NETMGMT.SC33.SC32_TCPIPA.IPSEC.CONTROL) ACCESS(READ)

TSS PERMIT(CS01) SERVAUTH(EZB.NETMGMT.SC33.SC32_TCPIPA.IPSEC.DISPLAY) ACCESS(READ)

TSS PERMIT(CS02) SERVAUTH(EZB.NETMGMT.SC33.SC32_TCPIPA.IPSEC.DISPLAY) ACCESS(READ)

TSS PERMIT(CS03) SERVAUTH(EZB.NETMGMT.SC33.SC32_TCPIPA.IPSEC.DISPLAY) ACCESS(READ)

TSS PERMIT(CS04) SERVAUTH(EZB.NETMGMT.SC33.SC32_TCPIPA.IPSEC.DISPLAY) ACCESS(READ)

TSS PERMIT(CS05) SERVAUTH(EZB.NETMGMT.SC33.SC32_TCPIPA.IPSEC.DISPLAY) ACCESS(READ)

TSS PERMIT(CS06) SERVAUTH(EZB.NETMGMT.SC33.SC32_TCPIPA.IPSEC.DISPLAY) ACCESS(READ)

TSS PERMIT(CS07) SERVAUTH(EZB.NETMGMT.SC33.SC32_TCPIPA.IPSEC.DISPLAY) ACCESS(READ)

TSS PERMIT(CS08) SERVAUTH(EZB.NETMGMT.SC33.SC32_TCPIPA.IPSEC.DISPLAY) ACCESS(READ)

TSS PERMIT(CS09) SERVAUTH(EZB.NETMGMT.SC33.SC32_TCPIPA.IPSEC.DISPLAY) ACCESS(READ)

TSS PERMIT(CS10) SERVAUTH(EZB.NETMGMT.SC33.SC32_TCPIPA.IPSEC.DISPLAY) ACCESS(READ)

Note the following syntax of this SERVAUTH resource:
– EZB.NETMGMT.<NSSD MVS System ID>.<NSS Client Symbolic Name>.IPSEC.CONTROL
– EZB.NETMGMT.<NSSD MVS System ID>.<NSS Client Symbolic Name>.IPSEC.DISPLAY

In our scenario, we had a few remaining SERVAUTH resources to define. If your user, CS02, wants to execute the ipsec command with the -x option, the user can display information about the NSS server and its IPSec clients. Likewise, if your user wants to display information about any type of client (IPSec or XML) supported by the NSS server, that use requires authorization to the nssctl command. Therefore, you need the resource profile and permissions for CS02 on the server system, as shown in Example 9-17.

Example 9-17
SERVAUTH profile to display NSS information with nssctl or ipsec -x

rdefine SERVAUTH EZB.NETMGMT.SC33.SC33.NSS.DISPLAY
PERMIT EZB.NETMGMT.SC33.SC33.NSS.DISPLAY CLASS(SERVAUTH) ID(CS01,CS02,CS03, CS04,CS05,CS06,CS07,CS09,CS10) ACC(READ)
setropts generic(servauth) refresh
setropts raclist(servauth) refresh

TSS PERMIT(CS01) SERVAUTH(EZB.NETMGMT.SC33.SC33.NSS.DISPLAY) ACCESS(READ)
TSS PERMIT(CS02) SERVAUTH(EZB.NETMGMT.SC33.SC33.NSS.DISPLAY) ACCESS(READ)                                                                    TSS PERMIT(CS03) SERVAUTH(EZB.NETMGMT.SC33.SC33.NSS.DISPLAY) ACCESS(READ)                                                                    TSS PERMIT(CS04) SERVAUTH(EZB.NETMGMT.SC33.SC33.NSS.DISPLAY) ACCESS(READ)                                                                    TSS PERMIT(CS05) SERVAUTH(EZB.NETMGMT.SC33.SC33.NSS.DISPLAY) ACCESS(READ)                                                                    TSS PERMIT(CS06) SERVAUTH(EZB.NETMGMT.SC33.SC33.NSS.DISPLAY) ACCESS(READ)                                                                    TSS PERMIT(CS07) SERVAUTH(EZB.NETMGMT.SC33.SC33.NSS.DISPLAY) ACCESS(READ)                                                                    TSS PERMIT(CS08) SERVAUTH(EZB.NETMGMT.SC33.SC33.NSS.DISPLAY) ACCESS(READ)                                                                    TSS PERMIT(CS09) SERVAUTH(EZB.NETMGMT.SC33.SC33.NSS.DISPLAY) ACCESS(READ)                                                                    TSS PERMIT(CS10) SERVAUTH(EZB.NETMGMT.SC33.SC33.NSS.DISPLAY) ACCESS(READ)

The syntax that is shown in Example 9-17 is quite different from what we have seen before, as shown in the following example:

EZB.NETMGMT.<NSS Server SYSID>.<NSS Server SYSID>.NSS.DISPLAY

Note that the NSS MVS system ID represents two of the fields in the resource profile.

Important:
The following display commands are used for NSS management: The ipsec command with its various options The nssctl command

Authorization for both commands is provided through the resource profile, as shown in the following example:

EZB.NETMGMT.<NSS Server SYSID>.<NSS Server SYSID>.NSS.DISPLAY

Although both commands are used for the NSS IPSec (IKED) discipline, the XML discipline takes advantage of only the nssctl command.

If user CS02 wants to display information about the IKE daemon at the NSS server node with the ipsec -w display command, the resource profile that is shown in Example 9-18 must be defined.

Example 9-18
SERVAUTH profile to display IKE at server with ipsec -w display

rdefine SERVAUTH EZB.NETMGMT.SC33.SC33.IKED.DISPLAY
PERMIT EZB.NETMGMT.SC33.SC33.IKED.DISPLAY CLASS(SERVAUTH) ID(CS01,CS02,CS03, CS04,CS05,CS06,CS07,CS09,CS10) ACC(READ)
setropts generic(servauth) refresh
setropts raclist(servauth) refresh

TSS PERMIT(CS01) SERVAUTH(EZB.NETMGMT.SC33.SC33.IKED.DISPLAY) ACCESS(READ)

TSS PERMIT(CS02) SERVAUTH(EZB.NETMGMT.SC33.SC33.IKED.DISPLAY) ACCESS(READ)

TSS PERMIT(CS03) SERVAUTH(EZB.NETMGMT.SC33.SC33.IKED.DISPLAY) ACCESS(READ)

TSS PERMIT(CS04) SERVAUTH(EZB.NETMGMT.SC33.SC33.IKED.DISPLAY) ACCESS(READ)

TSS PERMIT(CS05) SERVAUTH(EZB.NETMGMT.SC33.SC33.IKED.DISPLAY) ACCESS(READ)

TSS PERMIT(CS06) SERVAUTH(EZB.NETMGMT.SC33.SC33.IKED.DISPLAY) ACCESS(READ)

TSS PERMIT(CS07) SERVAUTH(EZB.NETMGMT.SC33.SC33.IKED.DISPLAY) ACCESS(READ)

TSS PERMIT(CS08) SERVAUTH(EZB.NETMGMT.SC33.SC33.IKED.DISPLAY) ACCESS(READ)

TSS PERMIT(CS09) SERVAUTH(EZB.NETMGMT.SC33.SC33.IKED.DISPLAY) ACCESS(READ)

TSS PERMIT(CS10) SERVAUTH(EZB.NETMGMT.SC33.SC33.IKED.DISPLAY) ACCESS(READ)

Tip: Until now, all the SERVAUTH resource profiles have been defined on the NSS server node, SC33. This pattern changes with the next SERVAUTH resource profile that we define on the NSS client node.

If user CS02 wants to display information about the IKE daemon’s NSS clients, the resource profile that is shown in Example 9-19 must be defined at the NSS client node. The command for this type of display is again ipsec -w.

Example 9-19 SERVAUTH profile to display IKE at NSS client with ipsec –w

rdefine SERVAUTH EZB.NETMGMT.SC32.SC32.IKED.DISPLAY
PERMIT EZB.NETMGMT.SC32.SC32.IKED.DISPLAY CLASS(SERVAUTH) ID(CS01,CS02,CS03, CS04,CS05,CS06,CS07,CS09,CS10) ACC(READ)
setropts generic(servauth) refresh
setropts raclist(servauth) refresh

TSS PERMIT(CS01) SERVAUTH(EZB.NETMGMT.SC32.SC32.IKED.DISPLAY) ACCESS(READ)

TSS PERMIT(CS02) SERVAUTH(EZB.NETMGMT.SC32.SC32.IKED.DISPLAY) ACCESS(READ)

TSS PERMIT(CS03) SERVAUTH(EZB.NETMGMT.SC32.SC32.IKED.DISPLAY) ACCESS(READ)

TSS PERMIT(CS04) SERVAUTH(EZB.NETMGMT.SC32.SC32.IKED.DISPLAY) ACCESS(READ)

TSS PERMIT(CS05) SERVAUTH(EZB.NETMGMT.SC32.SC32.IKED.DISPLAY) ACCESS(READ)

TSS PERMIT(CS06) SERVAUTH(EZB.NETMGMT.SC32.SC32.IKED.DISPLAY) ACCESS(READ)

TSS PERMIT(CS07) SERVAUTH(EZB.NETMGMT.SC32.SC32.IKED.DISPLAY) ACCESS(READ)

TSS PERMIT(CS08) SERVAUTH(EZB.NETMGMT.SC32.SC32.IKED.DISPLAY) ACCESS(READ)

TSS PERMIT(CS09) SERVAUTH(EZB.NETMGMT.SC32.SC32.IKED.DISPLAY) ACCESS(READ)

TSS PERMIT(CS10) SERVAUTH(EZB.NETMGMT.SC32.SC32.IKED.DISPLAY) ACCESS(READ)

Tips: Although the numerous authorizations that we describe here might seem tedious, we show them in detail to emphasize the following critical points:

- The numerous individual SERVAUTH profiles and authorizations provide a great deal of control and security. To understand them well, it is necessary to provide this level of detail. However, after you understand the concepts, you can use wildcards in many of the fields to reduce the amount of definition that is required.

-The definitions require detailed planning. As described in 9.2.1, “Preliminary tasks overview” on page 339, two of the planning steps are to prepare a logical network diagram and to complete a worksheet that contains the necessary information for these definitions. This preliminary work is useful to expediting the steps that are described in 9.2.6, “Configuring authorizations for NSS” on page 351.

-If you worked with IPSec and IP Filtering, the task of setting up NSSD for IPSec (IKED) clients becomes simple.

NSS XML client RACF user ID

The authorization tasks in this section apply only to the NSS XML client. Complete the following steps:

Create a user ID for the NSS client. In our scenario, we named the XML client NSSXML. The client’s password is to be XMLPASS. Example 9-20 shows the JCL that we used to create this user ID.

Example 9-20
XML Client user ID and password generation

ADDUSER NSSXML PASSWORD(NEW2DAY) +
NAME('ID for Comm Server') +
OWNER(HAIMO) UACC(READ) DFLTGRP(SYS1) +
AUTHORITY(JOIN) GRPACC +
OMVS(AUTOUID HOME(/u/nssxml) PROGRAM(/bin/sh))
CONNECT   NSSXML GROUP(SYS1) OWNER(HAIMO) AUTHORITY(JOIN) +
       UACC(ALTER)

TSS CREATE(NSSXML) NAME('ID for Comm Server') DEPT(dept) PASSWORD(NEW2DAY)

TSS ADD(NSS32A) UID(?) HOME(/u/nssxml) OMVSPGM(/bin/sh)

TSS ADD(NSS32A) PROFILE(SYS1)

TSS ADD(NSS32A) GROUP(omvs_group_acid) DFLTGRP(omvs_group_acid)

ALU NSSXML PASSWORD(XMLPASS) NOEXPIRED

PASSWORD USER(NSSXML) NOINTERVAL

TSS REPLACE(NSSXML) PASSWORD(XMLPASS,0)


ADDSD     'NSSXML.**' UACC(NONE) OWNER(NSSXML)
SETROPTS REFRESH RACLIST(TSOPROC ACCTNUM TSOAUTH)

TSS ADD(owningacid) DSN(NSSML.)

Permit this user ID to a new class that is created with the commands that are shown in Example 9-21. This class is used for the NSS SAF Access Service.

Example 9-21 Authorizing XML client user IDs to SERVAUTH class for NSS

RDEFINE SERVAUTH EZB.NSS.SC33.NSSXML1.XMLAPPLIANCE.SAFACCESS UACC(NONE)
PERMIT EZB.NSS.SC33.NSSXML1.XMLAPPLIANCE.SAFACCESS CLASS(SERVAUTH) ID(NSSXML) ACCESS(READ)
SETROPTS RACLIST(SERVAUTH) REFRESH
SETROPTS GENERIC(SERVAUTH) REFRESH

TSS PERMIT(NSSXML) SERVAUTH(EZB.NSS.SC33.NSSXML1.XMLAPPLIANCE.SAFACCESS) ACCESS(READ)

Note the following syntax for this class:
NSS.<NSSD MVS System ID>.<NSS Client Symbolic Name>.XMLAPPLIANCE.SAFACCESS
You need a class for each symbolic ClientID. Alternatively, you can use wildcards for the definition, but you lose some security granularity and control when using wildcards.
We had one remaining SERVAUTH resource to define for our NSS XML discipline scenario. If a user, CS02, wants to display information about the NSS server and the clients it is supporting, the user needs authorization to the nssctl command. Such authorization is provided through the resource profile and permissions for CS02’s RACF group that is shown in Example 9-22.

Example 9-22 SERVAUTH profile to display NSS information with ipsec -x or nssctl -d

rdefine SERVAUTH EZB.NETMGMT.SC33.SC33.NSS.DISPLAY
PERMIT EZB.NETMGMT.SC33.SC33.NSS.DISPLAY CLASS(SERVAUTH) ID(SYS1) ACC(READ)
setropts generic(servauth) refresh
setropts raclist(servauth) refresh

TSS PERMIT(SYS1) SERVAUTH(EZB.NETMGMT.SC33.SC33.NSS.DISPLAY) ACC(READ)

The syntax in Example 9-22 is different from previous syntax, as shown in the following example:

NETMGMT.<NSS Server SYSID>.<NSS Server SYSID>.NSS.DISPLAY

Note that the NSS MVS system ID represents two of the fields in the resource profile.

Important:
The following display commands for NSS management are available:

-The ipsec command with its various options

-The nssctl command

Authorization for both commands is provided through the resource profile, as shown in the following example:

EZB.NETMGMT.<NSS Server SYSID>.<NSS Server SYSID>.NSS.DISPLAY

Although both commands are used for the NSS IPSec (IKED) discipline, the XML discipline takes advantage of only the nssctl command.