Re: Encryption again - Question on TKE use to CCA
Yes, 1 catcher with control/usage on 1 domain and control on the rest to load all the keys on a card. If we did it on the Linux guest that will actually use the key, I would have to move all those guests around to 8 different CEC's in two different datacenters. That's just not going to happen. I have to have the keys there before it gets to the other data center. So hence a Linux whose only purpose in life is to run catcher (hmmm, how about delivering this as an SSC?) I don't envision a situation where we have to do lots quickly since the other CEC's are available all the time. We'd just move the servers to where the key is available. z/OS has been using keys for a while and they load when a new CEC comes in or if a card dies. And that's about it. Linux in an LPAR is a pain, especially in a GPDS and hyperswap environment where it's considered a foreign system and so would need its own LCU. We will likely just put it on non-replicated disk. The console is the HMC ascii, which isn't accessible to Linux engineers- we'd have to get an operator to screen share. So if that Linux doesn't boot after patching, we're looking at some fun in recovery. My thought was to have one per data center. Bring it up in the LPAR reserved for key loading when needed, but then put it back under z/VM (where Linux belongs __ ) on a routine basis. No, I can't just leave it down due to compliance reasons (must be subject to scanning and other asset management policy tools). IP changes would be problematic to the authentication software we use. On 9/24/20, 10:37 PM, "Linux on 390 Port on behalf of Timothy Sipples" wrote: Marcy, It seems like what you're envisioning is to have a "service" image to run catcher.exe (slight correction: it's actually catcher.exe rather than panel.exe) to facilitate TKE Workstation interactions with various Crypto Express CCA mode physical features (and associated domains) spread across several machines. That all seems fine to me, but one threshold question that comes to mind is whether sharing a single IP address supports "fast enough" operations. What I mean is that with a single IP address you'll only be able to have one instance of this service image running at any one time. If you're in a future situation where you have to perform lots of TKE operations across multiple machines/features/domains very quickly -- some sort of calamity involving rapid fire TKE operations -- your operational "throughput" *could* be significantly limited with only one running service image at a time. A slight, simple variation here would be to have a single service image with a default startup IP address but then allow an authorized operator to switch the image to a different IP address once that image starts up. That way you could have multiple instances of this service image running as long as only one of them is starting up at any one time. - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: Encryption again - Question on TKE use to CCA
Marcy, It seems like what you're envisioning is to have a "service" image to run catcher.exe (slight correction: it's actually catcher.exe rather than panel.exe) to facilitate TKE Workstation interactions with various Crypto Express CCA mode physical features (and associated domains) spread across several machines. That all seems fine to me, but one threshold question that comes to mind is whether sharing a single IP address supports "fast enough" operations. What I mean is that with a single IP address you'll only be able to have one instance of this service image running at any one time. If you're in a future situation where you have to perform lots of TKE operations across multiple machines/features/domains very quickly -- some sort of calamity involving rapid fire TKE operations -- your operational "throughput" *could* be significantly limited with only one running service image at a time. A slight, simple variation here would be to have a single service image with a default startup IP address but then allow an authorized operator to switch the image to a different IP address once that image starts up. That way you could have multiple instances of this service image running as long as only one of them is starting up at any one time. - - - - - - - - - - Timothy Sipples I.T. Architect Executive Digital Asset & Other Industry Solutions IBM Z & LinuxONE - - - - - - - - - - E-Mail: sipp...@sg.ibm.com -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: Encryption again - Question on TKE use to CCA
It would have the same IP and hostname. Disk and network is accessible to all CECs . Thanks for checking! From: Reinhard Buendgen Sent: Thursday, September 24, 2020 9:53 AM To: Cortes, Marcy D. [PRINCIPAL ENGINEER] Cc: LINUX-390@VM.MARIST.EDU Subject: RE: Encryption again - Question on TKE use to CCA Hm, wouldn't that "same Linux" (I assume you mean to boot the same image on different CECs) have different IP addresses, depending on where you boot it? I am afraid the TKE could be confused if you really used the same IP address on different CECs, but I guess it couldwork and it would "think" you just replaced all adapters (assuming the TKE looks at adapter S/Ns). But if each Linux instance has its own IP address then the TKE should be good at connecting to all of them and doing some work in parallel in particular if you want to configure the same master keys on multiple adapte domains. But to be on the safe side I will check with an TKE expert. Mit freundlichen Grüßen/Best Regards/Cordialement Reinhard Dr. Reinhard Bündgen Product Owner Security Linux on Z Linux on Z Development Mail:buend...@de.ibm.com<mailto:buend...@de.ibm.com> Phone: ++49-(0)7031-16-1130 Fax: ++49-(0)7031-16-3456 IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Matthias Hartmann Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 - Original message - From: mailto:marcy.d.cor...@wellsfargo.com>> To: mailto:buend...@de.ibm.com>> Cc: mailto:LINUX-390@VM.MARIST.EDU>> Subject: [EXTERNAL] RE: Encryption again - Question on TKE use to CCA Date: Thu, Sep 24, 2020 6:32 PM Thank you! One more question, would TKE be totally confused if I used the same linux, moving it CEC to CEC (in an LPAR) to load keys on say 8 boxes? Or would each CEC need to have its own Linux? Marcy From: Reinhard Buendgen mailto:buend...@de.ibm.com>> Sent: Thursday, September 24, 2020 6:03 AM To: Cortes, Marcy D. [PRINCIPAL ENGINEER] mailto:marcy.d.cor...@wellsfargo.com>> Cc: LINUX-390@VM.MARIST.EDU<mailto:LINUX-390@VM.MARIST.EDU> Subject: Re: Encryption again - Question on TKE use to CCA Hi Marcy, when using CCA (i.e. the TKE is configured to communicate with panel.exe) no authentication will be perfromed. You need neither enter an ID nor a password just click OK. This is not considered insecure because all the catcher does is to forward signed requests to the crypto adapter. For EP11 (i.e. if the TKE is configured to communicate with the ep11TKEd) it must a Linux user and password configured for the ep11TKEd as described here https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lxce/lxce_installing_hostpart.html (The default setting is to allow any user that has a password configured and is member of the ep11tke group to gain access through the ep11TKEd daemon.) Mit freundlichen Grüßen/Best Regards/Cordialement Reinhard Dr. Reinhard Bündgen Product Owner Security Linux on Z Linux on Z Development Mail:buend...@de.ibm.com<mailto:buend...@de.ibm.com> Phone: ++49-(0)7031-16-1130 Fax: ++49-(0)7031-16-3456 IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Matthias Hartmann Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 - Original message - From: Marcy Cortes mailto:marcy.d.cor...@wellsfargo.com>> Sent by: Linux on 390 Port mailto:LINUX-390@VM.MARIST.EDU>> To: LINUX-390@VM.MARIST.EDU<mailto:LINUX-390@VM.MARIST.EDU> Cc: Subject: [EXTERNAL] Encryption again - Question on TKE use to CCA Date: Thu, Sep 24, 2020 12:11 AM In this doc http://public.dhe.ibm.com/software/dw/linux390/docu/l91xct00.pdf page 13, what are these credentials? Where are they defined? Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu<mailto:lists...@vm.marist.edu> with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390<https://urldefense.proofpoint.com/v2/url?u=http-3A__www2.marist.edu_htbin_wlvindex-3FLINUX-2D390=DwMGaQ=jf_iaSHvJObTbx-siA1ZOg=gDiditHI8xOAKhJe7-PksxYsvTcY
Re: Encryption again - Question on TKE use to CCA
Thank you! One more question, would TKE be totally confused if I used the same linux, moving it CEC to CEC (in an LPAR) to load keys on say 8 boxes? Or would each CEC need to have its own Linux? Marcy From: Reinhard Buendgen Sent: Thursday, September 24, 2020 6:03 AM To: Cortes, Marcy D. [PRINCIPAL ENGINEER] Cc: LINUX-390@VM.MARIST.EDU Subject: Re: Encryption again - Question on TKE use to CCA Hi Marcy, when using CCA (i.e. the TKE is configured to communicate with panel.exe) no authentication will be perfromed. You need neither enter an ID nor a password just click OK. This is not considered insecure because all the catcher does is to forward signed requests to the crypto adapter. For EP11 (i.e. if the TKE is configured to communicate with the ep11TKEd) it must a Linux user and password configured for the ep11TKEd as described here https://www.ibm.com/support/knowledgecenter/linuxonibm/com.ibm.linux.z.lxce/lxce_installing_hostpart.html (The default setting is to allow any user that has a password configured and is member of the ep11tke group to gain access through the ep11TKEd daemon.) Mit freundlichen Grüßen/Best Regards/Cordialement Reinhard Dr. Reinhard Bündgen Product Owner Security Linux on Z Linux on Z Development Mail:buend...@de.ibm.com<mailto:buend...@de.ibm.com> Phone: ++49-(0)7031-16-1130 Fax: ++49-(0)7031-16-3456 IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Matthias Hartmann Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 - Original message - From: Marcy Cortes mailto:marcy.d.cor...@wellsfargo.com>> Sent by: Linux on 390 Port mailto:LINUX-390@VM.MARIST.EDU>> To: LINUX-390@VM.MARIST.EDU<mailto:LINUX-390@VM.MARIST.EDU> Cc: Subject: [EXTERNAL] Encryption again - Question on TKE use to CCA Date: Thu, Sep 24, 2020 12:11 AM In this doc http://public.dhe.ibm.com/software/dw/linux390/docu/l91xct00.pdf page 13, what are these credentials? Where are they defined? Marcy This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu<mailto:lists...@vm.marist.edu> with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
