Allow IPCONN USERAUTH(IDENTIFY) parameter w/o SSL for IPIC-connected CICS running in different intranet sysplexs

IPIC Connections between CICS regions running in different LPARs active in trusted SYSPLEX's, require secured SSL connections if the IPCONN USERAUTH(IDENTIFY) parameter is specified for the IPCON resources.

This is documented here:
http://www-01.ibm.com/support/docview.wss?uid=swg21410570.
In particular the technote states 'An SSL connection is required if the partner is outside the local sysplex.'

The tests, executed with SSL(CLIENTAUTH) and CIPHERS(0102) on the TCPIPSERVICE,
as per Knownledge center indication - see link below
https://www.ibm.com/support/knowledgecenter/SSGMCP_5.4.0/security/connections/dfht5_ip_user_security.htm
showed a relevant CPU increase compared to a SNA LU 6.2 ISC connection for DPL requests.
This increase is due to SSL authentication, even CIPHER is switched off (0102).
The CPU increase is 5 times more if you compare the ISC/LU62 run or IPIC run with ATTACHSEC(LOCAL).

The Knownledge Center also startes
"Defining an IPCONN resource with USERAUTH(IDENTIFY) means that you are prepared to accept unauthenticated, or asserted, user identifiers on the connection; that is, you are trusting the partner system".

This is the case, even if the partner is not in the local sysplex.

Indeed all z/OS LPARs reside on different but trusted SYSPLEXes environment, on the same intranet environment and without extranet communication, so there is not potential security exposure and the higher CPU cost is not acceptable in this case.
Without any changes the customer decides to don't migrate to IPIC communication for CICS connectivity.

The request is to have a new option to choose if, with USERAUTH(IDENTIFY), the SSL is
required or not for the authentication process.
With this option the security checking against the RACF USERID passed over the DPL request has to be managed in the same way when CICS regions are running in the same z/OS LPAR connected though IPIC.