Using Persistent Verification (PV)

With VTAM® 3.4 or later and RACF® installed, APPC/MVS can receive persistent verification requests. Persistent verification (PV) is an option that LUs can specify on outbound allocate (attach) requests. Persistent verification is an application security mechanism that maintains lists of verified user IDs and reduces the flow of passwords across the network.

APPC/MVS LUs can receive but cannot send persistent verification requests.

To use persistent verification on your system, you must:

Allow it between the appropriate LUs by specifying the PERSISTV or AVPV values in either:
- The VTAM APPL statement's SECACPT keyword, as described in Specifying the Level of Conversation Security for VTAM, or
- The RACF APPCLU profile SESSION segment, through the CONVSEC keyword, as described in Defining Conversation Security Levels that Sessions Allow.
If you specify conversation security values in both the VTAM APPL statement and the RACF APPCLU profile, the RACF value overrides the VTAM value.
Make sure the RACF subsystem is available to handle persistent verification requests. Refer to z/OS Security Server RACF System Programmer's Guide for more information about the RACF subsystem.
Make sure the network LU names of participating LUs are unique across interconnected networks. If your installation is using APPC/MVS support of network-qualified names to ensure that LU names are unique, the results of persistent verification requests are unpredictable.
A network-qualified name is a 17-byte name in the form network_id.network_lu_name, where the network-ID portion uniquely identifies an LU when the network-LU-name portion is identical to LU names on other networks in the installation. With persistent verification, the network ID is not used to verify PV requests. If network LU names themselves are not unique, LUs might, for example, accept conversations from the wrong partner LUs.

Because of this unpredictability, IBM® does not recommend the use of APPC/MVS support for network-qualified names for those LUs that your installation uses for persistent verification requests.

On sessions that allow persistent verification, the following sequence of events establishes persistent verification for user IDs passed on that session:

The outbound LU adds a user ID to its own signed-on-to list and sends security information like a user ID and password on an outbound allocate request, with a PV sign-on indicator in the function management header 5 (FMH-5).
If the inbound system (possibly MVS) successfully verifies the security information in the FMH-5 sent from the partner LU, the inbound system enters the user ID in a "signed-on-from list". The signed-on-from list contains a list of user IDs signed on for persistent verification from that outbound LU.
On subsequent allocate requests containing that user ID and a PV signed-on indicator, information that validates the user's identity is not included.
The inbound system receives the subsequent allocate requests and verifies that the user is in the signed-on-from list.
The user ID normally remains on the list for the duration of the session. Operator action or communication failure can cause the user ID to be dropped from the list.

MVS operators can use the RACF #DISPLAY SIGNON command to display the signed-on-from list and the #SIGNOFF command to remove entries from the signed-on-from list while a session is active.

For example, the following command would search the signed-on-from list for user USER01 to see if that user is signed on for persistent verification from LU01. If USER01 is signed on from that specific port of entry (POE), a list is returned to the operator console.

#DISPLAY SIGNON,APPL(LU02),POE(LU01),USER(USER01),GROUP(*)

The following operator command would remove user USER01 from the signed-on-from list of LU02:

#SIGNOFF APPL(LU02),POE(LU01),USER(USER01),GROUP(*)

See z/OS Security Server RACF Command Language Reference for more information about these commands.

When the operator removes an entry from the signed-on-from list, RACF grants control to the persistent verification verb exit, which sends a request to the partner LU to remove the entry from the signed-on-to list. When the request is complete, the operator receives RACF message IRRE006I, which contains a return and reason code. The return and reason codes are documented in z/OS Security Server RACROUTE Macro Reference. The return and reason codes for the persistent verification verb exit are:

Table 1. Persistent Verification Verb Exit Return and Reason Codes
Return Code	Reason Code	Meaning and Action
Hexadecimal (Decimal)	Hexadecimal (Decimal)	Meaning
00 (00)	--	Processing completed successfully.
0C (12)	04 (04)	The request code passed to the persistent verification verb exit was not correct.
	08 (08)	APPC/MVS is not active.
	0C (12)	An internal error occurred.
	10 (16)	An internal error occurred.

If you are using a security product other than RACF, the persistent verification verb exit return and reason codes may be different from those listed above.

Diagnosing PV Problems

There are some situations in which signed-on-to and signed-on-from lists might not be identical, possibly causing an erroneous return code of security_not_valid from an allocate request. For example, a partner application might have two windows, one that starts a conversation with a "sign-on" request, and a second that starts another conversation to the same LU and passes a "signed-on" indicator. If for some reason the second allocate reached the inbound LU first, the user ID would not be found on the signed-on-from list yet, and the "signed-on" request would be rejected. The user would need to try that request again later.

See SNA LU 6.2 Reference: Peer Protocols for more information about using persistent verification.