IMPORTER/EXPORTER keys can be at least as strong as the keys being transported. That is not true for RSA. Symmetric key lengths > 128 bits are "stronger" than even 4096-bit RSA.
Again, it is rare that you have to exchange keys between systems and tools (like EKMF) are an easier solution for this kind of maintenance. Most of the time, datasets are only shared within a "zone" where all the members share a CKDS.
I would love an ICSF 101, but we don't really have the resources to go all out with that. I've presented dozens of times to give high-level overviews.
I do plan to keep on presenting these. I think that I will get it recorded the next time.
Original Message:
Sent: Wed September 22, 2021 09:47 AM
From: Colin Paice
Subject: I'm trying to understand CSNBKGN2
After a lot of head scratching and experimenting, Im still struggling with some concept level stuff, and going round in circles
From the 10,000 ft level, why would I want to use exporter and importer keys. (Can you point me to any existing documentation on this - I haven't found any)
I can set up a symmetric key pair on each system using private and public keys and DH.
If I wanted multiple keys I could just change the "party" information and rerun the programs.
Using E&I keys require me to have a DH key to be able generate my first E&I key (in CSNBKGN2). So some extra work just to get started.
I also had another step or two of having to send the key to the remote system.
So overall using DH to generate my keys seems much easier and is less work than using Exporter and Importer keys.
I also see more admin work to look after the E&I keys, for example how can I tell if the data set with the exported key still matches the key in the keystore?. It is easy with the DH. I just recreate the key by running the job, and I know I have the current version of the key. With E&I I have to write things down.
If I want to export a cipher key I can use RSA public or an Exporter key.
Hence my question, why do I need Exporter and Importer keys.
Some possible answers I came up with
E&I are more secure
They are architecturally better
It is the way it was coded.
I feel the ICSF product needs an ICSF 101 - which "sells the product" and covers a lot of the concepts of the product without going into technical detail, giving the background and reasons, rather than the technical details. Consider the manager of the z/OS system programmers team. They need a document/presentation which explains to them why they should get their team to install and use it. I'm happy to come up with some chapter headings for you if you would find this useful
regards
Colin
------------------------------
Colin Paice
Original Message:
Sent: Tue September 21, 2021 09:09 AM
From: Eric Rossman
Subject: I'm trying to understand CSNBKGN2
Setting up ICSF for the first time, the first thing I need to do is set up a DH key on each system, so I have my EXPORTER on one system, and importer on the other system.
That is certainly a workable solution.
I could use this key as my KEK for all my keys (CIPHER,MAC), but best practice says I should have a different KEK for each type - so a KEK for CIPHER, and a KEK for MAC
It depends. In many cases, having one KEK to exchange keys with another system is fine. However, in some cases, you will want different KEKs. It really depends on your security needs.
I could set up
a DH for CIPHER and a DH for MAC to provide isolation,
or I could use CSNBKGN2 to create an EXPORTER key (and store it in my CKDS), and and have the IMPORTER encrypted with the DH, written to a dataset and send it to the remote site.
Is there any guidance on the best way of doing this? Using DH for each type sounds much simpler to implement.
Normally, you would set up 2 shared keys (EXPORTER_A/IMPORTER_B on one side, EXPORTER_B/IMPORTER_A on the other side) and then use that to exchange future keys. EC-DH allows for shared party data that can cause derivation of different key material by using different shared party data (see party_identifier parameter). There's also no problem with just creating unique EC-DH key pairs for each kind of key you want to derive.
I could recreate the exporter and importer keys every week if I wanted to... they are just used to get the key to the other system.
Sure.
I do not want to recreate a cipher key as it would mean dataset already encrypted with it would be unreadable.
Correct.
As you said I do not need to use CSNBKTB2 to create a skeleton for importer and exporter.
Yep.
However I do need to use CSNBKTB2 if I am using CIPHER because it needs a rule including "XPRTCPAC","ANY-MODE"
Right. I was speaking only of the EXPORTER, IMPORTER key types.
------------------------------
Eric Rossman
Original Message:
Sent: Tue September 21, 2021 08:18 AM
From: Colin Paice
Subject: I'm trying to understand CSNBKGN2
Eric,
Thank you for you comments, very useful, Ive managed to generate an IMPORTER and EXPORTER.
The fog in my head is clearing... but I have some questions.. Below is what I picture.. is this correct?
- Setting up ISCF for the first time, the first thing I need to do is set up a DH key on each system, so I have my EXPORTER on one system, and importer on the other system.
- I could use this key as my KEK for all my keys (CIPHER,MAC), but best practice says I should have a different KEK for each type - so a KEK for CIPHER, and a KEK for MAC
- I could set up
- a DH for CIPHER and a DH for MAC to provide isolation,
- or I could use CSNBKGN2 to create an EXPORTER key (and store it in my CKDS), and and have the IMPORTER encrypted with the DH, written to a dataset and send it to the remote site.
- Is there any guidance on the best way of doing this? Using DH for each type sounds much simpler to implement.
- I could recreate the exporter and importer keys every week if I wanted to... they are just used to get the key to the other system.
- I do not want to recreate a cipher key as it would mean dataset already encrypted with it would be unreadable.
- As you said I do not need to use CSNBKTB2 to create a skeleton for importer and exporter.
- However I do need to use CSNBKTB2 if I am using CIPHER because it needs a rule including "XPRTCPAC","ANY-MODE"
How am I doing?
regards
Colin
------------------------------
Colin Paice
Original Message:
Sent: Mon September 20, 2021 03:51 PM
From: Eric Rossman
Subject: I'm trying to understand CSNBKGN2
EXPORTER and IMPORTER aren't valid key types for single key creation.
"Valid type combinations depend on the key form, and are
documented in Table 77 on page 207 and Table 78 on page 208."
You want to look at Table 78 instead.
(You don't need to call CSNBKTB2 at all unless you need compliance-tagged keys. You can just specify EXPORTER for key_type_1 and IMPORTER for key_type_2.)
If you are trying to create only one half of an importer/exporter key pair, you will want to use something (like EC-DH) so that each side of the conversation has the corresponding key.
We don't allow one side to create both the EXPORTER and IMPORTER since that would effectively create a dual-use key (since you have both functional keys), so you normally do the EC-DH to make a pair first (or two since they are unidirectional). Then, you can create additional matched pairs for other operations (like creating a MAC key for your use and the corresponding MACVER key for the other side).
------------------------------
Eric Rossman
Original Message:
Sent: Mon September 20, 2021 03:34 PM
From: Colin Paice
Subject: I'm trying to understand CSNBKGN2
Hi Eleanor
Thanks for your reply, Im still a little confused(even more confused)
Do I
- specify Exporter in CSNBKTB2
- then in CSNBKGN2 specify OPEX, and specify KEK2
Or do I
- specify cipher in CSNBKTB2
- then specify OPEX in CSNBKGN2, and specify KEK2?
Does the documentation need to be updated in table 77 where it mentions CIPHER, but not exporter, or importer?
If I need a KEK when I specify IM or EX, can I create an exporter key without having an exporter key to encrypt it?
I can do it using DH, but I am still confused. Having to create an exporter key using DH, before I can generate an exporter key using CSNBKGN2 feels wrong. It may be I am missing some key bit of information (grin)
regards
Colin
------------------------------
Colin Paice
Original Message:
Sent: Mon September 20, 2021 01:18 PM
From: Colin Paice
Subject: I'm trying to understand CSNBKGN2
For CSNBKGN2 the doc says I can specify KEY_TYPE_ 1 as CIPHER, EXPORTER, IMPORTER etc.
Table 77 says I can use CIPHER DKYGENKY.. (and does not mention EXPORTER or IMPORTER)
I can only get CIPHER to work, and not EXPORTER or IMPORTER; I get reason code 155 if I try to use them.
Should I be able to specify EXPORTER and IMPORTER? Ive tried combinations of OP,IM and EX.
I've tried using a skeleton and specifying TOKEN, but it fails the same way.
Colin
------------------------------
Colin Paice
------------------------------