IMHO there are very few products that require ICSF as mandatory
prerequisite for any operations.
It's rather requirement for some product options.
Note: ICSF can work with or without cryptoexpress cards. Without
CryptoExpress secure and protected key mode are unavailable. You still
need CPAC (FC3863).
Caution: I'm not sure, but even without CPACF some basic CSF services
(SHA?) are available.
--
Radoslaw Skorupka
Lodz, Poland
W dniu 2019-01-22 o 17:57, Cieri, Anthony pisze:
I believe that it is the Secure+ feature for Connect:Direct that exploits the
Crypto hardware. If you are NOT using seure+, then I believe that there is no
"requirement" for ICSF.
However, I also believed that even if secure+ WERE enabled and you
attempted a process to a Secure+ enabled partner node that if ICSF was NOT
available, that the secure+ process WOULD execute, but that the encryption
workload would be processed in general CPs.
I was curious, so I tried an experiment and I offer my observations
below.
I sent a few processes to an established secure+ test node from a LPAR
with ICSF up and available. The processes executed successfully. Next, I
brought down ICSF on that same LPAR and resubmitted the same test processes.
To my surprise, they failed with the following message:
CSPA014E Unable to read remote node definition
I recall that somewhere between Connect:Direct V4.8 and version5.2, there was a
"requirement" to encrypt the Secure+ PARMFILE with Triple-DES. I suspect that
it is this change that now requires ICSF to be active.
So it appears that Connect:Direct (V5.x with the Secure+ feature
enable) is like newer releases of IBM's OpenSSH Server in that they now do
require ICSF to be active.
There were certainly "older" releases of both, that did NOT have a
"requirement" for ICSF to be active.
Hth
Tony
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of Greg Boyd
Sent: Tuesday, January 22, 2019 8:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ICSF and z/OS 2.3
[[ SEI WARNING *** This email was sent from an external source. Do not open
attachments or click on links from unknown or suspicious senders. *** ]]
There may have been changes to Connect Direct since the last time I worked with
it, but I suspect ICSF is required if you want to leverage the hardware
technology, and specifically the CEX cards. As Kirk points out, if you want to
use the random number generation on hardware then you need ICSF active. (And
you probably do want the performance of RNG in hardware.) Similarly, for
System SSL, if you want to use the Crypto Express cards for authentication
(public/private key operations), then ICSF needs to be active. Enabling the
cards and having ICSF active can make a big difference in throughput and
capacity (CPU savings), but strictly speaking it's probably not required unless
you configure the environment to use the crypto hardware.
Greg Boyd
Mainframe Crypto
www.mainframecrypto.com
On Fri, 18 Jan 2019 17:55:51 -0600, Steve beaver <st...@stevebeaver.com> wrote:
Also it’s required for Connect Direct
Sent from my iPhone
Sorry for the finger checks
On Jan 18, 2019, at 17:29, Kirk Wolf <k...@wolf-associates.com> wrote:
ICSF is currently required if you want to use the Unix /dev/random and
/dev/urandom devices.
These might be required by Unix apps (or jobs/stcs that use z/OS Unix
System services).
For exampe: IBM OpenSSH server will not work without ICSF and /dev/random
available.
On Fri, Jan 18, 2019 at 5:24 PM Greg Boyd <gregb...@mainframecrypto.com>
wrote:
ICSF is only required if you want to use the ICSF APIs, so it depends on
what, if anything in your shop might be using the APIs. System SSL (TLS)
will certainly leverage the APIs if you have Crypto Express cards available
and that might provide some CPU relief. The Guardium Database Encryption
Tool requires it if you want to encrypt IMS segments or DB2 tables at the
row level.
Pervasive is getting a lot of attention and if you're going that route, I
would highly recommend that ICSF be active everywhere. You don't want one
system writing ciphertext to a file and another system thinking that the
file is cleartext. IBM is also recommending that ICSF be 'always up'.
They have made a number of changes to the component so that it will come up
earlier in the IPL and it should be one of the last tasks running.
Given the growth in crypto workload, I take 'always up' to also mean
'running everywhere'. There are simply more things that can leverage ICSF,
some optionally and some require it.
I'm not sure why DFSMShsm would need ICSF active, unless they were using
the Encryption Facility for z/OS with the DFSMSdss feature.
Greg Boyd
Mainframe Crypto
www.mainframecrypto.com
On Fri, 18 Jan 2019 18:16:37 +0000, Mary Kay Tubello <mtube...@humana.com>
wrote:
Hello all,
Does anyone know if z/os 2.3 requires ICSF to be installed on each LPAR?
Thanks,
Mary Kay
Large Systems Engineering
IT Infrastructure
Humana
123 E. Main St. 40202 (CT6)
502-476-2772
mtube...@humana.com<mailto:mtube...@humana.com>
======================================================================
Jeśli nie jesteś adresatem tej wiadomości:
- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś
na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać
tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza)
tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać
karze.
mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st.
Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 0000025237,
NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na
01.01.2018 r. wynosi 169.248.488 złotych.
If you are not the addressee of this message:
- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have
printed out or saved).
This message may contain legally protected information, which may be used
exclusively by the addressee.Please be reminded that anyone who disseminates
(copies, distributes) this message or takes any similar action, violates the
law and may be penalised.
mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950
Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital
City of Warsaw, 12th Commercial Division of the National Court Register, KRS
0000025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN
169,248,488 as at 1 January 2018.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
