Persistent Verification Support for APPC Sessions

MORE INFORMATION

PV changes were implemented in SNA Server 4.0 but were not fully retrofitted to the SNA Server 3.0 product. In addition, modifications to the APPC interface (Wappc32.dll) were needed to provide correct interaction between PV and Already Verified (AV) support, which is a second method for managing APPC conversation level security. With the hotfix applied, if the host will accept AV and PV, and the APPC application specifies "security = AP_SAME", SNA Server does the following:

1. If it does not detect that the user is signed on to the host, it sends an ATTACH with the AV bit set and the PV bits set to "sign-on requested". A password is not included.
2. If it does detect that the user is signed on, it sends an ATTACH with the AV bit set and the PV bits set to "already signed on". Again, a password is not included.

The most basic way to keep an APPC conversation secure is to send a user_id and password on each ATTACH, which can then be verified by the receiving LU. The problem with this is that the password is continuously passed in messages, increasing the likelihood of its being intercepted. PV and AV both provide a mechanism for reducing (or removing altogether) the number of messages that contain the password, and thereby improving security.

For AV the password is never sent on any ATTACH. The receiving LU trusts the sending LU to have done all of the security checking. If a receiving LU trusts a sending LU, the sending LU can avoid including the password on any ATTACH by setting the AV indicator bit instead. The AV bit tells the receiving LU that the sending LU has already verified the TP's credentials (by some private method) and the receiving LU does not have to worry about doing any checking itself.

For PV, the password is sent on the first ATTACH, and is never sent again. On the first ATTACH, the PV bit is set, and a password is included. This signals the receiving LU to check the password and then add the user_id to a list of users who do not need to be verified again. On the second and subsequent ATTACHes the PV bit is set, but no password is included. This signals the receiving TP that it just needs to check that the user is in the list of users it has verified in the past.