Re: CPACF for TN3270 encryption
there is a relatively new red piece on how to configure TLS with tn3270: IBM z/OS IBM Personal Communications TTLS Enablement at http://www.redbooks.ibm.com/redpapers/pdfs/redp5538.pdf ITschak On Sat, Nov 9, 2019 at 4:08 AM Greg Boyd wrote: > System SSL (aka TLS) will work without ICSF being active and without CEX > cards being available. You may not like the performance and some functions > (i.e. specifically ECC) may not work. Elliptic Curve (ECC) requires that > CEX cards are available and ICSF is active, to drive those operations to > the card. > > Keep in mind that TLS (and System SSL) have two phases: > > The handshake phase performs authentication and requires public/private > keys which relies on either CEX cards or software routines. A low number > of handshakes per second can be handled in software, but if you have any > volume, having the cards can provide a significant savings in MIPS as well > as helping performance. Handshakes also do some hashing, which is done on > the CPACF (ICSF is not required on the latest versions of z/OS). > > The record phase uses symmetric encryption to protect the data and hashing > for integrity. The symmetric encryption is done on the CPACF, if you are > using DES/TDES or AES (if that is what is negotiated). Long ago, ICSF had > to be active to do AES, if you were running on a machine that didn't > support AES on the CPACF hardware ... circa z/890 and z990. But ICSF is > not required on the latest versions of z/OS, System SSL uses the native > crypto instructions on the CPACF. Hashing for the record phase is also > done on the CPACF (no ICSF required, on current versions of z/OS) if you > are using SHA-1, SHA-2. > > Greg Boyd > Mainframe Crypto > www.mainframecrypto.com > > > On Fri, 8 Nov 2019 01:05:42 -0600, Barbara Nitz wrote: > > >> Do we need ICSF to be running while implementing ATTLS ? > >I ran AT-TLS on a 2.1 RDT system *without* ICSF without a problem. And it > was for more than just TN3270 traffic at TLS 1.2. I haven't tried at a > higher z/OS level, but I don't think you need ICSF. > > > >Regards, Barbara > > > >-- > >For IBM-MAIN subscribe / signoff / archive access instructions, > >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for Legacy **| * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPACF for TN3270 encryption
System SSL (aka TLS) will work without ICSF being active and without CEX cards being available. You may not like the performance and some functions (i.e. specifically ECC) may not work. Elliptic Curve (ECC) requires that CEX cards are available and ICSF is active, to drive those operations to the card. Keep in mind that TLS (and System SSL) have two phases: The handshake phase performs authentication and requires public/private keys which relies on either CEX cards or software routines. A low number of handshakes per second can be handled in software, but if you have any volume, having the cards can provide a significant savings in MIPS as well as helping performance. Handshakes also do some hashing, which is done on the CPACF (ICSF is not required on the latest versions of z/OS). The record phase uses symmetric encryption to protect the data and hashing for integrity. The symmetric encryption is done on the CPACF, if you are using DES/TDES or AES (if that is what is negotiated). Long ago, ICSF had to be active to do AES, if you were running on a machine that didn't support AES on the CPACF hardware ... circa z/890 and z990. But ICSF is not required on the latest versions of z/OS, System SSL uses the native crypto instructions on the CPACF. Hashing for the record phase is also done on the CPACF (no ICSF required, on current versions of z/OS) if you are using SHA-1, SHA-2. Greg Boyd Mainframe Crypto www.mainframecrypto.com On Fri, 8 Nov 2019 01:05:42 -0600, Barbara Nitz wrote: >> Do we need ICSF to be running while implementing ATTLS ? >I ran AT-TLS on a 2.1 RDT system *without* ICSF without a problem. And it was >for more than just TN3270 traffic at TLS 1.2. I haven't tried at a higher z/OS >level, but I don't think you need ICSF. > >Regards, Barbara > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPACF for TN3270 encryption
> Do we need ICSF to be running while implementing ATTLS ? I ran AT-TLS on a 2.1 RDT system *without* ICSF without a problem. And it was for more than just TN3270 traffic at TLS 1.2. I haven't tried at a higher z/OS level, but I don't think you need ICSF. Regards, Barbara -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPACF for TN3270 encryption
Not quite. FTP is fully capable of transmitting datasets with the correct options. That, however, is for z/OS<->z/OS, not for z/OS<->PC. If you need to transmit RECFM=U to a PC then you must encapsulate with, e.g., terse, xmit, zip. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of R.S. Sent: Thursday, November 7, 2019 12:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: CPACF for TN3270 encryption IMHO the problem is with using file utilities for datasets. File - understood as MS-DOS, unix or Windows file - it is just (ordered) set of bytes. No internal structure like blocks or records. File formats like XLS, TXT, DOC are interpretation of some applications, it is not visible Dataset - set of block which may contain records. Structure, which is lost every time you transfer dataset from host to PC or when you transfer from host ...to host using file oriented tool like ftp. Note when you download a dataset from host, i.e. using IND$FILE or ftp, you always convert dataset to PC file. That could mean EBCDIC-ASCII translation or not, but it always mean lost of dataset format. So, when you want to upload the file to host again you have to provide "metadata" like FB 80 or so. Othwerwise you'll get corrupt file - the content is almost the same, but records are not. Of course ftp or IND$FILE can handle FB dataset with no problem, it also can handle VB datasets (in many cases). However RECFM=U datasets are (for my humble knowledge) simply not handled properly. Excepions may happen, but I never seen them. Nor working procedure how to transfer RECFM=U dataset. Remarks: 1. It has nothing to do with ADRDSSU. It is not problem of DSS, it is just problem with RECFM=U, regardless of the tool which created dataset. 2. Usually the simplest solution of to "pack" RECFM=U dataset to some FB dataset. Methods are TERSE or just XMIT. In both cases you get some FB dataset, which can be downloaded from host to PC file and then uploaded from PC file to host *with some additional information* about RECFM and LRECL. 3. Maybe there are other tricks or methods. I'm glad to learn them. -- Radoslaw Skorupka Lodz, Poland == 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,http://secure-web.cisco.com/1FTw09qld-N8zQpEvCmo4fAvgIopLKkR6aONnHTOJwsEQt730yCga9YmEcJn_rQHKFuzH8qJKIfOTifPrsbBuaQu3eLja4Mc4LlJHfqQPn791DStvCYJX6ltlKTs8pXYmZ8pv5JMMahxGRd3BRs-LdIo0HoaSaY6b4tHqxev-FykDgmMC82mgxRazmpEvpn8n4zd2eBkTZk1eKoqOcVTU_VPwCCR5YabhACOqIErM9cplOrT80Y2m1d44g97z2EZCbzPJD_otZGu073quUyblj_9HKXVAfJSCsSTEk6mmPvA18ydn9sI_Ce1ek8ZhmCndxQv-aGsbNQCUx1FOe9N-MXrLhZntsCMPrlnF2xUqKcyFgNubN1OsVPjHDK7V-GAD/http%3A%2F%2Fwww.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2019 r. wynosi 169.347.928 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,http://secure-web.cisco.com/1FTw09qld-N8zQpEvCmo4fAvgIopLKkR6aONnHTOJwsEQt730yCga9YmEcJn_rQHKFuzH8qJKIfOTifPrsbBuaQu3eLja4Mc4LlJHfqQPn791DStvCYJX6ltlKTs8pXYmZ8pv5JMMahxGRd3BRs-LdIo0HoaSaY6b4tHqxev-FykDgmMC82mgxRazmpEvpn8n4zd2eBkTZk1eKoqOcVTU_VPwCCR5YabhACOqIErM9cplOrT80Y2m1d44g97z2EZCbzPJD_otZGu073quUyblj_9HKXVAfJSCsSTEk6mmPvA18ydn9sI_Ce1ek8ZhmCndxQv-aGsbNQCUx1FOe9N-MXrLhZntsCMPrlnF2xUqKcyFgNubN1OsVPjHDK7V-GAD/http%3A%2F%2Fwww.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.347.928 as at 1 January 2019. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu
Re: CPACF for TN3270 encryption
IMHO the problem is with using file utilities for datasets. File - understood as MS-DOS, unix or Windows file - it is just (ordered) set of bytes. No internal structure like blocks or records. File formats like XLS, TXT, DOC are interpretation of some applications, it is not visible Dataset - set of block which may contain records. Structure, which is lost every time you transfer dataset from host to PC or when you transfer from host ...to host using file oriented tool like ftp. Note when you download a dataset from host, i.e. using IND$FILE or ftp, you always convert dataset to PC file. That could mean EBCDIC-ASCII translation or not, but it always mean lost of dataset format. So, when you want to upload the file to host again you have to provide "metadata" like FB 80 or so. Othwerwise you'll get corrupt file - the content is almost the same, but records are not. Of course ftp or IND$FILE can handle FB dataset with no problem, it also can handle VB datasets (in many cases). However RECFM=U datasets are (for my humble knowledge) simply not handled properly. Excepions may happen, but I never seen them. Nor working procedure how to transfer RECFM=U dataset. Remarks: 1. It has nothing to do with ADRDSSU. It is not problem of DSS, it is just problem with RECFM=U, regardless of the tool which created dataset. 2. Usually the simplest solution of to "pack" RECFM=U dataset to some FB dataset. Methods are TERSE or just XMIT. In both cases you get some FB dataset, which can be downloaded from host to PC file and then uploaded from PC file to host *with some additional information* about RECFM and LRECL. 3. Maybe there are other tricks or methods. I'm glad to learn them. -- Radoslaw Skorupka Lodz, Poland == 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 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2019 r. wynosi 169.347.928 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 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.347.928 as at 1 January 2019. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPACF for TN3270 encryption
On 11/7/2019 9:49 AM, Jake Anderson wrote: Do we need ICSF to be running while implementing ATTLS ? Jake, Yes. Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPACF for TN3270 encryption
Do we need ICSF to be running while implementing ATTLS ? On Wed, 30 Oct, 2019, 2:22 PM Mike Wawiorko, < 014ab5cdfb21-dmarc-requ...@listserv.ua.edu> wrote: > 3270 with SSL/TLS is implemented in System SSL - if you really need to > know more I'd read up on that. > > Another PAGENT policy function IPSEC tunnels does have the option for ZIIP > assist so if you're running 3270 or other traffic within tunnels you may be > using ZIIP. > > Mike Wawiorko > This e-mail and any attachments are confidential and intended solely for > the addressee and may also be privileged or exempt from disclosure under > applicable law. If you are not the addressee, or have received this e-mail > in error, please notify the sender immediately, delete it from your system > and do not copy, disclose or otherwise act upon any part of this e-mail or > its attachments. > Internet communications are not guaranteed to be secure or virus-free. The > Barclays Group does not accept responsibility for any loss arising from > unauthorised access to, or interference with, any Internet communications > by any third party, or from the transmission of any viruses. Replies to > this e-mail may be monitored by the Barclays Group for operational or > business reasons. > Any opinion or other information in this e-mail or its attachments that > does not relate to the business of the Barclays Group is personal to the > sender and is not given or endorsed by the Barclays Group. > Barclays Execution Services Limited provides support and administrative > services across Barclays group. Barclays Execution Services Limited is an > appointed representative of Barclays Bank UK plc, Barclays Bank plc and > Clydesdale Financial Services Limited. Barclays Bank UK plc and Barclays > Bank plc are authorised by the Prudential Regulation Authority and > regulated by the Financial Conduct Authority and the Prudential Regulation > Authority. Clydesdale Financial Services Limited is authorised and > regulated by the Financial Conduct Authority. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPACF for TN3270 encryption
3270 with SSL/TLS is implemented in System SSL - if you really need to know more I'd read up on that. Another PAGENT policy function IPSEC tunnels does have the option for ZIIP assist so if you're running 3270 or other traffic within tunnels you may be using ZIIP. Mike Wawiorko This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Execution Services Limited provides support and administrative services across Barclays group. Barclays Execution Services Limited is an appointed representative of Barclays Bank UK plc, Barclays Bank plc and Clydesdale Financial Services Limited. Barclays Bank UK plc and Barclays Bank plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. Clydesdale Financial Services Limited is authorised and regulated by the Financial Conduct Authority. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPACF for TN3270 encryption
Jake Anderson asked: >Is it possible to encrypt TN3270 connectivity using CPACF ? And then later added: >We got this feature along with our z14 so wanted to make use of this and am >not sure if PAGENT traffic can be offloaded to zIIP Just to be clear: CPACF is crypto in the chip (much like Intel AES-NI), has nothing to do with zIIP. Not clear whether you were thinking they were related. As Radoslaw noted, it can be hard to tell where encryption is happening, but my expectation would be that whatever is doing your TN3270 encryption would use CPACF if available. If it's not, it's pretty primitive; CPACF has been around at least a decade, things really should be using it by now. .phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPACF for TN3270 encryption
We got this feature along with our z14 so wanted to make use of this and am not sure if PAGENT traffic can be offloaded to zIIP On Tue, 29 Oct, 2019, 9:26 PM R.S., wrote: > Michael, > It's not so easy. > You use encrypted communication. That's what you know. > However you don't know what hardware is used for enciphering/deciphering > data. > I'm rather sure that it is NOT CryptoExpress card (let's omit > handshaking). Note, CPACF is not CryptoExpress. You can have CPACF and > no CryptoExpress cards. You cannot have CryptoExpress cards without > CPACF, but this is not interesting in this case. > However sometimes it is not worth to use crypto hardware for very small > data blocks. Like in terminal communication. In such case it can be > software algorithm, which means CPU cycles. Or not, because AFAIK it can > be offloaded to zIIP. > > -- > Radoslaw Skorupka > Lodz, Poland > > > > > > > W dniu 2019-10-29 o 10:47, Michael Babcock pisze: > > I can’t say I’m 100% sure but highly suspect it does. We don’t have our > > crypto express cards configured yet so I know it’s not using them. > > > > On Tue, Oct 29, 2019 at 4:44 AM Jake Anderson > > wrote: > > > >> "We use Rockets’s Bluezone for our 3270 emulator and all 3270 traffic > uses > >> TLS 1.2 via IBM’s policy agent" > >> > >> All its workload goes to CPACF ? > >> > >> On Tue, 29 Oct, 2019, 1:42 PM Michael Babcock, > >> wrote: > >> > >>> We use Rockets’s Bluezone for our 3270 emulator and all 3270 traffic > uses > >>> TLS 1.2 via IBM’s policy agent. > >>> > >>> On Tue, Oct 29, 2019 at 4:03 AM Jake Anderson < > justmainfra...@gmail.com> > >>> wrote: > >>> > Hi > > Is it possible to encrypt TN3270 connectivity using CPACF ? > > Just trying to understand its functionality and has anyone tried this > functionality implementated for TN3270 connectivity. > > Jake > > > > > == > > 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 025237, NIP: > 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na > 01.01.2019 r. wynosi 169.347.928 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 025237, NIP: 526-021-50-88. Fully paid-up share capital > amounting to PLN 169.347.928 as at 1 January 2019. > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPACF for TN3270 encryption
Michael, It's not so easy. You use encrypted communication. That's what you know. However you don't know what hardware is used for enciphering/deciphering data. I'm rather sure that it is NOT CryptoExpress card (let's omit handshaking). Note, CPACF is not CryptoExpress. You can have CPACF and no CryptoExpress cards. You cannot have CryptoExpress cards without CPACF, but this is not interesting in this case. However sometimes it is not worth to use crypto hardware for very small data blocks. Like in terminal communication. In such case it can be software algorithm, which means CPU cycles. Or not, because AFAIK it can be offloaded to zIIP. -- Radoslaw Skorupka Lodz, Poland W dniu 2019-10-29 o 10:47, Michael Babcock pisze: I can’t say I’m 100% sure but highly suspect it does. We don’t have our crypto express cards configured yet so I know it’s not using them. On Tue, Oct 29, 2019 at 4:44 AM Jake Anderson wrote: "We use Rockets’s Bluezone for our 3270 emulator and all 3270 traffic uses TLS 1.2 via IBM’s policy agent" All its workload goes to CPACF ? On Tue, 29 Oct, 2019, 1:42 PM Michael Babcock, wrote: We use Rockets’s Bluezone for our 3270 emulator and all 3270 traffic uses TLS 1.2 via IBM’s policy agent. On Tue, Oct 29, 2019 at 4:03 AM Jake Anderson wrote: Hi Is it possible to encrypt TN3270 connectivity using CPACF ? Just trying to understand its functionality and has anyone tried this functionality implementated for TN3270 connectivity. Jake == 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 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2019 r. wynosi 169.347.928 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 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.347.928 as at 1 January 2019. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPACF for TN3270 encryption
Try this aging SHARE presentation from 2014. You'll probably find a more recent one if your search the web or SHARE. https://share.confex.com/share/123/webprogram/Handout/Session15660/SharePittsburgh15660_Aug2014_System_SSL_And_Crypto.pdf Mike Wawiorko This e-mail and any attachments are confidential and intended solely for the addressee and may also be privileged or exempt from disclosure under applicable law. If you are not the addressee, or have received this e-mail in error, please notify the sender immediately, delete it from your system and do not copy, disclose or otherwise act upon any part of this e-mail or its attachments. Internet communications are not guaranteed to be secure or virus-free. The Barclays Group does not accept responsibility for any loss arising from unauthorised access to, or interference with, any Internet communications by any third party, or from the transmission of any viruses. Replies to this e-mail may be monitored by the Barclays Group for operational or business reasons. Any opinion or other information in this e-mail or its attachments that does not relate to the business of the Barclays Group is personal to the sender and is not given or endorsed by the Barclays Group. Barclays Execution Services Limited provides support and administrative services across Barclays group. Barclays Execution Services Limited is an appointed representative of Barclays Bank UK plc, Barclays Bank plc and Clydesdale Financial Services Limited. Barclays Bank UK plc and Barclays Bank plc are authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. Clydesdale Financial Services Limited is authorised and regulated by the Financial Conduct Authority. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPACF for TN3270 encryption
I can’t say I’m 100% sure but highly suspect it does. We don’t have our crypto express cards configured yet so I know it’s not using them. On Tue, Oct 29, 2019 at 4:44 AM Jake Anderson wrote: > "We use Rockets’s Bluezone for our 3270 emulator and all 3270 traffic uses > TLS 1.2 via IBM’s policy agent" > > All its workload goes to CPACF ? > > On Tue, 29 Oct, 2019, 1:42 PM Michael Babcock, > wrote: > > > We use Rockets’s Bluezone for our 3270 emulator and all 3270 traffic uses > > TLS 1.2 via IBM’s policy agent. > > > > On Tue, Oct 29, 2019 at 4:03 AM Jake Anderson > > wrote: > > > > > Hi > > > > > > Is it possible to encrypt TN3270 connectivity using CPACF ? > > > > > > Just trying to understand its functionality and has anyone tried this > > > functionality implementated for TN3270 connectivity. > > > > > > Jake > > > > > > -- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > -- > > Michael Babcock > > OneMain Financial > > z/OS Systems Programmer, Lead > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPACF for TN3270 encryption
"We use Rockets’s Bluezone for our 3270 emulator and all 3270 traffic uses TLS 1.2 via IBM’s policy agent" All its workload goes to CPACF ? On Tue, 29 Oct, 2019, 1:42 PM Michael Babcock, wrote: > We use Rockets’s Bluezone for our 3270 emulator and all 3270 traffic uses > TLS 1.2 via IBM’s policy agent. > > On Tue, Oct 29, 2019 at 4:03 AM Jake Anderson > wrote: > > > Hi > > > > Is it possible to encrypt TN3270 connectivity using CPACF ? > > > > Just trying to understand its functionality and has anyone tried this > > functionality implementated for TN3270 connectivity. > > > > Jake > > > > -- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > -- > Michael Babcock > OneMain Financial > z/OS Systems Programmer, Lead > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPACF for TN3270 encryption
We use Rockets’s Bluezone for our 3270 emulator and all 3270 traffic uses TLS 1.2 via IBM’s policy agent. On Tue, Oct 29, 2019 at 4:03 AM Jake Anderson wrote: > Hi > > Is it possible to encrypt TN3270 connectivity using CPACF ? > > Just trying to understand its functionality and has anyone tried this > functionality implementated for TN3270 connectivity. > > Jake > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Michael Babcock OneMain Financial z/OS Systems Programmer, Lead -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CPACF for TN3270 encryption
Yes, if you use the policy agent (PAGENT). ITschak On Tue, Oct 29, 2019 at 11:03 AM Jake Anderson wrote: > Hi > > Is it possible to encrypt TN3270 connectivity using CPACF ? > > Just trying to understand its functionality and has anyone tried this > functionality implementated for TN3270 connectivity. > > Jake > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for Legacy **| * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
