NAS: Allow GSS-API application programs to access the CSFRNG resource of the CSFSERV class

Description

GSS-API applications that use either the LIPKEY or SPKM mechanism call System SSL APIs and trigger System SSL DLLs to be loaded. Starting in z/OS V2R1, when System SSL DDLs are loaded, it uses ICSF random number generation support if ICSF is available. If the context initiator (client) or context acceptor (server) in these mechanisms does not have access to the CSFRNG resource of the CSFSERV class, ICH408I (which indicates insufficient authorization) might be issued to the console, but the application continues. The System SSL software implementation is used instead.

Table 1 provides more details about this migration action. Use this information to plan your changes to the system.

Table 1. Information about this migration action
Element or feature:	Network Authentication Service
When change was introduced:	z/OS V2R1.
Applies to migration from:	z/OS V1R13.
Timing:	Before first IPL of z/OS V2R2.
Is the migration action required?	Yes, if the following conditions are true: Your installation uses ICSF. The CSFSERV general resource class is active. A profile that covers the CSFRNG resource of the CSFSERV class is defined and does not grant READ access to the user IDs that use the LIPKEY or SPKM mechanism.
Target system hardware requirements:	None.
Target system software requirements:	None.
Other system (coexistence or fallback) requirements:	None.
Restrictions:	None.
System impacts:	The system issues informational message ICH408I that indicates insufficient authorization might be issued to the console.
Related IBM® Health Checker for z/OS® check:	None.

Steps to take

Follow these steps:

Determine whether the CSFSERV class is active. When active, this class restricts access to the ICSF programming interface. If it is not active, access to the ICSF programming interface (and specifically the CSFRNG callable service) is unrestricted. No configuration is necessary.
To determine which RACF classes are currently active, enter the SETROPTS command with the LIST parameter specified:
```
SETROPTS LIST
```
If the SETROPTS LIST command shows that the CSFSERV class is active, identify the profile that covers the CSFRNG resource. This might be a discrete profile named CSFRNG or, if generic profile checking is activated, a generic profile.
To determine whether a profile is defined to protect the CSFRNG resource, enter the following RLIST command:
```
RLIST CSFSERV CSFRNG
```
When you enter this command, RACF lists information for the discrete resource profile CSFRNG. If there is no matching discrete profile, RACF lists the generic profile that most closely matches the resource name.
If the RLIST command output reveals that there is a discrete or generic profile defined that covers the CSFRNG resource, examine the command output to ensure that the GSS-API context initiator (client) and acceptor (server) user IDs that use either the SPKM or LIPKEY mechanisms have at least READ access to the CSFRNG resource. If necessary, use the PERMIT command to give them the appropriate access. For example, if a discrete profile CSFRNG exists, the following command would give user BAILEY access:
```
PERMIT CSFRNG CLASS(CSFSERV) ID(BAILEY) ACCESS(READ)
```
If you do make changes, refresh the in-storage RACF profiles for the CSFSERV class:
```
SETROPTS RACLIST(CSFSERV) REFRESH
```

Reference information

For more information, see "Using Cryptographic Features with System SSL" in z/OS Cryptographic Services System SSL Programming.